For a birds-eye overview of what a topic map is, read The TAO of Topic Maps or the topic maps topic on QueSucede.com. Topics, my application is loosely based on the original Topic Map Specification.
The Topics application is broadly separated into two major components: the (visual) user interface and the underlying topic map engine. The engine, exposes a (fairly simple) interface to the outside world and in this case, the actual Adobe AIR application.
The engine itself, is broken out into, on one hand, the relevant topic map models (that is, topics, occurrences, associations and meta data) and on the other hand, the actual topic store. So, to be more specific, the application talks to the topic store; and it is the topic store that serializes and de-serializes the topic map object graphs to and from the backing store (that is, the database).
Now, when thinking about topic maps, I normally lump topics and their occurrences together because topics by themselves are not really that interesting. That is, in practical terms, a topic is basically no more than a (unique) identifier and a name. It is what we attach to a topic that is of interest. For example, we will attach some wiki-text to a topic, we’ll attach images and PDF-files to a topic or maybe even an Excel spreadsheet. Hence, it is the occurrences (that is, resources) associated to a topic that really make a topic be a topic from the point of view of a user of the application. Again, I would like to reiterate, from the users’ point-of-view, a topic is no more than an (addressable) identifier and a label (name) to which we peg occurrences.
Obviously, a bunch of individual topics (that is, orphaned topics) is of no real use from both the point-of-view of discoverability of information and navigational purposes. That is where associations come in to play and it is associations that put the map bit into the whole topic map concept. So, associations are what we use to establish a (formal) relationship between topics. For example, in a web-based topic map system, associations are exemplified by hyper-links, effectively linking two or more topics together.
Now, an association, in theory, is an easy concept, that is, it establishes a relationship between two or more topics. However, in practice, associations are the most misunderstood part of the topic maps experience. As previously mentioned, topics are no more than an entity to which you attach resources… hence people have no problem understanding that part of the topic maps concept. Not understanding associations stems from associations themselves, having several parts. First of all, an association has a type, that is, we can define different types of associations.
Just like in the real world, I have a different relationship with my mother than the one I have with my, eh, bank-manager. That is, if you were modelling yourself and the entities that surround you, you would create a topic for each of the entities (including yourself) and then establish the appropriate relationships between those entities. If we take the previous example a bit further, you yourself would be a topic, your mother would be a topic, your bank-manager would be a topic, your job would be a topic, each of your hobbies would be a topic, your spouse and children would be topics, etcetera, etcetera… so now you can see, that it makes sense to be able to create different types of relationships (that is, associations) between topics.
Obviously (or maybe it’s not so obvious), we need a bit more information within an association for it to be of any practical use. That additional bit of information is roles. For you to understand roles, we have to step back a bit and talk about members. At this moment, it makes sense to look at the graphic below for clarification.
Associations contain a collection of members. Two members, by default, but in theory, an association can (and will in practice) have several members. Members, contain a collection of topic references; one topic reference by default, but again, just like associations having several members, it possible for any given member to have several topic references. The image above, should clarify this.
So, let’s get back to the explanation of associations. Remember I said that an association has a type (to denote what kind of association it is), it also has a collection of members and each individual member plays a role. For example, my relationship with my mother is of type family, she belongs to the member with the role of mother and I belong to the member with the role of child. Obviously, taking the example a bit further, my brother will belong to the same member with the role of child as I do.
In (Ruby) code, the above would probably look something like this:
@association = {
:type => ‘family’,
:members => [
{
:role => ‘mother’,
:topic_references => [‘my_mother’]
},
{
:role => ‘child’,
:topic_references => [‘me’, ‘my_brother’]
}
]
}
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.
This in itself, that is, associations, is a very powerful concept, but topic maps can take this one step further by making types and roles, topics in themselves. Furthermore, even associations are topics. Specifically, the topic map engine that I have developed for my application (called CrystalMind), has this capability. This is possible, because from an object-oriented point-of-view, the Association class inherits from the Topic class (see diagram below).
To summarize, 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 (for example, roles, types and even associations themselves) being an actual topic (self-describing data structures comes to mind).
