Re: thoughts from Tuesday telecon

Steve Harris wrote:
> On Thu, Sep 22, 2005 at 05:03:08PM -0500, Pat Hayes wrote:
> 
>>6. The difference between the two is illustrated by the following example:
>>
>>G1: {ex:a ex:p ex:c .}
>>
>>G2: {ex:a ex:p ex:c .
>>ex:a ex:p _:y .}
>>
>>G3: {ex:a ex:p ex:c .
>>ex:a ex:p _:y .
>>_:y ex:q ex:d .}
>>
>>Each is a subgraph of the next; G1 and G3 are lean, G2 is not. G1 and 
>>G2 simply entail each other and are entailed by, but do not entail, 
>>G3.
> 
> 
> With use of the GRAPH keyword it surely is easy to distinguish these
> cases, and wouldn't a lean storage system will give supprising results
> when given queries like
> 
> ASK { GRAPH <G2> { ex:a ex:p ?y } FILTER(bnode(?y) }
> 
> ...
> 
> 
>>Now, if we understand the query in the remote, out-of-scope case, it 
>>can be argued that the latter two are redundant, since the second 
>>binding to the bnode adds no useful information; and, further, that 
>>it is inappropriate that two logically equivalent graphs (G1 and G2) 
>>should give different answer bindings. But for the huddle, in-scope 
>>case, it is important that the second binding for ?var is provided in 
>>the G3 case, since it allows for a subsequent query pattern
>>
>>[_:y ex:q ?w ]
> 
> 
> Unless its changed since I read it, _:y in query patters is treated as a
> sort of variable, that query being quivalent to [ ?y ex:q ?w ]. Allthough
> effectivly skolemised bnodes can be passed out, I'm not aware of any way
> of passing them back in, in the current syntax.
> 
> My engine allows you to pass in skolemised bnodes as URIs with bad syntax,
> eg <_:y>, as does Jena I believe, but thats a hack/bug/something.

I confess - ARQ does allow this.

>  
> 
>>(My own view is that none of this redundancy-removal is necessary, 
>>but I recognize that this does not seem to be the majority view.)
> 
> 
> I agree with this. The redundancy removal can be done on the client side,
> so without a really convincing use-case I dont find it a very tempting
> piece of code to write as an implementor.

I think the process must be to do told-bnode redundancy removal before 
applying the algebra for more complicated queries, including some FILTERs, 
making it servers-die, unfortunately.  The G1/G2/G3 example shows that the 
removal is dependent on the graph queried and not just the result set, making 
it a server-side operation.

There is also the minimization procedure in (c) in [0450] which applies to 
result sets independently of the graph queried.

	Andy

> 
> - Steve
> 

[0450]
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JulSep/0450.html

Received on Monday, 26 September 2005 11:12:56 UTC