Re: Content-Carrier Proposal

This has some appeal. But why have schema.org/Book and not an additionalType of http://www.productontology.org/id/Book (which presumably would really be more accurately http://www.productontology.org/id/Printedbook?)

Schema.org Book is pretty sparse and even some of the stuff that is there seems questionable (shouldn't Illustrator be part of Creative Work? It can have a number of pages and also be an ebook?)

I like the additionalType approach because it seems to cut through some of the more knotty modelling problems we might otherwise have to try and bite off in one go.

On the otherhand I have sympathy with Karen's point which is some of these things have properties we want to include - which either suggests extending Creative Work to embrace lots of additional properties, or adding to the rather odd list of more specific types of Creative Work?

Sorry this isn't more constructive - just trying to work my way back into the conversation having been on the sidelines since the turn of the year.

Owen

Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: owen@ostephens.com
Telephone: 0121 288 6936

On 7 Feb 2013, at 10:27, Richard Wallis <richard.wallis@oclc.org> wrote:

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