Topic maps: an enabling technology for learning experiences

Monday 4th of March 2013 07:06:07 PM

  Toggle Advanced Options

The topic map concept is one of the fundamental underpinnings of the web site. There are several reasons for this but probably the three most important ones being extensibility, flexibility and the ability for rapid development/prototyping of web site concepts.

We’ll be looking at the above mentioned points as we go along. However, let’s take a quick look at topic maps before we proceed.

I urge you to check out the official topic map specification. Between you and me though, the spec is rather heavy goings (as specs tend to be), so you might also want to check out the following articles: The TAO of Topic Maps, and MSDN's An Introduction to Topic Maps.

Right, let’s start: the fundamental elements of topic maps are topics (obviously), associations (the concrete relationships between topics) and occurrences (those resources actually attached to the individual topics). We’ll start off by taking a (very brief) look at each of these elements individually.


The most significant attributes of a topic are its unique identifier and its name. It is important to understand that a topic in itself does not contain any information. Essentially, it just acts as a peg to which we can attach resources and refer to in associations. I understand that that might sound a bit cryptic; however, the image below will hopefully clarify this point a bit more.

Topic map


Occurrences are those resources that we have attached to a topic. For web sites or web applications that might be JPEG or PNG image files, PDFs, or Word documents. If you think about it, that it what topic maps are all about, that is to say, navigating from one topic to the next, viewing (or listening to) those resources that are relevant to the current topic.


When discussing occurrences, I mentioned ‘navigating from topic to topic’ which brings us conveniently to associations. The notion of topics (and their occurrences) is the heart of the topic map concept; however without associations to actually link those topics, a topic map is in essence, useless. We must be able to ‘jump’ from one topic to its related topics, that is, navigate around the topic map. Again, take a look at the above image to clarify this.

Associations are probably the most puzzling element of topic maps. The fundamental concept of associations is simple: linking two (or more) topics to one another. However, in practice, associations are the most misunderstood element of topics maps so for that reason we’ll take a closer look at them. First of all, each association is of a given type. For example, in a typical topic map-based Content Management System (CMS) it is not unusual to find associations of type ‘Global’, ‘Project’, ‘Navigation’, and ‘Documentation’. This allows us to treat associations differently according to their type. For example, in a corporate environment, only those associations of type ‘Navigation’ will be displayed on the public-facing web site. All other associations are not displayed, hence making those topics that are linked to by associations of types other than ‘Navigation’ to not be navigable. Confusing, I know, but I hope that in due time, this concept will become more obvious.

What’s more, each association consists of at least two (and probably more) members and each of these members plays a specific role within the association. Let’s take a closer look at the above statement. Again, I’ll try to explain this with an example. Imagine the following two topics: Joe (an employee) and Project X (a top-secret project that Joe is working on); a hypothetical association between these two topics could be the following:

  • Type: ‘Work’
  • Member 1: Joe with role of ‘Employee’
  • Member 2: Project X with role of ‘Project’

Now, we could extend the above example to include another project (Project Y, I know, this company isn’t really imaginative with regards to their naming). That is, Joe is currently working on two projects:

  • Type: ‘Work’
  • Member 1: Joe with role of ‘Employee’
  • Member 2: Project X and Project Y, both with role of ‘Project’

In Ruby the above would probably look something like the following:

@association = {
    :type => ‘work’,
    :members => [
            :role => ‘employee’,
            :topics => [‘joe’]
            :role => ‘project’,
            :topics => [‘project_x’, ‘project_y’]

Taking a closer look at the above you can see that ‘members’ is a list of dictionaries and each member has a list of topic identifiers. This allows for extremely flexible associations, that is, each association can have several members (in fact, each association could have many more members, in practice, however, an association will have between two to four members). Furthermore, each member can point to one or more topics (again in practice, this would be anywhere between one and five topics).

So you can see that associations connect a set of topics together in a meaningful manner enabling you, the user of the topic map, to build a myriad of data models. Furthermore, associations allow us to actually ‘navigate’ a topic map (by means of links in a web-based topic map system).

Anyway, for the moment, I’ll stop here. There is still a lot to cover, for example, orphan topics, scope and finally, the advantages of having everything in your topic map (e.g., roles, types and even associations themselves) being an actual topic (self-describing data structures comes to mind).


Please take note@09-01-03 21:37:41 by Brett Kromkamp

The above text is copied verbatim from my old (now, non-existent) blog.