Re: makesOffer should accept Service

Hi,

> In all honesty I couldn't come up with a reason why this would be a wrong notation. So I was curious, does anybody think this is valid markup and if not, why not?

I rather strongly discourage using the two types on one entity. Offer on one hand and product / service on the other are two distinct conceptual entities.

a) The offer is the promise to transfer some rights on something for some compensation.
b) The product or service is the object or activity (or bundle thereof) to which the offer refers.

You can have multiple offers referring to the same product (e.g. you offer your house for sale at 100,000 or for rent at 1,000 USD), and and offer can refer to multiple products (e.g. in a bundle).

Of course, there is no absolute, universally valid partitioning of the world into conceptual elements, and you can always merge multiple entities into one, but that hampers the ability of a computer to do meaningful operations over the data. Offer vs. Product, Book Copy vs. Book Title, Legal Entity vs. Point of Sale are a few fundamental, well established, useful distinctions that ease the processing of respective data by computers.

So while search engines may be still be able to process such buggy data, this pattern should not be recommended.

Martin








On Jan 7, 2014, at 8:52 AM, Jarno van Driel wrote:

> Thanks Dan for giving your interpretation. Now I hope you don't mind but your response raises some new questions to me.
> 
> > 'The question "What is being offered?" is answered by the itemOffered property'...
> I understand that this is where triples come into play and that with it you can map relationships between entities but what confuses me is, when parsing markup like this through the different tools out there I get an array of types back which share the same properties. Doesn't this then imply there also is a relationship (even without the notation of itemOffered)?
> 
> If not, then when extracting the data of that multi-type entity ('Offer Service' - to stay with the example) don't things go wrong? 
> e.g. an Offer has a price property while Service doesn't. Doesn't this then give back back wrong/invalid data? 
> 
> 
> On Tue, Jan 7, 2014 at 4:20 AM, Dan Scott <dan@coffeecode.net> wrote:
> On Mon, Jan 6, 2014 at 11:43 AM, Jarno van Driel <jarno@quantumspork.nl> wrote:
> Somebody asked me yesterday why itemtype="http://schema.org/Product http://schema.org/Service"> has to be marked up this way just to be able to add an offer/Offer. He proposed to mark it up like itemtype="http://schema.org/Offer http://schema.org/Service">. Adding the Offer as a second type of Service and thus skipping Product all together.
> 
> In all honesty I couldn't come up with a reason why this would be a wrong notation. So I was curious, does anybody think this is valid markup and if not, why not?
> 
> My interpretation is that you would describing something that is both an Offer and a Service--which is subtly but significantly different from describing something that is an Offer to provide a Service. The question "What is being offered?" is answered by the itemOffered property, which links an Offer to a Product. In the proposed markup, there's nothing for that property to point at, so a consumer of the markup would likely consider it a dead end.
> 
> Of course, given enough encounters with this markup in the wild and/or a large enough customer insisting on the importance of this markup, it's possible that schema.org consumers would make a special case when they parse multi-typed items that include Offer as one of the types.
> 

--------------------------------------------------------
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 16:04:13 UTC