[sc34wg3] Topic Maps and RDF
Ann M Wrightson
sc34wg3@isotopicmaps.org
Fri, 16 Aug 2002 12:28:31 +0100
This is a multi-part message in MIME format.
------=_NextPart_000_0002_01C24520.6E98C190
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0003_01C24520.6E9BCED0"
------=_NextPart_001_0003_01C24520.6E9BCED0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
------=_NextPart_001_0003_01C24520.6E9BCED0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT> </DIV></BODY></HTML>
------=_NextPart_001_0003_01C24520.6E9BCED0--
------=_NextPart_000_0002_01C24520.6E98C190
Content-Type: text/html;
name="TM and RDF.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="TM and RDF.html"
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3D"Author" content=3D"ann.wrightson">
<meta name=3D"GENERATOR" content=3D"Mozilla/4.7 [en] (WinNT; I) =
[Netscape]">
<title>TM and RDF</title>
</head>
<body>
<h1>
A unifying model for topic maps and RDF (well, maybe)</h1>
Ann Wrightson
<br><a =
href=3D"ann.wrightson@alphaxml.com">ann.wrightson@alphaxml.com</a>
<br>16 August 2002
<br>
<h2>
Nature of this document</h2>
Response to Eric Freese's polemic, and Steve Newcomb's nocturne, at =
"Extreme"
2002 (<a =
href=3D"http://www.mulberrytech.com/Extreme/index.html">http://www.mulber=
rytech.com/Extreme/index.html</a>).
<p>Discussion document for sc34wg3 and other interested folks - if it =
isn't
knocked down soon, I may put a direct descendant in as a late-break for
XML 2002.
<p>Kite-flying aka working draft - so therefore not complete and =
polished
by any means.
<br>Comments welcome.
<br>
<h2>
Basis of this model</h2>
This model is based on typed relations - or for the markup community, =
bastard
groves. The presentation is informal but hopefully understandable ;-)
<br>The reference used for topic maps is sc34wg3 N298Rev1 (the Reference
Model document presented at XML Europe by Steve Newcomb et al) - called
"RM" below.
<br>The reference used for RDF is the concise description of RDF graphs
and triples given in section 0.2 of the W3C RDF Model Theory document,
<a =
href=3D"http://www.w3.org/TR/rdf-mt/">http://www.w3.org/TR/rdf-mt/</a>
.
<br>Apart from the above, this model has no intentional relationship to
any other model proposed for either topic maps or RDF.
<br>It has been inspired by some model-doodling using situation theory,
hence the notation used for the relations, with << as an opening
delimiter, and >> as a closing delimiter for the typed tuples.
<br>Note that "type" is used informally, not as specialized in =
topicmap-speak.
<h2>
Here we go...</h2>
<h3>
First, a topic map.</h3>
A topic map is a bunch of typed relations (aka node classes in =
grove-speak)
as follows:
<h4>
A relation representing subjects</h4>
A subject node is a member of a one-place relation <<s>>, where s
is a set of considered-to-be-synonymous things (arbitrary things, of =
many
kinds - this is the key bit of topic map "magic") which identify the =
subject
of this node. A topic map application model may restrict this freedom =
(eg
only allow urirefs and literals to be members of s).
<dt>
</dt>
<br>Note that there is only one relation representing all the subject =
nodes
- this models the unique-node-per-subject characteristic of topic maps.
Also note that nothing here is telling you how to get hold of these =
subject
nodes - an implementable interpretation of this model could use anything
sensible, eg a handle or cookie.
<h4>
Relations representing assertion patterns</h4>
Each assertion pattern is a distinct n+1-place typed relation =
<<at,rt1,rt2,rt3,...>>.
<p>For each assertion type, the first member of the tuple is constant,
and is a member of <<s>> representing the assertion pattern =
itself.
<br>The number n of remaining "slots" (RM castings) in an =
assertion
pattern relation corresponds to the number of A-C arc "legs" on an =
assertion
of this pattern in the RM, and each "slot" individually corresponds to
one of those "legs".
<br>The type of the typed "slot" rt1 in an assertion pattern's relation
represents the role-player constraint(s) on the corresponding casting in
the RM.
<br>The casting itself is represented (in a member/instance of the =
assertion
pattern relation, aka an assertion) by the occupation of this typed =
"slot"
by a subject node of the correct type (i.e. satisfying the role-player
constraints). Note that there is no requirement (here or in the RM) that
the role player constraints are fully represented within the topic map,
just that they are identifiable (i.e. are present as subject(s)). (This
is another species of topic map "magic".)
<h3>
Second, RDF.</h3>
An RDF graph is a bunch of typed relations as follows:
<h4>
A relation representing urirefs</h4>
A uriref is a member of a one-place relation <<uri>>, where uri is
a singleton set containing a uriref.
<h4>
A relation representing literals</h4>
A literal is a member of a one-place relation <<lit>>, where lit
is a singleton set containing a literal.
<h4>
A relation representing names</h4>
A name is a member of a one-place relation <<n>>, which is the =
union
of <<uri>> and <<lit>>.
<h4>
A relation representing blank nodes</h4>
A blank node is a member of a one-place relation <<x>>, where x is
a null value with identity.
<p>In other words, members of this relation exist, are distinct, and can
participate in triples, but no actual value can be attributed to any of
them. This models the property of RDF blank nodes that merging two RDF
graphs does not merge any blank nodes. This is the RDF "magic".
<p>(I think the concept as I use it here comes from discussion of =
various
kinds of null values in relational databases, and my memory attributes
it to C J Date, but I cannot remember the reference.)
<h4>
A relation representing triples</h4>
A triple is a member of a three-place relation <<P,S,O>>, where S
is a member of <<uri>> or <<x>>; P is a member of =
<<uri>>;
and O is a member of <<n>> or <<x>>.
<h3>
Third: a unifying model?</h3>
Neither of the above models can implement the other, but there is =
substantial
overlap. (This seems right to me, in the light of recent =
papers/discussions.)
<br>So, it makes sense to look for a unifying model which can implement
both - and of course, the presentation above is designed to support just
that.
<h4>
Subjects/Names</h4>
The unifying model needs to include the subjects relation <<s>> =
from
the topic map model.
<p><<uri>> and <<lit>> in the RDF model are subsets of =
<<s>>
in the topic map model.
<br>The additional bit needed, is to make sure that there are members of
<<s>> representing the concepts of null-with-identity, uriref =
&
literal, and representing the role-playing constraints (types) required
for the RDF triple assertion-patterns' "slots".
<h4>
Blank nodes</h4>
The unifying model needs to include the blank nodes relation <<x>>
from the RDF model.
<h4>
Assertion patterns</h4>
The unifying model needs to include the collection of assertion =
pattern
relations <<at,rt1,rt2,rt3,...>> from the topic map model.
<p>The additional bit needed, is that RDF triples are implemented as =
assertion
patterns, as follows.
<br>Each distinct RDF predicate is a distinct assertion pattern, i.e. =
<<P,S,O>>
in the RDF model maps directly to <<at,rt1,rt2>>. The role playing
constraints on rt1 and rt2 correspond to the rules given in the RDF =
model
concerning membership of S and O.
<p>Note: these role-playing constraints involve blank nodes. The =
connexion
between blank nodes and subjects representing role playing constraints
involving blank nodes is not modelled - see remark below.
<h3>
Concluding remarks</h3>
This is satisfyingly neat in quasi-formal terms. Is it any use?
<br>I think the answer to this depends on several things:
<ul>
<li>
have I forgotten any key points in either technology?</li>
<li>
can topic map thinking find some way to accommodate the concept of a =
blank
node (without losing the benefits of RDF "magic")? - in particular, this
is needed to make full sense of role-playing constraints involving blank
nodes.</li>
<li>
can RDF thinking find some way to accommodate the way topic maps reserve
the right to use "magic" to determine subject identity and the effect of
role-playing constraints?</li>
</ul>
Please direct brickbats c/o the author (I reserve the right to dodge the
heavier ones).
</body>
</html>
------=_NextPart_000_0002_01C24520.6E98C190--