Topic maps, RDF, DAML, OIL

A comparison

By:Lars Marius Garshol

This paper has since been replaced by a more recent and more thorough paper that also covers OWL and query languages: Living with topic maps and RDF.

For a concise statement of the relationship between RDF and Topic Maps, see Comparing Topic Maps and RDF.


The terms RDF, OIL, DAML, and topic maps all tend to be mentioned whenever technologies for the semantic web, knowledge management, or information management are being discussed. Finding someone who knows more than one of these well is almost impossible, however.

This paper sets out to change that, by providing quick introductions to each of the technologies, highlighting the similarities and differences between them. These technologies all come from very different backgrounds, and tend to be presented in very different ways, and yet on closer examination their anatomies turn out to be surprisingly similar.

The starting point of the paper is the observation that all these technologies provide a restricted set of mechanisms for making statements about the Universe of Discourse. The introductions to the technologies are done by describing how concepts such as 'thing', 'relationships between things', 'properties of things', 'types of things', 'names of things', 'kinds of things' and so on are represented within each technology.

After comparing the technologies it is shown how each of these technologies relate to one another and to what extent they build on each other or compete with each other. More importantly, the paper also shows how data can be moved from one representation to another, and how tools implementing the various technologies can be made to work together.


Lars Marius Garshol is currently Development Manager at Ontopia, a topic map software vendor. He has been active in the XML and topic map communities as a speaker, consultant and open source developer for a number of years.

Lars Marius has also been responsible for adding Unicode support to the Opera web browser. At the moment, he is completing his book on 'Developing XML Applications', to be published by Prentice-Hall in its Charles Goldfarb series later this year.

Lars Marius is one of the editors of the ISO Topic Map Query Language standard, and also co-editor of the Topic Map data model.

1. Interoperability between standards

An old joke has it that "The nice thing about standards is that there are so many to choose between". This certainly applies to RDF, topic maps, DAML, and OIL, though whether it really is nice to have to choose among so many standards is very much in doubt. The main purpose of having a standard is to make it possible for data and applications to be interoperable, something that is much harder when the data and applications use proprietary technologies. This benefit is compromised, however, when a number of standards occupy the same space, as in this case.

This paper serves a number of purposes, but the most important of them is to help readers deal with this problem of standards with overlapping functionality. This is done by comparing the standards so that readers have a reasonable foundation for choosing the right standard for their needs, and by showing how data can be moved back and forth between the representations of the different standards.

1.1. The backgrounds of the standards

Topic maps have a long and complicated history, beginning with the Davenport group, which in 1991 started a process to create a standard SGML DTD for software documentation. This group quite quickly spun off an offshoot called CApH (Conventions for the Application of HyTime) , one of whose tasks was to design an application for computerized back-of-book indexes. These indexes were intended to have one novel feature: it should be possible to merge them automatically. The ideas behind this application were what eventually became topic maps.

CApH worked on the concept for a long time, before topic maps was accepted by ISO's SGML working group as a new work item in 1996. ISO then spent another four years working on the standard before it was approved as ISO/IEC 13250:2000 in January 2000 ([ISO13250]. Topic maps then had the form of an SGML architecture based on HyTime. Work was later done by an informal organization known as TopicMaps.Org, which produced the XTM (XML Topic Maps) syntax for topic maps ([XTM1.0]). This was a reformulation of topic maps in XML syntax based on XLink. This syntax has since been accepted by ISO into ISO 13250 as an annex. The XTM syntax is used by nearly all topic map software today, while use of the original SGML syntax is rare.

Topic maps have many applications, but one of their main applications is that of solving the findability problem of information, that is: how to find the information you are looking for in large body of information. Topic maps can also be used for knowledge management, for web portal development, content management, and enterprise application integration (EAI). Topic maps are also being described as an enabling technology for the semantic web. (Note: throughout this section I will present what the proponents of each technology claim that it can do, and apply no critical analysis of my own, as that would be outside the scope of this paper.)

RDF (Resource Description Framework) [RDF] was developed by the W3C (World Wide Web Consortium) as part of its semantic web effort. RDF started as an extension of the PICS content description technology [PICS] (also a W3C technology), but was influenced by submissions from Microsoft and Netscape, and has evolved considerably beyond its beginnings. The first RDF working draft was released in October 1997, and the specification became a W3C Recommendation in February 1999. RDF is part of Tim Berners-Lee's effort to realize his vision of the Semantic Web.

As an information management technology RDF has a number of possible application areas. It is mainly intended for use in the semantic web, but it is also being described variously as a content management technology, a knowledge management technology, a portal technology, and also as one of the pillars of e-commerce.

DAML (DARPA Agent Markup Language) was created as part of a research program started in August 2000 by DARPA, a US governmental research organization. It is being developed by a large team of researchers, coordinated by DARPA. DAML is not defined by any standards body, but is published on, a site run as part of the DAML program.

DAML seems to be entirely focused on supporting the semantic web, though one would assume that it also has other uses. Given that DAML is much the same as OIL would seem that it too can be used to solve the findability problem, be used in e-commerce, and used in knowledge management.

