Re: Content-Carrier Proposal

I'm not sure if it is still relevant, but I took a look at the
Content-Carrier proposal. I am uncomfortable with the idea of
introducing the additionalType schema.org property for Microdata
output. Do we know for a fact that itemtype can't take multiple URIs,
similar to RDFa's typeof? If that is the case I would prefer seeing if
we can get Microdata changed (hey it's a living standard) rather than
introducing additionalType, which will put us on a slippery slope of
making generic Microdata <-> RDF tooling more difficult.

Also, I would like to see the proposal outline which actual types are
needed that are not currently present in Schema.org. Perhaps there
some types that are missing from a bibliographic perspective, and it
would be useful to have them in Schema.org? If so lets get them into
the proposal. A wholesale import of carrier types from MARC-land is
something we should try to avoid however. If OCLC cares about full
fidelity transformation between MARC and RDFa/Microdata I suggest they
put up their own type vocabulary at oclc.org and start using it. I
don't think it belongs at schema.org. I mean Kit, really? :-)

Lastly, the Product Types Ontology definitely seems useful, but can't
we use it already? Why does schema.org need to change? I personally
feel that if alignment with Wikipedia is really what you want then
Wikidata URIs will prove to be more useful in the long run as it is
mainlined into Wikipedia, e.g. http://www.wikidata.org/wiki/Q199769
instead of http://www.productontology.org/id/Laser_printer ... In
principle listing the Product Type Ontology as one source of possible
additional types seems fine. But I would much prefer us talk about
what types need to be in Schema.org that aren't already present, and
for us to document best practices for using schema.org as a vocabulary
for bibliographic data.

So I guess that's a -1 from me on the Content-Carrier proposal as it stands.

//Ed

[1] http://www.w3.org/community/schemabibex/wiki/Content-Carrier

On Thu, Feb 7, 2013 at 11:36 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> 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 Wednesday, 13 February 2013 09:44:44 UTC