- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 09 Sep 2004 18:49:51 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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