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

Axel Polleres wrote:
> some more issues inline... (copied dawg-comments again, hope this is ok.)

public-rdf-dawg-comments@w3.org is open to everyone for sending comments to
the working group.

Although we seem to use it for discussions as well - as long as things don't
get lost, I don't mind.

This reply is not endorsed by the WG.

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

It changes it from the existing published document.  Personally, I think that 
change is a good one.  I've never seem a real-life query with the form that 
would be affected so users aren't affected, and there are implementation 
advantages.


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

I have seem many queries with the this form so I have proposed for that to
happen.  I'll take discussion of this to the other thread fro Jorge if I may.

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

That's a bit out of context - the ref'ed paper describes a translation of
SPARQL OPTIONALs with declarative semantics to SQL, including getting the
nested cases right.  That's what I was describing as "daunting" - interesting 
translation, quite tricky.  Translating compositional SPARQL to SQL is very 
close to a 1-1 translation of the algebra into SQL operations (one case where 
people are using COALESCE).

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

I don't see why we need to force the choices here.  There are other ones that 
might reasonably turn up (such as having raw aBox, and inference 
engine+tBox+aBox) and ones we haven't though of yet.  The spec is about a 
mechanism to allow the application to set up what it wants.

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

	Andy

Received on Thursday, 7 December 2006 16:50:32 UTC