[Developers] [Data-modeling] Awards refactoring

[Jeff Prucher]

Since I haven't heard any objections to this, I'm going to go ahead and make
these changes (rename "award" to "award category", add a new type "award",
and switch the keys around) on Thursday of this week (4/17). Please jump up
and down and shout loudly if this will break any code that you're using.

Thanks,
Jeff Prucher 

> -----Original Message-----
> From: developers-bounces at freebase.com 
> [mailto:developers-bounces at freebase.com] On Behalf Of Faye Li
> Sent: Tuesday, April 08, 2008 5:56 PM
> To: Freebase data modeling mailing list
> Cc: 'For discussions about MQL,Freebase API and apps built on 
> Freebase'
> Subject: Re: [Developers] [Data-modeling] Awards refactoring
> 
> 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
> >
> >   
> 
> _______________________________________________
> Developers mailing list
> Developers at freebase.com
> http://lists.freebase.com/mailman/listinfo/developers
>