- 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