This document presents a sequence of UML diagrams and text that capture and explain the XTM model. It begins with a UML fragment that explains a pattern that is used throughtout the model. Next, this fragment is re-used to capture other aspects of the model. Each aspect is described in supporting prose. To provide a more concrete understanding of the model a instance diagram is created that adheres to the UML class daigram. This instance diagram is created for a given piece of existing TopicMap syntax. Following the instance diagram is the explanation of a rule that is subsequently applied to the model in order to achieve a simplification. The simplification itself is then presented and described.
This UML fragment is the one that was presented at the Swindon XTM meeting. TopicMaps are a very self referencing thing and to this end there needs to be a degree of closure to the model. This closure is achieved by having a common grounding for those aspects that are involved in self referential activities or share common structures. An example of this is that in the ISO1350 Model there are different ways of apply type, scope and names to things even though these structures are common, likewise to be able to make reified statements such as those in RDF it is necessary to be able to have Topic Associations reference Topic Associations instead of only topics.
The UML fragment explains a pattern whereby aspects of TopicMaps such as occurrence and scope are modelled as associations between aspects. What this ends up doing is creating handles onto things such as occurrences that can then be used in saying something about them, e.g. if an occurrence is a TopicAssociation and type is a topic association then it is possible to assign a type to an occurrence by another association of type 'type' that associates the occurrence association (associations can now be end points in other associations) and the topic which is its type. The simplicity of this approach means that it is easy to say things about other things in the model and it can all happen in a consistent way. Names, scope and type are all assigned in the same way even when being applied to nominally different aspects.
(Note: In this diagram, for CMTopic, read Topic; for CMTopicOccurrence, read TopicAssociation, and for CMTopicAssociation, read CMTopicOccurrence.)
What this model is missing is the actual assocend classes and the correct forms of multiplicity. However all of these details are captured in the occurrence part of the model below. What this diagram does show is how aspects of TopicMaps are modelled as associations, that topics are not links and that associations are topics.
The rest of this document explains how this approach can be applied to all the aspects of TopicMaps and includes an instance diagram to show how the model is used for real.
This section shows the complete XTM topic map model via a number of UML digrams and prose.
This main class hierarchy shows the key aspects that a topic is a subclass of resource, that a topicassociation is a subclass of topic, that a role (assoc end/ link end) is also a subclass of topic. The subtypes of AssociationRole are not shown in this diagram, to avoid clutter, but they are implicit. Specific subtypes of AssociationRole appear explicitly in the diagrams that follow.
Topic identity is about the association of a number of resources that in some way aim to disambiguate the intention of the topic as to the subject that the topic is a proxy for. In this model the topicassociation is refined as a topic identity association between a topic and a number of resources. Because topicassociation inherits from link and the roles inherit from link ends it is possible to link topics to resources in this standard way.
Here topic occuurrence is a subclass of topic association. In this model the resource being associated with a topic is represented in the model as a topic itself. Topics that are instantiations of resources are referred to as resourcedtopics. Because topicoccurrence is a subclass of topicassociation and thus topic it is possible to say other things about it, namely give it a name, a type and assign it in some scope.
Naming is something that occurs in a number of places in XTM and there is a need to have a common naming mechanism. In addition, making names resources gives them appropriate first class status in this model similar in fact to RDF. Names can be assigned to different aspects of the model by creating a naming association between the name resource and the topic map construct to be named.
Scope is modelled as a topic associated between topics that are the scoping topics and other end points that are the topic map constructs to whom scope is applicable, occurrences, names and association roles.
The class instance relationship is the clarification of type from ISO13250. ClassInstance is modelled as a subclass of topic association where the end points subclass assoc role in order to describe the semantic that the topics play in the classinstance association. Note: a decision was made that using subclassing was a more powerful way of capturing the operational intent and semantics of topic maps as opposed to public subjects. Public subjects are still reliant on prose and have no model to guide implementations. By capturing the intent formally there is no opportunity for misinterpreting the intent. Public subjects are a great mechanism for user defined extensions but are not suitable for capturing the core model.
This model semantic is missing from ISO13250 but recognised as being essential in XTM. Here it is modelled as a subclass of topic association and the roles subclass association roles, again to capture the semantic intent of the model.
These few UML diagrams capture the essential model of topic maps in a clean manner. This model has the property of closure and structure re-use (there is only one way to name things, type things, scope things). In the next section an example is given that uses this model to create a XTM instance diagram from an syntax fragment.
This section shows how an instance diagram is created from a syntax fragment. The instance model corresponds to the conceptual model described above.
<topic id="t1" identity="http://www.empolis.com/xtm/graham_moore.html"> <tn><basename scope="t2">Graham Moore<basename><tn> <occur type="t3" href="http://www.empolis.com/graham_moore_bio.html" /> <topic>
The diagram above shows a regular model that captures the aspects of the topic map model. If we wanted, for example, to add scope onto the occurrence we could do so by creating a new scope association between the occurrence association and the topic which was the theme.
This very elegant model does appear to be overkill for the job at hand. However, it has provided us with a regular base model from which we can make considered rationalisation, refinements and simplications. These simplications follow in the next section.
to complete