- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 07 Aug 2014 11:48:32 +1000
- To: public-rdf-shapes@w3.org
On 8/6/2014 20:40, Dave Reynolds wrote: > a. Strictly SPARQL wasn't sufficient on its own without some > surrounding control machinery. Rules IC-20 and IC-21 are SPARQL > templates - you run one query then for each result from that query you > instantiate the template, then run all the resulting template instances. If I understand the problem correctly, IC-21 needs to walk a transitive path (*), and the issue is that SPARQL 1.1 path expressions can not contain variables. If this is correct, then I believe you could express this scenario with a recursive user-defined SPIN function [1]. The SELECT would become an inner select, and you would replace the FILTER NOT EXISTS with something like FILTER ex:myHelperFunction(?list, ?p) where ex:myHelperFunction would have an ASK query as its body that would call itself (or another helper function) recursively. Still not trivial, but I believe SPIN can help here because it extends the expressivity of SPARQL. We have used SPIN in similar ways in the past, e.g. to overcome problems with pre-bound variables in nested selects. > b. This is not a human readable way to communicate the constraints. > Even the simple cases require thought to interpret, IC-12 and IC-17 > are seriously confusing [1]. Again, user-defined SPIN functions can make these queries easier to read and maintain. You can refactor any complex snippet into a helper function with a suitable name, and then there is potential for code reuse. Maybe this would address some of your concerns. Holger [1] http://composing-the-semantic-web.blogspot.com.au/2009/01/understanding-spin-functions.html
Received on Thursday, 7 August 2014 01:50:07 UTC