Re: Vehicles, and customizable products

Hi Martin, all

Le 29 juil. 2013 à 10:24, Martin Hepp <martin.hepp@ebusiness-unibw.org> a écrit :

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

Ah, OK. One problem I see is the following: the 2 statements
foo:DieselConfig gr:isVariantOf foo:BaseConfig .
foo:DieselConfig vso:fuelType <http://dbpedia.org/resource/Diesel>.
are not semantically bound. There's  nothing that makes it explicit that a foo:DieselConfig is something whose vso:fuelType is dbpedia:Diesel. This will probably turn out to be a problem when trying to describe the features of the foo:DieselConfig configuration. Imagine for instance that all foo:DieselConfig have an automatic transmission. You will want to say something like:
foo:DieselConfig vso:transmission dbpedia:AutomaticTransmission.
so you will end up with:
foo:DieselConfig gr:isVariantOf foo:BaseConfig .
foo:DieselConfig vso:fuelType dbpedia:Diesel.
foo:DieselConfig vso:transmission dbpedia:AutomaticTransmission.
-> what does it mean to be a foo:DieselConfig?

A configuration API is not really difficult - but it is a little bit more complicated than describing a "completely defined product": there is a minimum of different things that have to be explicitly said in order to precisely describe a range of products.
- I don't think it is possible using only one property as you do here ("gr:isVariantOf")
- but it can remain really simple: our cold ontology has 3 classes (Configuration, Specification, ConfigurationLink), and 4 properties that describe the nature of the link between a Configuration and a given Specification: is the specification part of the definition of the configuration in question (= has it been chosen by the customer)? is it implied by customer's selections? is it possible? impossible?

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

it is necessary if you want to precisely describe an automotive range (cf the question of the "compatibility rules" between features: I want a diesel car with manual transmission). We allow it through our "cold:impossible" property (which allows to state which of the previous choices have to be changed if you want to select the "impossible" feature)

> 
> 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).

I don't know whether this is just cosmetics in Google's point of view. They seem to want to limit the number of different properties in schema.org, and that doesn't seem bad to me. On the other hand, they explicitly allowed external types (cf the additionalType property - even if the testing tool does not seem to take them into account for the moment: I hope that they will change that, but at least, there's no error when you use them). 

Adding vso as it is to schema.org would mean a lot of new properties. I am feeling  uncomfortable with this idea, for several reasons:

- there will never be enough of them: you are obliged to have some form of "vso:feature" (or "gr:feature") property. But if we are able to handle effectively specifications (features) with such a generic property, why would we need dedicated properties for, say, the fuel type or the transmission type? Actually, we do not need these dedicated properties, as we will see

- these dedicated properties are a nuisance for the producer of large amount of data.
A manufacturer has their data using intern identifiers - for instance, one manufacturer has some code that means "diesel". It can easily mint a URI (say x:Diesel) from this code. So, it is easy for the manufacturer to publish triples such as:
x:ACar :hasSpecification x:Diesel.
(and they have to describe their range this way, including on the web, see our paper at LDOW)

The problem comes if you want to later "improve" that data and produce a vso compliant triple such as:
x:ACar vso:fuelType dbpedia:Diesel.

You have to run some script that creates this vso compliant triple, and this has to be done for every triple involving x:Diesel.

It is much more easy to just state, once for all, that:
x:Diesel owl:sameAs dbpedia:Diesel.
dbpedia:Diesel a vso:FuelTypeValue.

to get the same in terms of actual information (just some simple rdfs inference is needed)

(stating the first one of these 2 triples would be the job of the manufacturer, or of any third party interested in the question; the second one should be done by the "community" interested in describing cars)

So, I think that the vso:fuelType property is not really useful - only the vso:FuelTypeValue is. What is important, on the other hand, is a reference list of URIs of vso:FuelTypeValue (which, BTW, VSO do not provide. I don't think that it is enough to just state: find something in dbpedia, or mint your own URI. A thesaurus should provide reference terms).

Note BTW that the statement
x:ACar vso:fuelType dbpedia:Diesel.
conflates 2 things:
- that x:ACar has the Specification dbpedia:Diesel
- and that dbpedia:Diesel is a vso:FuelTypeValue - which doesn't need to be repeated every time you describe a diesel car.

On the other hand, when you know that dbpedia:Diesel is a vso:FuelTypeValue, you cannot misinterpret 
x:ACar :hasSpecification dbpedia:Diesel. 
as meaning that dbpedia:Diesel is the color of the car!

I also think that you are very close to a very good solution with your announced "gr:feature" property. Hence something that could make a very short proposal for an extension to schema.org:
- a new Specification class, to represent characteristics of a Product (I prefer the term "Specification" to "Feature", because it is more general)
- a new specification property (domain: completely defined product, range: Specification)

this "specification" property is very close to your gr:feature property. The main difference is in considering that its range is the Specification class.

This would allow the full description of products in schema.org: one would use "additionalType" to describe the specifications of a product, eg.
x:ACar :specification [a vso:FuelTypeValue ; :name "Diesel"].
or better, using "car" as a ns where the community would define automotive related classes of specifications:
x:ACar :specification car:Diesel.
car:Diesel a vso:FuelTypeValue ; :name "Diesel" ; foaf:focus dbpedia:Diesel.

and this would leave open the possibility to describe configurations with the cold ontology, or with any other vocab one may prefer to use.

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

you're right that we had been saying something like that, but we have corrected it - with some hesitations on the best way to do. There are some arguments to consider a cold:Configuration as a subclass of gr:ProductOrServiceModel, and others to consider it as a gr:Offering - and I am OK that we cannot state both, if we want to follow GR's modeling - what we really want to do :-). So, we have to choose. For now in the published data, we're telling Configuration is a subclass of gr:Offering (an easy way to say that a Configuration "has a price"). But working on the RDFa markup for schema.org, it seems easier to consider a Configuration as a schema:Product - that's what I did in the test page I posted.

(BTW: a "SRP" price could nevertheless be considered as a characteristic of a product)

Best,

fps