Re: Vehicles, and customizable products

Hi Francois,

> I am curious to know how you would do that. VSO recommends to make statements such as:
> foo:myCar vso:fuelType dbpedia:Diesel.
> 
> How can you adapt that to handle configurations? For configurations, you have to be able to state, for instance, that the fuelType may be diesel or gasoline, but not electric. I don't see how you can do that using the vso:fuelType property

you simply define three gr:ProductOrServiceModel instances:

foo:BaseConfig a vso:Automobile, gr:ProductOrServiceModel.

foo:DieselConfig a vso:Automobile, gr:ProductOrServiceModel ;
		 vso:fuelType <http://dbpedia.org/resource/Diesel>.

foo:GasolineConfig a vso:Automobile, gr:ProductOrServiceModel ;
		 vso:fuelType <http://dbpedia.org/resource/Gasoline>.

The you statet that foo:DieselConfig and foo:GasolineConfig are  gr:isVariantOf foo:BaseConfig.

foo:BaseConfig gr:isVariantOf foo:BaseConfig .
foo:DieselConfig gr:isVariantOf foo:BaseConfig .

By virtue of that, a data consumer knows that there 

- there is a base model without fuel type information and
- there are two variants (specializations) thereof, one with Gasoline, one with Diesel as a fuel type.

It does not explicitly tell you that there CANNOT be a variant with electric fuel, but since negation is a complex topic at Web scale, this is not really a shortcoming, as far as I can see.

And actually, you can model that in schema.org already as of now, if you use vso:Automobile or pto:Automobile with the additionalType property:


<div id="base_config" itemprop="isVariantOf" itemscope itemtype="http://schema.org/ProductModel" itemid="#BaseConfig">
	<link itemprop="additionalType" href="http://purl.org/vso/ns#Automobile" />
	<span itemprop="name">The ACME Base Car </span>
</div>

<div itemscope itemtype="http://schema.org/ProductModel" itemid="#DieselConfig" itemref="base_config">
	<span itemprop="name">The ACME Car with Diesel Engine </span>
	<link itemprop="http://purl.org/vso/ns#fuelType" href="http://dbpedia.org/resource/Diesel" />
</div>

<div itemscope itemtype="http://schema.org/ProductModel" itemid="#GasolineConfig" itemref="base_config">
	<span itemprop="name">The ACME Car with Gasoline Engine </span>
	<link itemprop="http://purl.org/vso/ns#fuelType" href="http://dbpedia.org/resource/Gasoline" />
</div>


The Google Structured Data Testing Tool will warn that it does not know the property <http://purl.org/vso/ns#fuelType>,

Error: Page contains property "http://purl.org/vso/ns#fueltype" which is not part of the schema.

but that is just cosmetics, since the tool could and should be configured to accept external properties as long as they use a full URI (or at least give a warning instead of an error).

So with adding VSO to schema.org, you could model at least basic variant information with schema.org. And it would be a minor task to implement that.

This does not reduce the potential of your more ambitious work in defining a full ontology for car specifications, but it would already get us far quickly, and that with a pattern that is the same for many vertical industries.

By the way: One small thing that I do not like about your proposal is that you say that a configuration is both a gr:MakeAndModel and a gr:Offering. Those are  two distinct entities, even if they often appear as a pair.

Martin


On Jul 27, 2013, at 9:40 AM, Francois-Paul Servant wrote:

> Hi Martin, and all
> 
> Le 26 juil. 2013 à 10:04, Martin Hepp <martin.hepp@ebusiness-unibw.org> a écrit :
> 
>> Hi all,
>> for the automotive segment, I strongly recommend integrating
>> 
>> 	http://www.heppnetz.de/ontologies/vso/ns
>> 
>> into schema.org.
>> 
>> It is a GoodRelations extension for all kinds of vehicles and will thus nicely fit to the already existing GoodRelations elements in schema.org.
>> 
>> Exposing configuration information can basically be done in two ways:
>> 
>> 1. Exposing the *rules* for compatibility of components; that is what Volkswagen does with their COO ontology,
>> 
>>   http://www.volkswagen.co.uk/vocabularies/coo/ns.html
>> 
>> 2. Exposing (a subset of) actually buildable cars or partly configured cars; this is what can be done with basic schema.org/GoodRelations/VSO elements, plus maybe the conceptual modeling work done at Renault.
>> 
>> For Web markup, I recommend the second route, but it will not require more than just translating the VSO ontology into a schema.org extension proposal, and I will tackle that as soon as my resources permit.
> 
> I am curious to know how you would do that. VSO recommends to make statements such as:
> foo:myCar vso:fuelType dbpedia:Diesel.
> 
> How can you adapt that to handle configurations? For configurations, you have to be able to state, for instance, that the fuelType may be diesel or gasoline, but not electric. I don't see how you can do that using the vso:fuelType property
> 
> Best,
> 
> fps
> 

--------------------------------------------------------
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/