[Data-modeling] Awards refactoring

[Jeff Prucher]

Logically, I'd say that either class of awards can be called "award", and
common use, even by the awards presenters, supports this. But I think common
usage also supports refering to the specific awards as "categories". Some
evidence:

http://www.oscar.com/nominees/ (note "jump to a category" in left column)
http://www.worldcon.org/hc.html
http://www.pulitzer.org/history.html (search for the word "category")
http://www.emmys.org/awards/awardsearch.php

I couldn't find any other names for the general award type other than just
"award".

Jeff P.


> -----Original Message-----
> From: data-modeling-bounces at freebase.com 
> [mailto:data-modeling-bounces at freebase.com] On Behalf Of 
> Kirrily Robert
> Sent: Tuesday, April 08, 2008 7:00 PM
> To: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] Awards refactoring
> 
> I don't know.  I think of a "category" as a grouping of 
> things rather than a specific thing.  Therefore, I would 
> think that "Academy Award" was a category of award, and 
> "Academy Award for Best Actor" would be a specific award.
> 
> K.
> 
> ----- "Faye Li" <faye at metaweb.com> wrote:
> > 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
> > >
> > >   
> > 
> > _______________________________________________
> > Data-modeling mailing list
> > Data-modeling at freebase.com
> > http://lists.freebase.com/mailman/listinfo/data-modeling
> 
> 
> --
> Kirrily Robert
> Freebase Community Director
> kirrily at metaweb.com
> 
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>