Beyond PSIs: Topic Map design patterns

Kal Ahmed
kal@techquila.com

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.

Keywords: Topic Maps; Interoperability; Metadata

Kal Ahmed

Beyond PSIs

Topic Map design patterns

Kal Ahmed [Techquila]

Extreme Markup Languages 2003® (Montréal, Québec)

Copyright © 2003 Khalil Ahmed. Reproduced with permission.

Introduction

Software design patterns, first codified by Gamma et al. [GAMMA94] 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 patterns are created and identifiers used for the elements of those patterns, 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. While it is really only suitable for a subset of all PSIs that might ever be created, by relating PSIs to usable and useful design patterns, it is hoped that the take-up of such PSIs can be encouraged.

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. [GAMMA94] define a Software Design Pattern as consisting of four essential elements:

  1. 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.
  2. 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.
  3. A description of the solution which defines the elements of the design, and their relationships.
  4. 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 as the names used in a software design pattern are simply handles used for the purposes of explanation of the pattern, in a topic map design pattern, the Published Subject Identifiers are the proposed identifiers to be used in the implementation of the pattern. Finally, 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 instead controlled vocabularies from which the required entries are select. The sorts 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.

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.

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.

Figure 1: A typed topic
[Link to open this graphic in a separate page]

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.

Figure 2: An untyped Occurrence
[Link to open this graphic in a separate page]
Figure 3: A typed Occurrence
[Link to open this graphic in a separate page]

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

Figure 4: A topic with Occurrence
[Link to open this graphic in a separate page]

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.

Figure 5: A typed binary association
[Link to open this graphic in a separate page]

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.

Figure 6: A typed 3-ary association
[Link to open this graphic in a separate page]

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

Figure 7: Subclass relationship
[Link to open this graphic in a separate page]

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 also an instance of the topic class “Species”.

Figure 8: One topic class as an instance Of another
[Link to open this graphic in a separate page]

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.

Figure 9: A scoped Occurrence
[Link to open this graphic in a separate page]

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

Figure 10: A scoped association
[Link to open this graphic in a separate page]

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

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. This pattern addresses the issue of naming topics for most flexible use in presentation.

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.

Figure 11: Hierarchical Naming Pattern
[Link to open this graphic in a separate page]

Example

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

Figure 12: Example of the Hierarchical Naming Pattern
<topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
  xmlns:xlink="http://www.w3.org/1999/xlink">

  <topic id="parent-child">
    <!-- Details here -->
  </topic>
  <topic id="parent">
    <!-- Details here -->
  </topic>
  <topic id="child">
    <!-- Details here -->
  </topic>

  <topic id="top">
    <baseName>
      <baseNameString>Top</baseNameString>
    </baseName>
  </topic>

  <topic id="top.computing">
    <baseName>
      <baseNameString>Top > Computing</baseNameString>
    </baseName>
    <baseName>
      <scope><topicRef xlink:href="#top"/></scope>
      <baseNameString>Computing</baseNameString>
    </baseName>
  </topic>

  <!-- Parent-child relation between Top and Top/Computing -->
  <association>
    <instanceOf><topicRef xlink:href="#parent-child"/></instanceOf>
    <member>
      <roleSpec><topicRef xlink:href="#parent"/></roleSpec>
      <topicRef xlink:href="#top"/>
    </member>
    <member>
      <roleSpec><topicRef xlink:href="#child"/></roleSpec>
      <topicRef xlink:href="#top.computing"/>
    </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).

Related patterns

The Hierarchical Classification Pattern documented in [AHMED03] can be used to define the hierarchical ordering of topics.

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.

Figure 13: The Topic Per Term Thesaurus Pattern
[Link to open this graphic in a separate page]

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.

Table 1
Diagram Class Name Subject Identifier
Term http://www.techquila.com/psi/thesaurus/#term
Broader-Narrower http://www.techquila.com/psi/thesaurus/#broader-narrower
Broader Term http://www.techquila.com/psi/thesaurus/#broader-term
Narrower Term http://www.techquila.com/psi/thesaurus/#narrower-term
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
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.

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.

