The XTM Conceptual Model and its Interchange Syntax do not map to one another directly, for a number of reasons. First, the Conceptual Model describes certain objects that are not represented directly in the syntax at all. Second, there are certain objects in the Conceptual Model that may be represented in more than one way in the syntax. Third, the syntax contains some constructs that map to specific association templates that conform to the Conceptual Model but do not form part of it.
We begin by looking at each item in the Conceptual Model and show which parts of the syntax it corresponds to, if any, and in what way. The syntactic items thus identified will consititue a minimal syntax, which is complete in itself, and could be used to represent any topic map at all, though it would not be optimally concise or readable.
Then we identify syntactic constructs that represent extensions to the minimal syntax through the use of association templates. For each of these, we shall provide equivalent syntactic representations of them using the minimal syntax.
Finally, we identify syntactic constructs that represent shorter and more readable forms for certain structures, but add no additional semantics in their own right. For these too, we shall provide equivalent syntactic representations using the minimal syntax.
Based on these mappings, it will be possible to map any topic map expressed in XTM syntax can back to the Conceptual Model, though this may be a two-stage process, passing through the minimal syntax as a first stage, then using the mapping from the minimal syntax to the Conceptual Model. The mapping may also involve the invocation of one or more of public association temptes included within the XTM specification.
There are several ways in which objects described by the Conceptual Model may relate to constructs in the XTM Interchange Syntax:
We shall go through the constructs of the Conceptual Model in the order in which they are presented in the XTM specification, and will state for each one whether it has a corresponding syntactic construct, and what the nature of the correspondence is.
There are two kinds of mapping from XTM syntax to the Resource object in the Conceptual Model:
The Subject may be an Addressable Subject or a Non-addressable Subject. These two cases are dealt with below.
If the Subject is an Addressable Subject, it IS is the Resource that is REFERENCED by the xlink:href attribute of the <resourceRef> subelement of a <subjectIdentity> element
If the Subject is a Non-addressable Subject, it is INDICATED by the Resource that is REFERENCED by the xlink:href attribute of the <subjectIndicatorRef> subelement of a <subjectIdentity> element
A <topic> element REPRESENTS a Topic.
Note that the Conceptual Model describes the following subtypes of Topic:
An <association> element REPRESENTS a Topic that is an Association.
An <role> element REPRESENTS a Topic that is a Role.
Note: The <role> element is not present in the syntax presented in Washington DC. The <member> construct included in that DTD is inadequate to cover the structure of the Conceptual Model, which requires a Topic that is the Role, zero or more Topics that are the players of the Role, and optionally a topic that is a Role in an Association Template, which provides constraints on the players of the Role. The content model for <member> has only two places for references to one or more Topics, and so cannot capture the Role, the players of the Role and the Role constraints. Also, the <association> element requires an optional <associationSpec> element to reference an association template, and the <instanceOf> subelement of <association> should be repeatable. The discussion here is therefore based on the following declarations, proposed as replacements for the <association> and <member> declarations of the 4 December 2000 DTD. Note that these declarations do preserve backward compatibility with that DTD.
<!-- association: Topic Association -->
<!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+ | role+ )*)>
<!ATTLIST association id ID #REQUIRED >
<!-- associationSpec: Points to a Topic Serving as an Association Template -->
<!ELEMENT associationSpec (topicRef | subjectIndicatorRef )>
<!ATTLIST associationSpec id ID #IMPLIED >
<!-- member: Member in Topic Association -->
<!ELEMENT member (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef )+ )>
<!ATTLIST member id ID #IMPLIED >
<!-- role: Role in Topic Association -->
<!ELEMENT role (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef ) , player* )>
<!ATTLIST role id ID #IMPLIED >
<!-- player: Player of Role in Topic Association -->
<!ELEMENT player (topicRef | resourceRef | subjectIndicatorRef )>
<!ATTLIST player id ID #IMPLIED >
The xlink:href attribute of a <subjectIndicator> element REFERENCES a Resource that IS a Subject Descriptor that INDICATES the Subject of the Topic that is REPRESENTED by the parent of the <subjectIndicator> element.
A <topicMap> element REPRESENTS a Topic Map.
The <scope> subelement of an <association> or <baseName> element REPRESENTS the Topic Set that IS the Scope of the Asssociation or Base Name REPRESENTED by the parent element
In general, a Topic Set IS the set of Topics that are REPRESENTED by any set of <topic>, <association> and/or <role> elements, and/or REFERENCED by any set of xlink:href attributes on <topicRef> and/or <subjectIndicatorRef> elements.
A <scope> element REPRESENTS a Scope.
A <baseName> element REPRESENTS a Base Name.
The content of the <baseNameString> subelement of a <baseName> element IS the String assigned within the Base Name relationship REPRESENTED by that <baseName> element to the Topic REPRESENTED by its parent element within the Scope REPRESENTED by the <scope> element that is the <baseNameString> element's previous sibling.
An <association> element REPRESENTS an Association (and, has already been said, the Topic that IS that Association).
A <role> element REPRESENTS a Role (and, has already been said, the Topic that IS that Role).
A <player> element REPRESENTS a Topic that plays the Role REPRESENTED by the <role> element that is its parent.
The xml:link attribute of the <topicRef> subelement of an <associationSpec> element REFERENCES an <association> element that REPRESENTS an Association that is the template for the Association REPRESENTED by the <association> element that is the parent of the <associationSpec> element.
Note: To allow this to work, the restriction stated in the DTD of 4 December 2000 that a <topicRef> element can only reference a <topic> element, needs to be relaxed. It also needs to be allowed to reference an element whose element type is represents a subtype of Topic.
The xml:link attribute of the <topicRef> subelement of a <roleSpec> element REFERENCES a <role> element that REPRESENTS a Role in a template Association that provides the role constraints for the Role REPRESENTED by the <role> element that is the parent of the <roleSpec> element.
Note: To allow this to work, the restriction stated in the DTD of 4 December 2000 that a <topicRef> element can only reference a <topic> element, needs to be relaxed. It also needs to be allowed to reference an element whose element type is represents a subtype of Topic.
It has been argued that the <subjectIndicatorRef> element can be used instead of the <topicRef> element for this purpose, since the Subject indicated by an XTM element is always the Subject of the topic represented by that element, and therefore the Topics themselves are the same. The problem with this approach is that it requires the system to resolve the xlink:href to find a Resource, then ascertain whether that Resource is or is not an element in an XTM document, in order to know how to process it. It would be far more efficient, and consistent with the previous decision that things that are different in kind should be expressed through different syntax, to state that the <topicRef> element should always be used to reference an XTM element that directly represents the relevant Topic, and to use the <subjectIndicatorRef> element when the Topic is being referenced indirectly, by identifying its Subject through a Subject Descriptor.
If this reasoning is sound, there are two consequences:
Note: The following parts of this document are in note form. They need to be expanded to show specific syntax examples.
The <instanceOf> element is shorthand for an <association> element whose <associationSpec> subelement references the public Class Instance Association Template, containing a <role> element whose <roleSpec> subelement references the public Class Role topic and whose <player> subelement references the topic identified by the <instanceOf> element itself, and a second <role> element whose <roleSpec> subelement references the public Instance Role topic and whose <player> subelement references the parent of the <instanceOf> element.
Example needed here
The <occurrence> element is shorthand for an <association> element whose <associationSpec> subelement references the public Topic Occurrence Association Template, containing a <role> element whose <roleSpec> subelement references the public Occurrence Role topic and whose <player> subelement references the topic identified by the <occurrence> element itself, and a second <role> element whose <roleSpec> subelement references the public Topic Role topic and whose <player> subelement references the parent of the <occurrence> element.
Example needed here
The exact structures for which <variant>, <variantName> and <parameters> are syntactic shorthand needs to be specified.
Note: The following parts of this document are in note form. They need to be expanded to show specific syntax examples.
The <subjectIndicatorRef> subelement of any element other than a <topic> element is syntactic shorthand for a <topicRef> element pointing to a <topic> element that itself has that <subjectIndicatorRef> as a subelement of its <subjectIdentity> subelement.
The <resourceRef> subelement of any element other than a <topic> element is syntactic shorthand for a <topicRef> element pointing to a <topic> element that itself has that <resourceRef> as a subelement of its <subjectIdentity> subelement.
Note: It is difficult to see how what a <resourceRef> subelement on <scope> would mean. What does it mean to be in the scope of a resource? Ditto for a <resourceRef> subelement on <mergeMap>, since if a <resourceRef> makes no sense on a <scope>, it makes no sense to add it to a <scope> when merging.
The <member> element is syntactic shorthand for a <role> element and its <player> subelement. It can only be used when there is no need to specify the Topic that is the Role itself.
Note: This is only included to ensure backward compatibility with topic maps that were created on the basis of the Core Deliverables presented on 4 December 2000 in Washington. If the requirement for such compatibility is dropped, then the <member> element can be droped also.
The <mergeMap> elemente is syntactic shorthand for the explicit inclusion of all the subelements of the <topicMap> element referenced by its xlink:href attribute, with the addition to every <scope> element of the all the subelements of the <mergeMap> element.