NetworkedPlanet

Topics

A Topic is the embodiment within a topic map of a subject of discussion. A topic is used to represent anything that you want to talk about in a topic map. There is no restriction on what can be represented as a topic. Commonly topics are used to represent items of interest in a domain e.g. people, documents, companies; but they can equally be used to represent concepts such as pensions, insurance, politics and can even be used to represent events such as the Battle of Trafalgar, the coronation of Henry VIII, John Smith's birthday and so on. The important thing to note is that what a topic represents is in no way constrained by the Topic Maps standard.

A Topic serves as a record or a focal point to which a number of different items can be attached. Most importantly for a computer, every topic has its own set of identifiers, these allows topic maps to be modularised and still maintain references between topics.

For human beings, topics also carry multiple names. Names can be specified in multiple languages (English, French, Spanish...) and in multiple forms (e.g. a name formatted for sorting; a soundex encoding of a name and so on). The standard even allows for non-textual representations of a name so graphical, and audio-visual representations of topic names can also be supported.

Topics can also be typed. A type specifies the category of "thing" that the topic belongs to. Seeing as a type of thing is itself something that you may want to say something about, in a topic map types are defined by other topics. So to say that "John Smith is a Person", I create a topic "John Smith" and a topic "Person" and then attach "Person" to "John Smith" as a type. The Topic Maps standard places no restrictions on the types that you define and to all intents and purposes a topic that is used as a type is no different to any other topic in the topic map.

Associations

Associations describe relationships between subjects by connecting together the topics in a topic map. Each association consists of a number of association roles each of which has a topic attached as a role player. The association role defines how the role player topic participates in an association.

Both the association itself and each of the association roles can be separately assigned a type. As with topics, this type is defined by another topic. So to model the fact that "John Smith" works for the company "ABC Corp.", we can create an association of type "WorksFor" and role types "Employer" and "Employee".

At first glance, this might seem like a lot of overhead - three more topics needed to create just a single relationship! But, of course the topics used to define the association and association role types are then used to define the type of every "WorksFor" association between a person and their employer.

Occurrences

Occurrences are the mechanism for providing more information about a topic than its name and relationship to other topics. The Topic Maps standard allows an occurrence to be specified either as a text string that is part of the topic map itself, or as a link to a resource maintained outside the topic map.

As with topics and associations, occurrences can be typed, and once again that type is specified by a topic. When an occurrence links to an external resource, the typing of an occurrence should be used to convey some information about the kind of resource that is to be found and its relationship to the topic. When the occurrence is an internal text string, only the nature of the relationship between the occurrence data and the topic is important.

As shown in the diagram below, occurrences cross a boundary between information maintained solely inside the topic map itself and external resources in a separately managed "resource space".

Names

For human beings, names are an important way in which we identify things, but names have restrictions. The most common problem is that the same name can mean multiple things - sometimes this is due to incomplete naming (e.g. "Do you mean George Bush Sr. or George W. Bush ?") but more often names that are otherwise the same can be distinguished by context (e.g. "Do you mean Paris, France or Paris, Texas ?"). The topic map paradigm has a context mechanism built in which allows not only names, but also occurrences and the roles played by topics in associations to be specified with an associated context. More on context later.

Identity By Address

For resources which are found on computer systems, the location of the resource can be used as an identifier. This form of identity is known as a subject address. When two topics have the same subject address, they are considered to be about the same thing.

Of course, using the address of a resource like this is not suitable for all forms of electronic document. For example some web addresses refer to pages that are generated automatically from real-time data and some resources can have addresses that are very short-lived. However there is also still a large "static" web that can make use of this form of identity, and many other systems such as content management systems provide some form of persistent address that stays with a piece of content for its entire lifetime and it is a simple matter to map such persistent addresses to a subject address.

Identity By Subject Description

While Identity By Address is suitable for electronic resources with some form of persistent address, it is not possible to assign such addresses to real-world things, nor is it possible to define and address for an abstract concept. However, it is possible to describe such things in a document and then make that document available at a persistent address. In the Topic Maps paradigm such a document is called a subject indicator because its purpose is to provide an indication of the nature of a topic to a human reader of the document. The address of the subject indicator document can then be applied to a topic as a subject identifier. It is important to note that it is always a human being that "understands" the content of a subject indicator, however a computer can make use of the fact that if two topics have the same subject identifier, they are both referring to the same resource that describes their nature and so they must both be about the same thing.

Identity By Declaration

Another common form of identity on the Web is a URL that does not point to any resource at all, but is simply defined as an identifier in its own right. XML developers will be most familiar with this form of identifier in use for XML Namespaces.

In topic maps it is equally possible to make use of this form of identifier simply by assigning a topic a subject identifier that does not point to any resource at all. This approach can be useful when the goal is to create a set of identifiers for concepts managed as some form of code list as you can simply define a mapping from a code to a URI suitable for use as a subject identifier without having to create a corresponding web resource.

From a human user's perspective, this form of identifier is less useful than Identity By Description as there is no authoritative resource that describes the subject. However, for a computer that only cares about comparing addresses, this approach works perfectly well and can often be a practical compromise solution for very large sets of subjects.

Merging

So far we have seen the different forms of identity that allow a topic map processor to find the cases where two topics represent the same thing. In a fully processed topic map, however, there must only ever be one topic for each represented thing. The process of merging defines how multiple topics are combined into a single topic to achieve this goal.

The merging operation is almost entirely intuitive. When two topics are merged, the result is a single topic that has the combined set of names, identifiers and occurrences of the two original topics and where either of the original topics are referenced anywhere else in the topic map, that reference is replace with a reference to the merged topic. Finally, the two merged topics are removed from the topic map.

The diagrams below show and example of the merging operation. The identifiers used to determine that the two topics should be merged have been ommitted for clarity.