Re: Vehicles, and customizable products

Dear all:

I think that from a bird's-eye view, we must separate two issues in here

a) extending schema.org for cars (actual new and used vehicles vs. configuration information) and
b) defining a more advanced standard for exchanging such information in use-cases other than Web search engines.

Ideally, a) is a subset of b).

But I think that a fully-fledged approach for b) goes beyond what reasonably fits into schema.org.

Also, in general, I think that materializing rules a publishing time (e.g. publishing a finite set of available configurations) works better with Microdata-/RDFa-based data publication on the Web than publishing rules themselves (e.g. publishing the constraints and options). So the full Volkswagen COO approach may not be an exact fit for schema.org.

Martin



On Jul 26, 2013, at 8:41 PM, Francois-Paul Servant wrote:

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

--------------------------------------------------------
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 Monday, 29 July 2013 08:49:44 UTC