- From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Date: Tue, 07 Jan 2014 20:51:38 +0100
- To: Martin Hepp <martin.hepp@ebusiness-unibw.org>, kcoyle@kcoyle.net
- CC: public-vocabs@w3.org
On 01/07/2014 08:21 PM, Martin Hepp wrote: > Dear Karen: > First, note that the current textual definitions of some schema.org elements are not yet as generic as they should be. I think this are still relicts from the early days of schema.org, when one wanted to be understood by typical Web developers, so catchy yet not context-neutral wording was used frequently. > > Conceptually, however, has schema.org shared the basic conceptual structure from GoodRelations (likely found in other conceptual models for e-commerce before), even before GoodRelations had been integrated. > > This basic model uses just four entities for representing e-commerce scenarios: > • An agent (e.g. a person or an organization), > • An object (e.g. a camcorder, a house, a car,...) or service (e.g. a haircut), > • A promise (offer) to transfer some rights (ownership, temporary usage, a certain license, ...) on the object or to provide the service for a certain compensation (e.g. an amount of money), made by the agent and related to the object or service, and > • A location from which this offer is available (e.g. a store, a bus stop, a gas station,...). > > This Agent-Promise-Object Principle can be found across most industries and is the foundation of the generic power of GoodRelations. It allows you to use the same vocabulary for offering a camcorder as for a manicure service or for the disposal of used cars. > > 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. > > 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. +1 I also find this distinction between object and promise extremely useful! One can find very similar distinction in payswarm vocabulary, part of emerging from W3C technology with aim to standardize Web Payments - https://web-payments.org/specs/source/vocabs/payswarm It uses terms: * Asset - "An asset describes a particular item that is provided as a part of a commercial transaction. [...] * Listing - "A Listing describes the combination of an Asset that is for sale under a specific License and a set of payment terms that must be fulfilled in order to access the Asset. [...] > > 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. >>> >>> 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, 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 types or other 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 >>> 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/ >>> >>> >>> >>> >>> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net http://kcoyle.net >> m: 1-510-435-8234 >> skype: kcoylenet >> > > -------------------------------------------------------- > 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, 7 January 2014 19:51:17 UTC