RE: Extension syntax Was: Re: Updated Example

Sorry, my example had some cruft in it. Here it is again:

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

The point is that itemtype isn't "essential". Furthermore there is no reason to assume that itemtype is the place where people should put the "essential" class and that the non-essential types belong in the "additionalType". We aren't even required to believe that things HAVE an essential type.

http://en.wikipedia.org/wiki/Essentialism


Jeff

> -----Original Message-----
> From: Young,Jeff (OR) [mailto:jyoung@oclc.org]
> Sent: Thursday, February 28, 2013 12:35 PM
> To: kcoyle@kcoyle.net; public-schemabibex@w3.org
> Subject: 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:45:40 UTC