 |
|
|
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.
Table of Contents
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.
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.
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.
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.
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.
The UML notation for topic map diagrams developed here is based entirely upon UML notation for static structures.
Topics are represented by the 3-segment box notation used to represent a class. The name in the top segment of the box gives the name of the topic type. Unlike a UML class diagram, in the topic map diagram there is not necessarily a direct correlation between the name given to the topic class and the name as it is represented in a topic map. When describing a pattern that uses PSIs for identifying classes of topic, the documentation should make clear the relationship between the class names shown in the diagram and the subject identifiers specified by the PSIs.
The following diagram shows an example of a topic as represented in the topic map class notation.
Occurrences and BaseNames are represented with the same class notation as topics. As with the Topic notation, the name of the class relates directly to the topic used to define the class of occurrences or names that the instance belongs to. To distinguish the three different uses of the class notation, we use a class stereotype.
To show that a particular class of topic may or should have occurrences or names of a particular type, use the UML aggregation notation.
The line with a open diamond at the end is drawn from the topic class to the occurrence or name class. We can use the multiplicity label next to the diamond to show how many of these occurrences or names a topic of the class should have. The following diagram shows that a topic of type "Person" may have zero or more occurrences of type "Email Address".
The class notation can also be used to represent classes of association by additionally making use of the UML notation for association classes. The association itself is represented as a solid line joining the role-playing classes. The roles played are annotated against the line along with any cardinality constraints imposed by the association class. The association class is represented by a three segment box connected to the association by a dotted line.
The following diagram shows a "Works For" association type which is expressed as a binary association between and instance of the "Person" class playing the role of "Employee" and an instance of the "Company" class playing the role of "Employer". The association is constrained to require exactly one instance of each role player in such an association.
N-ary associations are also supported by UML class diagram notation. In this case, rather than having a single solid line, the association is represented by an open diamond shape with the role-playing classes connected to the diamond by solid lines. The class of the association is represented with a dotted line from the diamond to the association class.
For example, the following diagram shows a 3-way association describing the "Plays For" association type which consists of roles "Goalkeeper", "Team", and "Season" played by instances of the class "Person", "Team" and "Year" respectively.
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".
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".
The topic map class diagram notation must support the specification of scope applied to topic names, occurrences and associations. This requirement is met by defining a stereotype named "scope" which can be applied to a UML association (represented in class diagrams as an open diamond shape) and a stereotype "theme" which can be applied to a UML association link (represented in class diagrams as the line from the association to one of the associated classes).
The stereotyped Association can then be applied to the aggregation links used between a Topic class and a BaseName or Occurrence class; and the AssociationEnds with the stereotype "theme" can be used to apply the themes. The diagram below documents that a "Film" topic has zero or more "Rating" occurrences, each of which may be scoped by a single theme which is itself an instance of the "Reviewer" class.
For a scoped association, there is a problem because it does not make sense from a UML perspective to create an association with an association at one of its ends. To work around this, the topic map diagramming notation just adds the extra theme-sterotyped association ends directly to the association being scoped and does away with the scope stereotype on the association. The diagram below documents that a "Film" topic plays the role "RatedThing" in a "HasRating" association with a "Rating" topic playing the role "RatingGiven" and that this association is scoped by a single topic of type "Reviewer".
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.
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.
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.
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.
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>Figure 12. Example Of The Hierarchical Naming Pattern
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).
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.
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.
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.
The following Published Subject Identifiers are used by the Hierarhcical 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 |
Table 1.
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.
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.
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.
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).
http://www.techquila.com/psi/classification/#classification
The role played by a topic representing a class in a classification scheme.
http://www.techquila.com/psi/classification/#instance
The role played by a topic representing a subject which is classified under a classification scheme.
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>Figure 14. Example of the Hierarchical Categorisation Pattern
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.
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.
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 [AHMED03] 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.
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.
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 |
Table 2.
The Published Subject Indicators for each identifier are presented below.
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.
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.
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.
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.
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.
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.
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.
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.
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.
http://www.techquila.com/psi/thesaurus/#related-term
The base type for roles played in associations of the type Term Relationship. Role players must be instances of the Term type.
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.
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.
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.
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.
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.
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.
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.
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.
