Re: makesOffer should accept Service

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> 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 "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.
>>>>
>>>> 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/
>>
>>
>>
>>
>>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
>