Skip to main content

Abstract

Software design patterns give programmers a high level language for discussing the design of software applications. For topic maps to achieve widespread adoption and improved interoperability, a set of topic map design patterns are needed to codify existing practices and make them available to a wider audience. Combining structured descriptions of design patterns with Published Subject Identifiers would enable not only the reuse of design approaches but also encourage the use of common sets of PSIs. This paper presents the arguments for developing and publishing topic map design patterns and a proposed notation for diagramming design patterns based on UML. Finally, by way of examples, the paper presents some design patterns for representation of traditional classification schemes such as thesauri, hierarchical and faceted classification.

Introduction

Software design patterns, first codified by Gamma et. al. have become an indispensable tool for the jobbing programmer. In software development, design patterns are structured descriptions of the common ways in which programmers overcome the kinds of problems which occur again and again in their work. By formalizing such patterns, programmers are able to talk to each other about them, to compare different patterns for a given solution, and to develop a reusable "tool-box" of both software components and approaches to building software components. For topic map practitioners, there is an interesting parallel. Often in a topic map application there will be more than one way of achieving a goal - the structure of topic maps is sufficiently flexible that two topic map designers faced with a problem may generate two (or more!) different solutions. In many cases there is no single correct solution, but instead a set of trade-offs to choose between. Developing formal patterns for topic map design would benefit designers in the same way as software engineers benefit from software design patterns:

  • Design patterns can be compared for their strengths and weaknesses

  • Design patterns can be reused in different applications

  • Less experienced designers can benefit from the insights provided by patterns used by other designers.

  • Tools can be built around patterns, making it easier to adopt the patterns and allowing application designers to concentrate on the higher-level aspects of the application.

PSIs and Patterns

The topic map community has already recognised that when vocabularies are created and identifiers used for the elements of those vocabularies, then documentation is required. The Published Subject Indicators recommendation from OASIS places certain constraints on this documentation:

  • The documentation must be retrievable from the URI used as the identifier for the published subject.

  • The documentation must be in human-readable form.

  • The documentation should provide human-readable and machine-processable metadata about itself.

However, the PSI recommendation is, perhaps rightly, silent about the content of such documentation and how it should be structured. The design pattern approach presented here goes beyond the PSI recommendation by recommending a pattern-based approach to subject identifier documentation for those identifiers which are intended as the components of a solution to one or more design problems.

The design pattern approach is intended to be a vehicle for communication between information professionals responsible for creating and maintaining topic map-based systems, rather than as a means for general communication of the meaning of PSIs. Although both forms are needed, there is no restriction placed on PSI documentation that prevents both pattern-based documentation and more user-oriented documentation from co-existing. It is also hoped that by the use of patterns to describe common solutions to topic map design problems that the quality and consistency of such designs can be improved and that tool-sets can be built to support the patterns, reducing the time and cost of implementation.

It is also worth noting at this point that having PSIs defined is not necessarily a pre-requisite for the documentation of a design pattern. The most general design patterns will be ones which are applied to the topic map meta model, rather than ones which apply to particular topic map applications, and so will not require the definition of any PSIs for their implementation. An example of such a pattern is the Hierarchical Naming Pattern given later in this paper.

Even when a pattern requires new subjects to be identified, there is no requirement that PSIs be used for establishing subject identity, although if the pattern is to be made public, then the subjects used must be published in some form and following the PSI recommendation makes sense.

What Makes A Topic Map Design Pattern

Gamma et. al. define a Software Design Pattern as consisting of four essential elements:

  • The pattern name - a handle used to describe a design pattern. Naming enables a design pattern to be talked about and expands the vocabulary used by designers.

  • A description of the problem that the pattern addresses. This gives the reader of the design pattern an idea about the context within which the pattern may be applied.

  • A description of the solution, which defines the elements of the design and their relationships.

  • A description of the consequences of applying a pattern. This might include an acknowledgment of the trade-offs involved in selecting a particular design pattern.

For a topic map design pattern, it is proposed that these four elements be present and used in exactly the same way as for software design patterns. In addition, as already discussed above, the creator of the design pattern should consider defining a set of Published Subject Identifiers for the implementation of the pattern. The process of defining PSIs for the implementation of the pattern can be seen as analogous to the naming of the classes and relations defined in a software design pattern, but is actually more prescriptive. The names used in a software design pattern are simply handles used for the purposes of explanation of the pattern whereas in a topic map design pattern, the Published Subject Identifiers are the proposed identifiers to be used in the implementation of the pattern. This more prescriptive approach also ensures that implementations across different topic maps are compatible, enabling more reusable software for processing the patterns to be created. Finally all topic map design patterns should include at least one example as a complete example in at least one topic map syntax is a useful tool for conveying the essence of the pattern to an experienced topic map author.

Not all vocabularies lend themselves to description in terms of a collection of design patterns. Vocabularies which simply enumerate the individuals of a class will not be suitable for such treatment, but with such vocabularies there is little sense of any design - they are typically a form of controlled vocabulary or domain ontology from which the required entries are simply selected. The kinds of vocabulary to which a pattern-based description can be most usefully applied are those which define the vocabulary for use in a particular information design approach. For example, the PSIs which define the individual terms in a particular thesaurus are not a suitable candidate for pattern-based description, but the PSIs which define the class of all thesaurus terms, and the class of broader-than/narrower-than associations are good candidates for documentation as a design pattern.

Classes Of Topic Map Design Pattern

The concept of a design pattern for topic map applications can be applied at two different levels of topic map design. At the first level, patterns can be created which are descriptions of a solution to a generalised problem. This level is very similar to the application of patterns in software engineering - the description of solutions to design problems. An example of such a design pattern is the approach used by most topic map designers to express the different labels to be applied to an association type. Many topic map designers create multiple names for a topic which defines an association class - usually one name per role in the association. The association role specifier is then used as the theme in the scope of the name most appropriate to use when the association is displayed from the context of a player of that role. This is a general design pattern in the sense that it can be expressed soley in terms of topic map constructs and without any reference to a specific vocabulary.

The second level is the description of the application of a vocabulary to represent some domain model in a topic map. This level is closer to that of the Published Subject Indicator where the pattern explains the usage of a vocabulary in order to ensure that the vocabulary is used consistently.

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.

/images/papers/05-03-05-fig01.png

Figure 1 - A Typed Topic

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.

/images/papers/05-03-05-fig02.png

Figure 2 - An Untyped Occurrence and Base Name

/images/papers/05-03-05-fig03.png

Figure 3 - A Typed Occurrence

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

/images/papers/05-03-05-fig04.png

Figure 4 - A Topic With Occurrence

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.

/images/papers/05-03-05-fig05.png

Figure 5 - A Typed Binary 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.

/images/papers/05-03-05-fig06.png

Figure 6 - A Typed 3-ary Association

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

/images/papers/05-03-05-fig07.png

Figure 7 - Subclass Relationship

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

/images/papers/05-03-05-fig15.png

Figure 8 - One Topic Class As An Instance Of Another

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.

