[Data-modeling] Awards refactoring

[Faye Li]

Jeff - I can't believe you remember my suggesting this -- but that's 
great! :)

In general I agree with you that type key changes should be avoided and 
any change should be made backward-compatible. The exception I'm 
evidently more open to, is when keeping the same key in the interest of 
backward compatibility unintentionally but unabashedly causes forward 
confusion. I can just imagine future discussion threads from users 
puzzled over the fact that the "Award" Type has the key "/award/<insert 
some weird name here>" while "Award Category" has the key 
"/award/award", and then some old-timer from the community will have to 
explain, sheepishly, the "legacy" schema and backward-compatibility 
policy that together produced this awkward design.

So my practical question is, hypothetically, if the type key were to be 
changed to a more logical name, would that break anyone's code? Please 
speak up if this would affect you. I see a trade-off between supporting 
our current community now and avoiding confusing future users (which 
dare I say number much higher than they do now...), and I think to 
evaluate that, the missing piece of information of actual impact of a 
key change must be known.

-- Faye


Jeff Prucher wrote:
> I'm cross-posting to the developers list because this proposal touches on
> the type keys in the awards domain, which might affect developers.
>
> There is a problem in the current awards schema. There is no way to group
> categories of awards together under the same general award. For example,
> there are topics for every Academy Award category (best picture, best
> original screenplay, etc.) of type "award", but there is no way to assert
> that all these awards are the same sort of award. So if you want to know
> which picture has won the most Academy Awards, you have to query against
> every academy award topic, do some kind of string matching against the topic
> name, or go by the awarding organization. (This last one wouldn't work,
> actually -- different Nobels are technically awarded by different groups,
> and some organizations sponsor multiple awards.)
>
> So I'm proposing (well, this was Faye's idea, really) that we add a new type
> that will connect to both "award" and "award presenting organization". This
> would ordinarily be a very simple thing to do. The problem is with the
> nomenclature. From a practical standpoint, the new type (i.e., for the
> general "Academy Award") should be called simply "award", and the old type
> (i.e., for the specific category, "Academy Award for Best Foo") should be
> renamed "award category". I'm pretty satisfied with making that change, but
> I'd like to hear other suggestions.
>
> My main concern with the naming I'm proposing is that the type keys might be
> a problem. The type "award category" (formerly known as "award") has a key
> of /award/award. The new type "award" can't use that, since keys are unique,
> so it would have to have some weirdly-named key. This is doable, just
> inelegant and probably confusing to anyone who tries to write queries using
> the keys. The alternative would be to move the /award/award key to the new
> "award" and create a new key for "award category", but this would completely
> break any code that uses this schema, which is not something I'm too keen on
> doing.
>
> The Academy Awards (type = award):
> http://sandbox.freebase.com/view/en/academy_awards
>
> Academy Award for Best Director (type = award category):
> http://sandbox.freebase.com/view/en/academy_award_for_best_director
>
> The Academy of Motion Picture Arts & Sciences (type= award presenting
> organization)
> http://sandbox.freebase.com/view/en/academy_of_motion_picture_arts_and_scien
> ces
>
> Thoughts on how best to proceed?
>
> Jeff Prucher
> Type Librarian & Ontologist
> Metaweb Technologies, Inc. 
>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
>