Warning: This tool or project is no longer maintained and kept available only for archival purposes. Since GoodRelations and schema.org have evolved significantly in the past years, the current status available on this page is unlikely to function as expected. We take no responsibility for any damage caused by the use of this outdated work, to the extent legally possible.

Due to a lack of resources, we are unable to provide support for this project outside of consulting projects or sponsored research. Please contact us if you can contribute resources to update and enhance these resources.

GoodRelations - The Web Vocabulary for E-Commerce

This is the archive of the goodrelations dicussion list

GoodRelations is a standardized vocabulary for product, price, and company data that can (1) be embedded into existing static and dynamic Web pages and that (2) can be processed by other computers. This increases the visibility of your products and services in the latest generation of search engines, recommender systems, and other novel applications.

[goodrelations] vso:feature, dpPedia and productontology

François-Paul Servant fps at semanlink.net
Mon Jan 28 11:19:07 CET 2013

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.


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/

More information about the goodrelations mailing list