/images/papers/05-03-05-fig08.png

Figure 9 - A Scoped Occurrence

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

/images/papers/05-03-05-fig09.png

Figure 10 - A Scoped Association

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.

Design Pattern Examples

This section presents a selection of design patterns with a focus on representing approaches to information organisation which are common in information architecture and library sciences.

Hierarchical Naming

Problem Statement

The topic map consists of a hierarchical ordering of topics. The topics in the hierarchy may all be of the same topic type or of different types. The problem is to provide topic names that can be easily processed by an application to provide either full context or no context depending on the use. For example, when listing all topics which are subordinate to a parent, just the topic name is needed as the name of the parent should provide sufficient context. However, when displaying a list of topics returned by a search, the full path to the topic through the hierarhcy should be displayed to give the user sufficient contextual information.

A further problem to be addressed is that the Topic Naming Constraint, which requires that two topics with the same name in the same scope be merged, forces nodes at different positions in the hierarchy to be merged if they have the same name. For example in a tree consisting of branches Top / Arts / People and Top / Sciences / People, we do not want the two nodes with the name "People" to be merged.

Solution

In the Hierarchical Naming pattern, each topic which is not at the root of the hierarchy is assigned two names. A "short name" which is the topic's display name determined according to the subject that the topic represents; and a "long name" which is a concatenation of the short names of all topics on the hierarchical path from the root to the topic, with a suitable separator character.

Examples of the Hierarchical Naming pattern can be seen in the Open Directory and other web directories based on DMoz data. Each category in the Open Directory has a short name which is the standard display name for the category. A long name for the category is composed of the names of all categories starting from Top that form the route from Top to the category.

In implementation, each topic which is part of the hierarchy has two base names. The long name is a topic base name in the unconstrained scope. The short name is a topic base name whose scope contains the topic that represents the parent category as a theme.

/images/papers/05-03-05-fig10.png

Figure 11 - Hierarchical Naming Pattern

Example

The following example shows two topics representing a pair of hierarchically ordered categories named using the Hierarchical Naming pattern.

<?xml version="1.0" encoding="utf-8"?>
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
      xmlns:xlink="http://www.w3.org/1999/xlink">

  <!-- Category Ontology -->
  <topic id="category">
    <baseName>
      <baseNameString>Category</baseNameString>
    </baseName>
  </topic>

  <topic id="subcategory-supercategory">
    <baseName>
      <baseNameString>Subcategory/Supercategory</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#supercategory"/></scope>
      <baseNameString>Has Subcategory</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#subcategory"/></scope>
      <baseNameString>Subcategory Of</baseNameString>
    </baseName>
  </topic>

  <topic id="subcategory">
    <baseName>
      <baseNameString>Subcategory</baseNameString>
    </baseName>
  </topic>

  <topic id="supercategory">
    <baseName>
      <baseNameString>Supercategory</baseNameString>
    </baseName>
  </topic>

  <!-- Category Instances -->
  <topic id="top">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName><baseNameString>Top</baseNameString></baseName>
  </topic>

  <topic id="arts">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName><baseNameString>Top / Arts</baseNameString></baseName>
    <baseName>
      <scope><topicRef xlink:href="#top"/></scope>
      <baseNameString>Arts</baseNameString></baseName>
  </topic>

  <topic id="arts.people">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Arts / People</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#arts"/></scope>
      <baseNameString>People</baseNameString>
    </baseName>
  </topic>

  <topic id="sciences">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Sciences</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#top"/></scope>
      <baseNameString>Sciences</baseNameString>
    </baseName>
  </topic>

  <topic id="sciences.people">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Sciences / People</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#sciences"/></scope>
      <baseNameString>People</baseNameString>
    </baseName>
  </topic>

  <!-- Category associations -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#top"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#arts"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#top"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#sciences"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#arts"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#arts.people"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#sciences"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#sciences.people"/>
    </member>
  </association>

</topicMap>

Analysis

The Hierarchical Naming pattern ensures that topics representing distinct categories in a hierarchy are not merged by the Topic Naming Constraint as long as no topic in the hierarchy has two child topics with the same short name. The pattern ensures that topics can be displayed with either a complete name giving the topic's context in the hierarchy or with a short name when the context is already established (e.g from the context of the parent category).

Hierarchical Classification Pattern

Problem Statement

Many classification systems consist of one or more hierarchies of subjects. A number of different hierarchical relationships are possible part-whole, broader-narrower and so on. Although the relationships may be different, the hierarchical semantics remain the same. An application dealing with multiple hierarchical relationship types requires a way to identify all of these types.

Pattern Description

The pattern given here for modelling a hierarchical classification system uses one topic to represent each class in the system. The hierarchy is then modelled by creating associations between subordinate and superordinate classes. However, it is recognised that there are a wide variety of different hierarchical relationships. For this reason, the type of the associations between the subordinate and superordinate classes are not defined by this pattern. Instead, this pattern defines the type of all such types, and the type of all role types for both subordinate and superordinate role players.

The other issue is how to relate the items classified by this scheme (the instances) to the topics which represent the classes. If an instance is represented by a topic, then an association should be made between the topic representing the class and the topic representing the instance. For this purpose, topic types are introduced to represent the classification of an instance ("Classified As") and the roles played in this relationship ("Classification" and "Instance"). If the instance is not represented as a topic, then an occurrence should be used, in which case the "Instance" type can be used as an occurrence type rather than as an association role type.

/images/papers/05-03-05-fig13.png

Figure 12 - The Hierarhical Classification Pattern

Analysis

This pattern creates a means of flagging an association type as being a hierarchical relationship, and of indicating which role is the superordinate and which the subordinate role. This may be done externally to the topic map which defines the association and role types, enabling a pre-existing topic map to be integrated without the need to edit it.

The classification semantics of the "Classified As", "Classification" and "Instance" types can be ommitted from this pattern where classification is not the purpose of the hierarhcy. For this reason, those subjects are defined in a separate PSI set (with a different base URI) from the hierarchy-defining subjects.

PSIs For the Hierarchical Classification Pattern

The following Published Subject Identifiers are used by the Hierarchical Classification Pattern:

Diagram Class Name

Subject Identifier

Hierarchical Relationship Type

http://www.techquila.com/psi/hierarchy/#hierarchical-relation-type

Subordinate Role Type

http://www.techquila.com/psi/hierarchy/#subordinate-role-type

Superordinate Role Type

http://www.techquila.com/psi/hierarchy/#superordinate-role-type

Classified As

http://www.techquila.com/psi/classification/#classified-as

Classification

http://www.techquila.com/psi/classification/#classification

Instance

http://www.techquila.com/psi/classification/#instance

Hierarchical Relation Type

http://www.techquila.com/psi/hierarchy/#hierarchical-relation-type

A type of association type. Associations which are typed by a topic which is an instance of this type represent a parent-child relationship between two or more topics.

Superordinate Role Type

http://www.techquila.com/psi/hierarchy/#superordinate-role-type

