- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 13 Feb 2013 10:43:29 -0600
- To: Laura Dawson <ljndawson@gmail.com>
- CC: public-schemabibex@w3.org
Laura, what displays on the screen seems pretty minimal -- do you know a way to see a "fuller record"?* kc * "fuller record" is common cataloging talk, but always makes me think "brush man" On 2/13/13 10:37 AM, Laura Dawson wrote: > 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 >> > > > -- 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:44:02 UTC