W3C home > Mailing lists > Public > public-vocabs@w3.org > July 2013

Re: Vehicles, and customizable products

From: Francois-Paul Servant <francoispaulservant@gmail.com>
Date: Tue, 30 Jul 2013 12:53:41 +0200
Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-Id: <E08E148E-B467-4DA1-9E76-9EAEFD9D1AC1@gmail.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>

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

> Hi Francois-Paul,
> thanks - this is a very nice example! But before adding the respective conceptual elements to schema.org, we should carefully think about how the number of elements can be kept at a minimum. As a quick guess, I think that one or two specializations of the isVariantOf property and one or two subtypes of ProductModel should already get us very, very far.

ah, I should have read this earlier, cf one of my previous messages, where I say that only one "isVariantOf" property is not enough.
Well, as I said, the core of the cold ontology is really simple: 3 classes: Configuration (~ ProductModel), Specification, ConfigurationLink (a tool class, but very useful to precisely describe the link between 2 configurations), 4 properties (chosenSpec, impliedSpec, possible, impossible). Maybe it can be streamlined, I agree that some names can be made better - and I would welcome any suggestions. But to describe configurations, we need a little bit more than to just describe non customizable products.

> 
> I think that combining your model and types and properties from
> 
>    http://www.volkswagen.co.uk/vocabularies/coo/ns.html
> 
> would be a very powerful solution.
> 
> Volkswagen e.g. already provides
> 
> coo:BaseModel
> coo:ChoiceOrComponent
> coo:CompleteCarModel
> coo:ConfigurationInfo
> coo:Derivative
> coo:PropertySpecification
> coo:RelativePriceSpecification
> coo:SpecItemCollection
> coo:Trim

some of these are related to the "configuration problem" (compatibility rules), others to the description of cars (eg.: Trim and Derivative could be subclasses of Specification)

For the description of car, it would be good to have things defined in a ns that is not linked in any way to a given manufacturer

> 
> And since it directly snaps into GoodRelations elements in schema.org, this should minimize the amounts of extra properties.
> 
> Martin

Best,

fps

> 
> 
> 
> On Jul 27, 2013, at 9:29 AM, Francois-Paul Servant wrote:
> 
>>> The main contribution of this work is a domain-independent proposal for the description of ranges of customizable products
>> 
>> If you wonder how this could work with schema.org, you may have a look at the following page - Warning: this is just a test I made about the publishing of Renault data with RDFa (we only publish our data as pure RDF at this time), so it is just a static test page (the links do not work). It shows that it should not be a big problem to integrate our configuration data into schema.org (and goodrelations) markup: as it is, the results in Google's structured data testing tool are (almost) OK.
>> 
>> http://www.semanlink.net/2013/07/coldrdfa/conf.html
>> 
>> you can test its validity, extract the RDFa content, test it with Google's  testing tool, etc from here:
>> 
>> http://www.semanlink.net/2013/07/coldrdfa/
>> 
>> Some explanations: this is a typical page of a "car configurator" - one of these applications that allow you to choose a customizable product such as a new car, one step at a time, choice after choice. Any page of such an application describes a "Partially Defined Product", or "Configuration": in the example given, the page "Megane Hatch / Diesel / Automatic gearbox". A configuration is completely characterized (and can be identified), by the list of the selected "specifications" (= "feature" = characteristics of the product that the customer chose), here the list ("Megane Hatch", "Diesel", "Automatic gearbox"). Beside some general information about the Configuration (eg. it's "from price"), the main part of the page is a long list of "specifications" (all the specifications relevant for the "Megane Hatch" model). Among them:
>> - some have been chosen (in bold black with a check mark); eg. "Megane Hatch" (cf cold:chosenSpec property)
>> - some are implied by the selections (in black italics): eg. "Brake Assist" (all "Megane Hatch / Diesel / Automatic gearbox" have "Brake Assist") (cf cold:impliedSpec property)
>> - some are "possible" (blue link): they can be selected. Eg. "Cruise control with speed limiter" is compatible with "Megane Hatch / Diesel / Automatic gearbox". You can select it (cf "cold:possible" property)
>> - some are impossible (gray): they are not compatible with the previous selections (cf cold:impossible property)
>> 
>> The specifications are grouped by "category", or "Configuration Variable" (alternate white/gray background): among a given "category", one and only one specification can be chosen. 
>> 
>> Let's consider one of the possible specifications, eg. "Cruise control with speed limiter". If you click it, you'll be selecting the specification in question (well, it would be the case in a true application: here, the link doesn't work, as I said). The point is: the effect of the click would be to get (= "to dereference the URI of") the "Megane Hatch / Diesel / Automatic gearbox / Cruise control with speed limiter" configuration
>> This is modeled in the "Configuration As Linked Data" ontology by the fact that the range of the "cold:possible" property is the "ConfigurationLink" class, which is made of one "Specification" (eg "Cruise control with speed limiter"), and the URI of the refined configuration (eg. "Megane Hatch / Diesel / Automatic gearbox / Cruise control with speed limiter").
>> 
>> It has not been completely easy to get a markup that gives what I want in Google's testing tool, but it turned out to be almost possible.
>> 
>> Best,
>> 
>> fps
>> Le 23 juil. 2013 à 03:01, Francois-Paul Servant <francois-paul.servant@orange.fr> a écrit :
>> 
>>> 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
>> 
> 
> --------------------------------------------------------
> 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, 30 July 2013 10:54:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:28 UTC