OIL (Ontology Inference Layer) is an initiative funded by the European Union programme for Information Society Technologies as part of some of its reasearch projects. The work has been done by participants in these projects, and the resulting specification is a specification published by the reseach project.

OIL is obviously a semantic web technology, and according to the OIL FAQ OIL is intended to solve the findability problem, support e-commerce, and enable knowledge management.

Below is a table that compares the usage areas of these technologies.

Findability Yes Yes Yes Yes
Portals Yes Yes Yes Yes
Content management Yes Yes Yes Yes
E-commerce Yes Yes Yes Yes
KM Yes Yes Yes Yes
Semantic web Yes Yes Yes Yes

From this comparison it should be clear that the application areas of these technologies, as presented by their respective proponents, are more-or-less identical. The only difference being that RDF, DAML, and OIL are not presented as EAI technologies. This, however, does not mean that they cannot be used for EAI purposes. In short, those wishing to exchange information in any of these areas and using one of these standards are likely to find that exchange partners have chosen one of the other technologies. As this paper will show, however, this is not necessarily a problem.

1.2. Requirements for solutions

The problem to be solved is that of making these four standards interoperate. At the lowest level that means being able to move data back and forth between the systems. A more ambitious goal is to be able to use software implementing different standards in the same production system, for example by using query languages or schema languages defined for one model with data represented in another. In this paper I will concentrate on moving data between the representations and not consider the issues of how to implement integrations in any depth.

This means that we will assume that there is an application A performing some function X for its users, based on topic maps, and another application B, also performing function X for its users, based on RDF. The problem to be solved is that of making A able to use B's data, and vice versa.

Before starting to look at specific ways to map data between representations it is useful to look at the criteria by which solutions can be judged. Below is a list of such criteria.

In general, there are two classes of approaches to mapping from one representation to another: schema-independent (or model-based) and schema-based mappings. The first class maps the model of the one representation directly to the model of the other, or it may model the one model inside the other. The result is that all data in one model can be mapped automatically into the other without further ado. The second class requires a mapping to be developed separately for every schema, but once that is done all conversions are automatic.

Of these two approaches, the model-based has an advantage in that it requires no effort to set up, which schema-based mappings do. It often has a disadvantage, however, in that the data in the target representation created by the mapping are often not in the desired form, and so require processing after the mapping. Both approaches can be complete, but model-based mappings are generally easier to implement. In short, one kind of mapping is not inherently superior to the other; one must examine individual proposals to find out which are the best.

1.3. How to implement solutions

There are two general approaches to implementing mappings between the models:

Which of these approaches that is the best depends on the needs of each particular application. The static mappings are by far the easier to implement, but in the situations where they are most appropriate the dynamic mappings are sufficiently more useful than the static ones that the effort of implementing them are worth it. Dynamic mappings are also the ones needed to achieve direct software integration.

In general, the exact form of the mapping between two data models is orthogonal to the issue of how it is implemented. Some mappings, however, may be difficult to implement efficiently as dynamic solutions.

2. Comparing the models

Before we move on to look at specific mapping solution this section compares the different models, explaining the relationship between the different models.

2.1. 'Things'

The central notion in both RDF and topic maps is that there are things that we wish to make assertions about. Examples of such things may be the person 'Lars Marius Garshol', the company 'Ontopia', and this paper. In topic maps such things are represented by constructs called topics, in RDF by constructs called resources. At heart, these constructs are the same: digital symbols representing some well-defined thing.

In RDF each resource is represented by a single URI (Universal Resource Identifier) , which makes it clear exactly what the resource is. If the RDF model is making assertions about documents and files the URI will be that of the document or file, but many RDF models discuss abstract things, in which case the URI is just a symbolic identifier for the resource.

In topic maps, the things in the real world that topics represent are called their subjects. Topics may identify their subjects in several ways, for example by specifying the resource that is the subject of the topic by means of a URI. This corresponds exactly to an RDF resource representing a document or file. Topics can also have subject indicators, however, which are URIs referring to resources that indicate (to a human) what the subject of the topic is. This corresponds exactly to an RDF resource that represents an abstract concept. [this discussion is not sufficient: the interpretation of URIs is more complex than this]

Whether one used RDF or topic maps, one would generally assign the same URIs to the three example things. would be a reasonable URI for the resource 'Lars Marius Garshol'. In a topic map this would be a subject indicator, and not a subject address. For Ontopia, would be the URI, and in a topic map it would be a subject indicator. For this paper would be the URI, and in a topic map this would be a subject address.

Below is a diagram that shows the representations of these three things in topic maps and RDF side by side for easy comparison.

Three things

As can be seen, topic maps and RDF have the same central concept, but treat it slightly differently. In an RDF model there is no application-independent way of telling whether a resource is abstract or concrete. In topic maps, that can be seen by whether the topic has a subject address or a subject indicator.

The main difference between these models and XML is that XML does not have this concept. In XML there is no notion that each element necessarily represents some real-world 'thing', nor is there any procedure for declaring the identity of that 'thing'. For this reason the rest of the sections do not apply to XML, since they discuss the characteristics of these 'things', and as the 'things' themselves are missing from XML, so must necessarily their characteristics be.

