W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Re: W3C Data Cube spec uses SPARQL too

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Thu, 07 Aug 2014 08:44:16 +0100
Message-ID: <53E32E50.6030106@gmail.com>
To: public-rdf-shapes@w3.org
On 07/08/14 02:48, Holger Knublauch wrote:
> 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.

Correct.

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

Sure. There's lots of rule style languages that you can write such 
things in. My only point was that it is not pure SPARQL.

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

Sure, packaging queries and query fragments as templates and labelling 
them is useful documentation. I've used various systems for that over 
the years. The requirement here is stronger than that. The need is for 
some "language" (a systematic, composable structure - not talking about 
syntax) for expressing "shapes". A library of templates doesn't feel 
like a very satisfactory answer for that need, but it might the best the 
WG will achieve.

Dave
Received on Thursday, 7 August 2014 07:44:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC