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: Sat, 8 Jun 2002 17:19:11 +0100
Message-ID: <5E13A1874524D411A876006008CD059F038D3977@0-mail-1.hpl.hp.com>
To: "Vangelis@Semanticweb.gr" <vangelis@semanticweb.gr>, "'Graham Klyne'" <GK@ninebynine.org>
Cc: "'RDF Interest'" <www-rdf-interest@w3.org>

Vangelis,

I agree that often a gragh will have a URI due to where it contained (e.g.
in a web page).  But not always: if the graph is in a database it does not
have a URI automatically (there might be a web interface on top that means
there is a natural one at that level).  If the graph is created in-memory,
it may be desirable to assign a URI to it before it becomes visible via its
natural URI because it going to be in a file or web page.

	Andy

-----Original Message-----
From: Vangelis@Semanticweb.gr [mailto:vangelis@semanticweb.gr] 
Sent: Saturday, June 08, 2002 1:25 PM
To: Seaborne, Andy; 'Graham Klyne'
Cc: 'RDF Interest'
Subject: RE: N3 and N-Triples (was: RDF in HTML: Approaches)


Hi Andy,

I do not understand the statement "If graphs had a URI..."
How is it possible that graphs do not have a URI? For the
SW to be realised, IMHO, graphs -RDF Models- must "exist" somewhere: stored
in a RDF server, inside a RDF page/document, embedded in an HTML document...
somewhere. Then, the URI of the container is the URI of the graph.

Am I missing something here?

Regards,

Vangelis
[mailto:vangelis@semanticweb.gr]



-----Original Message-----
From: www-rdf-interest-request@w3.org
[mailto:www-rdf-interest-request@w3.org]On Behalf Of Seaborne, Andy
Sent: Thursday, June 06, 2002 7:09 PM
To: 'Graham Klyne'
Cc: 'RDF Interest'
Subject: RE: N3 and N-Triples (was: RDF in HTML: Approaches)




Graham,

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.

	Andy

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


Andy,

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:about:

   <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
coherence.)

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.

#g
--
Received on Saturday, 8 June 2002 12:19:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:54 GMT