2.2. Relationships

When we create models of the world which contain things it is because we wish to make assertions about these things, and the main kind of assertion we wish to make is what relationships these things have with each other. RDF and topic maps both provide mechanisms for doing this, but these mechanisms are quite different.

In RDF resources can be assigned properties through the use of statements. These are simple triples, consisting of the resource being assigned a property, the property type (represented by a URI), and the property value, which can be a literal or a URI. The use of URIs as property values allows statements to express the relationships between things.

For example, to say that I am employed by Ontopia we could use this simple RDF statement: (, employed-by,

In topic maps the relationships between things can be expressed using associations. Associations are typed, like RDF statements, and the types are themselves topics. Any number of topics can play roles in an association, and their involvement in the association is defined by their association role type (which is also a topic). The relationship between me and Ontopia is perhaps best represented by an association of the type 'employed-by', where I play the role 'employee', and Ontopia the role 'employer'.

The diagram below shows what this relationship looks like in topic maps, using a graphical notation invented for the purpose.

One relationship in topic maps

Below, the same relationship is shown in RDF. Obviously, the relationship is a lot simpler, but it is harder to extend, and it is also not clear to software with no knowledge of the schema that it is a relationship.

The same relationship in RDF

There are three major differences between how RDF and topic maps represent relationships:

In short, in topic maps you know that what is relationships and what is not, all relationships are two-way, and it is easier to represent complex relationships.

2.3. Attributes

Another common wish in information modelling is to capture the attributes of the things being modelled. Attributes are pieces of information that may be attached to things, but which are not sufficiently important to be considered things in their own right.

Some examples of attributes of the thing 'Lars Marius Garshol' are: my name, my home page, and my birth date. In RDF, these things are simply properties of the resource 'Lars Marius Garshol' and are encoded using three statements: (, name, "Lars Marius Garshol"), (, homepage,, and (, birthdate, "1973-12-25").

The diagram below shows what this would look like in RDF. Note how it is impossible to tell the assignment of names, metadata, and resources with more information apart from one another, and also from the statement in the previous section, that represented a relationship.

Three attributes in RDF

In topic maps this would look entirely different. Topic maps have a concept of occurrences, which are pieces of information relevant to a topic. Occurrences can either be resources external to the topic map, which are then represented by the URI of the resource, or they can be strings internal to the topic map. Occurrences are typed, the types being topics.

The natural way to represent my home page would be to give me an occurrence of type "home page", and to set the URI to "". My birth date would become an internal occurrence, of type "birth date", where the value was a string representing the date. My name, however, would not be an occurrence. Topic maps have a concept of topic names (which are really privileged occurrences), and so my name would be represented as a name.

Unfortunately, the author's drawing skills are insufficient to represent the differences between a topic, its name, and two kinds of occurrences, and so there is no diagram of this.

This is perhaps the point at which the differences between topic maps and RDF become most pronounced. There are three different classes of attributes involved here, and these are worth discussing separately:

Again topic maps are found to be higher-level than RDF and to contain more explicit semantics. This means both that it is easier to develop generic software for topic maps, and that conceptualization of topic map applications is easier, because some of the work has been done in the standard itself.

2.4. Kinds of things

One of the most important pieces of information one generally wishes to record about things is of what kinds they are. For example, I am a person, while Ontopia is a company. This is very important information, and so both topic maps and RDF provide standardized means of representing it. In RDF, there is a standardized property called rdf:type which is used to represent the instance-of relationship between the class and the instance.

In topic maps this information is part of the model: each topic has a set of classes of which it is considered an instance. The information can therefore be represented directly. Topic maps also have a standardized association type for the class-instance relationship, which means that it is possible to represent this relationship with an association. Since this relationship is so fundamental most topic map implementations represent it as a property of topics, however.

This is in fact the area where topic maps and RDF have most in common, and rdf:type is as good as identical to the topic map notion of class-instance.

2.5. Context

It is often useful to be able to attach information about the context of the relationships and attributes of things. This context information may state that "this characteristic is only valid in a certain context", or provide useful metadata about the characteristic. RDF has no notion of such contexts, although by introducing anonymous resources in property assignments context information can be attached to the assignments. This is somewhat awkward, however.

In topic maps, such contexts are known as scopes. Scopes consist of sets of topics which define the context of validity, and can be attached to names, occurrences, and associations. This feature can be quite useful. For example, what if one wishes to make a multilingual information system where information may be available in many languages? In RDF this can be handled by defining separate properties for, say, names and definitions of concepts in each language. This is awkward and obscures the commonalities of names and definitions. It also obscures the fact that the differences between the various properties is one of context, and makes it harder to extend the schema. In topic maps this can be handled by using language as one axis of scope. Names are already first-class constructs to which scope can be attached, and definitions can be made occurrence types.

The main differences between topic maps and RDF in this area is that context is much easier to work with in topic maps, and that generic software can know how contexts are represented in each application. In fact, the Ontopia Omnigator ([Omnigator], is a generic topic map browser, which can analyze the scopes used in a topic map, and allows the user to set a context to be used for filtering the topic map as it is displayed. [screenshot of filter page?]

[Pepper01] provides an in-depth discussion of scope in topic maps, and has much useful information on the applications of scope.

2.6. Reification

Reification is a technique that originated in artificial intelligence, and the term quite literally means "thingification". This is also essentially what it means: to turn objects we wish to speak of into "things", so that we can make assertions about them. This is essential because before objects become things we cannot speak of them.

To take an example: what if wanted to make the statement that the name "Ontopia" is of Greek origin? In the topic map, the topic "Ontopia" has a name, which is "Ontopia", but we cannot create an association between this name and the Greek language, because associations only connect topics. The solution is to reify the name by making a topic that represents it, and then associate that topic with Greek.

The only problem with this solution is that it is impossible for software to know that subject of the topic "Ontopia's-name" is the name of the topic "Ontopia". This can be solved by giving the name an ID (which is possible in the XTM syntax) and then making the subject indicator of the "Ontopia's name" topic refer to this ID. This lets software know what the relationship between this topic and the topic name is.

RDF has a similar notion of reification, although it is used slightly differently there. This author is not sufficiently familiar with RDF to be able to compare the use of reification in RDF with its use in topic maps.

2.7. DAML and OIL

Unlike RDF and topic maps DAML is not a data model; instead, it is a schema language that can be used to constrain and describe data following the RDF data model. To put it another way: DAML is an RDF schema language. RDF already has a schema language, called RDF Schema [RDF-Schema], and DAML is an extension of this language. Note that DAML also extends the RDF syntax, and that DAML files cannot necessarily be parsed with RDF parsers.

The value of DAML is thus that it allows one to describe RDF data, and so makes it possible to add more semantics to the data. As one of the major differences between topic maps and RDF is that topic maps provide more information about their own semantics this is interesting as a possible way of narrowing the gap between RDF and topic maps. In general, what DAML adds to RDF Schema is additional ways to constrain the allowed values of properties, and what properties a class may have. In addition, it provides some properties that can be truly useful to generic software, which are:

In short, DAML strengthens the RDF schema language, and adds a little bit of semantics on top. The semanics are mainly things topic maps already have, apart from the ability to specify that a relationship is transitive. This ability is really a poor man's inference engine, and any inference engine, for RDF or for topic maps, will provide capabilities far beyond what this property provides.

OIL is very similar to DAML in that it, too, is an extension of RDF Schema, and the capabilities of the two languages are very similar. They are not entirely the same, however, despite the fact that the latest release of DAML is called DAML+OIL. The proponents of OIL claim that OIL has some desirable properties and capabilities that DAML does not, but these are not very relevant to the issue discussed in this paper, and will therefore not be discussed here.

To compare with topic maps, there is no standardized schema language for topic maps, although one is under development ([TMCL]). As for the semantics added by DAML to RDF, topic maps already have most of these. Stating that two association types or occurrence types are the same is done by merging them in topic maps. There is no need for an inverse of relationship, since all relationships are multidirectional in topic maps. The ability to say that a relationship is transitive, however, is missing from topic maps, and would make a useful addition.

2.8. Serialized models

To help readers get an overview of the models presented so far, this section shows the example model about the author and Ontopia using the different syntaxes of topic maps and RDF.

Below is shown the example model in LTM syntax ([LTM1.1]). The characteristics of the the typing topics are left out for clarity.

The model in LTM

[lmg : person = "Lars Marius Garshol"
{lmg, homepage, ""}
{lmg, birthdate, "1973-12-25"}

[ontopia : company = "Ontopia"

employed-by([ontopia] : employer, [lmg] : employee)

Below are shown the corresponding RDF triples.

The model in RDF triples


 "Lars Marius Garshol"}






2.9. Summary

RDF and topic maps have the same central concept, which I have here called 'thing'. They have entirely different notions about how characteristics are assigned to these 'things', however, and their ideas about how to establish the identities of the 'things' are also different. In RDF statements, in the form of (subject, property, object) triples, are the only way of assigning characteristics, while in topic maps topics may have names, occurrences, and participate in associations.

In RDF, the URI of the resource identifies it. In topic maps, the topic may have a URI that points to the resource that is the topic, and it may have any number of URIs that point to resources that explain what the topic is.

In a very real sense this makes RDF substantially lower-level than topic maps, and means that it is impossible to make sense of RDF models without knowledge of their schema to the extent that one can, for example, display the data in a user-friendly fashion. With topic maps, however, this is possible, because of the higher level of abstraction.

DAML and OIL use the same data model as RDF, which they do not enrich, and to which they contribute very little in the way of semantics, and so no further consideration needs to be given to them.

In the table below each row shows a possible correlation of terms between topic maps and RDF. This table is neither complete nor exact, but should provide a useful summary of the model comparison. Note that a very useful, and sadly overlooked, source on information about topic map terminology is annex B of [XTM1.0].

Topic map term Relationship RDF term
Topic map comparable to RDF graph
Topic comparable to Resource
Subject comparable to Resource
Resource comparable to Network-retrievable resource
Non-addressable subject comparable to Non-network-retrievable resource
Association kind of Statement
Occurrence kind of Statement
Name assignment type of Statement
Class of topics comparable to Class

3. Integrating the standards

Now that we know what the relationship between the two models is we can start considering the question of how to move data back and forth between the two representations.

3.1. Prior art

Before we move on to consider possible solutions we will look at the work already done in this area, and consider it in the light of the criteria presented in an earlier section.

3.1.1. The first attempt

The first publicized proposal for integrating RDF and topic map data was [Moore01]. This paper does a number of different things, and we'll go through them one by one.

The first thing it does is to represent RDF models using topic maps. This is done very simply by defining subject indicators for the concepts of RDF statements, subjects, properties, and objects. Each RDF statement then becomes an association of type RDF statement, where the subject, property, and object play the roles defined by the subject indicators already mentioned.

This provides a straightforward means of representing RDF in topic maps, although it leaves some questions open. For example, the RDF resources presumably become topics, but nothing is said about what happens with their URIs. Do they become subject addresses or subject indicators? It is clear that this mapping leaves a number of things to be desired also from a practical point of view. In Moore's defense it must be said that it does not seem to have been intended to be more than an academic exercise to show that topic maps are flexible enough to model RDF, and so I will leave it at that.

The next step taken in the paper is to model topic maps using RDF. Here RDF properties are defined for the various topic map constructs, and topic maps are represented accordingly. One notable aspect is that names, for example, are represented using an anonymous resource, in order that scope, foer example, may be attached to it. The model is not complete, however, as variant names are not handled, and again the question of how to handle subject addresses and subject indicators is left open. Again, however, Moore's text indicates that he intends merely to demonstrate that RDF can represent topic maps, and not to create a practical solution.

The last step taken in the paper is to propose a model-to-model mapping from RDF to topic maps, and this is the real purpose of the paper. The model-to-model mapping equates RDF model with topic map, and topic with resource. This is generally accepted, and this paper takes the same approach. The URIs of RDF resources are equated with the subject indicators of topics in topic maps, leaving unanswered the question if the URIs of some RDF resources may not also be subject addresses.

Finally, RDF statements are compared with associations in topic maps, and the paper proposes that statements can be mapped to associations if the property becomes the association type, and fixed, pre-defined topics are used to represent the subject and object roles in the association. This works, but can only be the first stage of a mapping, since, as we have already demonstrated, RDF statements can have a number of different topic map equivalents, not just associations.

Moore does not stop here, however, but proceeds to propose that the topic map model be extended with the concepts of "arc" and "association template". The paper leaves the workings of these somewhat unambigious, so the question of whether these concepts suffer from the same problem as the mapping to associations is unclear.

To summarize, Moore's work is interesting, and serves to highlight a number of interesting points, but it is not the final word on this issue. The author himself describes it as a "first positional paper introducing the concepts", and this is a fair summary.

3.1.2. A second attempt

Another interesting proposal is the one presented in [Lacher01]. This paper presents a method for mapping topic map data into RDF data, based on the topic map data model proposal presented in [PMTM4]. In fact, the approach presented is an RDF schema that directly represents the [PMTM4] model using RDF statements corresponding to the constructs found therein. This approach works, and is, as claimed by the authors, complete and reversible, but the resulting RDF data are very awkwardly represented.

[Lacher01] does not provide any serialized examples of topic maps mapped to RDF, so it is little difficult to evaluate this proposal fully, but some properties of the mapping are clear:

In short, this proposal is incomplete, in that it only considers mapping RDF to topic maps, and also in that the resulting RDF is relatively awkward to work with.

3.1.3. A third attempt

[Ogievitsky01] also considers the mapping of topic map data to RDF, and takes an approach similar to that of [Lacher01]. [Ogievitsky01] is also based on [PMTM4], but departs from it in several respects. It also uses a different RDF Schema from [Lacher01].

There are several interesting aspects of Ogievetsky's proposal:

In short, Ogievetsky's proposal is incomplete, in that it only considers going from topic maps to RDF, and it produces RDF output that is, again, awkward to work with. On the other hand, the treatment of the topic maps to RDF mapping is relatively complete.

3.1.4. Summary

To summarize, the work done on RDF and topic map integration to date is incomplete, in that the only in-depth proposals concern mode-based mappings of topic map data to RDF. The only work that is done on comparing the models is unsatisfactory. Also, hardly any of the problematic issues have been addressed, and few, if any, attempts have been made at separating constructs that are obviously very similar across the models from constructs that obviously very different.

3.2. From RDF to topic maps

As shown in the previous section RDF models consist of statements in the form of triples, and the correct representation of an RDF statement in a topic map can be any of a number of possible constructs in a topic map. The table below enumerates the possible appropriate mappings for an RDF statement in topic maps. The subject, property, and object columns, show what each corresponds to in topic map terms.

Statement Subject Property Object
Association Role playing topic Association type (and role types) Role playing topic
Occurrence Topic Occurrence type (and scope) Resource
Base name Topic Scope Base name value
Variant name Topic Scope (and base name) Variant name value
Subject indicator Topic URI prefix, if any Subject indicator URI
Instance of Topic Instance of association Topic

The obvious conclusion to be drawn from this is that a generalized mapping from RDF to topic maps that will work for any RDF model is not possible. A person with knowledge of the RDF schema, however, can construct an appropriate mapping. This is possible because while statements can correspond to many different things, each property corresponds to one, and only one, of these alternatives.

To make this discussion more concrete we will use an example RDF model to demonstrate the principles. This is the RDF version of WordNet found at, in which dictionary information can be found in RDF form. This dictionary is based around concepts with numbered IDs, and these concepts have word forms that can be used to refer to them, glossary definitions, references to more specialized concepts, and also references to similar concepts. Below is given the set of RDF statements pertaining to one word in WordNet.

A set of WordNet statements

1 : {,,}

2 : {,,

3 : {,,

4 : {,,

5 : {,,}

6 : {,,
          'perceive mentally, as of an idea; "Now I see!";
      "I just can\'t see your point"'}

These are the RDF statements that apply to the concept with the ID 200399152. Below I'll explain the significance of each statment.

  1. This statements says that this concept is an instance of the type "Verb"; that is, that it is a verb.

  2. This statement says that one word form which can be used to refer to this concept is "understand".

  3. This statement says that one word form which can be used to refer to this concept is "realize". This implies that "understand" and "realize" can be used as synonyms for the same concept. (Note that it is fully possible for these words to also refer to different concepts.)

  4. This statement provides an additional word form: "see".

  5. This statement says that the concept with ID 200399152 is a more specialized form of this concept.

  6. Finally, this statement provides the glossary definition of the concept.

Now that we understand the RDF application we are ready to start mapping it to a topic map. As there are only four RDF properties involved, this should not be too hard. Below is described how to map each of these properties into topic map constructs:

This means that we are now ready to actually perform the mapping and turn the entire WordNet RDF model into a topic map. I have developed an XML syntax for describing mappings from RDF to topic maps, and made a proof-of-concept implementation of this in Jython, using the Ontopia Topic Map Engine. The mapping file describes the mapping of each RDF property using a syntax that is essentially a templated version of the XTM 1.0 syntax.

This is done by writing a mapping file in XML which describes how the mapping is performed. The mapping file for the WordNet example can be seen below.

The WordNet mapping file


  <property uri="">

  <property uri="">

  <property uri="">
      <instanceOf>Glossary entry</instanceOf>

  <property uri="">
      <instanceOf>Hyponym of</instanceOf>

        <roleSpec>Specific term</roleSpec>

        <roleSpec>General term</roleSpec>


Each property element in the mapping file defines how to map an RDF property into topic map constructs. The URI of the subject resource always becomes the subject indicator of a topic, unless otherwise noted in the mapping file (there are no examples of this here). The templates can also be enriched beyond what is shown here; for example, the scope of base names, occurrences, and associations can be specified in the mapping file.

By feeding this mapping file together with the WordNet RDF snippet quoted above into our RDF-to-topicmap mapper a topic map equivalent to the one shown below (in LTM syntax [LTM1.1]) is created. The example is not shown in XTM syntax, as that would take up quite a bit of space, and be much less readable.

The result of the mapping

[understand : verb = "realize"
                   = "understand"
                   = "see"

{understand, glossary, [[perceive mentally, as of an idea; "Now I see!";
"I just can't see your point"]]}

hyponym-of([understand] : general, [perceive] : specific)

This topic map has one topic, understand, of type verb, with three base names, and a subject indicator. (This is what is contained in the square brackets.) That topic also has an occurrence, of type glossary, with the text given. Finally, there is an association, of type hyponym-of, where the topic understand plays the role of the general concept, while the topic perceive plays the role of the specific concept.

This solution is easy to configure, easy to use, and produces topic map data that is of quality comparable to that of topic maps created as topic maps to begin with. Given an existing topic map engine and an RDF parser the solution is also easy to implement. The Jython implementation is 300 lines of code. (The source is not given here for reasons of space.)

This solution has some weaknesses, admittedly, the most important being that it does not handle RDF property assignments that are indirect. That is, assignments that use anonymous resources. This could be because they use RDF collections, or because one wants to reify the property assignment. A second weakness is that in some cases it may be desirable to map RDF properties in more than one way, for example based on the type of the subject or information attached to the property assignment via reification. (Scope, for example, might well depend on reification.)

I have been unable to investigate these issues through a combination of lack of RDF expertise, and a lack of real-world examples which actually make use of these features. Most likely, the way to handle these cases would be to allow the mapping file to perform RDF queries using some RDF query language in order to produce the input data to the mapping. I hope to be able to explore this in later work.

3.3. A model-based mapping from topic maps to RDF

One way of mapping from topic maps to RDF is that of defining the topic map model using an RDF schema, and implementing something that can export topic maps in this RDF form. This, as already mentioned, is the approach taken by [Lacher01] and [Ogievitsky01]. As was also mentioned above, both of these use schemas that represent topic map data in a relatively awkward form, making the resulting data difficult to use.

In [Garshol01a] can be found an abstract model for topic maps defined using the infoset model approach first adopted by the W3C for the XML Information Set ([Cowan01]). This model is quite straightforward and an RDF Schema for it yields RDF models that are considerably easier in use than the ones already proposed. Below is shown an excerpt of the schema, to give an indication of how it looks.

RDF Schema for the infoset model

<!-- EXCERPT ONLY! -->

<!-- =========================================================================
========================================================================== -->

<rdfs:Class ID="TopicMapObject
  <rdfs:comment>The class of all objects that may be found in topic

<rdfs:Property ID="source-locators">
  <rdfs:domain resource="#TopicMapObject"/>
  <rdfs:range resource="#LocatorSet"/>

<!-- =========================================================================
========================================================================== -->

<rdfs:Class ID="TopicMap">
  <rdfs:comment>The class of topic maps.</rdfs:comment>
  <rdfs:subClassOf resource="#TopicMapObject"/>

<rdfs:Property ID="base-locator">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#Locator"/>

<rdfs:Property ID="topics">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#TopicSet"/>

<rdfs:Property ID="associations">
  <rdfs:domain resource="#TopicMap"/>
  <rdfs:range resource="#AssociationSet"/>

<!-- =========================================================================
========================================================================== -->

<rdfs:Class ID="TopicMap">
  <rdfs:comment>The class of topics.</rdfs:comment>
  <rdfs:subClassOf resource="#TopicMapObject"/>

<rdfs:Property ID="classes">
  <rdfs:domain resource="#Topic"/>
  <rdfs:range resource="#TopicSet"/>

<rdfs:Property ID="basenames">
  <rdfs:domain resource="#Topic"/>
  <rdfs:range resource="#BaseNameSet"/>

A mapping from topic maps to this schema would be quite straightforward to implement. The URIs of all RDF resources would be one of their [source locator] URIs, and those without source locators would be given auto-generated IDs. Below is shown what the example topic map might look like when exported to this RDF model.

The example topic map in RDF

<rdf:RDF xml:lang="en"

<TopicMap rdf:about="#id0"/>

<Topic rdf:about="#lmg">
    <BaseName rdf:about="#id1">
      <value>Lars Marius Garshol</value>

  <subjectIndicator rdf:resource=""/>

    <Occurrence rdf:about="#id2">
      <instanceOf rdf:resource="#homepage"/>
      <locator rdf:resource=""/>

    <Occurrence rdf:about="#id3">
      <instanceOf rdf:resource="#birthdate"/>

<Association rdf:about="#id4">
  <instanceOf rdf:resource="#employed-by"/>

    <AssociationRole rdf:about="#id5">
      <instanceOf rdf:resource="#employee"/>
      <player rdf:resource="#lmg"/>

    <AssociationRole rdf:about="#id6">
      <instanceOf rdf:resource="#employer"/>
      <player rdf:resource="#ontopia"/>


The example is rather long, and the syntax somewhat verbose, but the basic principles should be clear. This approach is simpler than the ones proposed in [Lacher01] and [Ogievitsky01], but the resulting RDF is still not of the kind one can would use directly in RDF applications.

The purpose of this section has mainly been to illustrate how topic maps could be modelled more straightforwardly based on the infoset approach than on [PMTM4]. The purpose achieved we move on.

3.4. Mapping from topic maps to RDF - approach 2

The other way of mapping from topic maps to RDF is to not implement topic maps as an RDF application, but instead to allow topic map data to be mapped to RDF using mapping declaration. This allows us to generate RDF data that is more convenient in use, and also allows us to produce RDF that can be used by RDF applications which know nothing whatever of topic maps.

Describing schema-based mapping from topic maps to RDF is somewhat harder than going from RDF to topic maps, mainly because in RDF the mapping depends on the property alone, while in topic maps things are much more complex. To be able to build mapping specifications we need a language that lets us express how to extract information from topic maps in a concise way. To put it another way: we need a query language. Given that ISO TMQL is not yet finished the obvious choice is tolog [Garshol01b]. (The version of tolog used here has been updated somewhat since the publication of the referenced paper.)

Again, the mapping specification will be an XML document, describing how to generate RDF statements from topic map data. Below is shown such a specification for the example topic map.

Mapping the example topic map to RDF

  <generator> <!-- 1 -->
    <query>employed-by($A : employee, $B : employer)</query>


  <generator> <!-- 2 -->
    <query>instance-of($A, person), has-name($A, $B)</query>


  <generator> <!-- 3 -->
    <query>instance-of($A, $B)</query>


  <generator> <!-- 4 -->
    <query>has-occurrence($A, birthdate, $B)</query>


  <generator> <!-- 5 -->
    <query>has-occurrence($A, homepage, $B)</query>


In this example the RDF model is produced by joining the results of all the generators into a single RDF model. A set of RDF statements is produced from each generator by first executing the query, and then for each match in the query resulting instantiating a statement by filling in the attribute values. Note that variables and constants can appear in any of the three statement template elements.

Variable references are replaced by one of the subject indicators of the topic held in the variable. It is possible to use a uri attribute on the statement template elements to override this, and use source locators (see [Garshol01a]), subject addresses, or generated object IDs instead. Base names and occurrences are represented either by their string values, or by the URI of the occurrence resource.

If we use the setup given above on the example topic map the result will be the RDF model shown below. The numbers before the RDF triples here refer to the number of the generator statement that caused them to be generated.

Topic map to RDF conversion result

1 : {,,}

2 : {,,
     "Lars Marius Garshol"}

3 : {,,

3 : {,,

4 : {,,

5 : {,,}

This solution is easy to implement (given a tolog query processor, of course), easy to use, and produces RDF data that can be used directly by RDF applications, and which may conform to any RDF schema. Its main weakness is that support for generating more complex RDF statements is missing, and this should be added in future versions.

4. Conclusions

This paper has compared the data models and features of RDF, topic maps, DAML, and OIL, and found that RDF, DAML, and OIL all share a data model and are a single family of specifications, while topic maps, on the other hand, are quite different. It is also found that some concepts are near-identical across the two data models, while others are very substantially different.

Based on the comparison of the models we have shown that a schema-independent mapping from RDF to topic maps is impossible, since topic maps are at a higher level of abstraction. We have proposed a solution for schema-based mappings from RDF to topic maps, and shown that it can produce good results, even if it does not support all the subtleties of the RDF data model. We have suggested how the solution could be extended to provide such support.

We have examined earlier attempts at schema-independent mappings from topic maps to RDF, and found them awkward in use. We have proposed our own solution, and found it to be slightly better, but not really sufficient. The conclusion to be drawn from this seems to be that schema-independent mappings can be useful, but that they are not the best solution in this case.

We have proposed a method for schema-based mappings from topic maps to RDF, and shown that this can produce good results, although it does not support all aspects of the RDF data model.

At a higher level, the conclusion in this paper is that moving data back and forth between topic maps and RDF is possible, but that schema-based mappings are necessary. The models are also found to have substantially different features, and to occupy different levels of abstraction. Conclusions about significance of these differences are left for the reader to draw.

It is hoped that this paper represents another step forward in the effort to create and document an understanding of the relationship between topic maps and RDF. Further steps are admitted to be necessary, and it is hoped that at least one paper to be presented at XML Europe 2002 will contain a paragraph concluding that "the analysis and proposals presented in [Garshol01], while useful, are incomplete" and go on to remedy that.


Thanks to Steve Pepper, for help on improving the prose presentation of the paper.

Thanks to Geir Ove Grønmo, for corrections of some omissions throughout the paper.

Thanks to David Allsopp, for answering some of my questions on RDF and DAML.

Thanks to Nikita Ogievetsky, Martin Lacher, and Graham Moore for discussing their solutions with me.

Thanks to Aaron Swartz and Eric Miller for a very constructive discussion, which was, sadly, too close to the deadline (through the author's own fault) to have much as impact on the paper as it should have had.


XML Information Set, John Cowan, W3C Proposed Recommendation. Available from
A Topic Map Data Model: An Infoset-based Proposal, Lars Marius Garshol. Available from
tolog: A topic map query language, Lars Marius Garshol, XML Europe 2001, Berlin. Available from
ISO/IEC 13250:2000 Topic Maps, International Organization for Standardization, Geneva. Available from
On the integration of Topic Map data and RDF data, Martin Lacher and Stefan Decker, presented at Extreme Markup Languages 2001, Montréal, Canada. Available from
Linear Topic Available from
RDF and TopicMaps: An Exercise in Convergence, Graham Moore, presented at XML Europe 2001 in Berlin. Available from
The Ontopia Omnigator, software from Ontopia AS in Oslo, Norway. Online demonstration at
XML Topic Maps through RDF glasses, Nikita Ogievetsky, presented at Extreme Markup Languages 2001, Montréal, Canada. Available from
Towards a general theory of scope, Steve Pepper and Geir Ove Grønmo, Extreme Markup Languages 2001, Montréal, Canada. Available from
PICS 1.1 Rating Services and Rating Systems -- and Their Machine Readable Descriptions, Jim Miller, Paul Resnick, and David Singer, W3C Recommendation, 31 October 1996. Available from
PMTM4's Processing Model for XTM 1.0, version 1.0.2. Available from
Resource Description Framework (RDF) Model and Syntax Specification, Ora Lassila and Ralph Swick, W3C Recommendation, 22 February 1999. Available from
Resource Description Framework (RDF) Schemas, Dan Brickly and R.V. Guha, W3C Candidate Recommendation, 3 March 2000. Available from
Draft Requirements for TMCL, Steve Pepper, ISO SC34 N 226, 8 June 2001. Available from
XML Topic Maps (XTM) 1.0, Steve Pepper and Graham Moore (editors), TopicMaps.Org. Available from