Template processing model

Hey,

I would like to ask you for feedback on the template processing model
used in Graphity. This is the last key piece of logic to be finished
before the next release of our processor.

A template is an OWL class that has gp:Template type and annotation
properties from GP vocabulary. gp:uriTemplate holds value of a URI
template that is matched against the request URI.

In general the mechanism is similar to XSLT, which uses XPath pattern
for matching instead of URIs:
<xsl:template match="*"/>

We have a couple of issues though.

1. Annotation inheritance

We have a concept of annotation property inheritance: templates can
have subclasses (sub-templates) that override specific properties and
inherit the rest from the superclass:

<#Template> a gp:Template, owl:Class ;
  rdfs:subClassOf imp:Template ;
  rdfs:isDefinedBy <#> .

imp:Template a
  gp:uriTemplate "path" ;
  rdfs:isDefinedBy imp: .

Since <#Template> does not have the gp:uriTemplate annotation, but is
a subclass of a class that does, the following is inferred:

<#Template> gp:uriTemplate "path" .

Other annotations, such as gp:skolemTemplate, gp:defaultLimit etc.,
are inherited the same way.

I don't think OWL provides this kind of inference - the only similar
topic I could find was this thread:
https://mailman.stanford.edu/pipermail/protege-owl/2010-July/014699.html
SPIN however does the same subclass based inheritance for queries:
http://spinrdf.org/spin.html#spin-class-description

So currently the inherited properties are materialized (before doing
any template matching) using this huge CONSTRUCT:
https://github.com/Graphity/graphity-processor/blob/master/src/main/webapp/WEB-INF/web.xml#L49

It works, but it is not general enough since it has a fixed subclass
depth (currently 3). Therefore I'm leaning towards a more recursive
approach that would traverse subclass paths. Not sure if it requires
SPARQL at all, or if Jena API would suffice. Maybe you have ideas?

2. Import precedence & Conflict resolution

Like in XSLT, templates are grouped in modules (ontologies) that can
import each other using owl:imports. XSLT defines import precedence
based on import order/depth, so that templates from importing
stylesheet have higher precedence than those from imported
stylesheets:
http://www.w3.org/TR/xslt20/#dt-import-precedence

JAX-RS provides an algorithm for determining URI template precedence.
So we can select the best matching template(s), but like in XSLT,
there still can be a conflict when the request matches more than one
template:
http://www.w3.org/TR/xslt20/#conflict

This is where import precedence comes into play. We wanted to
implement a mechanism similar to XSLT, but since there is no ordering
of owl:imports, I can only rely on import level (depth) starting from
the root ontology (the configured sitemap). Do you think it's good
enough? Another alternative would be to create a parallel import
mechanism with ordering, e.g. gp:imports (gpl: gp:).

It would be great to hear your thoughts.

Martynas

Received on Monday, 3 August 2015 09:16:56 UTC