Re: Vehicles, and customizable products

Hi,

thank you for your message.

Le 26 juil. 2013 à 00:52, Thad Guidry <thadguidry@gmail.com> a écrit :

> Hi Francois,
> 
> Looked through your slides.
> 
> Regarding reference of classes for configuration options.  I am thinking that SKOS would be a way to handle this.  Freebase has some of those classes that your referring to as well, and some are even sometimes linked to a SKOS Concept already.  Like Diesel Fuel for instance... https://www.freebase.com/m/0l0xy?props=&lang=en&filter=%2Fbase%2Fskosbase%2Fvocabulary_equivalent_topic&all=true

regarding configuration options (what we call "specification" in our papers, which is the term used by ISO step AP 214, and which has the advantage of being more general than "options" or "features" - it could be, for instance, a given value of CO2 emission), one point is that we'll need some hierarchy of classes (eg an electric sunroof is a sunroof). This can be achieved with SKOS or with a simple RDFS hierarchy of classes.

> But your right, that there needs to be a domain specific vocabulary for "Automobiles" in general.  Most of the work that you (Renault) and Volkswagen have done, should really land in the form of better schema in Schema.org for the sale, and maintenance of Automobiles.

I imagine that search engines do not really need such a vocabulary - they can deal easily with statements such as
foo:myCar :hasSpecification "electric sunroof".
But for other agents that do not have the same capabilities regarding the handling of text, it would be useful to have well established thesauri with real identifiers.

> 
> The work just needs to be done.  That is, a Schema proposal for dealing with the specific domain of "buying and selling car configurations" and the maintenance of them.
> 
> I looked briefly at the "values", within one Spec you provide as output, such as: http://uk.co.rplug.renault.com/speccats/BAv#var_PT1633
> 
> That Spec doesn't mean anything to me.

this is not a "cold:Specification", but a "cold:ConfigurationVariable" (hence the "speccat" in the URI, for "Specification Category" - again a term from ISO step AP 214). A "cold:ConfigurationVariable" is something such as "Type of gearbox" or "body color" or "fuel type", etc.
When you dereference this URI, you get the following statements: (note that the data use "co" instead of "cold" as prefix for the configuration ontology - sorry for that)

:var_PT1633
      a       owl:Class , co:ConfigurationVariable ;
      rdfs:label "Gearbox Type"@en ;
      co:confVarId "PT1633" ;
      co:hasValue <http://uk.co.rplug.renault.com/spec/BAv/PT1633_manual_gearbox#this> , <http://uk.co.rplug.renault.com/spec/BAv/PT1633_automatic_gearbox#this> ;
      co:lexicon :this ;
      owl:oneOf (<http://uk.co.rplug.renault.com/spec/BAv/PT1633_automatic_gearbox#this> <http://uk.co.rplug.renault.com/spec/BAv/PT1633_manual_gearbox#this>) .

the label says what it is - at least to human users or to agents with some capabilities regarding the handling of text: it is the "Gearbox Type".
You may notice that we are still hesitating a little bit in the way to link a "Configuration Variable" to the corresponding Specifications (hence the "hasValue" and "owl:oneOf"). But basically, we can consider a ConfigurationVariable as a class of Specifications, cf., for instance, these other statements:

<http://uk.co.rplug.renault.com/spec/BAv/PT1633_automatic_gearbox#this>
      a       co:Specification , :var_PT1633 ;
      rdfs:label "Automatic Gearbox"@en ;
      co:specId "PT1633_automatic_gearbox" .

basically: an "Automatic Gearbox" is a "Gearbox type"

> Can you point me to your value Spec of say "gasoline as the fuel type that I want the engine to use" i.e. "Gasoline" such as this Freebase identifier for the same value : https://www.freebase.com/m/05wy2

One point in the data as it is returned today: there is one "Lexicon" (one dictionary of ConfigurationVariables, each with a list of corresponding "Specifications") for each car model (one Lexicon for "Twingo", another one for "Laguna", etc.). So for each model, there is one URI for the "fuel type" conf variable, and one for "gasoline" (except for models such as "Twizy", which are electric only).

This is clearly a problem: we have one different vocabulary for each different model. We're working on that and we will come with identifiers with a larger scope than the model (for instance, we'll have one identifier and one only for ConfigurationVariables, independently of the model - but Specifications are typically dependent of the model: eg. "Climate Control" or "Sunroof" can mean something different on an old entry-level model and a new top level model - so it is important to have different identifiers for them. Of course, in some cases, such as the "gasoline as the fuel type", it is stupid to have different identifiers - this will be solved in a next release of our system).

