Re: Content-Carrier Proposal

All,

It turns out that I was confusing music and movies. Music cataloging 
does consider the score and each performance different expressions of 
the same work. Movie cataloging considers the screenplay and the movie 
to be different works -- there's an example in an LC training document 
[1]. I don't think this changes our approach. We still have the option 
of hanging audiobook off of book or making it a separate entry under 
creativeWork. If we hang it off of book then we also will need to add it 
to the value list http://schema.org/BookFormatType which so far has
  - eBook
  - hardcover
  - paperback

Then there is the question of abridgement. I don't think this is the 
information intended for Version in creativeWork, but the definition of 
that is quite terse. In /Book there is "bookEdition" which I suppose 
could contain this information. Note that there are abridged versions of 
texts as well as audio readings, but there are also many other types of 
information that one could consider for editions, like annotated 
editions, illustrated editions, adapted versions (e.g. for children), etc.

I looked into ONIX, although I can't guarantee that I found all the 
right places in that complex documentation. If you haven't ever looked 
at the ONIX code lists -- do take a look. [2] ONIX makes MARC look 
abbreviated. In the set of lists for ONIX for Books, list 81 is the 
"Product type" and "Audiobook" is one of those product types. So is 
"game" "musical recording" "software" and other things that go beyond 
books... so I'm not sure this helps us.


We also will need a property for the narrator/reader. ONIX uses "Read 
by" rather than "Narrator", although the audible.com site displays 
"Narrator" so that's what I'm used to seeing. I think we should use what 
ONIX uses since that will be what the audiobook providers are used to. 
Plus, it seems clear. I did not find a specific term in the MARC relator 
list.[3]

I will draft up "audiobook" under creativeWork and see how it goes. If 
we don't like it, we can try the other way.

kc

p.s. And we haven't even gotten to the hard stuff yet: serials! EEEK!

[1] 
http://www.loc.gov/marc/marc-functional-analysis/multiple-versions.html#english-patient
[2] http://www.editeur.org/ONIX/book/codelists/current.html
[3] http://loc.gov/marc/relators/relaterm.html

