- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 07 Jan 2014 13:38:03 -0800
- To: public-vocabs@w3.org
This page shows a use of offer related to a Book, which is a CreativeWork. http://www.w3.org/community/schemabibex/wiki/Holdings_via_Offer It does not make use of Product. kc On 1/7/14, 1:09 PM, Jarno van Driel wrote: > Thank you very much for your extensive explanation Martin. Because of it > I'm quite some steps closer to what I would like to understand. > > Now if I understand you correctly a multiple-type item should only be > used if one wants to create a (composite) type but should be avoided if > possible due to difficulty in parsing that type of data. > > Now in the example I wrote for somebody else (which led to my original > question) I marked up a 'house for sale' and it looked like this: > > <div itemscope itemtype="http://schema.org/Residence > http://schema.org/Product"> > ...[residence product data]... > <div itemprop="offer" itemscope > itemtype="http://schema.org/Offer">...[offer data]...</div> > </div> > > Now if I understand the previous posts correctly than I can consider > this markup to be correct, right? > > The only thing I still wonder though is why isn't it possible add the > offer property to more types. It seems a bit complex to have to add > Product to something you want to put up for sell while semantically > being more precise. Having the possibility to add an offer property to > things like for example Book, Residence, Store, Movie and such would > make it so much intuitive IMHO. So I wonder, is there a special reason > why 'offer' and 'itemOffered' are bound to Product? > > > On Tue, Jan 7, 2014 at 9:26 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > > > On 1/7/14, 11:21 AM, Martin Hepp wrote: > > In theory, we would not need a distinct type for "Product" (nor > Service); we could simply say we have an agent, and offer, and a > thing. But it felt unnatural to not have a Product class in an > e-commerce ontology. > > But I disagree that the product type is the same as the offer. > Being a product is a role that a thing can have, and this type > adds properties that are relevant only in this context (e.g. a > stock keeping unit). The offer is the promise to transfer some > or all rights on the thing. > > > Ah, but that isn't what I meant. I meant that in schema.org > <http://schema.org> "product" is a thing being offered. Which I > think would modify your scenario from: > agent - object - promise - location > > to: > > agent - promise - object - location > > The schema Product *definition* includes "made available" (we'll > ignore "for sale") in the definition of product. So offer and > product appear to be closely entwined, as a product is defined as > something that is offered. To separate them, one would need to > define product as "something made" with perhaps "eventually intended > for sale/exchange". That would be reminiscent of the indecs "people > create stuff, people make deals about stuff." > > Product can be contrasted with CreativeWork, whose definition is > less than enlightening: "The most generic kind of creative work, > including books, movies, photographs, software programs, etc." > CreativeWork is not by definition "made available" in the way that > Product is. And of course some creative works are products, so like > the separation of product and service we have fuzzy definitional > boundaries. What is the difference between a film as a creative work > and a film on DVD for sale? > > I'm not suggesting that we should or even can resolve these, but I > do see the problem as going beyond the product/offer issue. > > kc > > > > The beauty of this model is that > > - it fits a huge range of scenarios and > - with http://schema.org/Demand, we have a type that is the > exact mirror of the offer and can be used to model the demand > side in a structurally identical fashion. > > For instance, if you sell the same product at different > conditions in different countries, or at different times (e.g. > happy hours for drinks), you simply use multiple offers for the > same object. > > Martin > > On Jan 7, 2014, at 8:08 PM, Karen Coyle wrote: > > There is quite a bit of semantic ambiguity between > schema:product, service, and offer. Product seems to match > Martin's GoodRelations definition of "product or service", > but I could also think of product and service as "product > offered" "service offered", thus making them not fully > distinct from Offer, and possibly subtypes of offer. The > only reason I could see for a separation between product and > service would be if they have some distinct properties that > cannot be shared. > > kc > > Thing > Product > A product is anything that is made available for sale—for > example, a pair of shoes, a concert ticket, or a car. > Commodity services, like haircuts, can also be represented > using this type. > > Thing > Intangible > Service > A service provided by an organization, e.g. delivery > service, print services, etc. > > Thing > Intangible > Offer > An offer to sell an item—for example, an offer to sell a > product, the DVD of a movie, or tickets to an event. > > > > > On 1/7/14, 10:21 AM, Martin Hepp wrote: > > The properties of http://schema.org/Product are > naturally not sufficient for all possible details of > every possible object or activity that can be offered. > There are two solutions for that: > > 1. Propose additional properties for > http://schema.org/Service. > 2. Wait for the generic property-value proposal that I > am working on; more to follow on > http://www.w3.org/wiki/__WebSchemas/PropertyValuePairs > <http://www.w3.org/wiki/WebSchemas/PropertyValuePairs>. > > As a bit of background: In GoodRelations, there is one > joint class for products and services, because many data > sources (e.g. Web shops) are not able to signal whether > an item is a product or a service (e.g. because the > backend-database does not store this distinction). Thus, > we need a common abstraction. When integrating > GoodRelations into schema.org <http://schema.org>, we > merged that into http://schema.org/Product, since this > covers the majority of the use-cases. > > Martin > > On Jan 2, 2014, at 1:55 PM, Robert Kost wrote: > > Hi Martin — > > with regard to … > > > 2. As for modeling services, schema:Product > fits; it can be constrained by combining it with > www.productontology.org > <http://www.productontology.org> types or other > schema.org <http://schema.org> types without > problems (in general; some Google infrastructure > does not yet fully support multi-typed entities). > > > … I don’t understand. How would one use Product to > model, say: the services of a product liability > attorney who works on contingency: the SLA of an > internet service provider offering to provide > specific bandwidth rates, availabilities, etc. over > a specific period of time; a real estate broker > specializing in distressed properties; or a hospital > that specializes in orthopedic surgeries and that > wants to cite certain procedures or success rates? > None of the Product properties seem to support > these notions of performance, conditionality, rate, > quality, technique, delivery time and method, etc. > And, conversely, many of the Product properties do > not pertain. It is possible, I suppose, to stuff of > all of the salient differentiators into > “description,” but the utility of Schema is > undermined. In any event, Product seems to be a > tortured use of the word to describe what is being > offered. > > best, > > Rob > > > ------------------------------__-------------------------- > martin hepp > e-business & web science research group > universitaet der bundeswehr muenchen > > e-mail: hepp@ebusiness-unibw.org > <mailto:hepp@ebusiness-unibw.org> > phone: +49-(0)89-6004-4217 <tel:%2B49-%280%2989-6004-4217> > fax: +49-(0)89-6004-4620 <tel:%2B49-%280%2989-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/ > > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> > skype: kcoylenet > > > ------------------------------__-------------------------- > martin hepp > e-business & web science research group > universitaet der bundeswehr muenchen > > e-mail: hepp@ebusiness-unibw.org <mailto:hepp@ebusiness-unibw.org> > phone: +49-(0)89-6004-4217 <tel:%2B49-%280%2989-6004-4217> > fax: +49-(0)89-6004-4620 <tel:%2B49-%280%2989-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/ > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> > skype: kcoylenet > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Tuesday, 7 January 2014 21:38:31 UTC