For now, there is one "gasoline as the fuel type" by model. Once you have the the corresponding Lexicon, eg."http://uk.co.rplug.renault.com/speccats/BAv", search for the corresponding label (and, hmm, I'm afraid you won't find "gasoline" - search for "unleaded petrol" and you'll get http://uk.co.rplug.renault.com/spec/BAv/PT1628_unleaded_petrol#this)

> 
> and "Hatchback" ? such as this Freebase identifier for the same value : https://www.freebase.com/m/01cmcs
> 
> I would ideally love to see a "data dictionary" or "guide" for your Specs so that others could help participate with you, and not have to deal with Configuration UIDs from your API service endpoint.  I think just providing the community with this data dictionary, would be extremely helpful to coordinate efforts all around with folks.

I'd love it too and we're working on that. As I said, we have to work internally to reduce the number of identifiers that we use for the same thing. But we also need some "reference vocabulary" that define classes of Specifications that we can map our terms to.

For instance: there are different kinds of sunroofs available in the Renault range, depending on the model (possibly, more than one kind for a given model). So we have specifications such as "laguna:Sunroof", "twingo:Sunroof1", "twingo:Sunroof2" (Twingo and Laguna are 2 Renault models) - these are Renault specifications, and we need to use these identifiers to describe our range (for several reasons - including the fact that we want to state things about them!)
What we need then are terms in a reference vocabulary that identify "Sunroof", but also "Electric Sunroof", "Panoramic Sunroof", etc. This could be a RDFS hierarchy of classes:
:Sunroof rdfs:subclassOf :Specification .
:ElectricSunroof rdfs:subclassOf :Sunroof.
:ManualSunroof rdfs:subclassOf :Sunroof.
:PanoramicSunroof rdfs:subclassOf :Sunroof.

Then we (Renault) could provide:
twingo:Sunroof1 a :ManualSunroof.
twingo:Sunroof2 a :ElectricSunroof.
laguna:Sunroof a :ElectricSunroof, PanoramicSunroof.

We've begun to work with Makolab and some others on the definition of such classes of specifications. 

>  Then a Schema proposal can then begin to surface that classifies Configurator options for consumers / buyers / dealers, etc. with the expected values used in the Automobile industry.

indeed

> 
> (and I could certainly help to fillout the holes in Freebase for various classifications and heirarchy where it's needed for this domain)
> 
> Thoughts ?

we have to work more :-)

Best,

fps

> 
> 
> 
> On Mon, Jul 22, 2013 at 8:01 PM, Francois-Paul Servant <francois-paul.servant@orange.fr> wrote:
> Hi,
> 
> among the topics under discussions listed on the "WebSchemas/SchemaDotOrgProposals" page of the wiki, there is an item "Vehicles", with the mention "A proposal extending schema.org for describing vehicles is being prepared." I searched this list, but I only found one relevant thread ("Schema for vehicles"):
> http://lists.w3.org/Archives/Public/public-vocabs/2012May/0096.html
> 
> Did I miss something?
> 
> If there are some discussions, I could maybe contribute, as I have been working on a closely related subject at Renault, and we have some results to share. Renault publishes indeed structured data that describe its range of new cars. This work has been presented at ESWC 2012 [1] and at LDOW 2013 ([2], slides [3]); to connect to the RDF data, see [4].
> 
> The main contribution of this work is a domain-independent proposal for the description of ranges of customizable products (new cars have many optional features, and, this is the tricky point, there are constraints between the features that invalidate some of their combinations: a range of new cars is a "Constraint Satisfaction Problem"). The idea is simply to publish as data the content of the pages produced by the configurator applications that are used to present such ranges to human users. The "Configuration as Linked Data ontology" [5] provides the vocabulary for that. This approach is domain independent: it can be used for cars or for, say, computers. It allows a manufacturer to publish a description of its range using its own terms (an important point, for at least two reasons: it is simple, and features are often unique to a given manufacturer). This description being linked data based, and the complexity of the reasoning required to handle the constraints being hidden from the client, it can easily be crawled by agents such as search engines.
> 
> It remains however that some form of shared vocabulary (or vocabulary alignment) is needed if one wants to develop applications that aggregate data from several vendors (eg. range comparators, market places): some shared terms are needed for, say, "Automatic gearbox" or "CO2 emission value" (that may not be necessary for search engines which are very comfortable with just text). Some work has begun on this question, with contributors such as Makolab, a company well aware of semantic web and of the automotive industry.
> 
> Hope this is of interest to some of you.
> 
> Best Regards,
> 
> fps
> 
> [1] "Product Customization as Linked Data", ESWC 2012
> http://link.springer.com/chapter/10.1007%2F978-3-642-30284-8_47
> [2] "Describing Customizable Products on the Web of Data", LDOW 2013
> http://events.linkeddata.org/ldow2013/papers/ldow2013-paper-11.pdf 
> [3] Slides, LDOW 2013
> http://fr.slideshare.net/fpservant/ldow2013 
> [4] http://purl.org/configurationontology/quickstart 
> [5] http://purl.org/configurationontology
> 
> 
> 
> -- 
> -Thad
> Thad on Freebase.com
> Thad on LinkedIn