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

Bijan Parsia wrote:
> 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? 

With bnodes only in the WHERE clause, they can be treaded as variables,
I see no problem with this. Both stable (as proposed in the report) or 
well-founded semantics can handle non-stratified negation for non-ground 
programs (and coincide if negation is stratified).

With bNodes in heads, ie. head existentials, but without negation it 
seems to boil down at its core to Horn, so, yes, it should be decidable, 
since you can skolemize.

> The only thing generating BNodes, aside from lame RDF entailment,  

As for anything above RDF simple entailment, we run into all the same 
issues as the long list of recent "Combining Ontologies and Rules" 
papers list...

best,
axel

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


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

Received on Monday, 4 December 2006 22:26:54 UTC