Re: Works and instances

Agreed.

On 1/7/13 12:16 PM, "Philip Schreur" <pschreur@stanford.edu> wrote:

>Just a few comments to throw into the mix.  I think that we have to
>remember that even though a machine will be making use of the metadata,
>a wide variety of humans (most likely) with varying skills will be
>assigning it.    Whatever the schema is, it will have to be simple and
>clear enough to use or the end result will not be helpful.  We'll also
>be interested in not only linking related things, but NOT linking things
>which look related but aren't (in an automated way).  The ability to do
>both will be crucial.
>
>Phil
>
>On 1/7/2013 8:39 AM, Laura Dawson wrote:
>> When I was at Muze (now Rovi), which aggregates data about books, music,
>> movies, and video games, we used the example of "The Godfather", which
>>is
>> a book, a soundtrack, several movies, and a video game. We wanted to
>> define the concept/story of "The Godfather" uniquely, and branch out by
>> type of product from that.
>>
>> This became massively problematic very quickly (significant differences
>> between book and movie(s), video game does not really adhere to the
>>plot),
>> and we never did get One Database To Rule Them All. We certainly spent a
>> lot of time circling the drain, though.
>>
>> On 1/7/13 11:35 AM, "Tom Morris"<tfmorris@gmail.com>  wrote:
>>
>>> On Mon, Jan 7, 2013 at 10:56 AM, Karen Coyle<kcoyle@kcoyle.net>  wrote:
>>>
>>>> I'm not questioning whether people have
>>>> a notion of "work". I'm saying that I don't think that there will be
>>>> much
>>>> metadata for Work alone, at least not yet.
>>> I think that depends a lot on the source of your metadata.  If you
>>> start with a dusty book on a shelf somewhere, there may be a limited
>>> amount of Work metadata available (although you could certainly work
>>> out some basics like creator/author), but things like Wikipedia
>>> articles about a book or a GoodReads/LibraryThing page about a book
>>> are going to be almost entirely about the Work.  They'll discuss
>>> things like when it was written, first published, what languages it's
>>> been translated into, what language it was written in originally, etc.
>>> -- all, to my mind, properties of a Work.
>>>
>>> I agree with Richard that most users are going to mostly be searching
>>> for Works, with a final filter of a particular delivery medium ie the
>>> Netflix/DVD/Blu-ray version of the movie or the free e-book version of
>>> the book.  Most of the time they don't care about the stuff in the
>>> middle like which translation of the work it is or whether it's the
>>> director's cut of the movie (although a few will).
>>>
>>>> So your example
>>>> of two books and a movie fits in nicely here. If you want to say that
>>>> they
>>>> are the same work, you could create a Work "record" with an identifier
>>>> using
>>>> schema:creativeWork.
>>> I can't imagine anyone saying that a book and a movie are the same
>>> work.  One could debate at what level of granularity you want to model
>>> the adaptation from book to the Broadway play to the screenplay to the
>>> movie to the remake of the movie to the movie version of the book, but
>>> I don't think there'd be much debate that a movie and a book are
>>> different works.
>>>
>>>> Or you could "daisy chain" them together by saying that
>>>> they represent the same content. This is essentially what OCLC appears
>>>> to do
>>>> in WorldCat -- gathering the records that represent the same work, but
>>>> not
>>>> creating a new description for the work. (I actually think this is how
>>>> FRBR
>>>> *should* deal with works, but since it's based on cataloging rather
>>>>than
>>>> user activity, it takes a different approach.) This allows people to
>>>> create
>>>> work groupings based on their own needs, rather than a top-down
>>>>approach
>>>> where they have to discover a work description to use in order to
>>>> connect
>>>> their bibliographic descriptions.
>>> This is getting into the mechanics of how the data collection is done
>>> which I think is different from how the data is modeled.  Whether a
>>> cataloger selects a work to link to or this information comes from the
>>> publisher or an AI program works it out after OCRing title page is an
>>> "implementation detail."
>>>
>>> Tom
>>>
>>
>>
>
>
>-- 
>Philip E. Schreur
>Head, Metadata Department
>Stanford University
>650-723-2454
>650-725-1120 (fax)
>

Received on Monday, 7 January 2013 18:20:27 UTC