This is the archive of the goodrelations dicussion list

My suggestion is that if you as a vendor have the authoritative power to define a certain feature, you should do so, e.g. as Volkswagen is doing in the VVO:

http://purl.org/vvo/ns#GearboxDSG

If you want to provide more information, you could alway define a value instance of a value type in your own namespace.

The DBPedia recommendation is for those cases when a single data publishers is looking for a globally recognized identifier for a feature but does not have the power to introduce one, e.g. Peter Miller selling his car.

Note that you should rather not use www.productontology.org classes for types of *features*, since they are designed to represent types of *products or services*. In some cases, a feature can be a product at the same time, but in many cases that does not hold.

Also, I think that the new gr:ProductFeature pattern in the next GoodRelations release will provide a simpler mechanism for such scenarios anyway.
Martin

On Jan 28, 2013, at 5:19 AM, François-Paul Servant wrote:

> Hi Martin,
> 
> thank you for your answers.
> 
> I understand the difference between instance and class. My remark is more about usability and extensibility of the statements that we can make if we follow the recommendation to use dbPedia URIs as values for vso:feature-like properties vs if we use instances of the product ontology classes
> 
> For instance, in the case of body styles, we could imagine to have 2 kinds of station wagons: full-size wagons and two-doors wagons (there are no corresponding URIs in dbPedia, but that's not the point here - let's imagine there are). One could want to state something like
> 
> foo:myCar vso:bodyStyle <http://dbpedia.org/resource/Two_doors_wagon>.
> 
> still hoping consumers of the data be able to infer that this is a special kind of station wagon. For that, we would need to have defined some kind of hierarchy between the values of body style. It could be defined using SKOS (OK with individuals, but dbPedia entities are not supposed to be skos concepts), or a hierarchy of classes.
> 
> I think therefore that it would be better to use statements such as:
> foo:myCar vso:bodyStyle [
> 	a productontology:Two_doors_wagon.
> ].
> because if it is said somewhere that
> productontology:Two_doors_wagon rdfs:subClassOf productontology:Station_wagon
> we can infer using very simple reasoning that myCar's body style is also Station wagon.
> 
> This argument against using dbPedia URI is probably not that strong for properties such as body styles, which have a limited, stable list of possible values. But for features, I think it is: a constructor describing the features of its range will not want to say, for instance:
> foo:myCar vso:feature dbPedia:SunRoof.
> It will want to say that:
> foo:myCar vso:feature [
> 	a productOntology:SunRoof ;
> 	rdfs:label "Very large super cool sun roof different from all others";
> 	…(description of that wonderful sun roof: pictures, link to marketing blabla, etc)
> ]
> 
> If you use a dbPedia URI as object in a statement involving vso:feature, you cannot give additional information about the feature in question. And, as a vendor, you want to. So I think that it can be counterproductive to advertise such a practice.
> 
> fps
> 
> Le 28 janv. 2013 à 10:07, Martin Hepp <martin.hepp at ebusiness-unibw.org> a écrit :
> 
>> Hi Francois-Paul:
>> 
>> On Jan 26, 2013, at 7:59 AM, François-Paul Servant wrote:
>> 
>>> In http://www.productontology.org/#faq
>>> I read:
>>> "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because
>>> - they lack a suitable semantics for being used as classes, and
>>> - they are not valid OWL DL."
>>> 
>>> In http://www.heppnetz.de/ontologies/vso/ns#feature
>>> the comment about vso:feature says:
>>> "Use DBPedia resources to indicate the features, if possible."
>>> 
>>> I don't see what they should be a difference between a product and a feature of a product wrt their modeling
>>> 
>>> If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron
>>> it must also be bad to say that
>>> foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner
>> 
>> The answer is simply, yet it may not obvious, so thanks for the question:
>> 
>> You can (and should) use suitable DBPedia URIs for *instances* (individuals), but not for *classes* (types).
>> 
>> All examples in the Vehicle Sales Ontology (http://purl.org/vso/ns) and other GoodRelations extensions say that you should rather use DBPedia URIs for instances of predefined value *types*.
>> 
>> Example:
>> 
>> VSO defines
>> 
>>   http://purl.org/vso/ns#BodyStyleValue
>> 
>> as the range for 
>> 
>>   http://purl.org/vso/ns#bodyStyle
>> 
>> You can use
>> 
>>   http://dbpedia.org/resource/Convertible
>>   http://dbpedia.org/resource/Hatchback
>>   http://dbpedia.org/resource/Station_wagon
>>   http://dbpedia.org/resource/Sport_utility_vehicle
>>   http://dbpedia.org/resource/Roadster
>> 
>> as a value for that property, in statements like
>> 
>> foo:myCar vso:bodyStyle <http://dbpedia.org/resource/Convertible> .
>> 
>> An OWL/RDF reasoner will infer then that
>> 
>> <http://dbpedia.org/resource/Convertible> rdf:type vso:BodyStyleValue
>> 
>> which is perfectly fine.
>> 
>> Hope that helps!
>> 
>> Best
>> Martin
>> 
>> 
>> 
>>> 
>>> 
>>> Best,
>>> 
>>> fps
>>> _______________________________________________
>>> goodrelations mailing list
>>> goodrelations at ebusiness-unibw.org
>>> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations
>> 
>> 
>> 
>> --------------------------------------------------------
>> martin hepp
>> e-business & web science research group
>> universitaet der bundeswehr muenchen
>> 
>> e-mail:  hepp at 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/
>> 
>> 
>> 
> 
> 
> _______________________________________________
> goodrelations mailing list
> goodrelations at ebusiness-unibw.org
> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations

--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp at 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/