W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2014

Re: makesOffer should accept Service

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Tue, 07 Jan 2014 13:38:03 -0800
Message-ID: <52CC73BB.8060608@kcoyle.net>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:20 UTC