W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2004

Re: Named Containers / was: Re: UC&R ready for review

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
Message-ID: <20041005090952.GB11436@login.ecs.soton.ac.uk>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:21 GMT