W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2006

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

From: Axel Polleres <axel.polleres@urjc.es>
Date: Mon, 04 Dec 2006 14:05:49 +0100
Message-ID: <45741D2D.1070804@urjc.es>
To: Bijan Parsia <bparsia@cs.man.ac.uk>, public-rdf-dawg@w3.org, public-rdf-dawg-comments@w3.org

(maybe we shouldn't parallel discuss this on both dawg-comments and 
dawg, so let me know which list is the proper one.)

Bijan Parsia wrote:
> Background view: I think this is great stuff, but I suspect the group  
> is swamped enough without trying to take on this additional chunk of  
> work. It does suggest that a SPARQL/Next, or SPARQL/Extensions is  worth 
> a continuance.
> I hate making this argument, because, esp. when a group has gone this  
> long, there is little energy or will to do the "next" bit. And "easy  
> wins" aren't necessarily so easy to get to spec, as I have to remind  
> myself over and over again.

Pitty, if so, as I tried to stress, I restricted myself to simple 
extensions which IMO are useful/needed. Let's see...

> On Dec 4, 2006, at 8:39 AM, Axel Polleres wrote:
>> 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 that'd be valuable, but seems baliwickwise, more of a RIF  thing 
> (though I don't exactly see how they could do it).

I am frankly unsure, whether RIF sees this in its scope, I rather doubt it.

>>> 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  
>>> 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.
> People are sort of doing this at the protocol level.

Interesting, can you explain this more concretely?

>> (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.
> [snip]
>> 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.
> That does seem reasonable and natural, if a bit tricky syntactically.  
> If I may make a point I've generally argued *against*....there is  
> nothing in SPARQL that forbids you from constructing graphs to be  
> queried in this way.
> Of course, that's not satisfactory in a number of ways. OTOH, do you  
> want to have *inline* recursively queried CONSTRUCTs? I.e., a change  to 
> the syntax? If not, I think that defining a little rules language  using 
> SPARQL and RDF is great, but perhaps doesn't need to be *in*  SPARQL.

No, I see this as a a combination of SPARQL and TURTLE. Small semantic 
differences like the different "PREFIX" and "@PREFIX" keyword should be
easy to solve. You could view this that you define data including
views or the other way around that you define a query along with some 
additional data...

> The pieces are sort of obvioius...you want a document format that can  
> include both RDF data and construct queries. You could use Turtle for  
> the RDF and regular SPARQL for the queries. The queries could be  
> restricted to be CONSTRUCTs and could implicitly query (and add to)  the 
> current document.


> I think RIF can do such a thing. Doesn't seem to step on anyone's  toes.

As I said, I am unsure whether RIF sees such a syntax in its scope, I 
doubt, currently, and saw it rather possible in DAWG. I assume the 
resulting RIF "syntax" more involved for such combinded data+rules 
bases. Assumed neither in the scope of RIF nor in the scope of DAWG, 
could you think of any other forum to devise such an 
extension/combination of TURTLE+SPARQL properly?

> More complex scenarios are possible where the constructs are  pulling in 
> from other documents and "dumping" into the current  context. Sounds 
> like good fun.

Yes, this was my idea with the "implicit" metadata use case in RIF.

>> 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!
> Is this necessarily true? I mean, it's definitely the case that if  you 
> are naive you'll run into trouble, but that seems surmountable.  For 
> example, you could require the constructed triples in any round  of 
> evaluation produce a non-equivalent graph. Is there a case where  
> something like this wouldn't ensure termination in the RDF case?
> (You have to either go with BNodes as existentials and use  
> equivalence/minimization, or you have to be very strict in the  
> distinction between source nodes and construct generated nodes.)

Hmm, I think only if bNodes are not involved in recursion, honestly...
I am not sure whether I get you here, bu at the very least, you'd run 
into troubles if recursion over MINUS (or, to stay with existing 
constructs with OPTIONAL+BOUND), i.e. possible non-mon... depends maybe 
on the semantics which you can apply for negation and is thus an open 
issue which needs more research. I chose the bNode-free restriction to 
stay within safe grounds.


Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/
Received on Monday, 4 December 2006 13:11:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:52 UTC