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

Re: CreativeWork can't be a Product?

From: Chilly Bang <chilly_bang@yahoo.de>
Date: Tue, 8 Oct 2013 18:29:09 +0100 (BST)
Message-ID: <1381253349.32885.YahooMailBasic@web172603.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
Hi!

After i realized, that CreativeWork and Product have the same passage to the Offer:  itemprop="offers" itemscope itemtype="Offer", i tend to mean, that the "two types approach" is the main way to correctly describe something, what has more than one role simultaneously, like CreativeWork and Product.

I'm sure, many users have complications with html structure of own sites, cause they want find a way for correct describing of things, which refer to more than one type. It would be very helpful for all, if the "two types approach" would be mentioned as the way in the documentation/cookbook of the Schema.org.

thanks for explaining!

--------------------------------------------
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 Tuesday, 8 October 2013 17:29:40 UTC

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