Re: pls consider comments on disjunction

Dan Connolly wrote:
> Most of the comments continue to get handled by the editors etc.,
> forwarding to the WG as appropriate. One that I'm not sure
> what to do with is the thread beginning...
> 
> Disjunction vs. Optional ... and UNION Bob MacGregor (Sunday, 20 March)
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0034.html
> 
> Our decision on the disjunction and nestedOptionals issues...
>   http://www.w3.org/2001/sw/DataAccess/issues#disjunction
>   http://www.w3.org/2001/sw/DataAccess/issues#nestedOptionals
> are binding here... the question is whether this is sufficient
> new information that I should reopen the issue.
> 
> My own investigation is inconclusive. I encourage WG members to
> study it and let me know if you want the issue re-opened or not.
> 

There are separate strands in the discussions.  One is about the details of
UNION.  SPARQL UNION follows SQL UNION although it does not need the
explicit projections in SQL.  SQL UNIONs must align on column types; SPARQL
UNIONs are just the concatenatation of solutions - or aligned by column name
if you prefer.

There is also a larger discussion about disjunction and optionals.  There is
a test case and we seem to agree on the desirable results of the query under
discussion.  What is being covered is how to define OPTIONAL,

Bob's proposal for OPTIONAL is that it is "{pattern} OR TRUE" and involves 
the inclusion of a stage to reduce the results to the minimum information 
needed.  We know that this does not require access to the whole result set 
(which conflicts with a streaming requirement) but what is not clear to me 
is whether this is always true or whether with a form of "{pattern1} OR 
{pattern2}" the simplification algorithm must access the whole result set 
before it can emit the first result, thereby breaking streaming.  I 
currently think the algorithm in general does require whole result set 
access - if anyone has information on this, I would be most grateful if they 
would share it. (I have just seem a new message from Bob and need to read 
that soon.)

Geoff presents a formulation of optional as a logical expression - I haven't
had time to catch up on the latest.

I see now that talking about a order dependent queries has been confusing
because the simplistic evaluation of a query from top to bottom is not how a
logic engine approaches it.  However, rq23 is part tutorial; it has to 
explain to several different communities without becoming too long.

For me, the discussion on the comments lists has, at its heart, a debate
about whether SPARQL is a defined/developed to be a logic language or in a
more database-like way, taking features there and incorporating them.  There 
is some kind of connection to the likely future rules as well.


The process we have followed has been to tell stories though use cases 
rather than take a formalism and apply it.

We have UNION because of the use case of accessing RDF containing possible
alternative ways of modelling the information - the example is the simple
case of DC 1.0 and DC 1.1

At the moment SPARQL matching against a graph involves basic patterns (SQL
join), optionals (outer join) and UNION (SQL union).

[[Geoff (separately) also suggested that SPARQL has NULLs, not unbound
variables.  My belief is that these are equivalent for all the queries that
make sense (I'd call that the order dependent rules :-) and differ on
queries  that have the order dependence of a shared variable across two
optionals - this is precisely where SQL outer/inner join expressions are
order dependent.  I favour making these queries outside the spec.]]

rq23 does not use the term disjunction except in the note on the issue.

So, I think that reopening disjunction could be whether we add full logical
disjunction to SPARQL, not just a matter of whether to remove something.
The new information is not yet complete and I am against reopening it at the 
moment.

	Andy

Received on Friday, 25 March 2005 19:55:37 UTC