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

Seaborne, Andy wrote:
>>  > > 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).

agreed.

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

Hmm, yes, maybe too early to make a choice here at the moment, but 
without the dataset being explicitly specified, one never knows what the 
effect of non-monotonic combinations of OPTIONAL and !bound is, this is 
kind of a drawback in my opinion. This is what some people call "scoped 
negation". SPARQL allows scoped negation, but if the dataset is not 
explicit, then also the "scope" of negation is no longer excplicit.

That's why I opted to make domain closure explicit, if intended.

best,
axel



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

Received on Monday, 11 December 2006 08:50:18 UTC