- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Mon, 26 Sep 2005 12:11:29 +0100
- To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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