Re: Comments on SPARQL draft

Geoff Chappell wrote:
> Hi Andy,
> 
> Thanks for the reply. I just wanted to follow up on one item below. 
> 
> 
>>-----Original Message-----
>>From: Seaborne, Andy [mailto:andy.seaborne@hp.com]
>>Sent: Wednesday, November 03, 2004 11:10 AM
>>To: Geoff Chappell
>>Cc: public-rdf-dawg-comments@w3.org
>>Subject: RE: Comments on SPARQL draft
>>
> 
> 
> [...]
> 
> 
> 
>>>- Missing Value Assignment
>>
>>Assigment and the switch statement you describe imply a procedural view
>>of query execution.  Currently, SPARQL is declarative and execution
>>order does not matter in functional terms.  Hopefully, this allows
>>implmentations the freedom in optimization.  
> 
> 
> Can you explain why you consider these to be procedural? For example, a
> switch case such as:
> 
> Case condition_a:
> 	result_a
> Case condition_b:
> 	result_b
> Default:
> 	result_default
> 
> Could be re-written as:
> 
> (condition_a and result_a) 
> 	or 
> (not condition_a and condition_b and result_b)
> 	or
> (not condition_a and not condition_b and result_default)
> 
> which admittedly requires disjunction and negation, two features not
> currently in the sparql draft, but doesn't require a procedural view of
> things.

My natural reading of your switch statement is:

if ( condition_a ) then return result_a ;
if ( condition_b ) then return result_b ;
return result_default ;

so condition_a can guard condition_b when condition_b is not valid to execute.

If the negated conditions involve variables, then the order of execution 
matters as reflected in your syntax.  My (imprecise) discussion of this is:

http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0468.html

(and the discussion following has correcions).  Considered procedurally, 
reordering a query with negation involving variables gives different answers.


Negation is currently an area that would seem to be contentious.
DAWG is trying to balance an earlier recommendation which will enable 
people to access published RDF in a common way, with a more complete 
recommendation appearing later.  An earlier recommendation will have less 
features but will mean that applications can be built on wildely deployed 
technology and that agreed approaches to the next round of commonly 
encountered situations will start to emerge.

> 
> Similarly, I don't see how an assignment operator implies a procedural view
> of the world (as long as the same operator is used for both equality and
> assignment it doesn't even imply a necessary order of evaluation - is that
> what you mean by procedural in this instance?). 

Saying  ?x equals "foo"  and  ?x is assigned "foo"  would not be the same 
if "foo" isn't present in the graph.

> 
> OTOH, surely functions do imply an order of operations (i.e. for many
> functions, an optimizer would not be free to move a function evaluation to a
> point prior to where its arguments are bound to values). Do you consider
> this to mean that functions imply a procedural view of query execution?

The overall effect must be that any constraint will evaluate to true when 
applied to any solution found.  This has said nothing about order, nor 
about the way the solutions are found - just the condition at the end. 
The functions covered in SPARQL will be a subset from XPath/XQuery 
functions and operators based on those that do testing.

Where functions are testing values (boolean results) then an optimizer if 
going to have to ensure that the order is correct for the execution model 
that it is working with.

Functions are also an an extension point and any implmentations will be 
outside the recommendation if they are used.  It's highly implementation 
dependent as to how this happens - whether functions get called with 
unbound variables that later get bound in a solution or whether

	Andy

> 
> Thanks,
> 
> Geoff
>

Received on Sunday, 7 November 2004 17:47:02 UTC