W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2005

Re: xml without rdf, but with an ontology [0]

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 13 Jan 2005 15:31:32 +0100
Message-Id: <D1FD1FCA-656F-11D9-AAA2-000A95D9FA7A@bblfish.net>
Cc: atom-owl@googlegroups.com, bloged <users@bloged.dev.java.net>
To: www-rdf-interest@w3.org, 'Atom WG' <atom-syntax@imc.org>

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 GMT

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