Re: Works and instances

The way B&N works is that the minimal metadata describing the work is
entered at what they call "the work level". Important to note that this is
the "work" as defined internally at B&N. The basic criteria were set in
1998 and have not shifted much since then. If a description, review,
annotation, or what have you is good for all editions of the "work", it is
entered at that level. If it is specific to the edition, it is entered at
the edition level. They have a Work_ID, which is internal. Ideally they
would like for the editions to roll up into a single work, but that
requires a reconfiguration of their search engine, which they are not
budgeting for at present.

The lion's share of books can be dealt with via ISTC, but the edge cases
are numerous and troublesome and open to interpretation.

On 1/7/13 1:42 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>
>
>On 1/7/13 8:35 AM, Tom Morris 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.
>
>LT has both work pages and edition pages. Wikipedia is about the
>original work, with information about editions where relevant. Library
>catalogs, which are a prime first use case already exhibited in
>WorldCat, do not have separate work metadata. If we see this as marking
>up library data, the work is not represented. Online bookstores do not
>have separate work metadata, and they are another obvious use case. I do
>not believe that publisher metadata concerns itself with the Work since
>they are selling specific editions (and wouldn't want to link to a rival
>version of the same text). There are few generalizations that you can
>make in this environment that will be true, and particularly that most
>bibliographic data focuses on 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).
>
>This all depends on your definition of Work. Is a user looking for War
>and Peace looking for the work? If so, it would be legitimate to serve
>up a copy of Voyna i Mir or Guerra e Pace if you are defining Work as
>"the same story." In a public library with only works in English there's
>no problem, but in a large research library with all of the translations
>"workness" may not be user friendly even if well-defined and rigorously
>applied. (The user looking for the English version of Voyna i Mir is
>actually looking for the FRBR:Expression.)
>
>A film archivist has said that director's cut would be a different work
>in their environment. Most of us just want to know if it will play in
>our device.
>
>Already in this discussion we have had people state confidently that a
>book and a movie are and are not the same work. So we can see that there
>will be many different definitions of Work, and that not all
>bibliographic metadata sources use the work concept as part of their
>metadata. Obviously use of "instanceOf" or "versionOf" is optional, but
>it appears that it is only useful when there is a metadata description
>for the Work. I still argue that that is a minority case.
>
>kc
>
>>
>>> 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
>>
>
>-- 
>Karen Coyle
>kcoyle@kcoyle.net http://kcoyle.net
>ph: 1-510-540-7596
>m: 1-510-435-8234
>skype: kcoylenet
>

Received on Monday, 7 January 2013 18:52:10 UTC