A type of association role type. The player(s) of a role which is typed by an instance of this type in an association of the type Hierarchical Relation Type is the upper element in the hierarchy.

Subordinate Role Type

http://www.techquila.com/psi/hierarchy/#subordinate-role-type

An association role type. The player(s) of a role which is typed by an instance of this type in an association of the type Hierarchical Relation Type is the subordinate element in the hierarchy.

Classified As

http://www.techquila.com/psi/classification/#classified-as

An association type asserting the relationship between a topic representing a class in a classification system (playing the role Classification) and one or more topics representing instances of that class (playing the role Instance).

Classification

http://www.techquila.com/psi/classification/#classification

The role played by a topic representing a class in a classification scheme.

Instance

http://www.techquila.com/psi/classification/#instance

The role played by a topic representing a subject which is classified under a classification scheme.

Example

The following example builds on the hierarchical naming example to show how an instance (in this case Leonardo da Vinci) is classified in several locations in the hierarchy. Note that the subcategory-supercateory relationship is integrated with the pattern simply by adding types to the topics defining the association and its roles.

<?xml version="1.0" encoding="utf-8"?>
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
      xmlns:xlink="http://www.w3.org/1999/xlink">

  <!-- Import the topics defining the hierarchical    -->
  <!-- classification ontology from the URI specified -->
  <!-- by the PSI set                                 -->
  <mergeMap xlink:href="http://www.techquila.com/psi/hierarchy/hierarchy.xtm"/>

  <!-- ================= -->
  <!-- Category Ontology -->
  <!-- ================= -->

  <topic id="category">
    <baseName>
      <baseNameString>Category</baseNameString>
    </baseName>
  </topic>

  <topic id="subcategory-supercategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#hierarchical-relation-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Subcategory/Supercategory</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#supercategory"/></scope>
      <baseNameString>Has Subcategory</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#subcategory"/></scope>
      <baseNameString>Subcategory Of</baseNameString>
    </baseName>
  </topic>

  <topic id="subcategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#subordinate-role-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Subcategory</baseNameString>
    </baseName>
  </topic>

  <topic id="supercategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#superordinate-role-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Supercategory</baseNameString>
    </baseName>
  </topic>

  <!-- ======================= -->
  <!-- Classification Ontology -->
  <!-- ======================= -->

  <topic id="classified-as">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classified-as"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Classified Under</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#classification"/></scope>
      <baseNameString>Instances of this class</baseNameString>
    </baseName>
  </topic>

  <topic id="classification">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classification"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Classification</baseNameString>
    </baseName>
  </topic>

  <topic id="instance">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#instance"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Instance</baseNameString>
    </baseName>
  </topic>

  <!-- ================== -->
  <!-- Category Instances -->
  <!-- ================== -->
  <topic id="top">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName><baseNameString>Top</baseNameString></baseName>
  </topic>

  <topic id="arts">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName><baseNameString>Top / Arts</baseNameString></baseName>
    <baseName>
      <scope><topicRef xlink:href="#top"/></scope>
      <baseNameString>Arts</baseNameString></baseName>
  </topic>

  <topic id="arts.people">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Arts / People</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#arts"/></scope>
      <baseNameString>People</baseNameString>
    </baseName>
  </topic>

  <topic id="sciences">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Sciences</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#top"/></scope>
      <baseNameString>Sciences</baseNameString>
    </baseName>
  </topic>

  <topic id="sciences.people">
    <instanceOf><topicRef xlink:href="#category"/></instanceOf>
    <baseName>
      <baseNameString>Top / Sciences / People</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#sciences"/></scope>
      <baseNameString>People</baseNameString>
    </baseName>
  </topic>

  <!-- ===================== -->
  <!-- Category associations -->
  <!-- ===================== -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#top"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#arts"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#top"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#sciences"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#arts"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#arts.people"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#sciences"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#sciences.people"/>
    </member>
  </association>

  <!-- ================== -->
  <!-- Category instances -->
  <!-- ================== -->
  <topic id="leonardo">
    <baseName>
      <baseNameString>Leonardo da Vinci</baseNameString>
    </baseName>
  </topic>

  <!-- =========================== -->
  <!-- Categorisation associations -->
  <!-- =========================== -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classified-as"/>
    </instanceOf>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classification"/>
      </roleSpec>
      <topicRef xlink:href="#arts.people"/>
    </member>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#instance"/>
      </roleSpec>
      <topicRef xlink:href="#leonardo"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classified-as"/>
    </instanceOf>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#classification"/>
      </roleSpec>
      <topicRef xlink:href="#sciences.people"/>
    </member>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/classification/#instance"/>
      </roleSpec>
      <topicRef xlink:href="#leonardo"/>
    </member>
  </association>

</topicMap>

Topic Per Term Thesaurus Pattern

Problem Statement

The topic map application must model information from a thesaurus. Each term in the thesaurus must be available separately, possibly because additional meta data is to be added for each term. The hierarchical relationship between terms must be modelled as must any scope notes and/or term warrants from the thesaurus.

Pattern Description

In this pattern, the thesaurus is represented by creating a separate topic for each term. Each topic which represents a term should be typed as a Term using the PSI specified for that purpose.

The term string should be expressed as a base name of the topic. The broader/narrower and preferred/non-preferred term relationships should be expressed using binary associations between terms. If the thesaurus being modelled simply groups synonyms with out expressing a preferred term amongst them, this can be expressed as an n-ary association in which all of the term topics play the same role.

Other thesaurus entry meta data such as scope notes and warrants can be specified as occurrence data on the topic representing the term. To model metadata for a warrant or scope note, the occurrence resource should be reified in the topic map.

/images/papers/05-03-05-fig11.png

Figure 13 - The Topic Per Term Thesaurus Pattern

As shown in the diagram above, a class of association is created for thesaurus-specific term relationships. The class Term Relationship serves as a base class for all such association types and four subclasses of this association type are defined for Broader-Narrower relationships, for synonymy in a controlled vocabulary where one term is a preferred term, for synonymy in which all terms are considered equal synonyms (with no preferred term role), and for a Part-Whole relationship.

The Broader-Narrower and Part-Whole relationships are modelled as binary associations. Where a term has one of these relationships with many topics (e.g. as a whole consisting of a number of individual parts), these must be modelled using multiple binary relationships. The synonymy relationships, on the other hand, are modelled using a n-ary associations where the intention is to convey the fact that the members of the association are mutually synonymous (although potentially with one of ther terms being a preferred term). This approach is based on a design principle described in in which relationships modelled using n-ary associations are considered to be aggregate relationships in which removing one role player invalidates the relationship between all other role players.

For clarity, the diagram above omits the relationship between the role types in the associations. The Related Term role type serves as a base class for the other roles used in term-to-term relationships. These class relationships are shown in the diagram below.

/images/papers/05-03-05-fig16.png

Figure 14 - Term Relationship Role Hierarchy

Analysis

The pattern presented here allows an existing thesaurus to be translated into a topic map structure without losing the ability to apply warrants and notes to individual synonymous terms. The cost of this flexibility is that for presentation of all synonymous terms, associations must be traversed.

