Associations represent the relationship between two or more topics. An association consists of two parts. Firstly there is the association itself: this defines the nature of the relationship between all of the associated topics. As with occurrences, associations can be typed by a single type-specifying topic. It is this type that defines the nature of the relationship indicated by the association. Secondly, the association consists of a number of players, each of which is a topic and which plays a role in the association that is in turn described by another topic.
Let us build up an example association showing a relationship between Redmond Computers Inc. and an employee, John Smith. We can start by creating a simple association between the topic representing the company and the topic representing John Smith. This is shown in Sample 11
<topicMap>
<topic id="rci">
<baseName>
<baseNameString>Redmond Computers Inc.</baseNameString>
</baseName>
</topic>
<topic id="john-smith">
<baseName>
<baseNameString>John Smith</baseNameString>
</baseName>
</topic>
<association>
<member>
<topicRef xlink:href="#rci"/>
</member>
<member>
<topicRef xlink:href="#john-smith"/>
</member>
</association>
</topicMap>
Sample 11 - A simple association
As with our first topic example, this sample barely conveys any information at all. It states that there is some relationship between something called "Redmond Computers Inc." and something called "John Smith" but does not say anything about the nature of the relationship nor about what roles each partner plays in the relationship. Once again, this information is conveyed by topics. It is the type of the association that defines the nature of the relationship. The association type is defined using an <instanceOf> element. Each member of the relationship can be given a specific role using a <roleSpec> element. This is shown in Sample 12.
<topicMap>
<topic id="employs">
<baseName>
<baseNameString>Employs</baseNameString>
</baseName>
</topic>
<topic id="employer">
<baseName>
<baseNameString>Employer</baseNameString>
</baseName>
</topic>
<topic id="employee">
<baseName>
<baseNameString>Employee</baseNameString>
</baseName>
</topic>
<topic id="rci">
<baseName>
<baseNameString>Redmond Computers Inc.</baseNameString>
</baseName>
</topic>
<topic id="john-smith">
<baseName>
<baseNameString>Redmond, Washington</baseNameString>
</baseName>
</topic>
<association>
<instanceOf>
<topicRef xlink:href="#employs"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#employer"/>
</roleSpec>
<topicRef xlink:href="#rci"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#employee"/>
</roleSpec>
<topicRef xlink:href="#john-smith"/>
<!-- additional topicRefs to other employees
can go in here -->
</member>
</association>
</topicMap>
Sample 12 - A typed association
Now we can see far more information. There is type of the relationship is labelled as "Employs", and the contributions made by the topics of "Redmond Computers Inc." and "John Smith" are characterised as "employer" and "employee" respectively. In fact, the naming of these topics can be misleading - it is easy to assume from this association that the relationship is a one-way relationship from "Redmond Computers Inc." to "John Smith"; whereas, in fact, the association simply groups together the topics which play roles in it, without implying any ordered relationship between them. This aggregation property of the association is part of what gives the topic map paradigm its extraordinary power. From the topic of "Redmond Computers Inc." it might be possible to list all of the associations of the type "Employs" in which it plays the role of "Employer", and so get a company directory listing. Equally by following associations of type "Employs" from "John Smith" in which that topic plays the role of "Employee", we might get a complete employment history for this person.
If I wanted to list a number of employees in the same association construct, this is allowed in XTM syntax. I can either add another <member> element with its child <roleSpec> and <topicRef> elements or I can simply add another <topicRef> to the existing <member> element for the role of "employee". This latter option is a syntactic short cut for allowing multiple players of the same role in the same association to be specified.
One common issue when creating topic maps is how to label associations. Unlike topics, associations do not have any mark-up for specifying a label for each instance. Instead, many topic map applications will use the label of the topic that defines the type of the association. Very often the labels for associations in a topic map will be verbs, for example "Redmond Computers Inc. employs John Smith", but these verbs imply a direction to the association. Many topic map practitioners give the topic that types the association a label for each role that the association supports and then scope those labels by the topic that defines the role (the topic referred to from the <roleSpec> element). The logical conclusion of this approach with a simple binary association such as the one in our sample is to assign three separate names to the topic which defines the association type. In the unconstrained scope, the association type should be named with a noun such as "Employment". The use of a noun frees the name from the context of one or other of the roles in the association. The two other names should be verbs using the roles as the context for the name and the role types to define the scope of each name.
This is shown in Sample 13. In this sample, the label "Employment" is created in the unconstrained scope to be treated as the default name for the topic; the label "Employs" is to be used in the context of the employer and so is scoped by the topic "Employer"; similarly the label "Employed By" is scoped by the topic "Employee". An application may then use the role played by the topic currently in focus in the application as part of the user context when determining which is the best name to be applied, so in the context of "John Smith" playing the role of "Employee", the application would select the label "Employed By".
<topicMap>
<topic id="employs">
<baseName>
<baseNameString>Employment</baseNameString>
</baseName>
<baseName>
<scope>
<topicRef xlink:href="#employer"/>
</scope>
<baseNameString>Employs</baseNameString>
</baseName>
<baseName>
<scope>
<topicRef xlink:href="#employee"/>
</scope>
<baseNameString>Employed By</baseNameString>
</baseName>
</topic>
<topic id="employer">
<baseName>
<baseNameString>Employer</baseNameString>
</baseName>
</topic>
<topic id="employee">
<baseName>
<baseNameString>Employee</baseNameString>
</baseName>
</topic>
<topic id="rci">
<baseName>
<baseNameString>Redmond Computers Inc.</baseNameString>
</baseName>
</topic>
<topic id="john-smith">
<baseName>
<baseNameString>John Smith</baseNameString>
</baseName>
</topic>
<association>
<instanceOf>
<topicRef xlink:href="#employs"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#employer"/>
</roleSpec>
<topicRef xlink:href="#rci"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#employee"/>
</roleSpec>
<topicRef xlink:href="#john-smith"/>
</member>
</association>
</topicMap>
Sample 13 - Labelling a typed association
Of course, it is sometimes useful or necessary to attach other information to a specific association. We will look at how to do that later.
Just as we use scope to express the context within which a name or occurrence of a topic is valid, so we can also use scope to express the context within which an association is valid. The <scope> mark-up itself is exactly the same as that used for <baseName> and <occurrence> elements, and the mark-up appears as an optional child of the <association> element.
As an example, let us suppose that a rumour of merger talks between two companies is to be represented in the topic map. One way to do this would be to create a distinct association type, but we would then need to create a distinct type for every rumoured association. An alternative method would be to scope the association by a topic that indicates that the context for the association is that of "rumour". This is shown in Sample 14, below:
<topicMap>
<topic id="rumour"/>
<topic id="merger"/>
<topic id="merge-partner"/>
<topic id="companyA"/>
<topic id="companyB"/>
<association>
<instanceOf><topicRef xlink:href="#merger"/></instanceOf>
<scope><topicRef xlink:href="#rumour"/></scope>
<member>
<roleSpec><topicRef xlink:href="#merge-partner"/></roleSpec>
<topicRef xlink:href="#companyA"/>
<topicRef xlink:href="#companyB"/>
</member>
</association>
</topicMap>
Sample 14 - Using scope for an association
| Up: Topic Map Basics | |
| Previous: Topic Merging | Next: Adding Detail By Reification |