Introduction to the Pattern Notation

This paper uses a modified form of UML notation [UML] for diagramming the topic map patterns.

Any type is shown as a box divided into three with the name of the class written in the top box:

Figure 1 - A Type

An occurrence or base name is shown in a similar notation, but the fact that the box represents an occurrence or base name is shown by the use of the stereotype name enclosed in double angle-brackets. The stereotype name is either Occurrence or BaseName. The notation currently does not support the diagramming of variant names or of scope. The following diagram shows an untyped occurrence:

Figure 2 - The Untyped Occurrence Meta-class

Typed occurrences are represented by a class with both the << Occurrence >> stereotype and a class name. The following shows an occurrence of the type "Home Page":

Figure 3 - An Occurrence Type

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 black 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 black 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"

Figure 4 - A Topic With A Typed Occurrence

Association types are also expressed using this box notation, but you must also show the roles that may be played in the association and the classes of topic which may be role players. This is all achieved using UML's association class notation. The association class is represented by a three-segment box. The classes of topic which may play roles in the association are joined together with a solid line and at each joining point, the name of the role played by that class and the number of role players expected are written on the line at its connection point to the class. Finally, a dotted line joins the association class to the line connecting the role playing classes. The following diagram shows a "Works For" association between a topic of type "Person", playing the role "Employee" and a topic of type "Company" playing the role "Employer". The association is restricted to being a binary association as we require one and only one of each role player.

Figure 5 - A Typed Binary Association

If an association has more than two roles, a slightly different notation is used. Rather than a single line joining the role-playing classes, an open diamond shape forms the nexus of the association. For example the following diagram shows a three-way relationship "Plays For" between a "Player" (playing the role of "Goalkeeper"), one or more "Team"s (playing the role of "Team") and a "Year" (playing the role of "Season").

Figure 6 - A Typed N-Ary Association

Subclass-superclass relationships are shown using standard UML notation, a line with an open arrowhead pointing from the subclass to the superclass. The following example shows that the class "Car" is a subclass of "Motorised Vehicle"

Figure 7 - Subclassing

Finally, because in a topic map a topic can be both an instance of a class and also define a class, you may occasionally see two classes connected by a line with a solid black arrowhead. The arrow points from the instance to the class. So the following diagram states that "Elephant" is an instance of "Species".

Figure 8 - An Instance
Up: Topic Map Patterns For Information Architecture
Previous: Introduction Next: Thesaurii