Pattern Subject Indicators

The following subject identifiers are used by this pattern.

Diagram Class Name

Subject Identifier

Term

http://www.techquila.com/psi/thesaurus/#term

Term Relationship

http://www.techquila.com/psi/thesaurus/#term-relationship

Related Term

http://www.techquila.com/psi/thesaurus/#related-term

Broader-Narrower

http://www.techquila.com/psi/thesaurus/#broader-narrower

Broader

http://www.techquila.com/psi/thesaurus/#broader

Narrower

http://www.techquila.com/psi/thesaurus/#narrower

Synonymous Terms

http://www.techquila.com/psi/thesaurus/#synonymous-terms

Preferred Term

http://www.techquila.com/psi/thesaurus/#preferred-term

Non-Preferred Term

http://www.techquila.com/psi/thesaurus/#non-preferred-term

Synonym

http://www.techquila.com/psi/thesaurus/#synonym

Part-Whole

http://www.techquila.com/psi/thesaurus/#part-whole

Part

http://www.techquila.com/psi/thesaurus/#part

Whole

http://www.techquila.com/psi/thesaurus/#whole

Scope Note

http://www.techquila.com/psi/thesaurus/#scope-note

Editor Note

http://www.techquila.com/psi/thesaurus/#editor-note

General Note

http://www.techquila.com/psi/thesaurus/#general-note

Hierarchy Note

http://www.techquila.com/psi/thesaurus/#hierarchy-note

History Note

http://www.techquila.com/psi/thesaurus/#history-note

Translation Note

http://www.techquila.com/psi/thesaurus/#translation-note

Warrant

http://www.techquila.com/psi/thesaurus/#term-warrant

The Published Subject Indicators for each identifier are presented below.

Term

http://www.techquila.com/psi/thesaurus/#term

A type of topic which models a single term in a thesaurus. A term is a single word or phrase in a thesaurus.

Scope Note

http://www.techquila.com/psi/thesaurus/#scope-note

A type of occurrence of a Term which either references or contains information related to the thesaurus term. Typically scope notes are provided by the thesaurus compiler or editor. The scope note resource may be either contained inline as resource data or referenced from an occurrence of this type.

Editor Note

http://www.techquila.com/psi/thesaurus/#editor-note

A specialisation of Scope Note defining the type of occurrence which either references or contains editorial information related to the thesaurus term.

General Note

http://www.techquila.com/psi/thesaurus/#general-note

A specialisation of Scope Note defining the type of occurrence which either references or contains general information related to the thesaurus term.

Hierarchy Note

http://www.techquila.com/psi/thesaurus/#hierarchy-note

A specialisation of Scope Note defining the type of occurrence which either references or contains information related to the hierarchical placement of the thesaurus term.

History Note

http://www.techquila.com/psi/thesaurus/#history-note

A specialisation of Scope Note defining the type of occurrence which either references or contains historical information related to the thesaurus term.

Translation Note

http://www.techquila.com/psi/thesaurus/#translation-note

A specialisation of Scope Note defining the type of occurrence which either references or contains information related to the translation of the thesaurus term.

Term Warrant

http://www.techquila.com/psi/thesaurus/#term-warrant

A type of occurrence of a Term which references a source which justifies the use of the term in the thesaurus. A warrant may be referenced either by a link or by a citation entered as inline resource data in the occurrence. Multiple warrants should be modelled using one occurrence of this type per topic.

Term Relationship

http://www.techquila.com/psi/thesaurus/#term-relationship

The base class of relationships between terms defined by a thesaurus. Associations of this type may have any number of roles which must be of the type Related Term.

Broader / Narrower

http://www.techquila.com/psi/thesaurus/#broader-narrower

A type of association between two Term instances. In an association of this type, at one topic must play the role type Broader, and one topic must play the role type Narrower.

Broader

http://www.techquila.com/psi/thesaurus/#broader

A type of association role in an association of the type Broader / Narrower. The player of this role is the term with the broader definition of the two.

Narrower

http://www.techquila.com/psi/thesaurus/#narrower

A type of association role in an association of the type Broader-Term / Narrower-Term. The player of this role is the term with the narrower definition of the two.

Synonymous Terms

http://www.techquila.com/psi/thesaurus/#synonymous-terms

A type of association between two or more Term instances which asserts that all of the terms represented by the topics which are role players in the association are considered synonymous by the thesaurus. In an association of this type, EITHER all topics must play the role type Synonym OR one topic must play the role type Preferred Term and one topic must play the role type Non-Preferred Term.

Preferred Term

http://www.techquila.com/psi/thesaurus/#preferred-term

A type of association role which indicates that the role player or role players are terms preferred for use in the domain covered by the thesaurus.

Non-Preferred Term

http://www.techquila.com/psi/thesaurus/#non-preferred-term

A type of association role which indicates that the role player or role players are Term instances whose use is deprecated in the domain covered by the thesaurus.

Synonym

http://www.techquila.com/psi/thesaurus/#synonym

A type of association role. In an association of the type Synonymous Terms this role indicates that the role player or role players are all considered to be synonymous with one another.

Part-Whole

http://www.techquila.com/psi/thesaurus/#part-whole

A type of association which expresses a relationship between two or more terms where or more topics where one topic, playing the role Whole represents a whole thing and one or more topics playing the role Part each represent some component of the whole.

Part

http://www.techquila.com/psi/thesaurus/#part

A type of association role. In an association of the type Part-Whole, the role player or role players are all considered to be components which go to make up the player of the Whole role.

Whole

http://www.techquila.com/psi/thesaurus/#whole

A type of association role. In an association of the type Part-Whole, the player of this role is the topic which represents the thing which is constructed of the components represented by players of the Part role.

Example

