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] Recurring patterns in GoodRelations and related ontologies (VSO, TIO, ...)

Martin Hepp martin.hepp at ebusiness-unibw.org
Tue May 3 14:38:58 CEST 2011

Dear all:

Some of you may wonder why GoodRelations and related ontologies do not offer constructs for rules of recurring patterns, e.g. "opening hours for every first Friday per month" or "Happy hour - every cocktail is $ 1 from 17:00 - 18:00". Here is a bit of background information:

Through painful iterations, I've learned that it is best to keep implicit rules constructs out of an OWL ontology because 

1. they do not match naturally to OWL DL semantics,
2. correct query results require a comprehensive reasoner (i.e.: without a reasoner, you usually do not get correct results), and
3. they are complicated to populate if the data is generated ad-hoc, i.e., not pre-materialized (e.g. based on a dynamic service).

Now, what this means for you or for anybody publishing any statement that follows a recurring pattern is simply to

- wrap a SPARQL endpoint around a Web service or other computational functionality that generates the respective fact on demand 
- materialize the data for each individual day or interval if the amount of data allows the full materialization.

For example, instead of hiding complex rules for "happy hour discounts on Fridays", one would simply generate one gr:Offering instance for every single Friday in question and constrain the validity of the offer or its gr:UnitPriceSpecification to the time-span on that day using gr:validFrom and gr:validThrough. This sounds like a lot of data, but 

- you do not have to materialize them in advance but can instead generate them at query time (e.g. Virtuoso has powerful middleware for such tasks; you can even express your rules in SPARQL CONSTRUCT syntax),
- from the query perspective, it does not make a difference whether a publisher materializes the data in advance or computes it at query time; they both use the same representation, and
- exceptions are natural to represent, without any constraints.

The Tickets Ontology (http://purl.org/goodrelations) uses this to the extreme in the sense that train connections are materialized for every single calendar day. Again, this looks like a lot of redundant data, but it allows to model delays or train cancellations with ease.


Martin Hepp

More information about the goodrelations mailing list