Re: Proposal: Audiobook

>From the perspective of the graph that is built (and hopefully, hence the
applications of the data), there is no difference.

The difference should only be in the DOM.

guha


On Mon, Sep 30, 2013 at 9:13 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> Thanks, Guha, and pardon my "term dyslexia" re: micro/data/format.
>
> So for audiobooks, would we have:
>
> <div itemscope itemtype="http://schema.org/**Audiobook<http://schema.org/Audiobook>
> http://schema.org/Product">
>
> And/or a nesting of itemtypes:
>
> <div itemscope itemtype="http://schema.org/**Audiobook<http://schema.org/Audiobook>
> ">
>  [audiobook information here]
>   <div itemtype="http://schema.org/**Product <http://schema.org/Product>">
>     [product information here]
>
> In other words, can you "step down" the itemtypes, with the audiobook
> description first, then product information as a subordinate set of data?
>
> Is there a functional difference?
>
> kc
>
>
> On 9/30/13 8:28 AM, Guha wrote:
>
>> I don't believe microformats have the concept of explicit types.
>>
>> With microdata, rdfa and json-ld, yes, you can.
>>
>> guha
>>
>>
>> On Mon, Sep 30, 2013 at 8:16 AM, Karen Coyle <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>     I believe there was a question about using multiple types in
>>     microformat markup which I can't find now, nor an answer. So in case
>>     I dreamed it all, I'll rephrase it here: can one use multiple types
>>     in a microformat markup, and could someone please provide a brief
>>     example?
>>
>>     Thank you,
>>     kc
>>
>>
>>     On 9/26/13 5:46 AM, Vicki Tardif Holland wrote:
>>
>>
>>         On Thu, Sep 26, 2013 at 8:26 AM, Martin Hepp
>>         <martin.hepp@ebusiness-unibw._**_org
>>         <mailto:martin.hepp@ebusiness-**unibw.org<martin.hepp@ebusiness-unibw.org>
>> >
>>         <mailto:martin.hepp@ebusiness-**__unibw.org<martin.hepp@ebusiness-__unibw.org>
>>
>>         <mailto:martin.hepp@ebusiness-**unibw.org<martin.hepp@ebusiness-unibw.org>>>>
>> wrote:
>>
>>              Now, we can take at least two approaches for handling this:
>>
>>              1. We can use multiple supertypes, i.e. materialize a
>> multiple
>>              inheritance relation (e.g. make AudioBook a subtype of both
>>              CreativeWorks and Product)
>>              2. We can encourage the use of multiple types at markup time.
>>
>>              I strongly recommend option #2, because
>>
>>              - it waives the need to define relevant combinations ex ante,
>>              - it avoids the irritating listing of properties that are not
>>              relevant for most use cases, and
>>              - it decouples the evolution of type combinations from the
>>         evolution
>>              of the schema.org <http://schema.org> <http://schema.org>
>>
>>         specification.
>>
>>
>>
>>         Decoupling the evolution of type combinations from the evolution
>>         of the
>>         specification is an important point. If we have to serve all of
>>         the uses
>>         of AudioBook (or any other type) in its specification, we are
>>         going to
>>         end up with a tangle of multiple inheritance and/or duplicate
>>         properties
>>         which authors will not understand how to use.
>>
>>         - Vicki
>>
>>         Vicki Tardif Holland | Ontologist |vtardif@google.com
>>         <mailto:vtardif@google.com>
>>         <mailto:vtardif@google.com <mailto:vtardif@google.com>>
>>
>>
>>     --
>>     Karen Coyle
>>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234 <tel:1-510-435-8234>
>>     skype: kcoylenet
>>
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
>

Received on Monday, 30 September 2013 16:20:22 UTC