UNSAID : issues in interpretting a query

I had a look at "UNSAID". I didn't know what people want to do with this as we 
have to decide what happens and it isn't straightforward, to me at least.

==== Data
:a :p :b .
:a :q :c .
==== Query 1:
SELECT * WHERE
{
   UNSAID { :a :p ?x }
   { :a :q ?x }
}
====

so that is two parts, the first is "unsaid" of a graph pattern, the second is a 
usual triple pattern.  There is a shared variable.

http://www.w3.org/2001/sw/DataAccess/UseCases#d4.3
"""
4.3 Non-existent Triples

It must be possible to query for the non-existence of one or more triples or 
triple patterns in the queried graph.
"""

Thinking of UNSAID as a pattern-matching test, and interpretting the query 
procedurally as written - that is in the order given:

Step1:
UNSAID { :a :p ?x } matches the data so is false and hence there are no solutions.

==== Query 2 :
SELECT * WHERE
{
   { :a :q ?x }
   UNSAID { :a :p ?x }
}
====
Same thing except the order is reversed.

Executing in order:
Step1:
{ :a :q ?x }
matches with ?x = :c

Step2:
UNSAID { :a :p ?x } is UNSAID { :a :p :c }
and does not match so true.

Result: one solution of ?x = :c

UNSAID has resulted in an order dependence in a procedural interpretation.

----

An alternative interpreted of query execution is that it is a set of logical 
rules, which filter all possible solutions. This is what the current spec tries 
to outline in the definitions and make query execution order-independent.

In this case, you get the same answer in both cases which is one solution.

Try: solution(?x = :c)
so
1 - UNSAID { :a :p :c } is true
2 - { :a :q :c } is true.

Other than UNSAID, up to now both interpretations have been the same, given the 
rule on variables in OPTIONALS (no shared variables that do not exist in an 
enclosing pattern between OPTIONALS)

However in this interpretation it has not gone way, just gone somewhere else:

==== Query 3 :
SELECT * WHERE
{
   UNSAID { :a :p ?x }
}
====
has no solutions so removing part of the query reduced the number of solutions 
which is a bit paradoxcial for RDF.  Or there are an infinite number of 
solutions with ?x set to things not in the model.

This also shows a different way to think of UNSAID : can the UNSAID clause 
satisfied?  yes - lots of ways with ?x anyting except :b.

----

A logical assertion interpretation is a harder implementation: for a 
procedurals-style engine it means reordering queries to that any variables that 
used in an UNSAID pattern are defined first.  It will be quite easy to get into 
order dependences issues through the value extensibility as well.

It not the logical negation of UNSAID that's the heart of the matter, its
the negation hidden in the restriction of values of ?x to the universe
except ?x = :b.

If we had a SAID operation, it is possible to construct similar situations 
because it has restricted the range of ?x in every solution but not fixed it to 
a sequence of possible values.

--
SAID { :a :p ?x }
{ :a :q ?x }
--

Procedurally:
Step 1:
SAID { :a :p ?x } => true
Step 2:
{ :a :q ?x } => "?x = :c"

but with:
--
{ :a :q ?x }
SAID { :a :p ?x }
--
Step 1:
{ :a :q ?x } => "?x = :c"
Step 2:
SAID { :a :p ?x } => SAID { :a :p :c } => false, no solution
---

and interpretted as logical assertions:

try(?x = :c)
{ :a :q :c } is true
SAID { :a :p :c } is false
==> no solutions.

but removing the SAID means the query has more solutions.

----

UNSAID is something users want (it is a request that comes up from time to time 
on jena-dev) but I don't have a clear picture of what they expect.

There is nothing fundamenatlly new here - its not an RDF-ism as far as I can see 
and I'd like input from experts.  Are there other ways to think of UNSAID?

Personally, I prefer the logical assertion interpretation, which is order 
independent, but its harrder to explain to application writers.  Either will 
lead to support costs.  We may be able to restrict the syntax in some way to 
force one route of another but I'd like to hear opinions about the alternatives 
for teh meaning of UNSAID and query intepretation.

I hope this is clear - text email isn't the best medium sometimes and I have 
little depth in the area so I don't know the technical terms well enough.  I 
hope I'm just showing my ignorance and have missed something obvious.

	Andy

Received on Thursday, 9 September 2004 17:50:14 UTC