<?xml version="1.0" encoding="UTF-8"?>
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
      xmlns:xlink="http://www.w3.org/1999/xlink">

  <!-- ================================= -->
  <!-- Topic-per-term thesaurus ontology -->
  <!-- ================================= -->

  <topic id="term">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#term"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Term</baseNameString>
    </baseName>
  </topic>

  <!-- BT/NT association type -->
  <topic id="broader-narrower">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader-narrower"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Broader Term-Narrower Term</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#broader"/>
      </scope>
      <baseNameString>Specialisations</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#narrower"/>
      </scope>
      <baseNameString>Generalisation</baseNameString>
    </baseName>
  </topic>

  <topic id="broader">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Broader</baseNameString>
    </baseName>
  </topic>

  <topic id="narrower">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#narrower"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Narrower</baseNameString>
    </baseName>
  </topic>

  <!-- Part/Whole association type -->
  <topic id="part-whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part-whole"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Part-Whole</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#whole"/>
      </scope>
      <baseNameString>Has Parts</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#part"/>
      </scope>
      <baseNameString>Is Part Of</baseNameString>
    </baseName>
  </topic>

  <topic id="whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#whole"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Whole</baseNameString>
    </baseName>
  </topic>

  <topic id="part">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Part</baseNameString>
    </baseName>
  </topic>

  <!-- RT association type -->
  <topic id="related-terms">
    <baseName>
      <baseNameString>Related Terms</baseNameString>
    </baseName>
  </topic>

  <!-- RT association role -->
  <topic id="related-term">
    <baseName>
      <baseNameString>Related Term</baseNameString>
    </baseName>
  </topic>

  <!-- Synonym association type -->
  <topic id="synonym">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#synonym"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Synonym</baseNameString>
    </baseName>
  </topic>

  <topic id="preferred-term">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#preferred-term"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Preferred Term</baseNameString>
    </baseName>
  </topic>

  <topic id="non-preferred-term">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#non-preferred-term"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Non-Preferred Term</baseNameString>
    </baseName>
  </topic>

  <!-- Scope note occurrence type -->
  <topic id="scope-note">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#scope-note"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Scope Note</baseNameString>
    </baseName>
  </topic>

  <!-- Term warrant occurrence type -->
  <topic id="term-warrant">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#term-warrant"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Warrant</baseNameString>
    </baseName>
  </topic>

  <!-- term-warrant subclass of scope-note -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#subclass-superclass"/>
    </instanceOf>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#superclass"/>
      </roleSpec>
      <topicRef xlink:href="#scope-note"/>
    </member>
    <member>
      <roleSpec>
    <subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/core.xtm#sublcass"/>
      </roleSpec>
      <topicRef xlink:href="#term-warrant"/>
    </member>
  </association>

  <!-- =============== -->
  <!-- Thesaurus terms -->
  <!-- =============== -->
  <topic id="literary_studies">
    <instanceOf>
      <topicRef xlink:href="#term"/>
    </instanceOf>
    <baseName>
      <baseNameString>literary studies</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000017431"/>
    </occurrence>
  </topic>

  <topic id="literature_humanities">
    <instanceOf>
      <topicRef xlink:href="#term"/>
    </instanceOf>
    <baseName>
      <baseNameString>literature (humanities)</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000012941"/>
    </occurrence>
  </topic>

  <topic id="humanities">
    <instanceOf>
      <topicRef xlink:href="#term"/>
    </instanceOf>
    <baseName>
      <baseNameString>humanities</baseNameString>
    </baseName>
  </topic>

  <topic id="writings">
    <instanceOf>
      <topicRef xlink:href="#term"/>
    </instanceOf>
    <baseName>
      <baseNameString>writings</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000042061"/>
    </occurrence>
  </topic>

  <topic id="document_genres">
    <instanceOf>
      <topicRef xlink:href="#term"/>
    </instanceOf>
    <baseName>
      <baseNameString>document genres</baseNameString>
    </baseName>
  </topic>

  <association>
    <instanceOf>
      <topicRef xlink:href="#broader-narrower"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#narrower"/>
      </roleSpec>
      <topicRef xlink:href="#literature_humanities"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#broader"/>
      </roleSpec>
      <topicRef xlink:href="#humanities"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#broader-narrower"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#narrower"/>
      </roleSpec>
      <topicRef xlink:href="#literary_studies"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#broader"/>
      </roleSpec>
      <topicRef xlink:href="#humanities"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#broader-narrower"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#narrower"/>
      </roleSpec>
      <topicRef xlink:href="#writings"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#broader"/>
      </roleSpec>
      <topicRef xlink:href="#document_genres"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#synonym"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#non-preferred-term"/>
      </roleSpec>
      <topicRef xlink:href="#literary_studies"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#preferred-term"/>
      </roleSpec>
      <topicRef xlink:href="#literature_humanities"/>
    </member>
  </association>

  <association>
    <instanceOf>
      <topicRef xlink:href="#related-terms"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#related-term"/>
      </roleSpec>
      <topicRef xlink:href="#literature_humanities"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#related-term"/>
      </roleSpec>
      <topicRef xlink:href="#writings"/>
    </member>
  </association>
</topicMap>

Related Patterns

The Topic Per Concept Thesaurus Pattern models a topic map such that all synonyms are base names of the same topic, eliminating the need to traverse associations in order to present a concept.

The Part Whole and Broader Narrower relationships can be modelled as instances of the Hierachical Relationship Type introduced in the Hierarchical Classification pattern. The Part and Narrower roles are instances of the Subordinate Role Type and the Whole and Broader roles are instances of the Superordinate Role Type. This is shown diagramatically below. Using the Hierarhcical Classification Pattern enables an application aware of that pattern to display the hierarchical ordering of the thesaurus even if it is not aware of this design pattern.

/images/papers/05-03-05-fig17.png

Figure 15 - The Relationship between the Hierarchical Classification and the Topic Per Term Thesaurus Patterns

Topic Per Concept Thesaurus Pattern

Problem Statement

The topic map application must model information from a thesaurus, maintaining the hierarchical relationship between the concepts that the thesaurus defines and enabling efficient access to the list of terms that can be applied to each concept.

Pattern Description

This alternate pattern for thesaurus representation eliminates the associations used to relate synonyms in the Topic-Per-Term pattern. Instead, one topic is used to represent the single concept which all entries share in common. In this model, the topic may have multiple base names, one for each synonym and where preferred terms are expressed, the names of the non-preferred synonyms should be scoped appropriately.

The diagram below shows the Concept class of topic as having two kinds of name, one name specified in the unconstrained scope, representing a preferred term for the concept, and the other names scoped as a Non-Preferred Term. However, if the thesaurus being modelled does not express preferred and non-preferred terms, all synonymous terms can instead be represented as topic base names in the unconstrained scope.

For clarity, the diagram below does not repeat all the subclasses of Scope Note, however it is proposed that these should be exactly the same as in the Topic Per Term Thesaurus Pattern.

/images/papers/05-03-05-fig12.png

Figure 16 - The Topic Per Concept Thesaurus Pattern

Subject Indicators

The following subject identifiers are defined for use by this pattern. These are Published Subject Identifiers. For the complete description of each identifier, please visit the identifier URL.

Diagram Class Name

Subject Identifier

Concept

http://www.techquila.com/psi/thesaurus/#concept

Concept Relationship

http://www.techquila.com/psi/thesaurus/#concept-relationship

Related Concept

http://www.techquila.com/psi/thesaurus/#related-concept

Broader-Narrower

http://www.techquila.com/psi/thesaurus/#broader-narrower

Broader

http://www.techquila.com/psi/thesaurus/#broader

Narrower

http://www.techquila.com/psi/thesaurus/#narrower

Non-Preferred Term

http://www.techquila.com/psi/thesaurus/#non-preferred-term

Part-Whole

http://www.techquila.com/psi/thesaurus/#part-whole

Part

http://www.techquila.com/psi/thesaurus/#part

Whole

http://www.techquila.com/psi/thesaurus/#whole

Scope Note

http://www.techquila.com/psi/thesaurus/#scope-note

Editor Note

http://www.techquila.com/psi/thesaurus/#editor-note

General Note

http://www.techquila.com/psi/thesaurus/#general-note

Hierarchy Note