On 2/7/13 9:09 AM, Karen Coyle wrote:
> Difference between an audiobook and a book or ebook is the same as the
> difference between a recording of a symphony and the printed score for
> that symphony. The audiobook is a performance; it has a performer; it
> has a separate copyright; it may be abridged; other liberties may have
> been taken. An ebook is a new carrier for the same text as the paper
> book. It (presumably) has the same words (and thus same ISTC), same
> copyright, same list of creators. I see book/ebook as a classic
> content/carrier difference. I see book/audiobook as a larger difference
> than a carrier change.
>
> I believe that music folks would consider a score and a performance to
> be different FRBR:Works. Two different performances would be different
> expressions. However, audiobook is probably the same Work in the minds
> of most users, albeit different expressions. So calling it both a "Book"
> and an "Audiobook" makes sense to me. But it will need *at least* one
> additional field for performer. It turns out that in public libraries
> (and on audiobook sites online) users are as interested in the performer
> as they are the actual author of the text. There are folks who would
> listen to a grocery list if it were read by Simon Prebble ;-).
>
> kc
>
> On 2/7/13 7:52 AM, Richard Wallis wrote:
>> Karen,
>>
>> I don't think it is a format property we are talking about.  I don’t
>> think it is about the arbitrary separation of attributes in to Content
>> or Carrier
>>
>> We are trying, in this approach, to identify the sum of basic types of
>> thing that the composite thing we are describing is.
>>
>> So sticking with our example of an audiobook in WMA format on a CD :
>>
>>   * It is a CreativeWork
>>   * It may be considered a Book
>>   * It is an AudioBook
>>   * It is WMA
>>   * It is a CD
>>   * It has the attributes of a MediaObject
>>
>>
>> Summing together the properties you get from picking one of those as the
>> main type (some might choose CD, others Audiobook, or Book – all valid
>> ways to describe our thing) and adding the remainder as additionalType
>> properties.   Which elements are then not available to describe it that
>> you think are missing?
>>
>> You may be right that an audiobook is something that deserves its own
>> sub-type of Book – in which case does Ebook?  Or do we just recommend a
>> new BookFormatType - the current Schema answer for Ebook is to do just
>> that which delivers no extra properties to describe the Ebook specific
>> attributes.
>>
>> ~Richard.
>>
>>
>>
>> On 07/02/2013 13:30, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>
>>> I'm fine with tossing in a whole list of "types", but I don't see what
>>> this has to do with content/carrier if it can contain both. So maybe
>>> what we're talking about here, instead, is a more general "format"? And
>>> it would include "book" "picture book" "large print" "MP3" "movie"
>>> "BlueRay" "Operetta" "Map" and whatever else? If so, I would rename the
>>> page to reflect that.
>>>
>>> Also, audio book is going to need some very specific data elements that
>>> we don't have yet in schema.org. So I still maintain that audiobook is
>>> its own thing, not just an additional format on metadata for a book.
>>>
>>> kc
>>>
>>> On 2/7/13 4:39 AM, Laura Dawson wrote:
>>>> This is essentially how it is accomplished in ONIX as well. There's a
>>>> series of composite tags that can describe the "format" quite
>>>> adequately.
>>>>
>>>> From: Richard Wallis <richard.wallis@oclc.org
>>>> <mailto:richard.wallis@oclc.org>>
>>>> Date: Thursday, February 7, 2013 5:27 AM
>>>> To: Karen Coyle <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>,
>>>> <public-schemabibex@w3.org <mailto:public-schemabibex@w3.org>>
>>>> Subject: Re: Content-Carrier Proposal
>>>> Resent-From: <public-schemabibex@w3.org
>>>> <mailto:public-schemabibex@w3.org>>
>>>> Resent-Date: Thu, 07 Feb 2013 10:29:17 +0000
>>>>
>>>> Re: Content-Carrier Proposal
>>>> Sticking with the Product Ontology approach for a moment – an audiobook
>>>> in WMA on a cd would just be a combination of multiple types thus:
>>>>
>>>> http://schema.org/Book
>>>>     additionalType:http://www.productontology.org/id/Audiobook
>>>>     additionalType:http://www.productontology.org/id/
>>>> Windows_Media_Audio
>>>>     additionalType:http://www.productontology.org/id/ Compact_Disc
>>>>
>>>> The sub-types of MeadiaObject, as you suggest, may also be fertile
>>>> ground for other types to combine. So by adding:
>>>>
>>>>     additionalType:http://schema.org/ MeadiaObject
>>>>
>>>> To the example above, you could utilise the duration, region, etc.
>>>> properties that come with it to helpfully expand the description.
>>>>
>>>> I think part of the issue is the natural [librarian] urge to identify
>>>> what is content and what is carrier.  In some of the examples we are
>>>> discussing there are three or more elements – audiobook, mp3, CD –
>>>> film,
>>>> iso file, DVD – resulting in confusion about what to do with the middle
>>>> ones.  Personally I believe trying to enforce that categorisation of
>>>> attributes is not helpful.   MP3, paperback, European region DRM
>>>> protected, DVD, punched card, Kindle format, and/or a box set are all,
>>>> often, cumulative attributes of equal weight and importance.
>>>>
>>>> Within the library metadata community, deciding what are content vs
>>>> what
>>>> are carrier attributes has been a topic of of much, often inconclusive,
>>>> discussion that surfaces as each new format, device or encoding
>>>> emerges.
>>>>   I get the feeling that whatever is decided, the rest of the world
>>>> just
>>>> treats them as attributes of the thing.  Libraries have used these
>>>> categorisations to help them build [facets in] user interfaces, which
>>>> they could continue to do based on their local practices, but without
>>>> enforcing that view on the non-library consumers of bib data.
>>>>
>>>> So what I am trying to say in my long-winded way is that I don’t
>>>> believe
>>>> we need content/carrier specific properties adding to Schema.org types
>>>> to adequately describe these features.  We can achieve the same by
>>>> using
>>>> the additionalType property, combining schema types onto CreativeWork
>>>> sub-types, and external types such as those sourced from
>>>> productontology.org, to build a description of the thing in question.
>>>>
>>>> ~Richard.
>>>>
>>>> On 05/02/2013 19:25, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>>>>
>>>>     I've looked again at the content-carrier proposal and I believe
>>>> that it
>>>>     confounds content and carrier, so maybe we need a bit more
>>>>     clarification.
>>>>
>>>>     The proposal uses "audiobook on CD" for carrier. Clearly, however,
>>>>     "audiobook" is a creative work with producers, a reader (very
>>>> important
>>>>     - audio book readers are becoming famed for their performances),
>>>> a date
>>>>     of creation, not to mention information like "abridged/un
>>>> abridged" and
>>>>     separate copyrights. An audiobook can have a number of carriers,
>>>>     including being digital in WMA or MP3 format, with or without
>>>>     specific DRM.
>>>>
>>>>     Carrier needs to be defined much like mime types -- very strictly
>>>>     limited to the physical form or digital encoding of the content,
>>>> but not
>>>>     the content genre. If this makes sense to folks, then perhaps we
>>>> can
>>>>     come up with a shared definition and some examples.
>>>>
>>>>     The difficulty, as I see it, is with the combination of physical
>>>> carrier
>>>>     ("Compact Disc") and encoding ("MP3 w. Overdrive DRM"). To what
>>>> extent
>>>>     can we make assumptions that a "CD" is a "CD" for all purposes? For
>>>>     example, with DVDs, there are those horrid region codes that you
>>>> must
>>>>     specify or people don't know if they can play the DVD in their
>>>> player.
>>>>     So "DVD" alone does not define the encoded DRM; instead, there
>>>> are two
>>>>     parts: physical carrier (DVD) and encoding (region-limited DRM).
>>>> Or I
>>>>     can copy a large file to DVD that is a .iso file. Are these both
>>>>     carrier?
>>>>
>>>>     We might want to look at the sub-types of
>>>> http://schema.org/MediaObject
>>>>
>>>>     These appear to be intended only for online/embedded media, but
>>>> probably
>>>>     have some overlap with our case.
>>>>
>>>>     kc
>>>>
>>>>     On 2/4/13 4:22 AM, Ivan Herman wrote:
>>>>> Richard,
>>>>>
>>>>> as also discussed off-line, I changed the microdata/RDFa coding a
>>>>> bit. The
>>>>> previous solution in microdata was
>>>>>
>>>>> <span property="additionalType" href="..." >
>>>>>
>>>>> but that is invalid HTML5 (@href can appear on <link> and <a> elements
>>>>> only). I added <link> to the encoding instead (microdata allows the
>>>>> usage of
>>>>> <link> anywhere, not only in the header).
>>>>>
>>>>> I have also changed the RDFa part to be more in line with that
>>>>> version of
>>>>> microdata by folding the type specification into @typeof directly
>>>>> (RDFa
>>>>> allows that, the usage of explicit rdf:type or
>>>>> schema:additionalType is,
>>>>> though correct, unnecessary...)
>>>>>
>>>>> Cheers
>>>>>
>>>>> Ivan
>>>>>
>>>>> On Feb 2, 2013, at 22:04 , Richard Wallis <richard.wallis@oclc.org>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I have just added a Content-Carrier proposal to the Wiki.
>>>>>>
>>>>>> It does not propose extension of the vocabulary as such, but I
>>>>>> have linked
>>>>>> it from the Vocabulary Proposals page
>>>>>> <http://www.w3.org/community/schemabibex/wiki/Vocabulary_Proposals>
>>>>     as it is a proposal as to a recommended way to apply the current
>>>>     vocabulary to address an issue that concerns this group.
>>>>>>
>>>>>>
>>>>>> ~Richard.
>>>>>
>>>>>
>>>>> ----
>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>> Home:http://www.w3.org/People/Ivan/
>>>>> mobile: +31-641044153
>>>>> FOAF:http://www.ivan-herman.net/foaf.rdf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>     --
>>>>     Karen Coyle
>>>> kcoyle@kcoyle.net http://kcoyle.net
>>>>     ph: 1-510-540-7596
>>>>     m: 1-510-435-8234
>>>>     skype: kcoylenet
>>>>
>>>>
>>>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Friday, 8 February 2013 04:36:55 UTC