xml-dev - RE: Topic Maps and RDF

["Didier PH Martin" <martind@netfolder.com>]

Hi Kent,

Kent said:
Could someone across this area explain how Topic
Maps and RDF fit together, if at all?

Didier reply:
This is something we try to resolve since one year ;-). Here is what we
discovered.

a) topics are links (links governed by the Hytime architecture). We learned
that these links can easily be mapped to xlink:type="extended" links. So
far, so good.

b) RDF descriptions are, simply said, records about a resource. An RDF
record can also be perceived as a property collection or as a property set
(not to be confounded by SGML property sets).

c) both xlink and rdf behave like an architecture (I said, behave like). We
can have our own tags and include the "architecture" attributes in it, so
that, theoretically (or practically in the case of an SGML processor) an
Xlink or RDF processor can recognize and process the elements as xlink or
rdf elements. So far, so good.

The example below is a folder object. This object is a topic, as such, it
contains occurrences or links. It would obviously be useful to have more
than just links but also information about the resource pointed by the link
doesn't it? For example, to tell you who is the author, in which language is
this resource written, and so on and so forth.

So, in such ways that, in addition to include the object's location we also
have some more information about the object and that this information is "at
the right place" or contained near the "location" reference. This is the
principle of locality, which, as we all know, augment the readability of the
content. (have ever used a listing where you have to move back and forth
between the beginning of the document and the end of it. particularly when
the document has more than 50 pages? Remember how funny it was :-)).

So, the example below is XMLized and uses name spaces. Why? simply because
we talked about name spaces this week :-). No, just kidding, it also helps
the interpreter to retrieve its eggs.

Example:
--------
<tm:topic scope="public">
<tm:topname>
  <tm:basename>Name spaces</tm:basename>
  <tm:dispname>Name spaces</tm:dispname>
</tm:topname>
<tm:occurs xlink:type="extended">
  <tm:loc xlink:type="locator"
rdf:about="http://mydomain.com/HotTopic/name_space.htm"
xlink:href="http://mydomain.com/HotTopic/name_space.htm">
   <tns:name>Name_space</tns:name>
   <tns:creator>code runner, bip bip!</tns:creator>
   <tns:date>today</tns:date>
</tns:item>
</tm:occurs>
</tns:folder>

Let's explain a bit what it is, and the actual limits of merging this
"poutine" (for those who do not know what this is, it a strange mixture of
French fries and cheese :-).

a) the master element is the tm:topic element. When I said that the topic
element is a link, I should have said instead "contains an extended link"
when we adapt the topic map element to the XML world.  Thus, the scope
attribute is a topic attribute. An XML parser can now provide to a topic map
interpreter the tm:topic element and this latter to recognize that this is a
topic. Because the XML world does not have any architectural form
recommendation, a W3C compliant parser cannot make the right substitution,
so, the interpreter then needs a clear way to know that this is a topic.
Thus, we have to help this poor guy by being explicit and tell it that this
is a topic element (if we want it to do its job). So far, so good. We
discovered that architectural form cannot be applied when we deal with XML
parser which never heard about this feature (I have been told by a good
friend of mine these XML parsers consider Architectural form as snobbish,
but this is between you and me and do not repeat this to "SP" he does not
feel well these days :-))

b) We then have a name element which contains as sub elements several
flavors of naming. Enough to make Ben and Jerry jealous :-)

c) This is followed by the occurs element, itself the real stuff: the link
(with a background music of "Also spreach Zaratoustra"). It is a one to many
link. I.e. a link pointing to multiple resources. Here come the xlink
"extended" kind of link and this latter contains locations. Again, to help
our friend, the topic map interpreter, we used a keyword which is part of
the tm vocabulary (tm:occurs). Now the topic map parser knows that this is a
topic occurrence set. The topic map intepreter expect to retreive location
element as content.

Some sophisticated interpreter may do the following process
 1 - transform what the parser gave into an internal structure or use the
structure provided by the parser (i.e. the DOM)

 2 - Then, have different "element handler" recognize what an element is.
So, in our case, the tm:occurs, help our friend (the topic map interpreter)
to recognize here a topic map occurs element and then will expect locations
to be contained in it. The element could also ge given as food to the xlink
interpreter.  The "xlink:type" attribute is a keyword recognized by the
xlink interpreter and thus indicates to this latter that this is a one to
many kind of link and that this latter will contain one or more locators.
Thus, both the topic map and xlink interpreters have expectations about
what's should be coming next.

 3 - Then, we encounter a loc element. Hummm, we have some guys here that
have expectations about what this element should be. The xlink interpreter
is anxiously waiting for a "locator", the topic map interpreter for a
"location", this latter may simply decide that linkage is after all a matter
to be treated by the xlink interpreter and will simply let this later do the
job. These two guys already satisfied, give as food, the element to other
interpreters, just in case... Bang! (a big gong sound) the rdf interpreter
recognizes the "rdf:about" attribute and prepare itself to build a property
set for the resource identified by the "about" value. The rdf interpreter
expects properties to be contained in this element.  Finally, the
"xlink:href" attribute is what the xlink interpreter expected: a resource
reference. The xlink interpreter can do something with it like store it, or
information about the kind of behavior we expect from it if some more
attributes are included in the locator element. But wait a minute here! we
have two times the same value (a) for the rdf:about attribute and (b) for
the xlink:href attribute. Hummm, I guess these guys will go to meet the
judge to know how to resolve this dispute about the resource location. One
of these guys say that to be an rdf description "about" this resource, you
need to provide the resource URI as a value. And the other party repeat that
to be able to resolve the link, it needs the URI too. And I have been
convened to be part of the jury. Both have a good story to tell. Hummm hard
to decide.

And here I am, sitting on my jury chair, trying to figure out why these two
guys do not talk each other and could share the same resource pointer.

So here we are, yes we have all the intuition that these two world could be
merged and that it make sense that these two world be merged, but when you
are seated on a jury's chair, things are not so easy.

Have a good day (And please do not tell to SP what the other parsers think
about architectural form, I heard that he feels lonely these days since all
his SGML friends moved to XML, be kind to him :-))

Note: All resemblance between characters and real persons is pure
coincidence and the producers may not be held as responsible for such
resemblance :-))

PS: I am writing about this topic and issues and will try to do my jury's
job as well as possible.

Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Next conference: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)