Re: Another attempt...

On 19/03/2008, Richard Newman <rnewman@twinql.com> wrote:
> > Richard made two claims which I was trying to contradict:
>  > * That {} was unique each time in the query evaluation and
>
> I'm sure that there are many kinds of equality that hold between each
>  occurrence of the empty graph pattern in a SPARQL query (string= for
>  one). I'm sorry that I failed to get my point across; let me try again.
>
>  Each occurrence of {} in the syntactic input is important; you can't
>  just discard them. They are unique parsed entities.
>
>  They produce unique (i.e., different instances of) empty graph
>  patterns in the algebraic output. If I were jumping into Common Lisp,
>  each of these empty graph patterns might be EQL or EQUAL, but not EQ.
>
>  At this point you no longer have curly brackets, but algebra
>  operators. Identities exist in the algebra, but
>
>  (Union
>    (BGP)
>    (BGP))
>
>  does not simplify to
>
>  (BGP).
>

I'm not disagreeing about what does happen (because we all know how it
goes) I'm saying what should happen if certain things were true - like
we actually treated JOIN identity as an identity.  The SPARQL document
defines "Group Graph Pattern" as "a set of graph patterns".
http://www.w3.org/TR/2006/WD-rdf-sparql-query-20060220/sparql-defns.html

So a set doesn't contain duplicate patterns.  You're trying to say
that one empty group pattern doesn't equal another empty group
pattern.  Again, where does that come from?  Where is the equality
definition?  If I'm going on algebra it doesn't make sense - at least
the ones that I know of.

>  > * That the query that involved UNION had some specific order based on
>  > the syntax.
>
>
> Check the grammar and the algebra definition -- UNION is a binary
>  grammar element (rule 25), and Union is a binary algebra component
>  (12.4).
>
>  The order of the operands in the algebra expression comes from the
>  order of the elements in the parse tree, which comes from the order of
>  tokens in the syntactic representation of the query.
>

Okay, well that just seems to disagree with my understanding of the
SPARQL algebra (http://lists.w3.org/Archives/Public/public-rdf-dawg/2006OctDec/att-0102/sparql_semantics.pdf)
says:

"Several algebraic properties of graph patterns are proved in [1], most
notably that AND and UNION are associative and commutative. This permits
us to avoid parenthesis when writing sequences of AND operators or UNION
operators. This is consistent with the definitions of Group Graph Pattern and
Union Graph Pattern in [2] as being just sets of graph patterns."

You should be free to treat your elements of in a UNION in this regard
- which means that you can throw away your parsing of SPARQL - and
treat it algebraically.

>  > I was hoping someone would say: "In the SPARQL algebra the JOIN
>  > identity isn't equivalent to this thing in other algebras
>  > because...??... and that's why it you get the answer when it is
>  > involved in a UNION in SPARQL".  Defining multiset UNION has in no way
>  > helped me understand the result.
>
>
> I think the DAWG is trying to arm you with enough definitions for you
>  to phrase an objection using the terms defined in the spec.
>

If the spec was complete that would be do able.  But the spec isn't
complete and you have to go to implementations to test certain things.
 And that then introduces syntax and a whole range of things (like XML
serialization apparently).

>  The DAWG, and other implementors on the list, have plenty of
>  experience with SPARQL; you will have much better luck if you can
>  explain an objection as "I think these SPARQL algebra operators should
>  work this way"... or, better yet, provide a test case or two.
>

I have tried.

>  > Right.  So to concentrate on just this part of the SPARQL document, if
>  > the name "empty group pattern" is JOIN identity, what would the empty
>  > set, the UNION identity, be called?  The "even emptier group pattern"
>  > (as it has a cardinality of 0)?  And how would that look as SPARQL
>  > syntax perhaps "{-1}"?
>
> If I understand your question correctly: the UNION identity would be a
>  failing graph pattern (one that produces no results). Any pattern
>  UNIONed with a failing pattern is equivalent to the first pattern.
>
>  An example is:
>
>  { FILTER(false) }
>
>  but there is no special syntax for this in SPARQL, to my knowledge.
>

Right.

Received on Wednesday, 19 March 2008 00:05:14 UTC