http://www.techquila.com/psi/thesaurus/#hierarchy-note

History Note

http://www.techquila.com/psi/thesaurus/#history-note

Translation Note

http://www.techquila.com/psi/thesaurus/#translation-note

Warrant

http://www.techquila.com/psi/thesaurus/#term-warrant

The Published Subject Indicators follow. To save space, only the PSIs which are not already defined for the Topic Per Term Thesaurus Pattern are presented here.

Concept

http://www.techquila.com/psi/thesaurus/#concept

A type of topic which models the concept represented by a collection of synonymous terms in a thesaurus.

Concept Relationship

http://www.techquila.com/psi/thesaurus/#concept-relationship

The base type of associations between concepts which are defined in a thesaurus. An association of this type consists of any number of Related Concept roles.

Example

<?xml version="1.0" encoding="UTF-8"?>
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
      xmlns:xlink="http://www.w3.org/1999/xlink">

  <!-- ==================================== -->
  <!-- Topic-Per-Concept Thesaurus Ontology -->
  <!-- ==================================== -->

  <!-- Concept topic type -->
  <topic id="concept">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#concept"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Concept</baseNameString>
    </baseName>
  </topic>

  <!-- Non-Preferred Term. Used in this model as a basename scoping topic -->
  <topic id="non-preferred-term">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#non-preferred-term"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Non-Preferred Term</baseNameString>
    </baseName>
  </topic>


  <!-- BT/NT association type -->
  <topic id="broader-narrower">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader-narrower"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Broader Than-Narrower Than</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#broader"/>
      </scope>
      <baseNameString>Specialisations</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#narrower"/>
      </scope>
      <baseNameString>Generalisation</baseNameString>
    </baseName>
  </topic>

  <!-- Broader association role type -->
  <topic id="broader">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Generalisation</baseNameString>
    </baseName>
  </topic>

  <!-- Narrower association role type -->
  <topic id="narrower">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#narrower-concept"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Specialisation</baseNameString>
    </baseName>
  </topic>

  <!-- Related Concepts association type -->
  <topic id="concept-relationship">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#concept-relationship"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Related Concepts</baseNameString>
    </baseName>
  </topic>

  <!-- Related concepts association role type -->
  <topic id="related-concept">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#related-concept"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Related Concept</baseNameString>
    </baseName>
  </topic>

  <!-- Part/Whole association type -->
  <topic id="part-whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part-whole"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Part-Whole</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#whole"/>
      </scope>
      <baseNameString>Has Parts</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#part"/>
      </scope>
      <baseNameString>Is Part Of</baseNameString>
    </baseName>
  </topic>

  <!-- Part association role type -->
  <topic id="part">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Part</baseNameString>
    </baseName>
  </topic>

  <!-- Whole association role type -->
  <topic id="whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#whole"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Whole</baseNameString>
    </baseName>
  </topic>

  <!-- Scope Note occurrence type -->
  <topic id="scope-note">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#scope-note"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Scope Note</baseNameString>
    </baseName>
  </topic>

  <!-- Warrant occurrence type -->
  <topic id="term-warrant">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#term-warrant"/>
    </subjectIdentity>
    <baseName>
      <baseNameString>Warrant</baseNameString>
    </baseName>
  </topic>

  <!-- ============================ -->
  <!-- Thesaurus entries (concepts) -->
  <!-- ============================ -->

  <!-- Concept: literature (humanities) -->
  <topic id="literature_humanities">
    <instanceOf>
      <topicRef xlink:href="#concept"/>
    </instanceOf>
    <baseName>
      <baseNameString>literature (humanities)</baseNameString>
    </baseName>
    <baseName>
      <scope>
    <topicRef xlink:href="#non-preferred-term"/>
      </scope>
      <baseNameString>literary studies</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000017431"/>
    </occurrence>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000012941"/>
    </occurrence>
  </topic>

  <!-- Concept: humanities -->
  <topic id="humanities">
    <instanceOf>
      <topicRef xlink:href="#concept"/>
    </instanceOf>
    <baseName>
      <baseNameString>humanities</baseNameString>
    </baseName>
  </topic>

  <!-- Concept: writings -->
  <topic id="writings">
    <instanceOf>
      <topicRef xlink:href="#concept"/>
    </instanceOf>
    <baseName>
      <baseNameString>writings</baseNameString>
    </baseName>
    <occurrence>
      <instanceOf>
    <topicRef xlink:href="#term-warrant"/>
      </instanceOf>
      <resourceRef xlink:href="http://webapps.getty.edu/vow/AATSource?find=&amp;amp;logic=AND&amp;amp;note=&amp;amp;page=1&amp;amp;sourceid=2000042061"/>
    </occurrence>
  </topic>

  <topic id="document_genres">
    <instanceOf>
      <topicRef xlink:href="#concept"/>
    </instanceOf>
    <baseName>
      <baseNameString>document genres</baseNameString>
    </baseName>
  </topic>

  <!-- literature (humanities) NT humanities -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#broader-narrower"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#narrower"/>
      </roleSpec>
      <topicRef xlink:href="#literature_humanities"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#broader"/>
      </roleSpec>
      <topicRef xlink:href="#humanities"/>
    </member>
  </association>

  <!-- writings NT document-genres -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#broader-narrower"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#narrower"/>
      </roleSpec>
      <topicRef xlink:href="#writings"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#broader"/>
      </roleSpec>
      <topicRef xlink:href="#document_genres"/>
    </member>
  </association>

  <!-- literature (humanities) RT writings -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#concept-relationship"/>
    </instanceOf>
    <member>
      <roleSpec>
    <topicRef xlink:href="#related-concept"/>
      </roleSpec>
      <topicRef xlink:href="#literature_humanities"/>
    </member>
    <member>
      <roleSpec>
    <topicRef xlink:href="#related-concept"/>
      </roleSpec>
      <topicRef xlink:href="#writings"/>
    </member>
  </association>

</topicMap>

Analysis

In comparison with the Topic Per Term Thesaurus Pattern, this model of the thesaurus, one loses the ability to add warrants, scope notes or other meta data for individual terms but with a number of synonyms per concept, this model can lead to a much more compact topic map and also one which is easier to process for display purposes, as one need only enumerate all of the names of a topic to list all synonyms rather than follow associations.

Related Patterns

The Topic Per Term Thesaurus Pattern defines an alternate model for thesaurii which preserves each individual term as a separate topic in the topic map.

As with the Topic-Per-Term Thesaurus pattern, the Part-Whole and Broader-Narrower relationships can be modelled as instances of the Hierarchical Relationship Type introduced in the Hierarchical Classification pattern. The Part and Narrower roles are instances of the Subordinate Role Type and the Whole and Broader Concept roles are instances of the Superordinate Role Type. This is shown in Figure 15.

Faceted Classification Pattern

Problem Statement