Broader-Term / Narrower-Term

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-Term, and one topic must play the role type Narrower-Term.

Broader-Term

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

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 broader definition of the two.

Narrower-Term

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

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

Figure 14: An example of a thesaurus using the Topic Per Term Thesaurus 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">
    <topic id="narrower-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#narrower-term"/>
        </subjectIdentity>
        <baseName id="16540">
            <baseNameString>Narrower</baseNameString>
        </baseName>
    </topic>
    <topic id="literary_studies">
        <instanceOf>
            <topicRef xlink:href="#term"/>
        </instanceOf>
        <baseName id="16756">
            <baseNameString>literary studies</baseNameString>
        </baseName>
        <occurrence id="16738">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000017431"/>
        </occurrence>
    </topic>
    <topic id="related-term">
        <baseName id="16745">
            <baseNameString>Related Term</baseNameString>
        </baseName>
    </topic>
    <topic id="synonym">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#synonym"/>
        </subjectIdentity>
        <baseName id="16528">
            <baseNameString>Synonym</baseNameString>
        </baseName>
    </topic>
    <topic id="whole">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#whole"/>
        </subjectIdentity>
        <baseName id="16535">
            <baseNameString>Whole</baseNameString>
        </baseName>
    </topic>
    <topic id="part-whole">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #part-whole"/>
        </subjectIdentity>
        <baseName id="16531">
            <baseNameString>Part-Whole</baseNameString>
        </baseName>
        <baseName id="16532">
            <scope>
                <topicRef xlink:href="#whole"/>
            </scope>
            <baseNameString>Has Parts</baseNameString>
        </baseName>
        <baseName id="16533">
            <scope>
                <topicRef xlink:href="#part"/>
            </scope>
            <baseNameString>Is Part Of</baseNameString>
        </baseName>
    </topic>
    <topic id="scope-note">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #scope-note"/>
        </subjectIdentity>
        <baseName id="16529">
            <baseNameString>Scope Note</baseNameString>
        </baseName>
    </topic>
    <topic id="term-warrant">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #term-warrant"/>
        </subjectIdentity>
        <baseName id="16530">
            <baseNameString>Warrant</baseNameString>
        </baseName>
    </topic>
    <topic id="preferred-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#preferred-term"/>
        </subjectIdentity>
        <baseName id="16526">
            <baseNameString>Preferred Term</baseNameString>
        </baseName>
    </topic>
    <topic id="literature_humanities">
        <instanceOf>
            <topicRef xlink:href="#term"/>
        </instanceOf>
        <baseName id="16733">
            <baseNameString>literature (humanities)</baseNameString>
        </baseName>
        <occurrence id="16734">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000012941"/>
        </occurrence>
    </topic>
    <topic id="related-terms">
        <baseName id="16746">
            <baseNameString>Related Terms</baseNameString>
        </baseName>
    </topic>
    <topic id="broader-narrower">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader-narrower"/>
        </subjectIdentity>
        <baseName id="16536">
            <baseNameString>Broader Term-Narrower Term</baseNameString>
        </baseName>
        <baseName id="16537">
            <scope>
                <topicRef xlink:href="#broader-term"/>
            </scope>
            <baseNameString>Specialisations</baseNameString>
        </baseName>
        <baseName id="16538">
            <scope>
                <topicRef xlink:href="#narrower-term"/>
            </scope>
            <baseNameString>Generalisation</baseNameString>
        </baseName>
    </topic>
    <topic id="humanities">
        <instanceOf>
            <topicRef xlink:href="#term"/>
        </instanceOf>
        <baseName id="16736">
            <baseNameString>humanities</baseNameString>
        </baseName>
    </topic>
    <topic id="writings">
        <instanceOf>
            <topicRef xlink:href="#term"/>
        </instanceOf>
        <baseName id="16749">
            <baseNameString>writings</baseNameString>
        </baseName>
        <occurrence id="16750">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000042061"/>
        </occurrence>
    </topic>
    <topic id="non-preferred-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #non-preferred-term"/>
        </subjectIdentity>
        <baseName id="16527">
            <baseNameString>Non-Preferred Term</baseNameString>
        </baseName>
    </topic>
    <topic id="term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#term"/>
        </subjectIdentity>
        <baseName id="16525">
            <baseNameString>Term</baseNameString>
        </baseName>
    </topic>
    <topic id="document_genres">
        <instanceOf>
            <topicRef xlink:href="#term"/>
        </instanceOf>
        <baseName id="16751">
            <baseNameString>document genres</baseNameString>
        </baseName>
    </topic>
    <topic id="part">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part"/>
        </subjectIdentity>
        <baseName id="16534">
            <baseNameString>Part</baseNameString>
        </baseName>
    </topic>
    <topic id="broader-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #broader-term"/>
        </subjectIdentity>
        <baseName id="16539">
            <baseNameString>Broader</baseNameString>
        </baseName>
    </topic>
    <association id="literature_humanities_16494">
        <instanceOf>
            <topicRef xlink:href="#broader-narrower"/>
        </instanceOf>
        <member>
            <roleSpec>
                <topicRef xlink:href="#narrower-term"/>
            </roleSpec>
            <topicRef xlink:href="#literature_humanities"/>
        </member>
        <member>
            <roleSpec>
                <topicRef xlink:href="#broader-term"/>
            </roleSpec>
            <topicRef xlink:href="#humanities"/>
        </member>
    </association>
    <association id="literary_studies_16494">
        <instanceOf>
            <topicRef xlink:href="#broader-narrower"/>
        </instanceOf>
        <member>
            <roleSpec>
                <topicRef xlink:href="#narrower-term"/>
            </roleSpec>
            <topicRef xlink:href="#literary_studies"/>
        </member>
        <member>
            <roleSpec>
                <topicRef xlink:href="#broader-term"/>
            </roleSpec>
            <topicRef xlink:href="#humanities"/>
        </member>
    </association>
    <association id="literary_studies_16520">
        <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 id="writings_16494">
        <instanceOf>
            <topicRef xlink:href="#broader-narrower"/>
        </instanceOf>
        <member>
            <roleSpec>
                <topicRef xlink:href="#narrower-term"/>
            </roleSpec>
            <topicRef xlink:href="#writings"/>
        </member>
        <member>
            <roleSpec>
                <topicRef xlink:href="#broader-term"/>
            </roleSpec>
            <topicRef xlink:href="#document_genres"/>
        </member>
    </association>
    <association id="a1">
        <instanceOf>
            <topicRef xlink:href="#related-terms"/>
        </instanceOf>
        <member id="16742">
            <roleSpec>
                <topicRef xlink:href="#related-term"/>
            </roleSpec>
            <topicRef xlink:href="#literature_humanities"/>
        </member>
        <member id="16743">
            <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.

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.

