


From: Graham Klyne <GK@NineByNine.org>
Date: Sun, 09 Jun 2002 16:55:19 +0100
Message-Id: <>
To: "Seaborne, Andy" <Andy_Seaborne@hplb.hpl.hp.com>
Cc: "'RDF Interest'" <www-rdf-interest@w3.org>

At 05:08 PM 6/6/02 +0100, Seaborne, Andy wrote:
>Yes - the idea of a graph that encompasses both A and the remote graph is
>the effect I would like.  If graphs had a URI and bNodes had a local
>identifier, then I think everything could be made to work.  Unique bNode Ids
>in a different space to URIs achieves the same.

Yes... but I'm uneasy about the practical outcomes of using the second, in 
that there's nothing to stop the IDs being used when the remote graph 
fragment is separated from its parent graph.

>My current experiments with Joseki (an RDF server) used to do this by
>explicitly having an application convention on encoding graphs that
>preserved bNodes.  However, since changing to making the result of a query
>the minimal complete subgraph that matches the query and serializing into a
>standard syntax for RDF to enable HTTP caching, I loose the ability to
>round-trip information.

Hmmm... assuming you do not preserve and return results corresponding to 
distinct bnodes, I think that doing a minimal complete subgraph effectively 
separates the graph fragment from its parent graph, so you've effectively 
taken any bnode identifiers out of scope.

>The derived subgraph is an extra.  I don't think it is necessary for the
>"distributed graph" above.  I think serializing part of the big graph is
>enough and avoids subgraphs of subgraph, and one subgraph being the subgraph
>of two graphs (aka a subset of the intersection).  Partial serializations
>captures the idea that the it is the same graph at A and the remote graph R.

I'm not 100% convinced I'm understanding you fully, but I think I agree 
with what I do understand.  I'm not sure I understand what you mean by 
"subgraphs of subgraphs".  When a fragment of a remote graph is treated as 
a subgraph (i.e. a graph in its own right), then I think it has been 
separated and the bnode identifiers are out of scope.


>From: Graham Klyne [mailto:GK@ninebynine.org]
>Sent: 6 June 2002 17:00
>To: Seaborne, Andy
>Cc: 'RDF Interest'
>Subject: RE: N3 and N-Triples (was: RDF in HTML: Approaches)
>Good, I see.  I think the DAML debate is chasing a similar, or related,
>issue (but I've not followed it at all closely.)   (Or maybe not:  I think
>the MID may not work here, because it's not clear how it handles remote
>updates to the graph -- this is more than just a query environment.)
>Conceptually, I think that what you're trying to do is create a distributed
>representation of a single graph, so in that context I think the arguments
>for having URIs for bnodes don't need to be faced head-on.  Or, put another
>way, the requirement is to create a bnode scope that encompasses both A and
>the remote graph (let's call it R).  Anything that is stored by A could be
>taken as a projection out of R, but still part of R, not a separate
>graph.  I think there are some constraints that must be honoured, like any
>update in A is reflected in R, and that A and R cannot be assumed
>simultaneously to be under different interpretations.  This means that A
>cannot be treated as a complete graph in isolation.
>So if this works conceptually, what to do in practice?
>Thinking of my "out", maybe give R a URI and have A use that.  bnodes can
>have local identifiers that are qualified by the graph URI but are
>meaningless when treated separately.  Software in A that processes the
>(partial) graph must operate to ensure coherency with the original copy.
>Is this making any sense...?
> >It seems to me that a serialization of an RDF that could capture the
> >graph (shared bNodes and all) would be useful here.  MIDs would help.
>I'd suggest, rather, that you want a subgraph serialization that
>(a) refers back to the master graph (probably by URI?), and
>(b) has provision for local identifiers that are meaningless when isolated
>from the graph/subgraph context.
>E.g. something like:
>    <subgraph:RDF subgraph:ID='graph-URI'>
>     :
>    </subgraph:RDF>
>which is much like <rdf:RDF> except for the subgraph:ID attribute, and that
>its RDF-form contents may use an additional attribute in place of rdf:ID or
>    <rdf:Description subgraph:bnode='opaque-id'>
>     :
>    </rdf:Description>
>(If I've understood recent RDF discussions correctly, standard RDF will
>ignore this attribute and simply interpret the description as a blank node.)
>What I've sketched is clearly not standard RDF (though it bears a close
>relationship).  I think this is fine, because it's essentially a private
>agreement between the software components that are implementing a
>distributed RDF graph representation.  Maybe, in time, the distributed
>graph representation is useful enough that multivendor interoperability is
>desired, and hence standardization.  (In this case, the standardization may
>well need to include some protocol elements for dealing with maintaining
>The key point in all this is that the goal you have outlined is, I think,
>an extension to standard RDF capabilities and should not be shoehorned into
>standard RDF.
>There are many other things I could say about this, but I think they'd
>obscure the basic idea.  So I'll stop here.

Graham Klyne
Received on Sunday, 9 June 2002 11:42:25 GMT
