- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Thu, 17 Jun 2004 10:25:00 +0100
- To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Here is a testcase for optional triples: Data: :x :p :a . :x :q :b . Query: (Using [] to indicate an optional match) Q1: two separate optional parts: [(:x :p ?v)] [(:x :q ?v)] Possible results: R1: ?v = :a which matches the first part but then the second can't match. R2: ?v = :b which matches the second part but not the first. If executed in order, this would only happen is the first part included the "no match" case or if the second triple were matched first. R3: ?v = null is the trivial case of no match from either part and is unlikely to be what the application writer expects. If the query is: [(:x :p ?v)] a result of: ?v = null // Choosing not to match ?v ?v = :a // mathcing ?v seems unhelpful Q2: [(:x :p ?v) (:x :q ?v)] has no match because ?v can't be both :a and :b The key point here is that ?v occurs in both parts: in Q1, the optional parts are independent, in Q2 there is one optional part of two triple patterns. I think we will need to either define what happens or have some execution model that does not let the case of binding in different optional parts arise. Andy
Received on Thursday, 17 June 2004 05:35:36 UTC