Re: Content-Carrier Proposal

My instinct is a subclass of creative work for Performance would be a good idea

On 7 Feb 2013, at 17:57, Karen Coyle <kcoyle@kcoyle.net> wrote:

> Sure, if we can figure out where it goes. This is the problem I have with the hierarchy that class/sub-class forces on us. The elements of Book are:
> 
> Properties from Book
> bookEdition    Text    The edition of the book.
> bookFormat    BookFormatType    The format of the book.
> illustrator    Person    The illustrator of the book.
> isbn    Text    The ISBN of the book.
> numberOfPages    Integer    The number of pages in the book.
> 
> Most of which do not apply to audiobook, with the exception of ISBN, and possibly bookEdition. (Also note "bookFormat" there -- which has:
> 
> Instances of BookFormatType
> 
>    EBook
>    Hardcover
>    Paperback
> 
> but not audiobook.)
> 
> My gut feeling is that audiobook should be sub- to creativeWork, not to Book. Anyone see that differently? (This does mean repeating ISBN and possibly bookEdition.)
> 
> kc
> 
> On 2/7/13 9:44 AM, Richard Wallis wrote:
>> You are beginning to convince me that an AudiobookType - modelled on a
>> combination of Book and MusicRecording? - may be needed.
>> 
>> Then it could be the base type to be combined with CD, WMA, etc.
>> 
>> Do you want to draft a proposal?
>> 
>> ~Richard.
>> 
>> 
>> On 07/02/2013 17:09, "Karen Coyle" <kcoyle@kcoyle.net> 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 Thursday, 7 February 2013 18:42:09 UTC