# Re: Disjunction vs. Optional ... and UNION

```Geoff,

Very nice summary, but on the issue of 'x or not x' I fear that there is
no obvious
semantic basis for your assertion.  Not that there could not be one, but  I
haven't seen a proposal yet that looks like it covers all of the bases.
Below, you will see where
I believe a problem exists.  On some other points,  I completely
disagree with the SPARQL approach.

>- sparql UNION could just as well be called OR (I imagine choice of what to
>call it is somewhat a question of whether the language is formally described
>with e.g. relational algebra or relational/predicate calculus or..., and
>somewhat a matter of taste).
>
>
I am being told by others, at least on odd numbered days :), that UNION
is different from OR.  "OR' operates
on statements, while 'UNION' operates on graphs.  I actually like the
idea of a UNION that
operates on graphs, but syntactically such a UNION
could only be placed outside of a graph-forming operator (e.g., CONSTRUCT).
I don't see any graph-forming operators inside of the WHERE clause -- if
they exist, they
must be invisible, and I don't like invisible operators.

But what I really want is an OR in SPARQL that operates on (connects)
statements.

>- sparql OPTIONAL (x) means: x or not x, where not is negation as failure
>(or I guess set difference if you prefer).
>
I think that 'x or not x' captures the spirit of what we want, and 'x or
true' does also (modulo it produces
too many bindings), but I'm no longer convinced that it actually works
semantically.  If there really
is a value meaning 'UNBOUND' (i.e., if its not just some kind of fiction
in our semantics), then something
in the 'not x' expression has to make that binding
happen.  To be concrete, let  'x' correspond to '?x P ?y', and assume ?x
is bound to 'a', then we are
expecting that successful evaluation of
'not (a P ?y)'
will somehow cause ?y to be bound to NULL, i.e., to the unbound value.
I don't see any machinery that makes
that happen.  Perhaps there is a discussion somewhere that I missed that
says what the logical (e.g., model
theoretic) formalism is that makes this binding occur?
Recently, I came up with a scheme that isn't too distant from the 'not
x' that
WOULD cause the binding of ?y to NULL/UNBOUND.  I passed my idea on to
Pat Hayes, because I trust him to
tell me whether my proposal is viable or not, and I don't trust myself
to know for sure.  He is really
busy right now, but hopefully we will hear from him in a bit.

<snip>

>- sparql is a mixed model language - by that I mean that constraints are
>functional, everything else logical (lp-style) (that's why there are two
>ANDs, and two ORs). To the lp side of things, a FILTER clause looks like a
>single logical relation - e.g.:
>	FILTER ?a > 10 && ?b < 12
>Can be thought of as:
>	filter("?a > 10 && ?b < 12")
>where filter will be true if the functional evaluation of the constraints
>have an ebv of xs:true, false otherwise.
>
>
KIF has functions, and does not make this distinction.  Given that
simpler is better, I so far fail
to understand why we need two of everything.  Somehow, its seems that
SPARQL's functional constraints
are inferior to the KIF equivalent.

<snip>

> Nesting, disjunctions, and constraints aren't really an issue once the
>
>semantics of OPTIONAL are understood. An algorithm for evaluating a query
>according to those semantic might be:
>
>Convert query to SOP form.
>Order conjuncts in each product so that: positive triple pattern < filter <
>negated triple pattern or filter.
>Evaluate each product left to right and union the results.
>
>
The above algorithm appears to assume that triple patterns and filters
can be conjoined but
not disjoined.  The messiness of the syntax makes it hard for me to be
sure what is and
isn't expressible but it sounds to me that, for example, a KIF statement
(expressed in infix notation) such as
(?x P ?y) and (?z  P ?y) and ((?z Q ?y) or (?y > 5))
is not expressible in SPARQL.

Let me assume its not.  The rejoinder that I would expect to get from
the committee is,
"No, you can't say that in SPARQL, but you need to give us a use case
for why anyone
would want to say it".  The SPARQL committee appears to use use cases as
a bludgeon
that prevents principles like "orthogonality of operators" to take
hold.  An orthogonality
principle says that the scope of an operator should be as broad as is