NOTE:

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.

Figure 15: The Topic Per Concept Thesaurus Pattern
[Link to open this graphic in a separate page]

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.

Table 2
Diagram Class Name Subject Identifier
Concept http://www.techquila.com/psi/thesaurus/#concept
Broader-Narrower http://www.techquila.com/psi/thesaurus/#broader-narrower
Broader Term http://www.techquila.com/psi/thesaurus/#broader-term
Narrower Term http://www.techquila.com/psi/thesaurus/#narrower-term
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
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.

Example

Figure 16: An example of a thesaurus using the Topic Per Concept Thesaurus 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">
    <topic id="narrower-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#narrower-term"/>
        </subjectIdentity>
        <baseName id="16540">
            <baseNameString>Narrower</baseNameString>
        </baseName>
    </topic>
    <topic id="related-term">
        <baseName id="16745">
            <baseNameString>Related Term</baseNameString>
        </baseName>
    </topic>
    <topic id="synonym">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#synonym"/>
        </subjectIdentity>
        <baseName id="16528">
            <baseNameString>Synonym</baseNameString>
        </baseName>
    </topic>
    <topic id="whole">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#whole"/>
        </subjectIdentity>
        <baseName id="16535">
            <baseNameString>Whole</baseNameString>
        </baseName>
    </topic>
    <topic id="part-whole">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part-whole"/>
        </subjectIdentity>
        <baseName id="16531">
            <baseNameString>Part-Whole</baseNameString>
        </baseName>
        <baseName id="16532">
            <scope>
                <topicRef xlink:href="#whole"/>
            </scope>
            <baseNameString>Has Parts</baseNameString>
        </baseName>
        <baseName id="16533">
            <scope>
                <topicRef xlink:href="#part"/>
            </scope>
            <baseNameString>Is Part Of</baseNameString>
        </baseName>
    </topic>
    <topic id="scope-note">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #scope-note"/>
        </subjectIdentity>
        <baseName id="16529">
            <baseNameString>Scope Note</baseNameString>
        </baseName>
    </topic>
    <topic id="term-warrant">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #term-warrant"/>
        </subjectIdentity>
        <baseName id="16530">
            <baseNameString>Warrant</baseNameString>
        </baseName>
    </topic>
    <topic id="literature_humanities">
        <instanceOf>
            <topicRef xlink:href="#concept"/>
        </instanceOf>
        <baseName id="16733">
            <baseNameString>literature (humanities)</baseNameString>
        </baseName>
  <baseName>
      <scope>
                <topicRef xlink:href="#non-preferred-term"/>
            </scope>
            <baseNameString>literary studies</baseNameString>
        </baseName>
        <occurrence id="16738">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000017431"/>
        </occurrence>
        <occurrence id="16734">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000012941"/>
        </occurrence>
    </topic>
    <topic id="related-terms">
        <baseName id="16746">
            <baseNameString>Related Terms</baseNameString>
        </baseName>
    </topic>
    <topic id="broader-narrower">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #broader-narrower"/>
        </subjectIdentity>
        <baseName id="16536">
            <baseNameString>Broader Term-Narrower Term</baseNameString>
        </baseName>
        <baseName id="16537">
            <scope>
                <topicRef xlink:href="#broader-term"/>
            </scope>
            <baseNameString>Specialisations</baseNameString>
        </baseName>
        <baseName id="16538">
            <scope>
                <topicRef xlink:href="#narrower-term"/>
            </scope>
            <baseNameString>Generalisation</baseNameString>
        </baseName>
    </topic>
    <topic id="humanities">
        <instanceOf>
            <topicRef xlink:href="#concept"/>
        </instanceOf>
        <baseName id="16736">
            <baseNameString>humanities</baseNameString>
        </baseName>
    </topic>
    <topic id="writings">
        <instanceOf>
            <topicRef xlink:href="#concept"/>
        </instanceOf>
        <baseName id="16749">
            <baseNameString>writings</baseNameString>
        </baseName>
        <occurrence id="16750">
            <instanceOf>
                <topicRef xlink:href="#term-warrant"/>
            </instanceOf>
            <resourceRef xlink:href="http://webapps.getty.edu/vow/
            AATSource?find=&amp;logic=AND&amp;note=&amp;page=1&amp;sourceid=2000042061"/>
        </occurrence>
    </topic>
    <topic id="non-preferred-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/
            #non-preferred-term"/>
        </subjectIdentity>
        <baseName id="16527">
            <baseNameString>Non-Preferred Term</baseNameString>
        </baseName>
    </topic>
    <topic id="concept">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#concept"/>
        </subjectIdentity>
        <baseName>
            <baseNameString>Concept</baseNameString>
        </baseName>
    </topic>
    <topic id="document_genres">
        <instanceOf>
            <topicRef xlink:href="#concept"/>
        </instanceOf>
        <baseName id="16751">
            <baseNameString>document genres</baseNameString>
        </baseName>
    </topic>
    <topic id="part">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#part"/>
        </subjectIdentity>
        <baseName id="16534">
            <baseNameString>Part</baseNameString>
        </baseName>
    </topic>
    <topic id="broader-term">
        <subjectIdentity>
            <subjectIndicatorRef xlink:href="http://www.techquila.com/psi/thesaurus/#broader-term"/>
        </subjectIdentity>
        <baseName id="16539">
            <baseNameString>Broader</baseNameString>
        </baseName>
    </topic>
    <association id="literature_humanities_16494">
        <instanceOf>
            <topicRef xlink:href="#broader-narrower"/>
        </instanceOf>
        <member>
            <roleSpec>
                <topicRef xlink:href="#narrower-term"/>
            </roleSpec>
            <topicRef xlink:href="#literature_humanities"/>
        </member>
        <member>
            <roleSpec>
                <topicRef xlink:href="#broader-term"/>
            </roleSpec>
            <topicRef xlink:href="#humanities"/>
        </member>
    </association>
    <association id="writings_16494">
        <instanceOf>
            <topicRef xlink:href="#broader-narrower"/>
        </instanceOf>
        <member>
            <roleSpec>
                <topicRef xlink:href="#narrower-term"/>
            </roleSpec>
            <topicRef xlink:href="#writings"/>
        </member>
        <member>
            <roleSpec>
                <topicRef xlink:href="#broader-term"/>
            </roleSpec>
            <topicRef xlink:href="#document_genres"/>
        </member>
    </association>
    <association id="a1">
        <instanceOf>
            <topicRef xlink:href="#related-terms"/>
        </instanceOf>
        <member id="16742">
            <roleSpec>
                <topicRef xlink:href="#related-term"/>
            </roleSpec>
            <topicRef xlink:href="#literature_humanities"/>
        </member>
        <member id="16743">
            <roleSpec>
                <topicRef xlink:href="#related-term"/>
            </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 (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 a model for thesaurii which preserves each individual term as a separate topic in the topic map.

PSIs for the thesaurus patterns

This section presents the current subject indicators defined for the thesaurus patterns. This is provided for reference only. The most recent version of these published subject indicators can be found online at http://www.techquila.com/psi/thesaurus/

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.

Figure 17: The Hierarchical Classification Pattern
[Link to open this graphic in a separate page]

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 “Classification” and “Instance” types can be ommitted from this pattern where classification is not the purpose of the hierarhcy.

PSIs for the Hierarchical Classification Pattern

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

Table 3
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

See the example for the Faceted Classification Pattern.

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. [MURRAY02] 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:

  1. Which topic represents the root of the facet classification.
  2. 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.

Figure 18: The Faceted Classification Pattern
[Link to open this graphic in a separate page]

PSIs for the Faceted Classification Pattern

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

Table 4
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

Figure 19: Example of the Faceted Classification Pattern
<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

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

  <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 -->
  <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 <acronym>PSI</acronym> 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 type -->
  <topic id="wine-of-varietal">
    <baseName>
      <baseNameString>Wine Varietal</baseNameString>
    </baseName>
  </topic>

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

  <!-- Wine classes -->
  <topic id="all-wines">
    <baseName><baseNameString>All Wines</baseNameString></baseName>
  </topic>

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

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

  <!-- 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>

  <!-- Wine classification relationships -->
  <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>

  <!-- Regions -->
  <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 -->

  <!-- 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>

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

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

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

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

  <topic id="duboeuf_cab_2001">
    <baseName>
      <baseNameString>Duboeuf 2001 Cabernet Sauvignon</baseNameString>
    </baseName>
  </topic>

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

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

Bibliography

[AHMED03] Ahmed, Khalil. 2003. Topic Map Patterns For Information Architecture. Techquila. http://www.techquila.com/tmsinia.html.

[GAMMA94] Gamma, Eric, Helm, Richard, Johnson, Ralph, and Vlissides, John. 1994. Design Patterns — Elements of Reusable Object-Oriented Software. Addison-Wesley.

[MURRAY02] Murray, Phil. 2002. Faceted Classificaiton of Information. KMConnection. http://www.kmconnection.com/DOC100100.htm.



Beyond PSIs

Kal Ahmed [Techquila]
kal@techquila.com