Re: Another attempt...

Andrew Newman wrote:
> On 19/03/2008, Lee Feigenbaum <lee@thefigtrees.net> wrote:
>> Can you explain either where the specification is incomplete with
>>  regards to evaluating this query or else what you'd prefer the results
>>  of this query to be?
>>
> 
> This is very frustrating my first email had the example queries.  I
> said the results of:
> select *
> where {
>  {?s ?p ?o} . {}
> }
> 
> Contradicts the results of:
> select *
> where {
>  {?s ?p ?o} union {}
> }
> 
> I suggest that the second query return {} (as {} is defined in the SPARQL spec).

This is still unclear to me :) First of all, what dataset are you 
proposing these queries be evaluated against? An empty default graph or 
a default graph with triples? Are you saying that you believe that the 
SPAQL Recommendation specifies that both of these queries should return 
an empty solution set ({}) or are you saying that you acknowledge that 
it doesn't but wish that it did?

> The results don't make sense with respect to JOIN identity (which is
> defined in the SPARQL specification).  Unless SPARQL is creating its
> own algebra (if it is it has a lot of explaining to do - which I'm
> happy to read) and is ignoring existing set and/or bag algebra then
> the current results being returned by most/all SPARQL implementations
> is wrong.

Again, are you saying wrong in the sense of:

1) the implementations do not abide by the SPARQL specification, or
2) the implementations abide by the specification, which is not the 
results you'd desire to see?

> I'd suggest the SPARQL group does reuse existing algebras.  Wikipedia
> has some nice articles on bags and set algebras:
> http://en.wikipedia.org/wiki/Algebra_of_sets
> http://en.wikipedia.org/wiki/Multiset
> 
> I suggest the working group reads these, understands them (especially
> proposition 3 of the algebra of sets and multisets just being sets
> with cardinality) and adopts them.  This will help implementers and
> users of SPARQL if it reuses an existing algebra.
>
> I did try and give helpful alternatives:
> * Make the empty group pattern act like empty set (as it's the closest
> conceptually) and add a new universal group pattern.  Or maybe just
> change the syntax, rename it and make the description more clear.
>
> * Define a union identity and maybe make it expressible.
> 
> * Complete specifying identities in the SPARQL document.  What does 1
> do in respect to UNION?  And possibly 0 in respect to JOIN.  The way I
> was able to determine what 1 does with respect to UNION was run ARQ
> and the answer (A + 1) wasn't correct at least with respect to set and
> relational algebra.  Maybe it's defined in the set of tests (I haven't
> checked) but it should be in the document too.  Anyway, it's not clear
> why it's different to existing algebras (maybe add that too?).

OK, thanks. It sounds like you are asking for changes to the SPARQL 
syntax, algebra, and/or specification. The W3C membership endorsed 
SPARQL as a Recommendation in January, and the Working Group is not 
actively pursuing the design of the language (either the syntax, the 
algebra, or the document) at this time. We are collecting errata 
(mistakes in the specification, usually expressible as test cases for 
which the specification's demands do not match the WG's intentions) and 
feedback for future activity on SPARQL by the DAWG or other working groups.

I can't speak for future groups, but I believe that regarding your three 
specific suggestions here:

1) The first is unlikely to happen given the significant number of 
deployed implementations and uses of SPARQL that expect the current 
semantics from the empty group pattern SPARQL syntax.

2) Is a potential action that a future Working Group could take if they 
desire. For now, you can use { A } UNION { FILTER(false) } as Andrew 
suggested.

3) Again, this is action a future WG could take as could other 
individuals or organizations (as in the case of the Perez et al. paper 
that you cited previously).

thanks,
Lee

Received on Wednesday, 19 March 2008 13:27:07 UTC