A faceted classification system is one in which each resource is classified according to several separate hierarchical classification systems, called facets. provides a good overview of this form of classification and its applicaiton in organising information. Using a faceted classification system it should be possible to retrieve any instance by drill-down through one of the facets until you reach the entry under which the instance is classified. The power of a faceted classification though is that a user can combine facets to effectively filter the set of all instances far more rapidly. In addition, the facets can be used to address multiple classification criteria. For example a restaurant might be classified by location, cuisine and price range. By expressing these as three separate facets, one enables a user to drill down using the facet of most interest to them.

Pattern Description

Each separate facet can be easily modelled using the hierarchical classificaiton pattern already described. However in order to really make use of a faceted classification system it is important to be able to determine what facets are defined in the classification system, and the type or types of association which define the hierarchical relationship between classes in each facet.

In this pattern, we represent each facet with a topic. Doing this enables us to use that topic to provide labels for the facet (for creating the user interface) and also allows us to make further assertions about the topics which define the classes for that facet.

For an application to present a facet, it must be able to determine for each facet:

  • Which topic represents the root of the facet classification.

  • What type of association is used to construct the classification hierarchy.

These two pieces of information can be provided by associating the topic which represents the root of the facet's classification and the topic used to type the hierarchical association between facet's classes with the topic which represents the facet itself. The classification hierarchy for the facet must then be constructed from associations of the specified type. For the hierarchy to be properly recognised, such association types must themselves be instances of the Hierarchical Relation Type as defined in the Hierarchical Classification Pattern.

/images/papers/05-03-05-fig14.png

Figure 17 - The Faceted Classification Pattern

PSIs For The Faceted Classification Pattern

The following Published Subject Identifiers are used by the Faceted Classification Pattern:

Diagram Class Name

Subject Identifier

Facet

http://www.techquila.com/psi/faceted-classification/#facet

Facet Has Root

http://www.techquila.com/psi/faceted-classification/#facet-has-root

Facet-Root

http://www.techquila.com/psi/faceted-classification/#facet-root

Facet Has Hierarchy Type

http://www.techquila.com/psi/faceted-classification/#facet-has-hierarchy-type

Facet Hierarchy Type

http://www.techquila.com/psi/faceted-classification/#facet-hierarchy-type

Facet

http://www.techquila.com/psi/faceted-classification/#facet

A facet in a faceted classification system.

Facet Has Root

http://www.techquila.com/psi/faceted-classification/#facet-has-root

A type of binary association between an topic of type Facet (playing the role Facet) and another topic of any type (playing the role Facet-Root) which is the root class of the facet's classification hierarchy.

Facet-Root

http://www.techquila.com/psi/faceted-classification/#facet-root

An association role type. This role is played by a topic of any type in an association of the type Facet Has Root by the topic which represents the root class of the facet represented by the topic playing the Facet role.

Facet Has Hierarchy Type

http://www.techquila.com/psi/faceted-classification/#facet-has-hierarchy-type

A type of binary association between a topic of type Facet which plays the role Facet, and a topic of type Hierarchical Relation Type playing the role of Facet Hierarchy Type. This association asserts that the classification hierarchy used by the player of the Facet role is defined by associations of the type specified by the player of the Facet Hierarchy Type role.

Facet Hierarchy Type

http://www.techquila.com/psi/faceted-classification/#facet-hierarchy-type

A type of association role, played by a topic of the type Hierarchical Relation Type which is itself used to type associations which define the hierarchy of classification for a facet.

Example

