- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 07 Jan 2014 13:39:19 -0800
- To: public-vocabs@w3.org
Oops, I hit send while still reading: the types are Book and Product, so this is similar to Jarno's example. But in any case, it is an example with a creative work. kc On 1/7/14, 1:38 PM, Karen Coyle wrote: > 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:39:46 UTC