- From: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
- Date: Tue, 5 Oct 2004 10:09:52 +0100
- To: public-rdf-dawg@w3.org
On Tue, Oct 05, 2004 at 09:57:39AM +0100, Andy Seaborne wrote: > The proposal is trying to find common ground between all the approaches I > have found. It can't be compatible with all of them. The important thing > at the moment is question of whether the approach is acceptable. It does > provide some structure; in some places it does not say how an > implementation has to do things because different impls may choose to do > things differently. In particular, it changes the use of bNodes in SOURCE > and dc:source in your and Steve's test cases into a single, different > SOURCE operator so the relationship isn't fixed and there are no issues > about returning the ?snode variable. > > There are some issues that arise with bNodes such as which graph they are > in. I noted that "named graphs" does not allow bNodes. When returning > query results in a SELECT, bNodes don't make a lot sense but URIs do. > Hence, restricting to URIs so see if the overall approach is workable in > the working group. > > The proposal does not enforce a single way that a URI is associated with a > graph - maybe it should. What it does do is to say "SOURCE <uri>" and > leaves it to implementations to create the association of URI to the graph. > The test cases I produced have graphs in documents and its the URI of the > document (c.f. log:semantics). What it shouldn't enfoce is that the <uri> is the URI that was resolved to fetch the graph. That prevents you form holding two copies of a graph from different times in one store, for example. The testcases that Alberto and I put forward were not supposed to show a requirement for the SOURCE node to be a bNode, but allowing it to be. It doesnt have to be a bNode, but to ensure that any provenance information that is asserted against it is reliable it should be something that other graphs cannot use as a subject in statements. You could invent a URI scheme and reject it from incoming documents, but using bNodes seems like a good fit, to me. Ofcourse stores that do not care about provenance, or wish to enfoce it through other means can use whatever thye like to identify SOURCE nodes. > I showed how I thought it is done for RDFStore, finding the bNode used for > the graph, so recovering the bNode seems possible. Only if the SOURCE node is guanteed to be unique withing the store. - Steve
Received on Tuesday, 5 October 2004 09:09:57 UTC