RE: Extension syntax Was: Re: Updated Example

> Like all schema.org properties, additionalType is optional in instance
> data.  OTOH, Itemtype is required for the data to be recognized as
> microdata - at least, that's how it tests out at the Google rich
> snippets validation: the rich snippets won't show up properly without
> it.

I don't think this is true. Here is a Microdata fragment that doesn't have an itemtype that the Rich Snippet tool is able to parse without complaint:

<div itemprop="http://schema.org/publisher" itemscope="">
 <span itemprop="http://schema.org/name">Griffin</span>
</div>

If the itemtype isn't included, it should be safe to infer http://schema.org/Thing as the itemtype.

This is inferable type the only "essential" that is needed. Beyond that, there is no reason to think itemtype and additionalType have any semantic differences at all. If an item has two types, it doesn't matter which type goes in itemtype and which one(s) go in additionalType.

Jeff

> 
> Therefore, we need to think about what itemtypes are essential (as Ed
> said in an earlier email) since we can't be confident that
> additionalTypes will be used. Thus, if we think that eBook should be
> distinct from Book, then it will need to be an itemtype. If instead we
> think that the distinction isn't important (or is optional) then we
> don't need an itemtype for eBook -- we would instead use Book and some
> folks will include the optional additionalType for eBook. This is the
> distinction I am making -- that additionalType is optional, while
> itemType is not.
> 
> Note that the Product folks have taken a very different approach from
> the rest of schema.org - there are no sub-classes under Product for the
> different product types, while there are lots of sub-classes under
> "Event" and "Place" and the medical categories. etc. Instead the
> Product folks are relying on the additionalType added to the very
> generic "SomeProducts." This means that although it is called
> "additionalType"
> in many cases it will be the only real "type" information included,
> other than saying that it is a product. In examples that don't have an
> additionalType the only thing identifying the product is the name or
> the description. By analogy, one could have no sub-classes under
> CreativeWork and use the productOntology to distinguish the types of
> creative works. That isn't the approach that was taken for CreativeWork
> or for classes other than Product, however.
> 
> kc
> 
> >> This is one of my concerns with the product ontology: if the
> information is essential to the microdata markup, it cannot be ONLY in
> the additionalType. So where there is something like:
> >>
> >> Format: Audiobook on CD<br/>
> >>
> >> ... if we think that "CD" is an important bit of information for
> rich snippets or searching, then that needs microdata markup. The
> additional type statement:
> >>
> >> <link itemprop="additionalType"
> >> href="http://www.productontology.org/id/Compact_Disk"/>
> >>
> >> cannot be considered a substitute for markup of the display.
> >>
> >
> > Again I'm not seeing your point - are you trying to say that it is
> only valid to use text on display as property values?
> >
> > If you are, how does this, where the data asserting it is an
> Audiobook is embedded in an attribute, fit in with that?:
> >
> > <div itemscope itemtype="http://schema.org/Audiobook">
> > <span itemprop="name">Dune<span>
> > Format: Audiobook <br/>
> >
> >
> >
> >> Oddly enough, I am not finding examples where the carrier is marked
> up *at all* - not even in the movie or recorded music schemas.
> >
> >
> > That does not surprise me - the rest of the world is less inclined to
> categorise,  then group those categories, of things as  librarians do.
> >
> > A tall ginger bloke is not often referred to as a man of height type
> tall and hair colour red.
> >
> >> The Book schema uses this extension format, but with schema.org-
> defined terms:
> >>
> >> <link itemprop="bookFormat" href="http://schema.org/Paperback">Mass
> >> Market Paperback
> >
> > Yes, thats what is described as an internal, to the vocabulary,
> enumeration.
> >>
> >> Which seems a bit odd to me, but I can understand that they didn't
> want to create a class for each of the book product types.
> >
> >
> > Exactly why they encourage external enumerations for sets of
> externally managed values, because Schema would not be able to
> effectively manage them.
> >
> > Product Ontology, for one is following this encouragement, as I
> believe should we.
> >
> > We after all are not expecting Schema to manage authoratitve lists
> subjects, names, etc - so why think it for format types?
> >
> >> (Although schema has numerous classes that add no new properties.)
> >>
> >> In any case, I think we need to create examples both with and
> without the extensions to make sure that our proposals work either way.
> >
> >
> >
> > I'm all for providing examples of several ways of doing things. But I
> get the feeling that you believe that some are more right than others,
> or is that just a matter of personal preference?
> >
> >
> >>
> >>
> >> kc
> >>
> >>
> >>
> >>>
> >>> ~Richard.
> >>>
> >>>>
> >>>> This is analogous to:
> >>>>
> >>>> <span itemprop="creator">John Smith</span>
> >>>>
> >>>> There may be something better to call it than "abridged" - but I
> >>>> couldn't think of anything at the time. I am in touch now with
> some
> >>>> audiobook publishers so I can ask them these questions. This
> >>>> information should not be in a general note, though, because it
> has
> >>>> particular significance for the sales of audiobooks. I'll ask my
> >>>> contacts for better terminology.
> >>>>
> >>>> kc
> >>>>
> >>>>
> >>>> On 2/23/13 10:10 AM, Richard Wallis wrote:
> >>>>> I read the abridged property as having a Boolean intent -
> >>>>> ³abridged² or ³unabridged²  - I was going to suggest ³yes²/²no²
> or
> >>>>> true/false as more appropriate ranges for such a property.
> >>>>>
> >>>>> Would not commonEndeavour  not be a better way to link an
> abridged
> >>>>> AudioBook and the Book it is an abridgement of?
> >>>>>
> >>>>> ~Richard.
> >>>>>
> >>>>>
> >>>>> On 23/02/2013 16:30, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:
> >>>>>
> >>>>>      Karen has also proposed an abridged property with a range of
> Text.
> >>>>>      It might be nice if the property was tweaked to have a
> domain and
> >>>>>      range of schema:Book so the link between the two could be
> followed.
> >>>>>
> >>>>>      Jeff
> >>>>>
> >>>>>      Sent from my iPad
> >>>>>
> >>>>>      On Feb 23, 2013, at 4:31 AM, "Richard Wallis"
> >>>>>      <richard.wallis@oclc.org> wrote:
> >>>>>
> >>>>>          Updated Example to reflect proposed Audiobook type Hi,
> >>>>>
> >>>>>          Following Karen posting a proposed Audiobook Type, I
> have
> >>>>>          updated the example in the Example Library to reflect
> it:
> >>>>>
> >>>>> <http://www.w3.org/community/schemabibex/wiki/Examples/mylib/A8>
> >>>>>
> >>>>>          ~Richard.
> >>
> >> --
> >> 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 Thursday, 28 February 2013 17:35:43 UTC