Re: Proposal: Audiobook

Is this not why  'additionalType<http://schema.org/additionalType>' was added to Thing?

~Richard

On 30 Sep 2013, at 17:19, Guha <guha@google.com<mailto:guha@google.com>> wrote:

>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<mailto: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/Product">

And/or a nesting of itemtypes:

<div itemscope itemtype="http://schema.org/Audiobook">
 [audiobook information here]
  <div itemtype="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>
<mailto: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<mailto:martin.hepp@ebusiness-unibw.org>>
        <mailto:martin.hepp@ebusiness-__unibw.org<mailto:martin.hepp@ebusiness-__unibw.org>

        <mailto:martin.hepp@ebusiness-unibw.org<mailto: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<http://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>>
        <mailto:vtardif@google.com<mailto:vtardif@google.com> <mailto:vtardif@google.com<mailto:vtardif@google.com>>>


    --
    Karen Coyle
    kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net>> http://kcoyle.net<http://kcoyle.net/>
    m: 1-510-435-8234<tel:1-510-435-8234> <tel:1-510-435-8234<tel:1-510-435-8234>>
    skype: kcoylenet



--
Karen Coyle
kcoyle@kcoyle.net<mailto:kcoyle@kcoyle.net> http://kcoyle.net<http://kcoyle.net/>
m: 1-510-435-8234<tel:1-510-435-8234>
skype: kcoylenet