W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2002

RE: N3 and N-Triples (was: RDF in HTML: Approaches)

From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
Date: Thu, 6 Jun 2002 17:08:39 +0100
Message-ID: <5E13A1874524D411A876006008CD059F044B8ECC@0-mail-1.hpl.hp.com>
To: "'Graham Klyne'" <GK@ninebynine.org>
Cc: "'RDF Interest'" <www-rdf-interest@w3.org>


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.

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.

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.


-----Original Message-----
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'>

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'>

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

Received on Thursday, 6 June 2002 12:09:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:41 UTC