Re: Prototype SPARQL engine based on Datalog and relation of SPARQL to the Rules Layer

Fred Zemke wrote:
> Axel Polleres wrote:
> 
>> * I'd like to suggest to the working group some straightforward 
>> extensions of SPARQL such as adding the set difference operator MINUS, 
>> and allowing nesting of ASK queries in FILTER expressions which come 
>> basically for free in the approach.
>>
>> * Finally, I discuss an extension towards recursion by allowing 
>> bNode-free-CONSTRUCT queries as part of the query dataset, which may 
>> be viewed as a light-weight, recursive rule language on top of of RDF.
> 
> 
> I think the ASK and CONSTRUCT ideas are very natural. I proposed them 
> when I first took a look at SPARQL,
> though my starting point was experience within SQL.

yes, I mention explicitly that these are "easy wins" in my opinion.

> SQL experience shows it is useful to be able to write subqueries.
> In SPARQL, two natural places to put subqueries are ASK inside of FILTER
> and CONSTRUCT inside of FROM.

> However, I don't follow you when you call CONSTRUCT inside of FROM
> "recursive".  I don't see a way, for example, to construct triples with 
> a verb
> "is_ancestor_of" from a graph containing the verb "is_parent_of",
> unless you have a priori information about the maximum number of
> generations in the graph.

I am not talking about nesting CONSTRUCT as you do (which by the way is 
another interesting idea, but, as you correctly point out, does not 
involve recursion. What I mean here is that CONSTRUCT queries should be 
allowed *as part of the dataset*.

I.e., the dataset is a set of RDF graphs *plus* views which define 
implicit triples within these graphs. (in the spirit of views in SQL). 
Since these views can recursively refer to the same dataset in the FROM 
clause, you have an implicitly recursive view definition.


Example:

"graph"  g1 is defined by the following triples
and CONSTRUCT query:
------------------------------------------------
p1 childOf p2.
p2 childOf p3.
CONSTRUCT { ?P1 ancestorOf ?P2 . }
FROM g1 WHERE {{p1 childOf p2} UNION
            { ?P1 childof ?P3. ?P3 ancestorOf ?P2. } }

------------------------------------------------

Now you pose query:

SELECT ?P1 P2
FROM g1
WHERE { ?P1 ancestorOf ?P2 . }

clearly, the CONSTRUCT as part of the dataset is recursively
referring to the same dataset, so the semantics should be the transitive 
closure in my opinion. Advantages of allowing such implicit definition
of metadata within RDF are e.g. explained in RIF use case 10, see
http://www.w3.org/TR/rif-ucr/#Publishing_Rules_for_Interlinked_Metadata

and what I wanted to achieve was using SPARQL CONSTRUCT as one possible 
syntax for this.

Hope this clarifies matters.
Note I suggest here to only allow bNode-free CONSTRUCTs,
within graphs since otherwise you won't reach a fixpoint
when evaluating this query!

best,
axel



> Rather, I would position CONSTRUCT inside of FROM as the ability
> to create what SQL folks call an in-line view.  One benefit of in-line 
> views
> would be that one developer could design an in-line view that
> other developers (or self, later in time) would simply cut-and-paste into
> their work.  This spares the need to re-invent a wheel.
> 
> Anyway, at the time I proposed these ideas, they were acknowledged
> as good but to be saved for an r2 version of SPARQL.
> 
> Fred
> 
> 
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Monday, 4 December 2006 09:44:52 UTC