- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Fri, 25 Mar 2005 19:55:02 +0000
- To: Dan Connolly <connolly@w3.org>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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