- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 7 Aug 2006 17:33:02 +0100
- To: Pat Hayes <phayes@ihmc.us>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
Slight emendation: On Aug 7, 2006, at 5:22 PM, Bijan Parsia wrote: [snip] > """The answer set of a query is the largest set of query answers > that are entailed by the answer KB such that no answer in the set > is entailed by any other answer in the set.""" > > Non-redundancy. [snip] DQL distinguishes between the answer set and the response set: """Response Set While there are no global requirements on a response set other than that all its members are correct answers, it is recommended that servers ensure that answer bundles do not contain duplicate or redundant answers, i.e., answers which are subsumed by other answers. One answer subsumes another if its bindings are a superset of the bindings in the other answer. Servers that are able to guarantee that their response sets contain no duplicate answers can be called non-repeating. Servers that are able to guarantee that their response sets contain no duplicate or redundant answers can be called terse. Servers that are able to guarantee that their response sets will be correctly terminated with 'none' can be called complete.""" OWLQL (<http://ksl-web.stanford.edu/KSL_Abstracts/KSL-03-14.html>) as a more elaborate discussion. I think I prefer the way that SPARQL does it, if DISTINCT gets fixed. I certainly don't want to have the granularity of redundancy placed at the server level. If I can't compute a non-redundant answer because I've run out of resources, I should timeout/fault with out of memory, whatever. If I have an imcomplete minimizer, I should be able to verify that that my answer set is minimal, or fault. The difficulties of streaming answers isn't really addressed in SPARQL, but I'm not sure that they are quite the same for SPARQL. """Guaranteeing terseness is a quite harsh requirement on a server that is incrementally deriving answers and returning bundles of answers as they are produced. The difficulty is that if such a server derives and returns an answer A1 with an unbound may-bind variable (i.e., A1 does not provide a binding for that variable), then it cannot later return any answer A2 that it derives containing the same bindings as those in A1 with the addition of a binding for the unbound may-bind variable because A1 would subsume any such A2. Similarly, if such a server derives and returns an answer A1 with a binding B for a variable V that occurs in the query only as a value in a minCardinality (maxCardinality) restriction in the query pattern, then it cannot later return any answer A2 that it derives containing the same bindings as those in A1 with the addition of a binding for V that is less than (greater than) B because A1 would subsume any such A2. """ Don't have anything to say about this, really, right now. Cheers, Bijan.
Received on Monday, 7 August 2006 16:32:30 UTC