- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 13 Jan 2005 15:31:32 +0100
- To: www-rdf-interest@w3.org, 'Atom WG' <atom-syntax@imc.org>
- Cc: atom-owl@googlegroups.com, bloged <users@bloged.dev.java.net>
Tim Bray, Roy Fielding and other have recently made some interesting
comments on the atom list saying that xml's tree structure has an
implicit semantics. If this is the case then one should be able to
map any xml into triple space graph. There is no special need for
any special rdf/xml.
So let me take the following example, a little extended version of the
example from the current atom spec.
<feed atom:version="draft-ietf-atompub-format-03: do not deploy"
xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-03">
<head>
<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<generator uri="https://bloged.dev.java.net/"
version="0.5">BlogEd</generator>
<author>
<name>John Doe</atom:name>
</author>
</head>
<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>vemmi://example.org/2003/32397</id>
<versionid>vemmi://example.org/2003/32397/v1</versionid>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</feed>
By following an nearly DOMish interpretation of the above we get the
graph below
_f -feed->_f1
|-head->_h1
| |-title--> _t1
| | |--xxx:string--> "example Feed"
| |-link--->_l1
| | |--href-> _href1
| | |---xxx:string---v
| | "http://example.org/"
| |-updated->_up1
| | |-xxx:string-> "2003-12-13T18:30:02Z"
| |--author-->_a1
| | |-name-> _nme
| | | |-xxx:string-> "John Doe"
| | |-mbox-> _mbox1
| | |-xxx:string->"john@doe.com"
| |-generator-> _gen
| |---uri--->_u1
| | |-----xxx:string-----v
| | "https://bloged.dev.java.net/"
| |-version-> _ver
| | |--xxx:string-> "0.5"
| |--xx:string-> "BlogEd"
|
|--entry-->_e1
|--title--> _t2
| |-xxx:string---v
| "Atom Powered Robots Run Amok"
|--link->_l1
| |-href-> _href2
| |----xxx:string---v
|
"http://example.org/2003/12/13/atom03"
|-id-> _id
| |-xxx:string--v
|
"vemmi://example.org/2003/12/13/atom03"
|-versionid-> _vs1
| |----xxx:string------v
|
"vemmi://example.org/2003/12/13/atom03/v1"
|--updated->_up
|--xx:string-> "2003-12-13T18:30:02Z"
So that is a graph. It is easy to see how a beginner DOM programmer
could generate one such
automatically. No magic there. And I think it nicely captures Tim Bray
and Roy Fielding's
intuition that xml nodes express properties on their parents.
Now let us imagine we now have an ontology that contains the following
statements
for all S and O
if S --title----> O then O -is a-> <xxx:String>
if S --link-----> O then O -is a-> <Link>
if S --href-----> O then O -is a-> <xxx:anyUri>
if S --updated--> O then O -is a-> <xxx:dateTime>
if S --author---> O then O -is a-> <Person>
if S --name-----> O then O -is a-> <xxx:String>
if S --mbox-----> O then O -is a-> <xxx:String>
if S --uri------> O then O -is a-> <xxx:anyUri>
if S --version--> O then O -is a-> <xxx:string>
if S --entry----> O then O -is a-> <Entry>
if S --title----> O then O -is a-> <xxx:String>
if S --link-----> O then O -is a-> <Link>
if S --name-----> O then O -is a-> <xxx:String>
if S --id-------> O then O -is a-> <xxx:anyUri>
if S -versionId-> O then O -is a-> <xxx:anyUri>
if S --updated--> O then O -is a-> <xxx:dateTime>
With the above facts we can then update our graph like this
(I have not added all the consequences to keep the graph readable)
_f -feed->_f1
|-head->_h1
| |-title--> _t1 ==is=a==> <xxx:String>
| | |--xxx:string--> "example Feed"
| |
| |-link--->_l1
| | |--href-> _href1 ==is=a=> <xxx:anyUri>
| | |-xxx:string->
"http://example.org/"
| |
| |-updated->_up1 ==is=a=> <xxx:dateTime>
| | |-xxx:string-> "2003-12-13T18:30:02Z"
| |
| |--author-->_a1
| | |-name-> _nme ==is=a==> <xxx:String>
| | | |-xxx:string-> "John Doe"
| | |
| | |-mbox-> _mbox1 ==is=a==> <xxx:String>
| | |-xxx:string->"john@doe.com"
| |-generator-> _gen
| |---uri--->_u1 ==is=a=> <xxx:anyUri>
| | |-----xxx:string----v
| | "https://bloged.dev.java.net/"
| |-version-> _ver ==is=a=> <xxx:String>
| | |--xxx:string-> "0.5"
| |--xx:string-> "BlogEd"
|
|--entry-->_e1
|--title--> _t2 ==is=a==> <xxx:String>
| |-xxx:string--v
| "Atom Powered Robots Run Amok"
|
|--link->_l1
| |-href-> _href2 ==is=a=> <xxx:anyUri>
| |-xxx:string--v
|
"http://example.org/2003/12/13/atom03"
|
|-id-> _id ==is=a=> <xxx:anyUri>
| |-xxx:string--v
| "vemmi://example.org/2003/12/13/atom03"
|
|-versionid-> _vs1 ==is=a=> <xxx:anyUri>
| |-------xxx:string------v
|
"vemmi://example.org/2003/12/13/atom03/v1"
|
|--updated->_up ==is=a=> <xxx:dateTime>
|--xx:string-> "2003-12-13T18:30:02Z"
Still no magic.
So next we assume that the ontology contains a graph transformation
rule that allows
the following transformation
from
S -----is a--> <xxx:String>
|-xxx:string-> "some string here"
to
"some string here"
ie: S == "some string here"
and from
S -----is a--> <xxx:anyUri>
|-xxx:string-> "http://bblfish.net/"
to
<http://bblfish.net>
ie: S == <http://bblfish.net>
From the above rules our graph now becomes
_f -feed->_f1
|-head->_h1
| |-title--> "example Feed"
| |
| |-link--->_l1
| | |--href-> <http://example.org/>
| |
| |-updated->_up1 -is-a-> <xxx:dateTime>
| | |-xxx:string-> "2003-12-13T18:30:02Z"
| |
| |--author-->_a1
| | |-name->"John Doe"
| | |-mbox-> "john@doe.com"
| |-generator-> _gen
| |---uri---v
| | <https://bloged.dev.java.net/>
| |-version-> "0.5"
| |--xx:string-> "BlogEd"
|
|--entry-->_e1
|--title--> "Atom Powered Robots Run Amok"
|
|--link->_l1
| |--------href----v
| <http://example.org/2003/12/13/atom03>
|
|-id-> <vemmi://example.org/2003/12/13/atom03>
|
|---------------versionid------v
| <vemmi://example.org/2003/12/13/atom03/v1>
|
|--updated->_up -is-a-> <xxx:dateTime>
|--xx:string-> "2003-12-13T18:30:02Z"
The above graph is just a consequence of applying those rules.
We could have other rules such as
the versionid property is functional, inverse functional, symmetric and
transitive
ie:
if S --versionid--> O then S == O
This would give us the following graph
_f -feed->_f1
|-head->_h1
| |-title--> "example Feed"
| |-link--->_l1
| | |--href-> <http://example.org/>
| |
| |-updated->_up1 -is-a-> <xxx:dateTime>
| | |-xxx:string-> "2003-12-13T18:30:02Z"
| |
| |--author-->_a1
| | |-name->"John Doe"
| | |-mbox-> "john@doe.com"
| |-generator-> _gen
| |-----------uri---v
| | <https://bloged.dev.java.net/>
| |-version-> "0.5"
| |--xx:string-> "BlogEd"
|
|--entry--> <vemmi://example.org/2003/12/13/atom03/v1>
|--title--> "Atom Powered Robots Run Amok"
|
|--link->_l1
| |-----href---v
| <http://example.org/2003/12/13/atom03>
|
|-id-> <vemmi://example.org/2003/12/13/atom03>
|
|--updated->_up -is-a-> <xxx:dateTime>
|--xx:string-> "2003-12-13T18:30:02Z"
Interestingly enough the graph above I get is (nearly) exactly the same
as the triple model
I get from parsing the closest rdf/xml I could get that resembles the
atom example xml:
<?xml version="1.0" encoding="utf-8"?>
<atom:feed atom:version="draft-ietf-atompub-format-03: do not
deploy"
xmlns:atom="http://purl.org/atom/ns#draft-ietf-atompub-format-03"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<atom:head rdf:parseType="Resource">
<atom:title>Example Feed</atom:title>
<atom:link atom:href="http://example.org/"/>
<atom:updated>2003-12-13T18:30:02Z</atom:updated>
<atom:author rdf:parseType="Resource">
<atom:name>John Doe</atom:name>
</atom:author>
</atom:head>
<atom:entry rdf:parseType="Resource">
<atom:title>Atom-Powered Robots Run Amok</atom:title>
<atom:link atom:href="http://example.org/2003/12/13/atom03"/>
<atom:id>vemmi://example.org/2003/32397</atom:id>
<atom:versionid>vemmi://example.org/2003/32397</atom:versionid>
<atom:updated>2003-12-13T18:30:02Z</atom:updated>
</atom:entry>
</atom:feed>
So that would tend to indicate that we are close to the intuitions of
the original
developers of rdf/xml.
But it looks like we don't need the special syntax of rdf/xml with the
rdf:parseType
thinggy. Any xml can be mapped to a graph following the rules implicit
in the example given above.
Having an ontology for the entities in that appear in the xml allows
one to do graph
transformations and reasoning. An ontology for the entities is all that
is therefore
required to make use of the 1rst level graph, and make it possible to
understand what
types of extensions to the xml are allowable. [1]
Am I on the right track here?
Henry Story
[0] My internet connection was down this morning, during which time
I wrote this, before being able to read the responses to my previous
mail on the rdf interest and atom-owl list entitled "a simpler form
of xml". This e-mail just works on the previous thought but is much
clearer I think.
For those readers on atom-owl and bloged I have fixed the ascii
graphs in this version.
[1] I could develop that in another email, if people are interested
Received on Thursday, 13 January 2005 14:32:00 UTC