<?xml version="1.0" encoding="UTF-8"?>
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
  xmlns:xlink="http://www.w3.org/1999/xlink">

  <!-- ===================================================
       Topic Map : Example Facetted Classification
       File: fc-example.xtm
       Notes:
         This topic map has been created as a simple example
         of using the facetted classification model described
         in "Topic Map Patterns For Information Architecture"
         (http://www.techquila.com/tmsinia.html).

         The topic map shows the facetted classification of
         wines by a "Region" facet and "Varietal" facet.
         This example was derived from a much larger example
         of facetted classification which can be seen at
         http://www.facetmap.com/browse.jsp

  ======================================================= -->

  <!-- To minimize the size of this example, the topics
       defining the faceted classification ontology are imported
       rather than being defined in this topic map -->
  <mergeMap xlink:href="http://www.techquila.com/psi/faceted-classification/faceted-classification.xtm"/>
  <mergeMap xlink:href="http://www.techquila.com/psi/hierarchy/hierarchy.xtm"/>
  <mergeMap xlink:href="http://www.techquila.com/psi/thesaurus/thesaurus.xtm"/>

  <!-- Topic Types -->
  <topic id="wine-class">
    <baseName>
      <baseNameString>Class Of Wine</baseNameString>
    </baseName>
  </topic>

  <topic id="varietal">
    <baseName>
      <baseNameString>Varietal</baseNameString>
    </baseName>
  </topic>

  <topic id="region">
    <baseName>
      <baseNameString>Region</baseNameString>
    </baseName>
  </topic>

  <topic id="wine">
    <baseName>
      <baseNameString>Wine</baseNameString>
    </baseName>
  </topic>

  <!-- ================= -->
  <!-- Association types -->
  <!-- ================= -->

  <!-- Supercategory/Subcategory. Declared as an instance of the
       Hierarchical Relationship pattern -->
  <topic id="subcategory-supercategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#hierarchical-relation-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Subcategory/Supercategory</baseNameString>
    </baseName>
  </topic>

  <topic id="subcategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#subordinate-role-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Subcategory</baseNameString>
    </baseName>
  </topic>


  <topic id="supercategory">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/hierarchy/#superordinate-role-type"/>
    </instanceOf>
    <baseName>
      <baseNameString>Supercategory</baseNameString>
    </baseName>
  </topic>

  <!-- Part-whole association type from thesaurus PSI set -->
  <topic id="part-whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part-whole"/>
    </subjectIdentity>
  </topic>

  <topic id="part">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part"/>
    </subjectIdentity>
  </topic>

  <topic id="whole">
    <subjectIdentity>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#whole"/>
    </subjectIdentity>
  </topic>

  <!-- Wine is of Varietal -->
  <topic id="wine-of-varietal">
    <baseName>
      <baseNameString>Wine Varietal</baseNameString>
    </baseName>
  </topic>

  <!-- Wine is from Region -->
  <topic id="wine-from-region">
    <baseName>
      <baseNameString>Wine From Region</baseNameString>
    </baseName>
  </topic>

  <!-- Wine classes -->
  <topic id="all-wines">
    <instanceOf>
      <topicRef xlink:href="#wine-class"/>
    </instanceOf>
    <baseName><baseNameString>All Wines</baseNameString></baseName>
  </topic>

  <topic id="red-wine">
    <instanceOf>
      <topicRef xlink:href="#wine-class"/>
    </instanceOf>
    <baseName>
      <baseNameString>Red Wine</baseNameString>
    </baseName>
  </topic>

  <topic id="white-wine">
    <instanceOf>
      <topicRef xlink:href="#wine-class"/>
    </instanceOf>
    <baseName>
      <baseNameString>White Wine</baseNameString>
    </baseName>
  </topic>

  <!-- Wine Varietals -->
  <topic id="cab-sauv">
    <baseName>
      <baseNameString>Cabernet Sauvignon</baseNameString>
    </baseName>
  </topic>

  <topic id="merlot">
    <baseName>
      <baseNameString>Merlot</baseNameString>
    </baseName>
  </topic>

  <topic id="chablis">
    <baseName>
      <baseNameString>Chablis</baseNameString>
    </baseName>
  </topic>

  <topic id="chardonnay">
    <baseName>
      <baseNameString>Chardonnay</baseNameString>
    </baseName>
  </topic>

  <!-- ================================================== -->
  <!-- Facet Definitions. We create a hierarchical        -->
  <!-- relationship for each facet in our classification. -->
  <!-- ================================================== -->

  <!-- Wine Class facet -->
  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#all-wines"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#red-wine"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#all-wines"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#white-wine"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#red-wine"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#cab-sauv"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#red-wine"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#merlot"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#white-wine"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#chablis"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#subcategory-supercategory"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#supercategory"/></roleSpec>
      <topicRef xlink:href="#white-wine"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#subcategory"/></roleSpec>
      <topicRef xlink:href="#chardonnay"/>
    </member>
  </association>

  <!-- Wine Source Facet -->
  <topic id="the-world">
    <baseName><baseNameString>The World</baseNameString></baseName>
  </topic>

  <topic id="europe">
    <baseName><baseNameString>Europe</baseNameString></baseName>
  </topic>

  <topic id="france">
    <baseName>
      <baseNameString>France</baseNameString>
    </baseName>
  </topic>

  <topic id="burgundy">
    <baseName>
      <baseNameString>Burgundy</baseNameString>
    </baseName>
  </topic>

  <topic id="rhone">
    <baseName>
      <baseNameString>Rhone</baseNameString>
    </baseName>
  </topic>

  <!-- Part/Whole relationships between regions -->
  <association>
    <instanceOf><topicRef xlink:href="#part-whole"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#whole"/></roleSpec>
      <topicRef xlink:href="#the-world"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#part"/></roleSpec>
      <topicRef xlink:href="#europe"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#part-whole"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#whole"/></roleSpec>
      <topicRef xlink:href="#europe"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#part"/></roleSpec>
      <topicRef xlink:href="#france"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#part-whole"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#whole"/></roleSpec>
      <topicRef xlink:href="#france"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#part"/></roleSpec>
      <topicRef xlink:href="#burgundy"/>
    </member>
  </association>

  <association>
    <instanceOf><topicRef xlink:href="#part-whole"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#whole"/></roleSpec>
      <topicRef xlink:href="#france"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#part"/></roleSpec>
      <topicRef xlink:href="#rhone"/>
    </member>
  </association>

  <!-- ============================================ -->
  <!-- Faceted Classification Definitions           -->
  <!-- The following topics and associations define -->
  <!-- the facets in our classification. Each facet -->
  <!-- is represented by a topic and the root class -->
  <!-- of the facet is specified by an association  -->
  <!-- ============================================ -->

  <!-- Region Facet Definition -->
  <topic id="region-facet">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
    </instanceOf>
    <baseName><baseNameString>Region Facet</baseNameString></baseName>
  </topic>

  <!-- Region Facet root is The World -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-has-root"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
      </roleSpec>
      <topicRef xlink:href="#region-facet"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-root"/>
      </roleSpec>
      <topicRef xlink:href="#the-world"/>
    </member>
  </association>

  <!-- Region Facet hierarchy is the Part-Whole relationship -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-has-hierarchy-type"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
      </roleSpec>
      <topicRef xlink:href="#region-facet"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-hierarchy-type"/>
      </roleSpec>
      <topicRef xlink:href="#part-whole"/>
    </member>
  </association>

  <!-- Wine Type Facet -->
  <topic id="wine-type-facet">
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
    </instanceOf>
    <baseName><baseNameString>Wine Type Facet</baseNameString></baseName>
  </topic>

  <!-- Wine Type facet root is "All Wines" -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-has-root"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
      </roleSpec>
      <topicRef xlink:href="#wine-type-facet"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-root"/>
      </roleSpec>
      <topicRef xlink:href="#all-wine-types"/>
    </member>
  </association>

  <!-- Wine Type facet hierarchy is subcategory/supercategory -->
  <association>
    <instanceOf>
      <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-has-hierarchy-type"/>
    </instanceOf>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet"/>
      </roleSpec>
      <topicRef xlink:href="#wine-type-facet"/>
    </member>
    <member>
      <roleSpec>
        <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/faceted-classification/#facet-hierarchy-type"/>
      </roleSpec>
      <topicRef xlink:href="#subcategory-supercategory"/>
    </member>
  </association>


  <!-- ========================================== -->
  <!-- Example classification                     -->
  <!-- NOTE: in a real system, the classification -->
  <!-- and its definition should probably be      -->
  <!-- maintained as separate topic maps          -->
  <!-- ========================================== -->
  <topic id="duboeuf_cab_2001">
    <baseName>
      <baseNameString>Duboeuf 2001 Cabernet Sauvignon</baseNameString>
    </baseName>
  </topic>

  <!-- Wine's classification on the Wine Type facet -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#wine-of-varietal"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#varietal"/></roleSpec>
      <topicRef xlink:href="#cab-sauv"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#wine"/></roleSpec>
      <topicRef xlink:href="#duboeuf_cab_2001"/>
    </member>
  </association>

  <!-- Wine's classification on the Region facet -->
  <association>
    <instanceOf>
      <topicRef xlink:href="#wine-from-region"/>
    </instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#wine"/></roleSpec>
      <topicRef xlink:href="#duboeuf_cab_2001"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#region"/></roleSpec>
      <topicRef xlink:href="#burgundy"/>
    </member>
  </association>

</topicMap>

Conclusions

Topic map design patterns provide a means of communicating the ways in which common information representation problems can be addressed using topic maps. By combining topic map design patterns and Published Subject Identifiers, a design pattern can also enable greater interoperability of topic maps by introducing common ontologies.

Topic map design patterns can be developed in a modular manner, with one pattern making use of one or more other patterns. Modular designs can aid interoperability still furhter as applications aware only of the lower-level patterns would still be able to intepret at least some of the semantics of the higher-level patterns.

Creating and using patterns need not limit choice, patterns can be used to codify the different ways of approaching a particular problem and can make it easier to compare the trade-offs made in approaches

Future Work

This paper presents just a few design patterns based on the interest of an applications developed by the author. To encourage discussion of patterns in general, and to provide a forum for the publication of topic map design patterns, a Wiki has been started at http://www.topicmapcentral.com/wiki/Wiki.jsp. The patterns described here will be published in the wiki and new contributions are encouraged.

One of the goals of creating small, easily understood patterns is to enable the topic map tool-sets to provide higher-level functionality. The patterns presented here will be incorporated into the TMTab topic map editing application (http://www.techquila.com/projects/tmtab/) and the TMBrowse topic map browser application (a web application being developed as part of the TM4J project).