W3C home > Mailing lists > Public > www-rdf-interest@w3.org > April 2003

N3/CWM formulae, how they relate to graph nodes, and graph comparison

From: Graham Klyne <gk@ninebynine.org>
Date: Thu, 17 Apr 2003 11:22:42 +0100
Message-Id: <5.1.0.14.2.20030417103520.00b79ed0@127.0.0.1>
To: RDF interest group <www-rdf-interest@w3.org>

For some time, I've assumed that a formula in N3/CWM is an RDF graph node 
that (somehow) embodies a graph.  Now I've noticed something that leads me 
to question the relationship between formulae and graph nodes.

I understand that cwm itself implements formulae by tagging each statement 
with a "context identifier", which (I guess) is itself a URI.  But I've 
taken that to be just an implementation detail rather than a definitive 
model of what is going on.

I once made an attempt (in [1]) to model the abstract syntax of 
RDF-with-formulae, treating a formula as another kind of graph node.  That 
model treats formulae and URIrefs as disjoint nodes in a graph (and 
predates the RDFcore work that clarifies that a URIref *is* an RDF graph 
node, rather than being something that labels a node).  More recently, in 
code, I have been modelling RDF graph nodes such that URIref and blank 
nodes may *additionally* contain a (sub)graph.

(The following discussion is based on the RDF abstract graph model that can 
be found in the RDF Concepts working draft [2].  Although I'm a co-editor 
of this draft, the particular text to which I refer is not my own and does 
represent RDFcore WG consensus:  I mention this to try and avoid any 
appearance of appealing to authority of my own text.)

In Notation3, we have expressions like:

    ex:f1 :- { ex:s1 ex:p1 ex:o1 . } .

which I understand to mean that the formula node is also identified by the 
URI ex:f1.  Which suggests that either:
   (a) the URI and formula (subgraph) are somehow bound together, or
   (b) the formula is a property (in the RDF sense) of the URI node.
or something else that I haven't thought of.

Lacking any particular vocabulary to suggest (b), I have previously gone 
along with (a).  But now a realize this raises another question:  does it 
make sense to have the following in the same graph?:

    ex:f1 :- { ex:s1 ex:p1 ex:o1 . } .

and

    ex:f1 :- { ex:s2 ex:p2 ex:o2 . } .

i.e. two different formulae associated with the same URI?  If so, are they 
the same node or are they different nodes.  Saying they're the same node 
leads me to conclusion (b) above (or some other approach I haven't thought 
of), and hence to ask what is the vocabulary that relates a formula to a 
node.  Saying they're different nodes seems to lead to a breakdown of the 
idea that a URI (alone) always denotes a single given concept.

How are other people treating the node/formula relationship (if at all)?

In case all this seems rather abstract, it has arisen because I've obtained 
some unexpected results when comparing graphs that contain formulae:

     { base1:s1 base1:p1 base1:o1 .
       base2:s2 base1:p1 base2:o2 .
       base3:s3 base1:p1 base3:o3 . } base2:p2 base2:f2 .

and

     { base1:s1 base1:p1 base1:o1 . } base2:p2 base2:f2 .

would reasonably seem to be different RDF graphs, but what about:

     base1:f1 :-
     { base1:s1 base1:p1 base1:o1 .
       base2:s2 base1:p1 base2:o2 .
       base3:s3 base1:p1 base3:o3 . } base2:p2 base2:f2 .

and

     base1:f1 :-
     { base1:s1 base1:p1 base1:o1 . } base2:p2 base2:f2 .

?

The algorithm I use to compare graphs, based on Jeremy Carroll's paper [3], 
looks for a bijection between graph nodes, where (per [2]) "M(uri)=uri for 
all RDF URI references uri which are nodes of either graph.", so both of 
the above pairs of graphs compare as equivalent.  This seems surprising to 
me, so I'm trying to figure out what I should try and fix.

#g
--

[1] http://www.ninebynine.org/RDFNotes/UsingContextsWithRDF.html#xtocid-6303976

[2] http://www.w3.org/TR/rdf-concepts/#section-Graph-syntax

[3] http://www.hpl.hp.com/semweb/publications.htm#Matching%20RDF%20Graphs



-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
Received on Thursday, 17 April 2003 06:31:49 GMT

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