Re: thoughts from Tuesday telecon (rdfSemantics)

On Thu, 2005-09-22 at 17:03 -0500, Pat Hayes wrote:
[...]
> 7. Another, related, question is whether or not logically equivalent 
> graphs should give identical answer bindings. We did not give this 
> issue as much telecon attention as it needed, mia culpa.
> 
> Peter P-S, if I understand his point, claims that implementations 
> should be free to store graphs in RDF-equivalent forms (in 
> particular, to convert graphs to their 'lean' subgraphs) without 
> affecting interoperability,

Yes, I think that point is well-made, but..

>  so that it should not be possible for a 
> SPARQL query to distinguish G1 and G2.

... I think you might be taking that too far.

Consider a design where minimal-ness is treated analagously
to distinctness:

 * it's always correct to return a minimal answer

 * a minimal answer is required when the query requests
 it explicitly, using DISTINCT or perhaps a new MINIMAL keyword.

 * a redundant answer is allowed as long as the query doesn't
 say otherwise.


Both implementations that keep their datasets in lean form as
well as those that don't can meet those criteria. Those
that don't will have some extra work to do when
the query requires a DISTINCT/MINIMAL answer.



> On the telecon we discussed Enrico's suggestion that SPARQL answers 
> should have redundancies removed, so as to achieve this. It was noted 
> that this could be done either at the client or server side of the 
> transaction, and it was agreed that it should be a client-specifiable 
> option, if included, rather than mandatory (although this does not 
> seem to fully meet Peter's objection. Do I have this right??).

I think it can go far enough.

>  Enrico 
> noted however that the operation cannot be done simply as a 
> client-side post-SPARQL 'tidying-up' operation, since the reduction 
> of the answer set after the bindings are first identified has a 
> knock-on effect on subsequent SPARQL processing and filtering. (There 
> is an example in the IRC log, which I cannot access at present.) 
> Thus, this option must be somehow incorporated into the SPARQL 
> definition, and SPARQL-defined syntax must be provided to allow users 
> to specify whether they want redundancies to be removed or not, if we 
> indeed choose to allow this as a user option.
> 
> Another possible option is to simply require that SPARQL treats all 
> KBs as being lean, but this would seem to impose too high a burden on 
> KB maintainers (and would not satisfy Peter's requirement that 
> implementations be free to choose lean or fat storage (?))

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 27 September 2005 13:23:34 UTC