- From: Martynas Jusevičius <martynas@graphity.org>
- Date: Mon, 3 Aug 2015 11:16:27 +0200
- To: public-declarative-apps@w3.org
- Cc: Arto Bendiken <arto@dydra.com>, Džiugas Tornau <dziugas@graphity.org>, Ignas Tornau <ignas@graphity.org>, colin@maudry.com, James Anderson <james@dydra.com>
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