Re: Content-Carrier Proposal

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 Thursday, 7 February 2013 17:09:43 UTC