Describing a Topic Map Design Pattern in UML

In order to clearly explain a particular design pattern, it is often useful to have some diagramming technique available. Diagrams can often concisely and clearly express that which becomes verbose and convoluted in prose. Rather than create a new palette of diagramming shapes for expressing topic map design patterns, it is proposed that the UML class diagram be used for diagramming.

The UML class diagram is almost exactly right for describing topic map patterns. Classes can be used to represent classes in the topic map, with stereotypes used to differentiate between topic, occurrence and association classes. The UML association class notation allows the expression of typed or untyped topic map associations with typed or untyped roles, and even allows the expression of cardinality and role membership constraints.

As there is currently no standard constraint language for topic maps, these UML diagrams provide a formal method of documentation of some, if not all, constraints that a design pattern imposes upon the topic map in which it is used. It is anticipated that it should be straight-forward to convert the constraints described in these diagrams into a constraint language, although this has yet to be proven.

A Simple UML-based Notation For Topic Maps

The UML notation for topic map diagrams developed here is based entirely upon UML notation for static structures.

Topics

Topics are represented by the 3-segment box notation used to represent a class. The name in the top segment of the box gives the name of the topic type. Unlike a UML class diagram, in the topic map diagram there is not necessarily a direct correlation between the name given to the topic class and the name as it is represented in a topic map. When describing a pattern that uses PSIs for identifying classes of topic, the documentation should make clear the relationship between the class names shown in the diagram and the subject identifiers specified by the PSIs.

The following diagram shows an example of a topic as represented in the topic map class notation.

Occurrences And BaseNames

Occurrences and BaseNames are represented with the same class notation as topics. As with the Topic notation, the name of the class relates directly to the topic used to define the class of occurrences or names that the instance belongs to. To distinguish the three different uses of the class notation, we use a class stereotype.

To show that a particular class of topic may or should have occurrences or names of a particular type, use the UML aggregation notation.

The line with a open diamond at the end is drawn from the topic class to the occurrence or name class. We can use the multiplicity label next to the diamond to show how many of these occurrences or names a topic of the class should have. The following diagram shows that a topic of type "Person" may have zero or more occurrences of type "Email Address".

Associations And Association Roles

The class notation can also be used to represent classes of association by additionally making use of the UML notation for association classes. The association itself is represented as a solid line joining the role-playing classes. The roles played are annotated against the line along with any cardinality constraints imposed by the association class. The association class is represented by a three segment box connected to the association by a dotted line.

The following diagram shows a "Works For" association type which is expressed as a binary association between and instance of the "Person" class playing the role of "Employee" and an instance of the "Company" class playing the role of "Employer". The association is constrained to require exactly one instance of each role player in such an association.

N-ary associations are also supported by UML class diagram notation. In this case, rather than having a single solid line, the association is represented by an open diamond shape with the role-playing classes connected to the diamond by solid lines. The class of the association is represented with a dotted line from the diamond to the association class.

For example, the following diagram shows a 3-way association describing the "Plays For" association type which consists of roles "Goalkeeper", "Team", and "Season" played by instances of the class "Person", "Team" and "Year" respectively.

Subclass-Superclass Associations

Although in a topic map, the subclass-superclass relationship is defined through the use of associations, it makes sense in the diagrammatic notation to make use of the standard UML notation as a shortcut. So the following diagram shows that the topic class "Car" is a subclass of the topic class "Motor Vehicle".

Instances In Topic Map Class Diagrams

Because in a topic map it is possible for a class to also be an instance, it may sometimes be necessary to create a UML diagram which would not be possible to translate directly into most OO programming languages. For example the following diagram shows that the topic class "Elephant" is an instance of the topic class "Species" and that "Nelly" is an instance of "Elephant".

Scope

The topic map class diagram notation must support the specification of scope applied to topic names, occurrences and associations. This requirement is met by defining a stereotype named "scope" which can be applied to a UML association (represented in class diagrams as an open diamond shape) and a stereotype "theme" which can be applied to a UML association link (represented in class diagrams as the line from the association to one of the associated classes).

The stereotyped Association can then be applied to the aggregation links used between a Topic class and a BaseName or Occurrence class; and the AssociationEnds with the stereotype "theme" can be used to apply the themes. The diagram below documents that a "Film" topic has zero or more "Rating" occurrences, each of which may be scoped by a single theme which is itself an instance of the "Reviewer" class.

For a scoped association, there is a problem because it does not make sense from a UML perspective to create an association with an association at one of its ends. To work around this, the topic map diagramming notation just adds the extra theme-sterotyped association ends directly to the association being scoped and does away with the scope stereotype on the association. The diagram below documents that a "Film" topic plays the role "RatedThing" in a "HasRating" association with a "Rating" topic playing the role "RatingGiven" and that this association is scoped by a single topic of type "Reviewer".

Shortcomings of the Notation

The notation shown here does not currently support the representation of variant names. This problem has not been addressed as up to now it has not been needed in the creation of pattern documentation. However, it would seem reasonable to make use of an additional stereotype in order to express the relationship between a base name, a variant name and the variant parameters.

Up: Topic Map Design Patterns For Information Architecture
Previous: What Makes A Topic Map Design Pattern	Next: Design Pattern Examples