Re: Content-Carrier Proposal

Owen, I agree but I'm not confident that I know enough to create a 
Performance subclass. I think I'll just do the "schema.org" thing and 
create what I can where I can. Unless someone here is up on performance 
metadata?

kc

On 2/7/13 10:41 AM, Owen Stephens wrote:
> 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
>>
>

-- 
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 21:01:24 UTC