Re: thoughts from Tuesday telecon

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

- Steve

Received on Friday, 23 September 2005 08:54:43 UTC