- From: Aaron Bradley <aaranged@gmail.com>
- Date: Wed, 9 Oct 2013 07:09:22 -0700
- To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Cc: chilly_bang@yahoo.de, Dan Scott <dan@coffeecode.net>, Public Vocabs <public-vocabs@w3.org>
- Message-ID: <CAMbipBsM1oqZu4wRAbC+6zvm25aeLiYtvykEVcwwMjkjwyudvw@mail.gmail.com>
Indeed Martin. The results of the additionalType test, and test with the
relative second URI were anticipated; the results of the tests with two,
full, space-separated URIs for the itemtype value were not.
On Wed, Oct 9, 2013 at 7:05 AM, Martin Hepp <martin.hepp@ebusiness-unibw.org
> wrote:
> Hi Bradley
> (& Google Structured Data Testing Team ;-) !)
>
> On Oct 9, 2013, at 3:59 PM, Aaron Bradley wrote:
>
> > This is exactly what my microdata testing revealed as well, for all of
> the solutions discussed.
> >
> > If an additional type is declared using <link itemprop="additionalType">
> the additional type property is recognized, but any properties associated
> exclusively with the additional type are reported as an error ("Error: Page
> contains property "[X]" which is not part of the schema."):
> >
> http://www.google.com/webmasters/tools/richsnippets?url=http://www.airshock.com/schools/flunkout-both.php
> >
>
> I think this is correct behavior in Microdata. You could try full URIs for
> the properties of the secondary type (instead of just the local part);
> then, the tool may not complain. Whether Google will understand them is
> another issue, though.
>
> > If an additional type is listed as an additional URL in the itemtype
> declaration, the additional type is not recognized, and properties
> exclusive to it are listed as an error:
> >
> http://www.google.com/webmasters/tools/richsnippets?url=http://www.airshock.com/schools/flunkout-both-2.php
>
> This is a bug in the Google validator.
>
> >
> > This is the case whether or not full URLs are used for both types used
> as the itemtype value (above), or if only the item type name is used for
> second type:
> >
> http://www.google.com/webmasters/tools/richsnippets?url=http://www.airshock.com/schools/flunkout-both-4.php
> >
> From the top of my head, only full URIs for types are allowed with
> itemtype, so multiple types must use multiple full URIs.
>
> > The NU Validator complains about the white space being used, but if this
> is replaced with "%20" it borks both types for the Structured Data Testing
> Tool:
> >
> http://www.google.com/webmasters/tools/richsnippets?url=http://www.airshock.com/schools/flunkout-both-3a-p20.php
> >
> I would say that this is a bug too.
>
> > As Egon notes, the SDTT recognizes only the first item type. If the
> order is reversed, it's the other item-specific property that is listed as
> an error:
> >
> http://www.google.com/webmasters/tools/richsnippets?url=http://www.airshock.com/schools/flunkout-both-3.php
> >
> This is a bug in the tool.
>
> Martin
>
> >
> >
> > On Wed, Oct 9, 2013 at 6:17 AM, Chilly Bang <chilly_bang@yahoo.de>
> wrote:
> > Hello!
> >
> > The "two types approach" isn't valid - Rich Snippet Testing Tool doesn't
> detect the second type and means, the property from the second type isn't
> part of the schema.
> >
> > Here is an example, as i understand the "two types approach" relating to
> my issue:
> >
> >
> http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004e84e6adc79a951051ef6f09c3f62
> >
> > The way with additionalType gives the same validation problem out: the
> type, setted with additionalType, isn't detected by Testing Tool, the
> property of the second type isn't part of the schema...
> >
> >
> http://www.google.com/webmasters/tools/richsnippets?q=uploaded:8004e84e9dd5fcb63ed38bef8ac3d69b
> >
> > greets
> > egon
> >
> >
> > --------------------------------------------
> > Martin Hepp <martin.hepp@ebusiness-unibw.org> schrieb am Di, 8.10.2013:
> >
> > Betreff: Re: CreativeWork can't be a Product?
> > An: chilly_bang@yahoo.de
> > CC: "Dan Scott" <dan@coffeecode.net>, public-vocabs@w3.org,
> aaranged@gmail.com
> > Datum: Dienstag, 8. Oktober, 2013 14:23 Uhr
> >
> > Hi Chilly,
> > it is not a bug, but a feature - schema.org follows the idea
> > that if you need multiple types (not exactly, but roughly
> > what you mean with inheritance), you shall represent that at
> > the *instance* level, not in the *schema*.
> >
> > The choice is very pragmatic and effective: If you have
> > certain types in a vocabulary that are not disjoint, you
> > would otherwise have to materialize all (or at least a lot
> > of reasonable) combinations. That would blow up the
> > vocabulary significantly. Plus, many of the types we are
> > discussing here represent *roles*, not rigid, essential
> > types. So a book that is described as a product is simply
> > the intersection of Book and Product. A book that is
> > described in a non-commercial context is just a book.
> >
> > Since the semantics of Product is essentially that of a
> > Thing used as the object in an offer, a large share of
> > schema.org types would have to appear as specializations of
> > Product.
> >
> > Multiple typing at instance level is NOT a workaround. It is
> > a flexible modeling paradigm, rooted in the notion of
> > facets.
> >
> > Martin
> >
> > On Oct 8, 2013, at 12:57 PM, Chilly Bang wrote:
> >
> > > Hello!
> > >
> > > I read all your answers - many thanks for
> > clarifying this issue. As i see there are mainly two
> > approachs to get thing done: "two types approach" and using
> > of additionalType.
> > >
> > > It is very helpful to have such workarounds, but they
> > are only workarounds, not a "right" solution. This issue
> > seems to be solvable with just simple change of type passage
> > structure/inheriting, namely: one things must be maked
> > possible, CreatieWork type must can inherit Product type. I
> > mean such inheritance is a simple thing, which is even
> > partly present, on other place: CreativeWork can inherit
> > Offer, but why not Product? Making it possible would make
> > such workarounds like "two types approach" redundant - they
> > are indeed redundant cause of impossibility of inheritance,
> > which is possible on another, near place.
> > >
> > > Schema.org has pretty clear structure, maintaining of
> > it provides Schema.org to more users and makes the
> > implementing more easy, selfexplaining and issueless. But if
> > one thing is possible on one place, on another similar place
> > is this not possible and needs workarounds so the whole
> > clear structure of Schema is confused. It is just my
> > feeling.
> > >
> > >
> > > --------------------------------------------
> > > Dan Scott <dan@coffeecode.net>
> > schrieb am Mo, 7.10.2013:
> > >
> > > Betreff: Re: CreativeWork can't be a Product?
> > > An: "Chilly Bang" <chilly_bang@yahoo.de>
> > > CC: public-vocabs@w3.org
> > > Datum: Montag, 7. Oktober, 2013 22:37 Uhr
> > >
> > > On Mon, Oct 07, 2013 at 09:16:01PM
> > > +0100, Chilly Bang wrote:
> > >> Hello!
> > >>
> > >> i'm busy at the moment with marking up with
> > microdata of
> > > an online bookstore and realized the following
> > dilemma:
> > >> if a page is about describing and selling of a
> > > CreativeWork/Book, so i come to selling properties
> > with
> > > itemprop="offers" itemscope="" itemtype="http://schema.org/Offer".
> But on this way i can't
> > > describe the book i sell like Product, with product's
> > > properties - i can't find any passage from CreativeWork
> > to
> > > Product. There is in fact a passage from Offer to
> > Product,
> > > with itemprop="itemOffered" itemscope="" itemtype="
> http://schema.org/Product", but repeating isn't a good
> > > way, beside of this it isn't easy to get such passage
> > into
> > > html, even with itemref.
> > >>
> > >> I see no possibility to go the way
> > > CreativeWork->Product->Offer (or
> > > CreativeWork->Product and CreativeWork->Offer),
> > but
> > > only CreativeWork->Offer, or Product->Offer.
> > > CreativeWork can't be a Product or am i wrong?
> > >>
> > >> Imho CreativeWork surely can own product's
> > properties so
> > > it must gladly have a passage from any CreativeWork
> > property
> > > to Product.
> > >
> > > You can just use both types in the itemtype
> > declaration, for
> > > example,
> > > itemtype="Book Product".
> > >
> > > We're doing this in the #schemabibex group to express
> > offers
> > > for a given
> > > item. And Martin gave a wonderful example of this
> > approach
> > > on this list
> > > just a few days back at
> > > http://lists.w3.org/Archives/Public/public-vocabs/2013Sep/0206.html
> > >
> > >
> >
> > --------------------------------------------------------
> > martin hepp
> > e-business & web science research group
> > universitaet der bundeswehr muenchen
> >
> > e-mail: hepp@ebusiness-unibw.org
> > phone: +49-(0)89-6004-4217
> > fax: +49-(0)89-6004-4620
> > www: http://www.unibw.de/ebusiness/ (group)
> > http://www.heppnetz.de/ (personal)
> > skype: mfhepp
> > twitter: mfhepp
> >
> > Check out GoodRelations for E-Commerce on the Web of Linked
> > Data!
> > =================================================================
> > * Project Main Page: http://purl.org/goodrelations/
> >
> >
> >
> >
> >
> >
>
> --------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail: hepp@ebusiness-unibw.org
> phone: +49-(0)89-6004-4217
> fax: +49-(0)89-6004-4620
> www: http://www.unibw.de/ebusiness/ (group)
> http://www.heppnetz.de/ (personal)
> skype: mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
>
>
Received on Wednesday, 9 October 2013 14:09:53 UTC