From Wiki of the E-Business and Web Science Research Group
Jump to: navigation, search
GoodRelations is a standardized vocabulary for product, price, and company data that can be embedded into existing static and dynamic Web pages.

Project Main Page
Developer's Wiki
GoodRelations Cookbook

This page is a stub and will be completed shortly.

On this page, we will provide instructions on how to use the GoodRelations ontology without including an explicit products or services ontology, i.e., by specifying products and services mainly by textutal element.

Such can be useful if your source data (e.g. the RDBMS schemas of your Web shop) does not provide enough detail to automatically describe the products by references to eClassOWL or other ontologies.

This recipe can be complemented by Recipe 3 (reusing a merchant-specific catalog group structure).

This page is currently a stub. If you have any urgent questions, please contact Martin Hepp at mhepp<at>computer<dot>org.

Don't forget to make your RDF data known:

Alternatives for describing your products

In GoodRelations, you have at least three options for describing WHAT you are selling:

a) Use an existing, fully-fledged products or services ontology (e.g. eClassOWL). Many such ontologies are available or close to an official release. eClassOWL allows a much more fine grained description of the item, e.g. by ranges on properties etc. See


for details.

b) Turn an proprietary structure (e.g. a large merchant's catalog structure) into a proprietary ontology for products and services and describe your items by references to that structure. This approach is (partly) described in

The advantage is that you don't put a lot of burden on the publisher to lift his/her data. Alignments with other structures can then be established incrementally, elsewhere, and by someone else.

c) Describe the item lexically only. Example: default:SonyCellPhoneModel_s1234

     a gr:ProductOrServiceModel ;
     rdfs:comment "Sony cell phone model s1234, water-proof, shock-resistant"^^xsd:string ;
     foaf:page <> ;

In this case, you formally know only that what is being sold is a ProductOrServiceModel (or gr:ActualProductOrService or gr:ProductOrServicesSomeInstancesPlaceholder), and that it is described by a string that contains certain words.

But that may already be quite useful for queries - you can search for something that is a product and whose textual description contains the word "phone". And you have access to all commercial properties in a machine-readable way.

I assume that we can eventually get a really huge data cloud of product and offering data on the Web pretty soon.

Once that is done, we can start using all kinds of semantic technologies to establish links and alignments between the variants a), b), and c).

Materials to be added

II. As for describing WHAT you are selling, there are multiple options in GoodRelations:

a) Use a precise products and service ontology like eClassOWL - with that you can say that you are talking of "galvaninzed bolt"s with a particular gauge and resistance to corrosion etc.
Pro: Semantically precise, allows for parametric search
Con: Feasible only if your range of products is already classified, otherwise you must first classify all items manually.

b) Just make each product an instance of gr:ProductOrService (actually: one of its three subclasses) and describe it in natural language.
Pro: Easy to create, even for less structured sources or special things
Con: Not a lot of semantic (though the meta-data of GoodRelations provides already a lot of added value - if you know that something is a gr:ProductOrService, its price is 50$, and its rdfs:comment field contains the word "Guitar", you have a lot more certainty about whether this is what you are looking for and regarding its commercial meta-data).

c) Use a proprietary hierarchy and convert that into a products and services ontology (details are here:
Pro: Often not a lot of extra effort over b), users have access to the source hierarchy for navigation and search
Con: Semantic interoperability between multiple hierarchies remains difficult.

d) Using dbPedia entries - as you can see in the following paper, there are many striking arguments for that, in particular the broad coverage (more than 200,000 good categories - 8 times as much as eClassOWL contains).

Hepp, Martin; Siorpaes, Katharina; Bachlechner, Daniel: Harvesting Wiki Consensus: Using Wikipedia Entries as Vocabulary for Knowledge Management, IEEE Internet Computing, Vol. 11, No. 5, pp. 54-65, Sept-Oct 2007.
PDF at

Problems with this approach are that
- it is hard to filter out product categories from other dbPedia URIs (on the other hand, we could leave that up to human intelligence at the annotation stage). Also, basically everything that is an object could serve as a product (someone may offer New York city or the Moon for sale - legally problematic, but ontology-wise perfectly correct).
- Lack of formal attributes for describing the products in more detail.
- Difficult to implement for exports from Web shop software, since most businesses have not yet classified their products in terms of dbPedia URIs. So while ideal for manual descriptions using the GoodRelations Annotator, it is not perfect for bulk data exports.
- Mapping to industrial classifications, namely eClassOWL is difficult (same as with c)).

But basically we are in perfect agreement and we are already planning to add dbPedia URIs as an alternative approach for describing the type of product or service in more detail.

In the meantime, you can already do so manually by editing the RDF/XML file an attaching a link to the dbPedia URI of your choice.

foo:myProduct rdf:type gr:ActualProductOrServiceInstance
foo:myProduct rdf:type <>

However, one must be careful, because the semantics of the dbPedia URI for types of products is not necessary that of a class of functionally similar objects. dbPedia URIs can be interpreted both with a "topic" semantics or with a narrow "class" semantics. If used as a class, does <> subsume only actual TV sets or also user's manuals for TV sets?

But again - we are working on a model for the proper representation.