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

On 4 Dec 2006, at 13:05, Axel Polleres wrote:

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

No idea ;) Probably comments.

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

I agree with that evaluation, but my bitter experience is that change  
is tricky and expensive. I put a lot of work into coming up with what  
I thought was a useful and relatively straightforward version of  
distinct and, while there was some interest, the group didn't go for  
it, even as an additional option, for what seem to be reasonable  
reasons. Maybe this is a less large leap.

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

Then I would imagine it's out of scope for DAWG. However, a working  
group note (or member submission) would be a reasonable way to go.

[snip]
>> People are sort of doing this at the protocol level.
>
> Interesting, can you explain this more concretely?

Well, if you have an endpoint which provide dynamically the results  
of a construct, you can at least chain queries. Recursing them isn't  
done to my knowledge.

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

Great. Then it's going to be out of scope of this round. OTOH, it  
doesn't require a change to SPARQL at all. (ASK as filters might be  
handled by the filter operation extension mechanism?)

[snip]
>> 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?

Well, I can think of a number of people who might be interested in  
such a thing, but no formal body at the moment seems ready to address  
Yet Another Rules Language, even on that is a neat extension of  
SPARQL. Probably the best thing is to write up a spec and try it as a  
member submission. If you were a working group member and the WG felt  
engaged on it, it could be a working group submission.

I'm not active at the moment in the group, so I certainly wouldn't  
want to champion more work for them.

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

Ah, yeah. I tend to only think of positivew sparql queries.

Aren't you going to have to be careful about negation anyway?  
Forgetting whether naive or semi-naive style evaluation would work  
(without care), do you think such rules (with BNodes) are decidable?  
The only thing generating BNodes, aside from lame RDF entailment,  
would be the construct rules but the only terms they can synthesize  
would be BNodes, so at some point they'll "run out" of other terms to  
combine and thus start generating merely redundant BNodes, I would  
think. (Writing completely without a net :)). In the OWL case, hmmm,  
allowing BNodes in the construct might not be as bad as allowing non- 
distinguished variables (which would put you in, or close to, SWRL,  
yes?)

> I chose the bNode-free restriction to stay within safe grounds.

Yes, which, alas, tends to be a non-starter in this space, at least  
for standardization. Though it's hard to say, given SPARQL's  
skolemizing treatment of BNodes.

Interesting.

Cheers,
Bijan.

Received on Monday, 4 December 2006 13:59:37 UTC