This is the archive of the goodrelations dicussion list

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 
or
- 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.


Best

Martin Hepp