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
> 
> 
>