Re: AdditionalType was: audiobook options in objects

Does with me.

~Richard


On 13/02/2013 15:16, "Owen Stephens" <owen@ostephens.com> 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
> Telephone: 0121 288 6936
> 
> On 13 Feb 2013, at 14:03, Karen Coyle <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> 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
>>>