W3C home > Mailing lists > Public > public-vocabs@w3.org > October 2013

Re: CreativeWork can't be a Product? - two types approach not valid

From: Chilly Bang <chilly_bang@yahoo.de>
Date: Wed, 9 Oct 2013 14:17:28 +0100 (BST)
Message-ID: <1381324648.15697.YahooMailBasic@web172605.mail.ir2.yahoo.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Cc: Dan Scott <dan@coffeecode.net>, public-vocabs@w3.org, aaranged@gmail.com
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/
 
 
 
Received on Wednesday, 9 October 2013 13:17:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:32 UTC