Re: Disjunction vs. Optional ... and UNION

Bob MacGregor wrote:
> Andy,
> 
> 
>>><clip>.  First, I am assuming that the
>>>following query returns no bindings:
>>>
>>>SELECT ?x ?y
>>>  WHERE  { ?book dc10:title ?x }
>>> 
>>>I shouldn't since it doesn't refer to OPTIONAL or UNION within the 
>>>query, and the
>>>spec cites those as prerequisites for allowing unbound values.
>>
>>
>>Could you please say where in the spec you found text to draw that 
>>conclusion? It is not true.
>>
>>It says in 2.1
>>
>>"""
>>Optional matches and alternative matches may leave some variables 
>>unbound (see the bound test).
>>"""
>>which is true about solutions to patterns; the text is not about 
>>SELECT results.
> 
> 
> The impression that I am getting is that the committee is unaware how 
> unorthodox the semantics
> is for SPARQL.  I was using Occam's razor, assuming that if the language 
> is designed to leave variables unbound,
> then it would say that up front.  The language you cite above is the 
> only language that speaks directly to this issue.
> The document contains no examples like the one up above.

I can certainly add some text to bring out the issues of unbound variables. 
Added to my ToDo list.

> 
> 
>>
>>The query
>>
>>SELECT ?x ?y
>>  WHERE  { ?book dc10:title ?x }
>>
>>can return bindings - it's a projection of a query solutions involving 
>>?x and ?book.
>>
> 
> This is a horrendous decision by the committee.  The above query ought 
> to be flagged as illegal.
> Given that RDF is basically a small subset of FOL, its not at all clear 
> to me why you are
> inventing a brand new semantics that does not resemble any of the 
> mainstream logic languages.
> 
> Regards, Bob

SELECT in SPARQL gives the query processor information about the variables of 
interest to the application.  This enables optimization in both query execution 
and in the size of serialized network results.

Within a query, any query processor that does optimizations involving reordering 
is going to be doing flow analysis on queries.  It is quite capable of noticing 
where variables are used and needs that to perform even basic reordering.

The basis for SPARQL queries is the pattern - the result form is a presentation 
of solutions from the pattern matching.

The process is:
   pattern match => process solution sequence[*] => result form


SQL needs SELECT in subqueries because columns are typed.  To get union 
compatibility, the application writer has to explicitly ensure that columns that 
are not type compatible are removed and any ambiguity in column union 
compatibility is resolved (e.g two columns of integers with a single integer 
column).   RDF is not typed, hence SPARQL results are not typed and the issues 
need not arise.

	Andy

[*] Project, distinct, group by, limit/offset

Received on Wednesday, 23 March 2005 10:36:39 UTC