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

some more issues inline... (copied dawg-comments again, hope this is ok.)

Seaborne, Andy wrote:
> -------- Original Message --------
> 
>>From: Axel Polleres <mailto:axel.polleres@urjc.es>
>>Date: 4 December 2006 17:40
>>
>>Seaborne, Andy wrote:
>>
>>>-------- Original Message --------
>>>
>>>
>>>>From: Axel Polleres <mailto:axel.polleres@urjc.es>
>>>>Date: 4 December 2006 17:05
>>>>
>>>>Seaborne, Andy wrote:
>>>>
>>>
>>>>>What's the use case for MINUS?
>>>>
>>>>set difference, ie not being forced to use the weird
> 
> OPTIONAL/!BOUND
> 
>>>>combination for this.
>>>
>>>
>>>That's not a use case - I was wondering what new capabilities, what
>>>new query tasks, this makes it easier for the apoplication writer.
>>>It's not a technology question - it's a value querstion.
>>
>>ah, I see. No, my point was really only... if it is already there, why
>>can I not write it directly. :-) 
>>
>>I didn't want to do rocket science either with the paper, just
>>bridging the gap to the rules world...   ;-)
> 
> A fine thing to do - my caution comes from the fact the SW Rules World
> is still "unstable".
> 
> 	Andy

- Precisely, but this is no argument against, I assume?
   What I say that
    a) SPARQL itself can be viewed as an SW rules langyuage (in case RIF
       doesn't come up with something like that... one valid starting
       point in my opinion, not implying additional work for DAWG and
       this is only a personal and not a RIF opinion of course)

    b) the rules fragment I am referring to is well-studied and
       -established, when I meant "rules world", I menat this fragment
       which is at the core of what most proposals for SW rules language
       should be able to handle and not a particular SW rules language

    c) SPAQRL is also not 100% stable and still a bit in flux
       was at least my latest impression correct me if I am wrong.

- as for your examples about "changing" SPARQL:

 > > 1/ Treatment of nested optionals (discussed in Richard's and Jorge's
 > > work and most people agree with the change - i.e. not queries anyone
 > > cares about!

What is the problem here? I am not aware that I change the semantic of 
nested optionals, I was following exactly Joprge's approach here, in 
order to stay compositional.

 > > 2/ Treatments of filters in OPTIONALs
 > >
 > > { ?x foaf:age ?age . OPTIONAL { FILTER (?age > 18 ) . ?x foaf:name
 > > ?name } }

This is a nasty one... but I could make it work with a slightly modified 
b-join translation in my approach, if the group wants this.
In this context you write:
"The semantics for SPARQL have, so far, been declarative and top-down."
What I propose is a translation to allow also bottom-up evaluation.
I can do the other treatment of FILTERs as well, but it would need to 
separate BGPs from FILTERS and you'd need to track down the joining BGP 
for corresponding FILTERS in the translation.

Need to check details though, and after all, as said in the thread by jorge,

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Oct/0030.html

  this drops compositionality... Is this really what the group wants???
I didn't find a resolution on this question upon quick browsing of the 
archives and would be glad for a pointer.

You further mention in your blog:
"The complexity of the exact mapping to SQL in the semantics preserving 
SPARQL-to-SQL is daunting."
Note that I still need to check
http://www.cs.wayne.edu/~artem/main/research/TR-DB-052006-CLJF.pdf
but: my translation is intertranslatable with SQL, since I use 
non-recursive datalog with negation which is well-known to be
translatable to SQL and corresponds with Jorge's semantics.


 > >3/ In your case - the treatment of datasets. Two common use cases
 > >  are the defauilt dataset being the RDF merge of the named graphs,
 > > or the default graph is the manifest of the named graphs.  As the
 > > default graph is the true statements and the ones in the named
 > > graphs are quoted, there is a semamtci web difference between the
 > > two kinds.

Sure, I call the former "domain closure assumption" in my report, but I 
do not enforce it, so also the latter is fine. This brings me to think 
that it probably would be convenient to have this maybe explicit in the 
language, and not just leave it to the implementation, right?

e.g. distinguish between explicit:

  FROM g1
  FROM NAMED g2, ...

and implicit, e.g. by introducing something like:

  FROM g1
  FROM NAMED CLOSURE

or so (admittedly this first suggestion might not look very 
appealing...).  I do not expect this to go in the current spec of 
course, but anyway, it would be better to make it explicit when the 
NAMED graphs are implicitly given with the default graph, or no?

best,
axel

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

Received on Wednesday, 6 December 2006 10:53:27 UTC