Re: bnodes as answer bindings

>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.

I still think this is the best stance for the 
standard to adopt. I can see a perfectly good 
utility for servers which run fast but do not 
*guarantee* non-redundancy. Im quite sanguine 
with this because the economic pressures on 
servers and customers seem to converge on 
eliminating redundancy where practicable: there 
is no motivation for anyone to gratuitously 
introduce redundancy for no reason, only to save 
the considerable work involved in checking for 
non-redundancy when an absolute guarantee of 
nonredundancy is not required. I would vastly 
prefer to use such a server than one that times 
out trying to establish a minimal answer set, 
particularly when we might be talking about 
answer sets with high orders of magnitude.

>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.

*You* should, yes. That is, the user has the 
option of computing a minimal answer set if it is 
absolutely required.

>  The difficulties of streaming answers isn't really addressed in SPARQL

That whole aspect of the DQL proposal, allowing 
answers to be delivered in bundles, never really 
took off. DAWG took the position early on that 
this was a case of level mismatch, and that 
chunking belonged at the network traffic level, 
not the query language level. I now think that 
this is right, and this part of DQL (which I was 
largely responsible for) was misplaced.

>, 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.

Its not really relevant to anything except the 
abandoned DQL answer-bundling design, which as I 
say is flogging a dead horse.

Pat

>
>Cheers,
>
>Bijan.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 7 August 2006 19:40:49 UTC