wurvoc.org - linked open data for Quality of Life

I am proud to announce the official launch of wurvoc.org. Built by the Intelligent Systems Group at Wageningen UR Food & Biobased Research, the goal of wurvoc.org is to serve as a hub for various vocabularies and semantic web services we have developed and are still developing. Many of these vocabularies (modeled in RDF and OWL) have been built using public funding and we feel it important that this information is also publicly available in a way that is open and reusable.

Vocabularies

Currently, wurvoc.org publishes 4 vocabularies:

• The Ontology of Units of Measure models concepts and relations important to quantitative scientific research. It has a strong focus on units and quantities, measurements, and dimensions.
• The Food Additives vocabulary describes substances added to food to improve the flavour, taste, shelf-life, stability et cetera of the food product. Food additives that are approved by EFSA, the European Food Safety Authority are labelled with an E-number.
• The Dairy ontology contains a hierarchy of types of dairy products and provides general information about these products.
• The Drinks vocabulary contains a classification hierarchy of various types of beverages.

Our aim is both to publish more vocabularies and data in the near future, and to extend and improve the current vocabularies: although the data is Open, it is not yet truly Linked in the sense that it has very few relations with external datasets.

Software

We've developed the wurvoc publication platform, a set of REST services on top of the Sesame framework. In line with linked data principles, the platform publishes each vocabulary and each vocabulary term on its own URI. For example, an ontology on food additives is available at http://www.wurvoc.org/vocabularies/food-additives/, and the food additive Pectin is reprsented by http://www.wurvoc.org/vocabularies/food-additives/Pectin.

The platform uses HTTP content negotation to determine the representation format, currently supporting XHTML, RDF/XML, Turtle, N3, NTriples, and TriG (with JSON on the ToDo list).

OUM Web Services

Apart from a vocabulary publication platform, wurvoc.org also offers a number of SOAP-based web services on top of the Ontology of Units of Measure (OUM). These web services provide a number of useful functions, including lookup and matching functions as well as more advanced stuff, such as unit conversion or formulaic consistency checking.

Future plans

We are aiming to publish the publication platform software as open source as soon as possible. Various improvements are also planned, including a SPARQL endpoint and support for JSON.

I'd very much like to hear your comments on what we've brewed sofar, what you think is good and what you think could be better. I encourage you to reuse our linked data (and would appreciate it if you could let us know if you do).
I also plan to keep you up to date on our findings regarding use, performance, and general lessons that we learn after the launch of this project. Watch this space :)

Simple rules using construct queries in Sesame

A while ago I put together a simple rule-based reasoner for Sesame 2 (available in Aduna's Sesame extension SVN). The idea was to have a configurable rule-based reasoner that would reuse Sesame's query engine (in combination with SeRQL/SPARQL CONSTRUCT queries) to perform simple customized entailment.

The idea is fairly simple: the reasoner works as a stacked SAIL in Sesame's repository configuration (the SAIL is a Sesame internal api that wraps the physical data storage medium). Rules are defined in an RDF format that reuses SeRQL syntax for defining graph patterns. By adding these rules to the Sesame repository the reasoner picks up on them, creates actual SeRQL CONSTRUCT queries out of these rules and then uses Sesame's own query engine to execute the rules, adding the rule result back into the repository.

For example, a rule defining that an uncle of some person P is the brother of one of the parents of P would look like this (using Turtle syntax):

ex:defUncle a custom:Rule;
   rdfs:comment "my parent's brother is my uncle";
   custom:head "{X} ex:uncleOf {Y}";
   custom:body "{X} ex:brotherOf {} ex:parentOf {Y}" .

The reasoner would translate this to the following SeRQL query:

 CONSTRUCT {X} ex:uncleOf {Y}
 FROM {X} ex:brotherOf {} ex:parentOf {Y} 

For those of you not familiar with SeRQL, the SPARQL equivalent would look like this:

 CONSTRUCT {?X ex:uncleOf ?Y }
 WHERE {?X ex:brotherOf ?Z.  ?Z  ex:parentOf  ?Y. } 

I've recently returned to this reasoner, for use in the Tiffany project. In this project, we are developing a Research Management System for researchers in the food industry, and one core concept in this system is a hierarchy of Research Questions and associated activities. Each activity is used by at least one team, and we need to keep a number of things up to date. For example, if a Research Question has an associated activity that is used by team X, the research question itself should also be marked as "used by team X". Moreover, if a research question A has a subquestion B, and that subquestion is used by team X, then research question A should also be marked 'used by team X'.

Previously we tried to support this from code, by explicitly calculating and asserting RDF triples for the 'isUsedBy' relation whenever an activity is linked to (or unlinked from) a research question, or whenever the research question hierarchy is changed. However, the seemingly simple rules for entailment of isUsedBy quickly become devilishly complex when implemented in an imperative fashion. The function that deals with this is well over 100 lines of code. Now, compare that to the rule-based approach:

 tifrule:activityUsedBy a custom:Rule ;
    custom:body "{X} tifn:activity {Y} tifn:isUsedBy {T} " ;
    custom:head "{X} tifn:isUsedBy {T} " .

 tifrule:inheritanceUsedBy a custom:Rule ;
    custom:body "{X} rdf:type {tifn:ResearchQuestion} ;
                     tifn:isUsedBy {T} ,
             {Y} tifn:hasSubQuestion {X} " ;
    custom:head "{Y} tifn:isUsedBy {T} "

Simple. And from some early tests I ran, remarkably good performance too.

Next steps are to investigate how the performance of the approach holds up when I add more rules, and when I start doing many updates on the repository (after all, it's nice if querying is quick, but we also expect users to add new data or update existing information, and that requires that we do not have a large performance penalty for updates).