- From: Laura Dawson <ljndawson@gmail.com>
- Date: Wed, 13 Feb 2013 11:37:07 -0500
- To: <kcoyle@kcoyle.net>, <public-schemabibex@w3.org>
If this perspective helps¡ŠI developed Audible's taxonomies in 2006 (so they could use them with Endeca) and I don't see that they've strayed much from it. It's very ONIXy, I guess is what I'm saying. On 2/13/13 10:32 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote: >owen, great minds and all of that... I've pulled an audio book display >off of my local public library to use as an example. Here's the permalink: > >http://www.berkeley-public.org/record=b1727690~S11 > >I also looked at audible.com and audiobooks.com (amazon doesn't seem to >have audio books). The commercial sites include really minimal info, so >they shouldn't be hard to accommodate. > >I haven't gotten around to editing the actual html from the public >library because of course it's all full of CSS (longing for the old days >of simple html). But I will attack this. I will also eliminate some of >the data (e.g. multiple subjects -> one subject for illustration). So >let's do it. > >kc > >On 2/13/13 9:16 AM, Owen Stephens wrote: >> When I saw Dan Brickley talk about Schema.org <http://Schema.org> a >> little while back (watch it at >> http://www.youtube.com/watch?v=_-6mhdjE1XE) the thing that struck me is >> how incredibly pragmatic the approach was - it was about 'how do people >> currently represent this on the web' not 'how best to represent this'. I >> keep having to remind myself about this when I think about making >>proposals. >> >> With this in mind I've followed Karen's example and started to look at >> how Audiobooks are described on the web - I'm keen that whatever markup >> we propose is going to support these examples. I've started collecting >> examples and added them to the wiki. I did start to work out how these >> might be supported by some of the proposals with no, or only small, >> changes to the existing HTML markup - but haven't had time to complete >> this yet. >> >> It would be good to get some links to existing library specific displays >> of audiobooks as well - don't have any of these yet, so please add to >> the wiki if you have some. >> >> I guess that I'm trying to get into what I think is the schema.org >> <http://schema.org> mindset rather than a more general modelling mindset >> and ground proposals in real world existing html markup. I'm keen that >> we ground proposals in real world stuff, and think this is a way of >> ensuring this is what we do. To my mind this is a strength of discussing >> specifics like Audiobooks over the more abstract content vs carrier >> discussion - if we do this for some key types that exemplify content vs >> carrier, we may find a set of consistent approaches that all work in the >> same way, or we may find that we need different approaches in different >> areas - but we shouldn't worry either way. >> >> I think we'll stand a better chance getting three proposals for >> "Audiobook", "Radio Play" and "TV Show recording" to be added than a >> single, more abstract, how to do content vs carrier proposal. >> >> I'd be interested in knowing if this strikes a chord with others >> >> Owen >> >> Owen Stephens >> Owen Stephens Consulting >> Web: http://www.ostephens.com >> Email: owen@ostephens.com <mailto:owen@ostephens.com> >> Telephone: 0121 288 6936 >> >> On 13 Feb 2013, at 14:03, Karen Coyle <kcoyle@KCOYLE.NET >> <mailto:kcoyle@KCOYLE.NET>> wrote: >> >>> Richard, I don't think that we can declare that each bibliographic >>> description describes a single, uncomplex type. To begin with, there >>> is that library bugaboo "kit" in which the item in question is >>> simultaneously multiple types: >>> a kit with multiple parts, each of which is a different thing (a >>> puppet, a book, some crayons) >>> >>> There is also: >>> a book with an included CD >>> >>> There are also many libraries that do not create separate records for >>> the hard copy and digital: >>> record for a book with an additional link to the online copy >>> >>> And almost none create separate records for hardcopy and paperbacks. >>> >>> The upshot is that we will need to handle multiple types in a single >>> description. These are also an "AND" relationships, at least in >>> relation to the bibliographic data. How would this be done? >>> >>> [And in another thread, as I say, I do not consider a "CD" to be a >>> further typing of a creative work, since I would not say that a "CD" >>> is a type of musical work.] >>> >>> kc >>> >>> >>> On 2/13/13 6:57 AM, Richard Wallis wrote: >>>> Hi All, >>>> >>>> I¡¯ve pulled this out of the audiobook thread as I think it is >>>>generally >>>> applicable to several areas of our discussions. >>>> >>>> Karen¡¯s points below highlight several points relevant to this, which >>>>I >>>> will try to clarify. >>>> >>>> This emerged from the audiobook thread as audio book is a good example >>>> of something in our domain of multiple types ¡© a creative work, >>>>possibly >>>> a book, with a file format (WMA, MP3, etc), and a physical form (CD, >>>> cassette tape, etc.). That thread has moved on and we proposing a new >>>> sub-type of CreativeWork ¡© AudioBook, which I agree with. For the >>>> purposes of examples in this email am presuming that proposal has been >>>> accepted. >>>> >>>> Starting with Karen¡¯s second question: >>>> >>>> /Second, it still isn't clear, however, if you have multiple >>>> associatedMedia fields, e.g. A, B and C, whether that means that >>>>you >>>> have that CW in three different media, or if you have the CW in a >>>> single medium that is defined as A+B+C. >>>> / >>>> >>>> >>>> She is referencing multiple instances of a property, however I believe >>>> it is the same question for multiple types. >>>> >>>> It is an AND relationship. >>>> >>>> The turtle syntax is really helpful for envisioning multiple types: >>>> <http://example.com/1234> >>>> a schema:Audiobook, pto:Windows_Media_Audio, pto:Compact_Disk; >>>> >>>> Which can be unpacked as: >>>> <http://example.com/1234> >>>> a schema:Audiobook; >>>> a pto:Windows_Media_Audio; >>>> a pto:Compact_Disk; >>>> >>>> Which can be read as: >>>> <http://example.com/1234> is the identifier for a thing which is >>>> a Audiobook and, >>>> a Windows_Media_Audio, and >>>> a Compact_Disk >>>> >>>> If you want to describe something (an audio book) that is available in >>>> several formats, you are describing relationships between different >>>> things. >>>> >>>> Against my better judgement and dipping into FRBR language to explain >>>> it.... >>>> >>>> You would have the description of an Expression, of type Audiobook, >>>>with >>>> links to instances (Manifestations) for each format. Each instance >>>>would >>>> be a combination of Audiobook and Compact_Disc; Audiobook and DVD; >>>> Audiobook and Cassette; etc. >>>> >>>> Check out the examples library >>>> A0<http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A0> >>>> (Expression) and its related instances (Manifestations) >>>> A1<http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A1> and >>>> A3<http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A1> to >>>> see how this might be encoded. >>>> >>>> >>>> >>>> Moving on to how we encode multiple types for a thing there are a >>>>couple >>>> of issues to address. >>>> >>>> Firstly, the differences between RDF (Turtle), RDFa, and Microdata. >>>> >>>> * RDF is the most obvious ¡© as per the above example you just keep >>>> adding type statements as required. >>>> * RDFa add the type URI to the ¡®typeof¡¯ attribute: >>>> >>>> <div vocab="http://schema.org/" >>>> typeof="Audiobook >>>> http://www.productontology.org/id/Compact_Disk"> >>>> >>>> * Microdata is a little more difficult as the microdata standard does >>>> not natively support multiple types. To overcome this limitation >>>> Schema introduced the addtionalType property so that they could >>>> encode this concept using microdata, thus: >>>> >>>> <div itemscope itemtype="http://schema.org/Audiobook"> >>>> <link itemprop="additionalType" >>>> href="http://www.productontology.org/id/Compact_Disk"> >>>> >>>> >>>> The fact that the microdata solution uses additionalType as the >>>>property >>>> name introduces the impression that the other type(s) are somehow >>>> subordinate. Maybe it would have been better to have ¡®alsoOfType¡¯ as >>>>a >>>> property name. >>>> >>>> The important effect of this approach is that there is no relevance in >>>> the order of their declaration. For instance a librarian may describe >>>> an audiobook on CD in microdata thus: >>>> <div itemscope itemtype="http://schema.org/Audiobook"> >>>> >>>> <link itemprop="additionalType" >>>> href="http://www.productontology.org/id/Compact_Disk"> >>>> >>>> >>>> Whereas a retailer may describe the same thing as: >>>> <div itemscope >>>>itemtype="http://www.productontology.org/id/Compact_Disk"> >>>> >>>> <link itemprop="additionalType" href=" >>>>http://schema.org/Audiobook"> >>>> >>>> These are both valid and equivalent to each other. >>>> >>>> >>>> ~Richard >>>> >>>> >>>> On 09/02/2013 20:09, "Karen Coyle" <kcoyle@kcoyle.net >>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>> >>>> Owen, I take your point: additionalType seems to be sub-typing >>>> CreativeWork, not adding information about the product. I vaguely >>>> recall >>>> having been warned about additionalType -- that it is not often >>>> used and >>>> seems to be tricky. Here's the definition of "aT": >>>> >>>> "An additional type for the item, typically used for adding more >>>> specific types from external vocabularies in microdata syntax. >>>> This is a >>>> relationship between something and a class that the thing is in. >>>> In RDFa >>>> syntax, it is better to use the native RDFa syntax - the 'typeof' >>>> attribute - for multiple types. Schema.org <http://Schema.org> >>>> tools may have only weaker >>>> understanding of extra types, in particular those defined >>>>externally." >>>> >>>> Richard posted this in an email: [1] >>>> " >>>> 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 >>>> > >>>> >>>> First, I think that "/associatedMedia" in CreativeWork looks to be >>>>a >>>> better fit for this. It is defined as: "The media objects that >>>>encode >>>> this creative work. This property is a synonym for encodings." >>>> >>>> Second, it still isn't clear, however, if you have multiple >>>> associatedMedia fields, e.g. A, B and C, whether that means that >>>>you >>>> have that CW in three different media, or if you have the CW in a >>>> single >>>> medium that is defined as A+B+C. I believe that Richard's example >>>> above >>>> was the latter. You seem to be concerned about encoding the former. >>>> Surely we need to be able to distinguish between them. I believe >>>>that >>>> means moving toward item or offer-level description for the >>>>different >>>> encodings. I can't think of any other way to make it clear. >>>> >>>> kc >>>> >>> >>> -- >>> Karen Coyle >>> kcoyle@kcoyle.net <mailto: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 16:37:50 UTC