Re: AdditionalType was: audiobook options in objects

I think this is exactly what schema.org aims at - don't worry about the under-the-hood data model, stick to what is expressed in the html
(and thanks for the public library eg - I should have some time to look at this tomorrow)

Owen

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

On 13 Feb 2013, at 17:03, Karen Coyle <kcoyle@kcoyle.net> wrote:

> So for our schema.org work, do we just concentrate on what shows on the html displays? I guess we have no choice, eh?
> 
> kc
> 
> On 2/13/13 10:51 AM, Laura Dawson wrote:
>> LOL!
>> 
>> There isn't. And I think this is going to be true for most retail sites
>> with search functions - the search is IP that the retailer's not going to
>> share due to competitive issues. I'm intimately familiar with Audible's
>> and Barnes & Noble's, because I worked pretty strenuously on those; also
>> Muze/Rovi's, which is a white-label book database that is heavily fielded
>> for faceted search. One thing we're going to have to contend with is the
>> reluctance of retailers to display everything they ingest - they may USE
>> it, as Audible does for Endeca's purposes, but they won't SHOW it.
>> 
>> 
>> On 2/13/13 11:43 AM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>> 
>>> 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
>> 
>> 
>> 
>> 
> 
> -- 
> 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 19:19:52 UTC