BOUND operator; and can other operators apply to unbound variables?

Apologies if I'm covering old ground.  I noticed the BOUND predicate
introduced into SPARQL.  BOUND only works if the optimizer is limited in 
its ability
to reorder patterns and constraints.

This raises a general question about constraints and functions (operators):

Are operators allowed to apply to unbound variables?  The spec says that 
they cannot
apply  in the case of XPath operators.  I couldn't find language that 
limits the other
cases.  Clearly, UNBOUND isn't limited to apply only to bound variables.

It is  MUCH preferable if operators CAN apply to unbound variables, which
means they can generate variable bindings.
Sophisticated logic implementations allow extensible operators to 
generate bindings,
because that allows the language to be easily extended. 
However, that works well only if the specification
of an extensible operator includes guidance on which variables must be bound
for the operator to work correctly.

Perhaps that's asking too much of SPARQL?

Returning to BOUND:

If operators CAN apply to unbound variables,  then the position of a BOUND
constraint apparently is quite sensitive to its location, i.e., the 
optimizer cannot
safely permute constraints containing a BOUND predicate.  In my own use 
of BOUND,
I sometimes use it as a guard condition to avoid breaking on operators 
that require certain
variables to be bound.  However, I also make use of a variant of the AND
operator (SEQUENCE) that tells the optimizer not to reorder the conjunct 
clauses
within a SEQUENCE constraint.

If operators CANNOT apply to unbound variables, then BOUND is obviously
an exception to that rule.  In that case, the spec should spell out 
explicitly that
something very unusual is happening.

In any case, the spec needs to be more explicit about the bound/unbound
semantics, and about ordering of constraint clauses.

Philosophically, I do have another question.  The need for some kind of
negation operator  is orders of magnitude more important than having a
BOUND operator.  The illustration of using
BOUND to perform negation-as-failure is an egregious hack.  Is this
included because the committee didn't have the courage to define
a true negation-as-failure operator?

In the spec, the first example of BOUND is just dumb, except as a motivation
for the negation-as-failure example, because:

SELECT ?name
 WHERE ( ?x foaf:name  ?name )
         OPTIONAL ( ?x foaf:mbox ?mbox )
   AND bound(?mbox)

is equivalent to

SELECT ?name
 WHERE ( ?x foaf:name  ?name )
       ( ?x foaf:mbox ?mbox )

so no one in their right mind would write the former version.

That means that the only legitimate example of BOUND in the spec is to 
simulate
negation-as-failure in very awkward fashion.

Cheers, Bob


-- 

Bob MacGregor
Chief Scientist

	
	Siderean Software Inc
390 North Sepulveda Blvd., Suite 2070
<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=5155+Rosecrans+Ave&csz=Hawthorne%2C+Ca+90250&country=us> 
El Segundo, CA 90245
bmacgregor@siderean.com <mailto:bmacgregor@siderean.com> 	
tel: 	+1-310 647-4266
fax: 	+1-310-647-3470