XML Topic Maps (XTM)

1. Introduction

This specification defines XML constructs that can be used to define a set of related topics that provide named sets of occurrences of resources that are relevant to a particular subject. In addition it provides mechanisms for defining associations between topics, and characteristics that can be used to subset topics and associations so that user can see different facets (views) of the subject.

This specification defines a concrete representation, expressed in XML, of the general SGML architecture for topic maps defined in ISO/IEC 13250. It provides both a concrete syntax for the expression of topics and associations based on the use of XML Pointers and the XML Linking Language and a mechanism whereby application-specific elements can be declared to be topic map components.

Introduction to Topic Maps (from ISO/IEC 13250)

The Topic Map International Standard provides a standardized notation for interchangeably representing information about the structure of information resources used to define topics, and the relationships between topics. A set of one or more interrelated documents that employs the notation defined by this International Standard is called a "topic map". In general, the structural information conveyed by topic maps includes:

• groupings of addressable information objects around topics (occurrences), and
• relationships between topics (associations).

A topic map defines a multidimensional topic space -- a space in which the locations are topics, and in which the distances between topics are measurable in terms of the number of intervening topics which must be visited in order to get from one topic to another, and the kinds of relationships that define the path from one topic to another, if any, through the intervening topics, if any.

NOTE: Two topics may be connected through an association, and they can also be connected by virtue of sharing an occurrence.

In addition, information objects can have properties, as well as values for those properties, assigned to them externally. These properties are called "facet types".

NOTE: The word "facet" can mean one side of a many-sided, polished object, or one segment of a compound eye (e.g. an insect's). Its metaphorical use here captures the idea that a facet is a property of a set of information objects that can be used to create a view of them.

Several topic maps can provide topical structure information about the same information resources. The Topic Maps architecture is designed to facilitate merging topic maps without requiring the merged topic maps to be copied or modified. Because of their extrinsic character, topic maps can be thought of as "overlays" on, or extensions to, sets of information objects.

Intoduction to XML Links (from W3C specification)

The XML Linking Language (XLink) specification defines constructs that may be inserted into XML DTDs and document instances to describe links between resources. A link, as the term is used here, is an explicit relationship between two or more resources or portions of resources. The XLink specification is concerned with the syntax used to assert link existence and describe link characteristics.

XLink is a mechanism for asserting link relationships using elements contained in XML document instances. A simple case of establishing a link relationship within an XML document is the ID/IDREF mechanism. This mechanism is described in the XML 1.0 Recommendation, and is thus out of scope for XLink, but this specification provides a mechanism that extends this basic capability in a number of ways:

• XLinks asserts relationships among multiple resources.
• XLinks provide an explicit mechanism to associate meta-data with the link.
• XLinks provide additional functionality, such as out-of-line links.

An important application of XLinks is in hypertext systems. For the purpose of this specification, "hyperlinks" are considered to be those links that are meaningful, frequently for direct use by end users. This specification defines hypertext meta-data that can be associated with a link.

A simple hyperlink case is an HTML A element, which has these characteristics:

• The hyperlink is expressed at one of its ends.
• The hyperlink identifies the one other end (although a server may have great freedom in finding or dynamically creating that destination.)
• Users can only initiate travel from the hyperlink.
• The hyperlink's effect on windows, frames, go-back lists, stylesheets in use, and so on is determined by user agents, not by the hyperlink itself. For example, traversal of A links normally replaces the current view, perhaps with a user option to open a new window.

While this set of characteristics is already very powerful and obviously has proven itself highly useful and effective, each of these assumptions also limits the range of hypertext functionality. The hyperlinking model defined in the XLinks specification provides ways to create hyperlinks that go beyond each of these specific characteristics, thus providing features previously available mostly in dedicated hypermedia systems.

1.1 Document Conventions

Topic Maps are defined in ISO/IEC 13250 as an SGML document architecture whose definition conforms to the Architectural Form Definition Requirements in Normative Annex A.3 of ISO/IEC 10744:1997, the "SGML Architectural Form Definition Requirements" (AFDR). The formal definition of the topic map notation is expressed as a meta-DTD. The specification of the Topic Maps architecture is accomplished by a combination of narrative text and formal definitions.

In this document the topic map architecture is expressed in terms of both a fixed set of predefined XML elements, and as a set of namespace-controlled architectural forms that can be applied to an element with an applicaton-defined name. Application developers can choose to retain the element names defined in the specification or can use name-spaced attributes to identify the use of the constructs with elements with application-dependent names, but may not mix both approaches. When the predefined element names are used application-dependent extensions can only be made at points indicated in the content model of the predefined elements.

Location of elements within an XML Topic maps is defined through a set of rules for defining XML locations as Unique Resource Locators (URLs) taken from the XML Linking Language specification.

Wherever possible the text of this document is a copy of the relevant clause of the standard or specification it is derived from, with modifications to cover its use within an XML Topic Maps environment, and with the addition of examples where appropriate. The code productions within the text are derived from the standard, but are expressed in an XML conformant form. The code productions have been moved to the start of each section, preceding the description of their components, to conform with W3C documentation style.

1.2 Origin and Goals

The goals and objectives of this specification are to represent in XML the functions provided in SGML by International Standard 13250. The goals of this standard are stated within its Scope statement as:

"Topic maps enable multiple, concurrent views of sets of information objects. The structural nature of these views is unconstrained; they may reflect an object oriented approach, or they may be relational, hierarchical, ordered, unordered, or any combination of the foregoing. Moreover, an unlimited number of topic maps may be overlaid on a given set of information resources.

Topic maps can be used:

• To qualify the content and/or data contained in information objects as topics to enable navigational tools such as indexes, cross-references, citation systems, or glossaries.
• To link topics together in such a way as to enable navigation between them. This capability can be used for virtual document assembly, and for creating thesaurus-like interfaces to corpora, knowledge bases, etc.
• To filter an information set to create views adapted to specific users or purposes. For example, such filtering can aid in the management of multilingual documents, management of access modes depending on security criteria, delivery of partial views depending on user profiles and/or knowledge domains, etc.
• To structure unstructured information objects, or to facilitate the creation of topic-oriented user interfaces that provide the effect of merging unstructured information bases with structured ones. The overlay mechanism of topic maps can be considered as a kind of "external markup mechanism", in the sense that an arbitrary structure is imposed on the information without altering its original form."

1.3 Relationship to Existing Standards

In addition to ISO/IEC 13250 three standards have been especially influential in the development of this specification, and the standards it is based on:

• HyTime (ISO/IEC 10744): Defines inline and out-of-line link structures and some semantic features, including traversal control and presentation of objects. Forms the theoretical basis for both ISO/IEC 13250 and the XML Linking Language (XLink).
• XML Linking Language (XLink): Provides mechanisms for creating links, aggregate objects, and link collections out of them, using the W3C Extensible Markup Language (XML)
• XML Pointer Language (XPointer): Provides mechanisms for identifying specific parts of Internet resources.

1.4 Terminology

The following terms are defined in ISO/IEC 13250 (modified here as necessary to allow for the use of the term in an XML rather than an SGML/HyTime environment):

added themes

Topics added to the sets of themes comprising the scopes within which topics have their topic characteristics. Added themes can be specified in two ways:

1. Within the topic map document whose scopes are affected, by means of the added themes (addthems) attribute of the document element. The specified themes are added to the scopes of all of the topic characteristics which are assigned to topics via the topic links and association links contained in the document.
2. Inside or outside the topic map document whose scopes are affected, by means of elements conforming to the themes to be added (AddedThemes) architectural form. The specified themes are added to the topic characteristics assigned to topics via:
   • entire topic map documents (specified via the tmdocs attribute),
   • topic links (that is, the name characteristics and occurrence characteristics assigned to topics via topic links) (specified via the cassign attribute),
   • association links (that is, the roles played in associations by topics, as assigned to topics via association links) (specified via the cassign attribute, or any combination of the foregoing.

association

See "topic association".

association link

A hyperlink element conforming to the association link architectural form defined by this International Standard.

association role

One of the roles that topics play in a given topic association.

association type

1. A subject which is a class of topic associations.
2. One of the classes of topic associations of which a particular association link is an instance. The association types of which a given association link is an instance can be specified by its optional types attribute.

base name

1. A subelement (BaseName) of a TopicNames subelement of a topic link.
2. A name characteristic of a topic that is specified in the content of a BaseName element.

display name

1. A subelement (DisplayedAs) of a TopicNames subelement of a topic link, containing the identifying information intended to be displayed by the application to represent the subject of the topic link.
2. A name characteristic of a topic that is specified in the content of a DisplayedAs element.

facet

1. The subset of information objects that share an externally-applied property.
2. The values given to a particular property externally applied to a set of information objects.

facet link

A hyperlink that applies values for a given property (as well as the property itself) to one or more information objects.

facet type

A property applied by one or more facet links to one or more objects.

facet value

A member of the set of all values of a particular facet type.

occurrence role

The sense in which some set of occurrences is relevant to a topic. In the Topic Maps architecture, occurrence roles are specified as anchor roles (as defined in the HyTime architecture) of topic links.

public subject descriptor

A subject descriptor (see the definition of "subject descriptor") which is used (or, especially, which is designed to be used) as a common referent of the identity attributes of many topic links in many topic maps. The subject described by the subject descriptor is thus easily recognized as the common binding point of all the topic links that reference it, so that they will be merged.

scope

The extent of the validity of a topic characteristic assignment (see the definition of "topic characteristic assignment"): the context in which a name or an occurrence is assigned to a given topic, and the context in which topics are related through associations. This International Standard does not require that scopes be specified explicitly. If the scope of a topic characteristic assignment is not explicitly specified via one or more scope attributes, the scope within which the topic characteristic applies to the topic includes all the topics in the entire topic map; this special scope is called "the unconstrained scope". If a scope is specified, the specification consists of a set of topics, which, in the context of their role as members of such a set, are called "themes". Each theme contributes to the extent of the scope that the themes collectively define; a given scope is the union of the subjects of the set of themes used to specify that scope.
NOTE: If it is desired to specify a scope which is the intersection (rather than the union) of two topics, this can be accomplished by creating a topic whose subject is that intersection, and then by using that topic as a theme.

sort key

sort name

1. A subelement (SortName) of a TopicNames subelement of a topic link, containing a string that is an alternative representation of a topic name that is intended to be used for alphabetic or other ordering.
2. A name characteristic of a topic that is specified in the content of a SortName element.

subject

In the most generic sense, a "subject" is anything whatsoever, regardless of whether it exists or has any other specific characteristics, about which anything whatsoever may be asserted by any means whatsoever.
NOTE: The invisible heart of every topic link is the subject that its author had in mind when it was created. In some sense, a topic link reifies a subject. The identity attribute of a topic link is provided to allow the author of the topic link to indicate, as unambiguously as possible, the subject he had in mind as the organizing principle of the topic. See the definition of "subject descriptor".

subject descriptor

Information which is intended to provide a positive, unambiguous indication of the identity of a subject, and which is the referent of an identity attribute of a topic link. (See also the definition of "public subject descriptor".)
NOTE: There is no requirement that a subject descriptor be text, although it can be the text of a definition of the subject. It can also, for example, be a listing in a catalog of subjects, such as an acquisition number of an asset in a museum collection, a catalog number in a sales catalog, or a subject heading in a catalog of library subject headings. The distinction between a subject descriptor that happens to be a definition and an ordinary occurrence of a definition is that, in the case of the subject descriptor, the topic link's author has indicated (by referring to it by means of the value of the identity attribute) that it is to be regarded as the authoritative definition of the organizing principle of the topic link. In the other case, by characterizing a definition as a definitional occurrence, the author is merely acknowledging the existence of the definition and its possible relevance to the subject of the topic link. Subject descriptors may be offline resources.

theme

A member of the set of topics comprising a scope within which a topic characteristic assignment is valid. See also the definitions of "scope" and "topic".

topic

1. An aggregate of topic characteristics, including zero or more names, occurrences, and roles played in associations with other topics, whose organizing principle is a single subject.
2. A topic link element.

topic association

1. A specific relationship among specific topics that is asserted by an association link element.
2. An association link element.

topic characteristic

Any defining characteristic of a topic. There are three kinds of topic characteristics:

1. names,
2. occurrences, and
3. roles played in relationships ("associations") with other topics.

For example, a name of a topic is a "name characteristic" of that topic.

topic characteristic assignment

1. The mechanism whereby a topic characteristic becomes a characteristic of a topic. For example, TopicNames subelements of topic link elements are used to assign names to topics as topic characteristics, so, in topic map documents, they perform the function of assigning topic name characteristics.
2. The fact that a particular topic characteristic is a characteristic of a particular topic.

topic link

A hyperlink element conforming to the topic link architectural form.
NOTE: See also the definition of "topic".

topic map

1. Any topic map document conforming to the architecture defined by the International, or the document element (TopicMap) of such a document.
2. The document element type (TopicMap) of the topic map document architecture.

topic name

1. A string of characters specified as a name of a topic; a name characteristic of a topic.
2. A topic name (TopicNames) element, as defined by this specification.
3. Either a base name (BaseName), display name (DisplayedAs) or name to be used as sort key (SortName) element, as defined by this specification, and/or the information that such an element contains.
4. A combination of the foregoing definitions.

topic occurrence

Information that is specified as relevant to a given subject.

topic type

1. A subject which is a class of topics.
2. One of the classes of topics of which a particular topic link is an instance. The topic types of which a given topic link is an instance can be specified via its optional types attribute.

unconstrained scope

The scope comprised of all of the topics in a topic map. When no applicable scope attributes are explicitly specified as governing a topic characteristic assignment, the scope within which the topic characteristic assignment is made is the unconstrained scope.
NOTE 12: In other words, the unconstrained scope is the default scope. Thus, for example, in a given topic map, if no scope attributes are explicitly specified for the name characteristics of any topics, any two topic links that have any of the same names will be merged, due to the effect of the topic naming constraint.

The following terms are defined in the W3C XML Linking Language specification:

arc

A symbolic representation of traversal behavior in links, especially the direction, context and timing of traversal.

element tree

A representation of the relevant structure specified by the tags and attributes in an XML document.

hyperlink

An explicit relationship between two or more data objects or portions of data objects with an eye to presentation and traversal in user interfaces.

inclusion

The process of traversing a link for the purpose of copying the target element tree into the source element tree.

inline link

Abstractly, a link which serves as one of its own resources. Concretely, a link where the content of the linking element serves as a participating resource.

link

An explicit relationship between two or more data objects or portions of data objects.

linking element

An element that asserts the existence and describes the characteristics of a link.

local resource

The content of an inline linking element. Note that the content of the linking element could be explicitly pointed to by means of a regular locator in the same linking element, in which case the resource is considered remote, not local.

locator

Data, provided as part of a link, which identifies a remote resource.

multidirectional link

A link whose traversal can be initiated from more than one of its participating resources. Note that being able to "go back" after following a one-directional link does not make the link multidirectional.

out-of-line link

A link whose content does not serve as one of the link's participating resources . Such links presuppose a notion like extended link groups, which instruct application software where to look for links. Out-of-line links are generally required for supporting multidirectional traversal and for allowing read-only resources to have outgoing links.

participating resource

A resource that belongs to a link. All resources are potential contributors to a link; participating resources are the actual contributors to a particular link.

remote resource

Any participating resource of a link that is pointed to with a locator.

resource

In the abstract sense, an addressable unit of information or service that is participating in a link. Examples include files, images, documents, programs, and query results. Concretely, anything reachable by the use of a locator in some linking element. Note that this term and its definition are taken from the basic specifications governing the World Wide Web, such as IETF RFCs [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808].

sub-resource

A portion of a resource, pointed to as the precise destination of a link. As one example, a link might specify that an entire document be retrieved and displayed, but that some specific part(s) of it is the specific linked data, to be treated in an application-appropriate manner such as indication by highlighting, scrolling, etc.

traversal

The action of using a link; that is, of accessing a resource. Traversal may be initiated by a user action (for example, clicking on the displayed content of a linking element) or occur under program control.

2. Locator Syntax

The locator for a resource within an XML Topic Map must be provided by means of a Uniform Resource Identifier reference, or URI-reference [IETF RFC 2396]. A URI-reference is a URI [IETF RFC 2396], [IETF RFC 1738] and [IETF RFC 1808] with an optional fragment identifier separated from the URI by a crosshatch ("#") character. For locators into XML resources, the fragment identifier format is specified by the XPointer specification.

3. The Topic Map Element

The topic map (TopicMap) element can be used as the document element of documents that conform to this specification. Its formal definition is:

<!-- AddedElements: Elements added for use within a specific topic map.
Defaults to no added elements.-->
<!ENTITY % AddedElements "" >
<!-- TMCFC: Topic Map Context Free Content - the set of elements
allowed at the first level of a topic map.-->
<!entity % TMCFC
"Topic|Assocication|Facet|AddedThemes %AddedElements;"
>
<!-- Topic map document element -->
<!ELEMENT TopicMap (%TMCFC;)* >
<!ATTLIST TopicMap
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "topicmap"
addthems CDATA #IMPLIED >

Issues:
1) What is the correct URL for identifying the topic map specification. (Should it point to this spec or to the standard?)
2) Is there any reason for retaining the HyTime attribute that defines this element as a HyTime hub document within the XML version? (I am presuming that it would be possible to embedd a topic map within a resource that has metadata in it, so that it would not necessaruly be the hub document in the XML application.)

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!-- Element conforming to the Topic Map document element architecture -->
<!ELEMENT SubjectMap (%TMCFC;)*                                 >

<!ATTLIST SubjectMap
   xmlns:TM      CDATA    #FIXED "http://www.infoloom.com/topicmaps"
   TM:TopicMap   CDATA    #FIXED "topicmap"
   TM:addthems   CDATA    #IMPLIED                                  >

Issue: Should the namespace be declared on all elements or should we depend on the fact that all TM relevant elements must be declared within a TM:topicmap element, which should be sufficient to define the namespace for all subelements as well?

The TMCFC parameter entity indicates that valid topic map documents may or may not have any topic links, association links or facet links in them. Some conforming applications may support only Facet element types, while others may not support Facet element types. At certain well specified points in the model user defined elements can be added to the contents of topic map elements. These points are indicated by the presence of the %AddedElements; parameter entity reference.

NOTE: When application-defined names are assigned to elements within an XML Topic Map the element names in the replacement string for the TMCFC parameter entity should be changed to match those of the first level subelements within the topic map.

The effect of specifying the added themes (addthems) attribute is to add the themes that it references to the scopes of all of the topic characteristic assignments made throughout the document of which the element is the root element.

The addthems attribute can be used to acknowledge and document the fact that the document specifies only topic characteristic assignments that are within the scope defined by the set of themes that it specifies. It can be used to avoid specifying these common themes explicitly in every scope. After a topic map document is merged with other topic map documents, the contributions that it made to the resulting merged topic map can be distinguished from the contributions of all others by virtue of the fact that everything it contributed continues to appear within the scopes of the topics specified by the addthems attribute of its document element.

4. Topic links

4.1 The Topic Link Element

The topic link (Topic) element is used to assign topic name characteristics and topic occurrence characteristics to a topic. It has the following form:

<!ELEMENT Topic (TopicNames | Occurrences)* >
<!ATTLIST Topic
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "topic"
id ID #REQUIRED
identity CDATA #IMPLIED
types CDATA #IMPLIED
scope CDATA #IMPLIED >

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Subject (TopicNames | Occurrences)* >
<!ATTLIST Subject
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
TM:TopicMap CDATA #FIXED "topic"
id ID #REQUIRED
TM:identity CDATA #IMPLIED
TM:types CDATA #IMPLIED
TM:scope CDATA #IMPLIED >

NOTE: While the Topic element is defined as a HyTime variable link (varlink) in the International Standard it is the individual occurrences referenced by the topic that are defined using the XML Linking Language.

Every topic link is intended by its author to be organized around exactly one subject, regardless of whether that subject is explicitly defined anywhere. A topic link may declare zero or more names and zero or more pieces of information ("occurrences") that are relevant to its subject. Names, and the scopes within which the names are applicable to the subject, are declared by means of TopicNames subelements. Occurrences are the anchors of the topic link; these, and the scopes within which the occurrences are applicable to the subject, are specified by means of Occurrences subelements.

The required unique identifier (id) attribute allows the topic to be adressed by association links, by the identity attributes of other topic links, and, in their roles as themes in scopes, by scope and addthems attributes.

The optional subject identity (identity) attribute refers to the local ID or remote URL of one or more resources that provide indications ("subject descriptors") that can be used to identify the subject (organizing principle) of the topic. All of the other topic characteristics specified by the topic link are regarded as elaborating, and in no way contradicting, the subject described by the subject descriptor(s), if any. There are no restrictions on the kinds of information that may be referenced by an identity attribute.

Any two or more topic links that reference the same subject by means of their identity attributes are equivalent to a single topic link that has the union of the characteristics (the names, occurrences, and associations) of both topic links. The two or more topic links may be merged, and/or applications may process and/or render them as if they have been merged.

NOTE: The two or more topic links do not have to have identical URLs in order to be merged under this rule. It is only necessary that the subject that is somehow indicated by the two identity attributes be resolvable to the same URL. (For example, one topic map could use a local ID, another could use a relative URL while a third could use an absolute URL, all of which reference the same resource.) If two or more topics refer to exactly the same subject descriptor, the subject descriptor may be described as a "public subject descriptor", and it becomes possible to automate the merging of all such topics by making the assumption that, if they all share the same subject descriptor resource, they all share the same subject identity.

If the identity attribute references one or more topic links, topic map processing applications must regard the referencing topic link, and all the referenced topic links, as having one and the same subject, and therefore they may all be merged.

The optional topic types (types) attribute references one or more topic links. The subject of each such referenced topic link is a class of subject of which the referencing topic link is an instance.

NOTE: The class-instance relationship established between the subject of each referenced topic link and the subject of the referencing topic link could alternatively be established by a topic association link whose semantic is the relationship between a class and an instance of that class. In other words, the types attribute establishes a relationship between topics (a topic association), rather than being a means whereby the referencing topic becomes an occurrence of each of the referenced topics. The topic relationships established by the types attribute are not superclass-subclass relationships. They are only class-instance relationships. Superclass-subclass relationships between topics can be asserted by topic association links that have been user-defined for that purpose.

The optional scope (scope) attribute references the themes that are added to the scopes within which all names and occurrences specified by the topic link are valid.

NOTE: The scope attribute of the Topic element is designed to permit a reduction in syntactic redundancy by providing a means whereby the themes that are common to the scopes within which all the names and occurrences of a topic are valid can be specified once for all. There is no requirement that it be used, however, even if its use would reduce redundancy.

A valid topic link must have at least one of the following: a topic name, a topic occurrence, or a role played in an association with at least one other valid topic.

NOTE: When only acting as the end point for an otherwise undefined association link anchor the element should be defined as an XML empty element by use of the /> tag closing delimiter.

4.2 Topic Names

A topic may have zero or more name characteristics (topic names). Topic names are specified using topic name (TopicNames) elements; all such names become topic characteristics of the topic whose subject is the subject of the containing topic link.

<!ELEMENT TopicNames (BaseName+, DisplayedAs*, SortName* ) >
<!ATTLIST TopicNames
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "topname"
scope CDATA #IMPLIED >
<!ELEMENT BaseName (#PCDATA) >
<!ATTLIST BaseName
TopicMap CDATA #FIXED "basename"
scope CDATA #IMPLIED >
<!ELEMENT DisplayedAs (#PCDATA %AddedElements;)* >
<!ATTLIST DisplayedAs
TopicMap CDATA #FIXED "dispname"
scope CDATA #IMPLIED >
<!ELEMENT SortName (#PCDATA) >
<!ATTLIST SortName
TopicMap CDATA #FIXED "sortname"
scope CDATA #IMPLIED >

Issue: Should the namespace be defined on all four elements?

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Names (Name+, DisplayAs*, SortBy* ) >
<!ATTLIST Names
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
TM:TopicMap CDATA #FIXED "topname"
TM:scope CDATA #IMPLIED >
<!ELEMENT Name (#PCDATA) >
<!ATTLIST Name
TM:TopicMap CDATA #FIXED "basename"
TM:scope CDATA #IMPLIED >
<!ELEMENT DisplayAs (#PCDATA %AddedElements;)* >
<!ATTLIST DisplayAs
TM:TopicMap CDATA #FIXED "dispname"
TM:scope CDATA #IMPLIED >
<!ELEMENT SortBy (#PCDATA) >
<!ATTLIST SortBy
TM:TopicMap CDATA #FIXED "sortname"
TM:scope CDATA #IMPLIED >

The three kinds of topic name that must be used: base name (BaseName), display name (DisplayedAs), and name used as sort key (SortName), specified by means of the three corresponding element types that a TopicNames element may contain. At least one BaseName element must occur within each TopicNames element.

The scope (scope) attribute of the TopicNames element specifies the themes that are common to the scopes of all of the topic names specified by the contained BaseName, DisplayedAs and SortName elements. The scope is the context (or area of validity) in which the name characteristic(s) specified by a TopicName element is/are assigned to the topic whose subject is the subject of the containing topic link.

The scope attributes of the contained name elements (BaseName, DisplayedAs and SortName) may be used to add more themes on a name-by-name basis, in the same manner as the scope attribute of the containing Topicnames element.

NOTE: Thus, the scope attribute of the TopicNames element form is really just a means of avoiding the syntactic redundancy of specifying the themes common to the contained elements separately via the scope attribute of each contained element.

If no scope attribute is specified by a BaseName, DisplayedAs or SortName element and no scope attribute is specified by its containing TopicNames element, nor by the containing TopicNames's containing Topic element, then the scope of the name characteristic specified by that BaseName, DisplayedAs or SortName is unconstrained. If any of the aforementioned scope attributes are specified, then the scope is constrained to the themes specified by those scope attributes, even if the scope attributes specify no themes, plus any themes added via any applicable Addedthemes elements in the bounded object set, plus any themes added via the addthems attribute of the containing TopicMap document element.

The content of the optional display name (DisplayedAs) element specifies a name that is designed to be displayed by an application to a user, when the name specified by the BaseName elements within the same containing TopicNames should not be used for display purposes.

NOTE: The display name can be used to specify an abbreviated name for use in situations where display resources are limited, or it can be a graphic expressed in some data content notation.

The content of the optional name to be used as sort key (SortName) element specifies a name that is designed to be used to represent the topic in a sorting process that arranges a list of topics in some order, when the name specified by the BaseName elements within the same containing TopicNames should not be used for that purpose.

NOTE: Thus, the BaseName elements, at least one of which is required, is also, in effect, the default content of the optional DisplayedAs and SortName elements. If no DisplayedAs elements are specified, the BaseName elements are to be used as display names. Similarly, if no SortName elements are specified, the BaseName elements are to be used as sort keys.

The data content of both BaseName and SortName elements must be text strings, and they may be words or phrases. The data content of a DisplayedAs element may be either a text string or notation data; if it is notation data, it may be a displayable graphic or other information intended to identify the subject to one or more of the senses of the user of the topic map, e.g.:

<TopicNames id="Leonardo">
<BaseName>Leonardo da Vinci</BaseName>
<DisplayedAs><IMG src="MonaLisa.gif"></DisplayedAs>
<SortName>Da Vinci, Leonardo</SortName>
</TopicNames>

NOTE: There are two reasons why base names, display names, and names used as sort keys may share a single containing TopicNames element:

1. to allow them to share a common scope, specified via the scope attribute of the containing TopicNames element, and/or
2. to indicate that base names, display names, and sort keys correspond to one another. Therefore, if a one-to-one relationship is desired between base names and display names, for example, each pair, consisting of one base name and one display name, must be contained in a separate TopicNames element. However, if no display names or sort names are used, and many base names of a single topic have the same scope, all of the base names may appear within a single TopicNames element.

Two distinct subjects may not have the same name characteristic within exactly the same scope (a "topic naming constraint"). When topic maps are processed, each distinct set of themes that serves as a scope constitutes a namespace in which no two subjects can have the same name. If a conforming topic map application detects a situation in which multiple topic links have the same name characteristic within the same scope, the topics shall be merged.

NOTES:
1) This means that applications that render the topic map will behave as though there was only a single topic link whose characteristics comprise the union of the topic characteristics of all of the topic links that had the same name within the same scope.

2) The topic naming constraint is designed to preserve the ability to identify subjects unambiguously in terms of their topic name characteristics. The topic naming constraint is also necessary in order to support the most basic functionality of indexes and glossaries, which must make distinctions between the various meanings of words and phrases in order to support navigation to the relevant occurrences. Topic map authors must use scopes to distinguish between the different meanings of any name that is used for more than one subject. Consequently, if a topic map author does not wish to specify scope attributes explicitly, that author cannot use the same name for any two different subjects, because the default scope is a single scope: the unconstrained scope. Since any two identical names will appear within that single scope, the two subjects of which the two names are topic characteristics will be automatically merged. Such merging is erroneous and extremely undesirable unless the two topic links that have the same name in the same scope also have the same subject identity.

3) As an aid to topic map authors, topic map authoring and merging applications may be designed in such a way as to give warning when topic links are being merged on account of the fact that they have the same name in the same scope.

4) One of the effects of the topic naming constraint is that the merging of topic maps can be accomplished in such a way as to make the merger maintainable even when the member topic maps are maintained separately, asynchronously, and with no extra, agreed-upon discipline (such as some sort of element naming discipline) designed to permit easy maintenance of references among the component documents of the merged topic map. The topic naming constraint makes the addressing of the subjects covered by topic maps dependent only on their names and the distinguishing criteria of their names (the scopes within which their name characteristics are valid), and not on the organization or tagging of their corresponding topic links.

5) If any two topic maps that are to be merged conflict with one another because they happen to provide the same name within the same scope for two different subjects, the merger of the different subjects can be prevented by applying different added themes to one or both of their containing topic map documents, using one or more AddedThemes elements. The added themes specified by such Addedthemes elements can serve to distinguish the two identical names, because they will no longer appear within exactly the same scope.

4.3 The Topic Occurrence Element

By means of location addresses specified in its content, the topic occurrence (Occurrences) element references information (one or more "occurrences") that is relevant to the subject of the containing topic link. This specifications requires that occurrences are specified as XML extended link elements. They are defined a follows:

<!ELEMENT Occurrences (xlink:locator*) >
<!ATTLIST Occurrences
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
TopicMap CDATA #FIXED "occurs"
scope CDATA #IMPLIED
occrl CDATA #IMPLIED
type CDATA #IMPLIED
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED >

Issue: xml:locator elements must have IDs. Should we ask W3C to allow these to be implied?

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Instances (xlink:locator*) >
<!ATTLIST Instances
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
TM:TopicMap CDATA #FIXED "occurs"
TM:scope CDATA #IMPLIED
TM:occrl CDATA #IMPLIED
TM:type CDATA #IMPLIED
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED > 

The xmlns:xlink XML namespace attribute indicates that attributes with the xlink: qualifier are taken from the XML Linking Language (XLink) specification. The attributes associated with XML extended links are defined under the heading Extended Links in that specification.

All of the occurrences specified by any given Occurrences element fall into a single user-defined category of occurrences called an "occurrence role" -- the role played by the occurrences in contributing to the information that participates in the subject characterized by the containing topic link. Within a single topic link, more than one Occurrences element may reference the same information, in which case the information plays multiple occurrence roles.

NOTE: For example, if the subject of a topic link is Leonardo Da Vinci, there may be a "scientific-biography" occurrence role, and a separate "artistic-biography" occurrence role. Some information resources may fall into both categories; if so, such resources will be referenced by both of the Occurrences elements that correspond to the two occurrence roles, e.g.:

<Topic id="Leonardo" types="Painter Engineer Anatomist">
<TopicNames>
<BaseName>Leonardo da Vinci</BaseName>
<DisplayedAs><IMG src="MonaLisa.gif"></DisplayedAs>
<SortName>Da Vinci, Leonardo</SortName>
</TopicNames>
<Occurrences type="artistic-biography">
<xlink:locator id="location2345"
href="http://www.britannia.com/encyclopedia/10/L.htm#Leonardo">
....
</Occurrences>
<Occurrences type="scientific-biography">
<xlink:locator id="location2345"
href="http://www.britannia.com/encyclopedia/10/L.htm#Leonardo">
....
</Occurrences>
<Topic>

The occurrence role is the scope within which the occurrences are relevant to the subject of the containing topic link. The set of themes (topics) that constitute the scope is specified via the optional scope (scope) attribute. If no scope attribute is specified by an Occurrences element, and no scope attribute is specified by its containing topic link element, then the scope of the occurrence characteristics specified by that Occurrences element is unconstrained. If either of the aforementioned scope attributes are specified, then the scope is constrained to the themes specified by those scope attributes (even if the scope attributes specify no themes), plus any themes added via any applicable addthms elements in the bounded object set, plus any themes added via the addthems attribute of the containing topicmap document element.

The optional occrl attribute can be used to provide a mnemonic name for the occurrence role.

The optional occurrence role type (type) attribute references a single topic link. The subject of the referenced topic link is a class of occurrence role of which the occurrence role expressed by the Occurrences element is an instance.

NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing Occurrences element could alternatively be established by assigning a unique identifier to the occurrence and then making the Occurrences element an occurrence of the referenced topic link, within the scope of an occurrence role whose meaning is that the occurrence role is an instance of the subject of the topic link.

If the occurrence role type (type) attribute is specified, and if the topic referenced by the type attribute has a name characteristic that lies within a scope that is appropriate to the topic map user's context, the referenced topic's name characteristic is used to characterize the occurrence role for the user. Otherwise, the value of the occrl attribute is used to characterize the occurrence role for the user.

NOTE: The topic referenced via the type attribute can have many names in scopes designed for many different user contexts, including many different natural languages and delivery platforms, while the occrl attribute or XML element type name is just a single token. Therefore, the use of a topic, referenced by the type attribute, to characterize the occurrence role offers far more flexibility and representational power than the simple mnemonic naming facility offered by the occrl attribute or XML element type name.

The xlink:locator element that forms the content of an Occurrence element is defined in the Locator elements section of the XML Linking Language (XLink) specification.

NOTE: The Occurrences element type is derived from the anchspec element type of the HyTime architecture. For the purposes of this specification, however, the HyTime attributes are considered to be replaced by the equivalent XLink attributes.

5 Association Links

5.1 Association Link Elements

The association link (Association) element is used to express relationships among topics. Topic Maps applications define the nature of the relationships, and of the roles played by topics in those relationships. In XML Topic Maps association links are XML extended links, and are defined as:

<!ELEMENT Association (Role)+ >
<!ATTLIST Association
TopicMap CDATA #FIXED "assoc"
scope CDATA #IMPLIED
linktype NMTOKEN #IMPLIED
type CDATA #IMPLIED
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED >

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Relationship (Arc)+ >
<!ATTLIST Relationship
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
TM:TopicMap CDATA #FIXED "assoc"
TM:scope CDATA #IMPLIED
TM:linktype NMTOKEN #IMPLIED
TM:type CDATA #IMPLIED
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED >

The xmlns:xlink XML namespace attribute indicates that attributes with the xlink: qualifier are taken from the XML Linking Language (XLink) specification. The attributes associated with XML extended links are defined under the heading Extended Links in that specification.

The optional scope (scope) attribute specifies the scope (the set of themes) within which the association is applicable to the topics that serve as anchors of the association link. If the scope attribute is not specified, the scope is unconstrained. If the scope attribute is specified, then the scope is constrained to the themes specified by the scope attribute (even if the scope attribute specifies no themes), plus any themes added via any applicable addthms elements in the bounded object set, plus any themes added via the addthems attribute of the containing topicmap document element.

The optional hyperlink type (linktype) attribute can be used to provide a mnemonic name for the association type. If the linktype attribute is not specified, the XML element type name is regarded as the mnemonic name of the association type.

The optional association type (type) attribute references a single topic link. The subject of the referenced topic link is a class of association of which the association expressed by the association link is an instance.

NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing association link could alternatively be established by making the association link an occurrence of the referenced topic link, with an occurrence role whose meaning is that the association link is an instance of the subject of the topic link.

If the association type (type) attribute is specified, and if the topic referenced by the type attribute has a name characteristic that lies within a scope that is appropriate to the topic map user's context, the referenced topic's name characteristic is used to characterize the association type for the user. Otherwise, the value of the linktype attribute (or, if the linktype attribute is not specified, the XML element type name) is used to characterize the association type for the user.

NOTE: The topic referenced via the type attribute can have many names in scopes designed for many different user contexts, including many different natural languages and delivery platforms, while the linktype attribute or XML element type name is just a single token. Therefore, the use of a topic, referenced by the type attribute, to characterize the association type offers far more flexibility and representational power than the simple mnemonic naming facility offered by the linktype attribute or XML element type name.

5.2 The Association Role Element

In XML Topic maps the Role element is defined as an empty XML Linking Language Arc element as follows:

<!ELEMENT Role EMPTY >
<!ATTLIST Role
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "assocrl"
anchrole NMTOKEN #IMPLIED
type CDATA #IMPLIED
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type (arc) #FIXED "arc"
xlink:from IDREF #REQUIRED
xlink:to IDREF #REQUIRED
show (new|parsed|replace) "replace"
actuate (user|auto) "user" >

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Arc EMPTY >
<!ATTLIST Arc
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
TM:TopicMap CDATA #FIXED "assocrl"
TM:anchrole NMTOKEN #IMPLIED
TM:type CDATA #IMPLIED
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
xlink:type (arc) #FIXED "arc"
xlink:from IDREF #REQUIRED
xlink:to IDREF #REQUIRED
xlink:show (new|parsed|replace) "replace"
xlink:actuate (user|auto) "user" >

Issue: I have chosen to use xlink:arc rather than xlink:locator as this seems a more natural match. However, we need to be aware that there is a problem with the first draft of the xlink:arc specification in that it requires the use of IDs rather than URLs to locate linked resources. This would make it impossible to define an association between two topics in different maps. Is this a problem? Should we request W3C to change IDREF to CDATA to allow a URL to be specified? Would there be advantages in allowng multiple references for from or to (e.g. by using IDREFS in place of IDREF)?

The xmlns:xlink XML namespace attribute indicates that attributes with the xlink: qualifier are taken from the XML Linking Language (XLink) specification. The attributes associated with XML extended links are defined under the heading Arc Element in that specification.

In an XML Topic Map the association role (Role) element specifies a user-defined role that one topic plays with respect to another. The two topics that are associated by the role are referenced by means of unique identifiers specified in the xlink:from and xlink:to attributes.

Within a single association link, more than one Role element may reference the same topic, in which case the topic plays multiple roles in the association.

NOTE: Thus, the containing Association element can assert that a topic has one or more relationships with the same or different topics, each relationship having a specific relationship direction.

Regardless of the association role(s) they play in the relationship expressed by the containing Association element, all topics referenced in the content of the contained Role elements play their roles in that relationship within the same scope.

NOTE 44: This is the reason why there is no scope attribute on the Role element form.

The optional HyTime-defined anchor role (anchrole) attribute can be used to provide a mnemonic name for the association role. If the anchrole attribute is not specified, the XML element type name is regarded as the mnemonic name of the association role.

Issue: Should we put this in a separate HyTime name space or is it better to keep it as part of the TM namespace?

The optional association role type (type) attribute references a single topic link. The subject of the referenced topic link is a class of association role of which the association role expressed by the Role element is an instance.

NOTE: The class-instance relationship thus established between the subject of the referenced topic link and the referencing Role element could alternatively be established by making the Role element an occurrence of the referenced topic link, within the scope of an occurrence role whose meaning is that the association role is an instance of the subject of the topic link.

If the association role type (type) attribute is specified, and if the topic referenced by the type attribute has a name characteristic that lies within a scope that is appropriate to the topic map user's context, the referenced topic's name characteristic is used to characterize the association role for the user. Otherwise, the value of the anchrole attribute (or, if the anchrole attribute is not specified, the XML element type name) is used to characterize the association

NOTE: The topic referenced via the type attribute can have many names in scopes designed for many different user contexts, including many different natural languages and delivery platforms, while the anchrole attribute or XML element type name is just a single token. Therefore, the use of a topic, referenced by the type attribute, to characterize the association role offers far more flexibility and representational power than the simple mnemonic naming facility offered by the anchrole attribute or XML element type name.

The commonly used class-member relationship between two topics can be specified using Associations as follows:

<Association type="ClassMembership">
  <Role type="Supertype" xlink:from="Topic1"      xlink:to="ClassTopic2">
  <Role type="Subtype"   xlink:from="ClassTopic2" xlink:to="Topic1"     >
</Association>

By using application-specific names, and taking advantage of the fact that the default value for the type attribute is the XML element type name, this example can be simplified to:

<ClassMembership>
  <Supertype xlink:from="Topic1"      xlink:to="ClassTopic2">
  <Subtype   xlink:from="ClassTopic2" xlink:to="Topic1"     >
</ClassMembership>

6. Themes To Be Added Architectural Form

The themes to be added (AddedThemes) element allows themes to be added:

• to all the scopes of all topic characteristic assignments (that is, all topic names, topic occurrences, and roles played in associations with other topics) specified by topic links and topic associations in the topic map documents referenced via the topic map document entities (tmdocs) attribute, and/or
• to the scopes of all topic names and topic occurrences specified by specific topic links (and the subelements of topic links) referenced via the characteristic assigners (cassign) attribute, if any, and/or
• to the scopes of all roles played by topics in topic associations specified by specific association links referenced via the characteristic assigners (cassign) attribute, if any.

In XML Topic Maps the element is defined as:

<!ELEMENT AddedThemes ANY >
<!ATTLIST AddedThemes
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "addthms"
addthems CDATA #REQUIRED
tmdocs ENTITIES #IMPLIED
cassign CDATA #IMPLIED >

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT GeneralThemes ANY >
<!ATTLIST GeneralThemes
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
TM:TopicMap CDATA #FIXED "addthms"
TM:addthems CDATA #REQUIRED
TM:tmdocs ENTITIES #IMPLIED
TM:cassign CDATA #IMPLIED >

The added themes (addthems) attribute's value is a reference to one or more topic link elements. The referenced topic link elements must be regarded by topic map applications as additional themes in the scopes of the topic characteristics specified via the tmdocs and cassign attributes.

The tmdocs and cassign attributes are independent of one another. If both are specified, the tmdocs attribute does not establish a location source for the addresses specified via the cassign attribute; the cassign attribute must be used in such a way that it establishes its own location source(s).

NOTE: When topic maps are to be merged, the tmdocs attribute can be used allow applications to distinguish between the characteristics of topics in terms of the different topic maps that contributed those characteristics. For example, a topic can be created that represents the rhetorical position or purpose of a given topic map, and then, by means of an addthms element, that new topic can be used as an additional scope within which all the topic characteristics specified by the topic map is said to be valid. After the topic map document is merged with other topic map documents, the contributions that it made to the resulting merged topic map can be distinguished from all others by virtue of the fact that everything it contributed continues to appear within the scope of the topic representing the document or hyperdocument that contributed it.

The addthms element's content is not defined by this specification. While any element can be used the element will normally be specified as an empty XML element, e.g.

<AddedThemes addthms="European-Artists"
             tmdocs="http://www.EU-topics.org/maps/artists.xml" >

7. Facet Linking

The "facet linking" facility allows property/value pairs to be added to read-only information objects. The properties are called "facet types", and the values are called "facet values". This specification does not constrain the nature of facet linking applications; they may or may not also use topic links.

NOTE: The property/value pairs applied by facet links can be used, for example, as selection criteria to create partial views of a corpus of information. It should be noted, however, that topic links are much more generalized and powerful than facet links.

7.1 The Facet Link Element

The facet link (facet) element form is used to apply property/value pairs to information objects specified by the contained fvalue elements. Facet link properties (facet types) and values (specified by means of the contained fvalue elements) are user-defined.

In XML Topic Maps the facet element is defined as an XML extended link as follows:

<!ELEMENT Facet (FacetValue+) >
<!ATTLIST Facet
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
TopicMap CDATA #FIXED "facet"
linktype NAME #IMPLIED
type CDATA #IMPLIED >

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Property (Value+) >
<!ATTLIST Property
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
TM:TopicMap CDATA #FIXED "facet"
TM:linktype NAME #IMPLIED
TM:type CDATA #IMPLIED >

The optional hyperlink type (linktype) attribute can be used to provide a mnemonic name for the property (facet type). If the linktype attribute is not specified, the XML element type name is regarded as the mnemonic name of the property.

The optional facet type (type) attribute references a single topic link. The subject of the referenced topic link is the property (the facet type) specified in all of the property/value pair assignments made by the facet link.

NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing facet link could alternatively be established by making the facet link an occurrence of the referenced topic link, with an occurrence role whose meaning is that the facet link is an instance of the subject of the topic link.

If the facet type (type) attribute is specified, and if the topic referenced by the type attribute has a name characteristic that lies within a scope that is appropriate to the topic map user's context, the referenced topic's name characteristic is used to characterize the property (the facet type) for the user. Otherwise, the value of the hyperlink type (linktype) attribute (or, if the linktype attribute is not specified, the XML element type name) is used to characterize the property for the user.

NOTE: The topic referenced via the type attribute can have many names in scopes designed for many different user contexts, including many different natural languages and delivery platforms, while the linktype attribute or XML element type name is just a single token. Therefore, the use of a topic, referenced by the type attribute, to characterize the property (the facet type) offers far more flexibility and representational power than the simple mnemonic naming facility offered by the linktype attribute or XML element type name.

7.2 Facet Value Architectural Form

The facet value (FacetValue) element form specifies a user-defined value of the property (facet type) being applied by the containing facet link. The information objects to which the property/value pair is being assigned are referenced by means of the location addresses specified in the content of the fvalue element.

In XML Topic Maps the FacetValue element is defined as an XML Extended Link as follows:

<!ELEMENT FacetValue (xlink:locator*) >
<!ATTLIST FacetValue
xmlns CDATA #FIXED "http://www.infoloom.com/topicmaps"
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
TopicMap CDATA #FIXED "fvalue"
facetval NMTOKEN #IMPLIED
type CDATA #IMPLIED
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED > 

The XML namespace attribute (xmlns) defines the topic map namespace. In the model defined above the topic map related element and attributes have been defined as part of the default namespace, which has no namespace qualifier. An alternative mechanism is to use a named namespace to identify that an element is defined in terms of the architectural form, as follows:

<!ELEMENT Value (xlink:locator*) >
<!ATTLIST Value
xmlns:TM CDATA #FIXED "http://www.infoloom.com/topicmaps"
xmlns:xlink CDATA #FIXED "http://www.w3.org/XML/XLink/0.9"
TM:TopicMap CDATA #FIXED "fvalue"
TM:facetval NMTOKEN #IMPLIED
TM:type CDATA #IMPLIED
xlink:type (extended) #FIXED "extended"
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:showdefault (new|parsed|replace) #IMPLIED
xlink:actuatedefault (user|auto) #IMPLIED > 

The xmlns:xlink XML namespace attribute indicates that attributes with the xlink: qualifier are taken from the XML Linking Language (XLink) specification. The attributes associated with XML extended links are defined under the heading Extended Links in that specification.

The optional facet value name (facetval) attribute specifies the token which is the value of the property/value pair being assigned. If the facetval attribute is not specified, the XML element type name of the FacetValue element is the value being assigned.

NOTE: The rules for defaulting the values of the type attribute of a Facet element and the facetval attribute of a FacetValue element mean that a property assignment defined using the following set of predefined elements:

<Facet type="Language">
<FacetValue facetval="English">
<xlink:locator id="location1234" href="http://www.MI5.org/files/secrets.htm"/>
</FacetValue>
</Facet>

could also be defined as:

<Language>
<English>
<xlink:locator id="location1234" href="http://www.MI5.org/files/secrets.htm"/>
</English>
</Language>

if the appropriate namespace controlled attributes have been assigned to the Language and English elements in the associated DTD.

The optional facet value type (type) attribute references a single topic link. The subject of the referenced topic link is the significance of the facet value.

NOTE: The class-instance relationship established between the subject of the referenced topic link and the referencing fvalue element could alternatively be established by making the fvalue element an occurrence of the referenced topic link, with an occurrence role whose meaning is that the fvalue element is an instance of the subject of the topic link.

8. Conformance

If an XML Topic Map document complies with all provisions of this specification, and is a valid XML document, it is a conforming topic map document.

Issue: Is it necessary to validate the XML file, or is it sufficient that the XML document is well-formed?

A conforming application intended to use existing XML Topic Maps must be able to:

• parse the interchange syntax,
• identify the topic map constructs defined by this specification, and
• apply whatever processing the application designers considered appropriate, in light of the requirements to be fulfilled by the application, and the semantics of those constructs as defined by this specification.

A conforming application intended to create XML Topic Maps must be able to export the information expressible using the predefined elements and attributes defined in this specification.

A conforming application intended to read and write XML Topic Maps must meet both of the above sets of requirements. If an application can import topic maps, has features to edit them, but cannot export altered topic maps in the interchange syntax defined by this International Standard, then it is not a conforming application.

NOTE: This specification constrains neither the uses to which topic maps can be put, nor the character of the processing that may be applied by a conforming application. This conformance clause is intended to guarantee that conforming topic maps can be understood to whatever degree conforming read-only applications are intended to understand them, and that the topic mapping information expressed using the topic map syntax will be preserved by conforming read/write applications (except to the extent that the users of read/write applications deliberately alter that information).

Annexes

A. XML Topic Map Templates

A topic map template consists of a customized DTD and, optionally, a set of topics, associations and facets that are relevant to more than one topic map. The topics and associations in a topic map template typically define the topics that will be referenced using the type and scope attributes to create subsets of the topic map.

The following (simplified) example shows a topic map template based on the predefined topic map elements defined within this specification:

<!DOCTYPE TopicMap [
<!-- AddedElements: Elements added for use within a specific topic map.
                    Defaults to no added elements.--                       >
<!ENTITY % AddedElements ""                                                >

<!-- TMCFC: Topic Map Context Free Content - the set of elements
            allowed at the first level of a topic map.--                   >
<!entity % TMCFC
   "Topic|Assocication|Facet|AddedThemes %AddedElements;"                  >

<!-- Topic map document element --                                         >
<!ELEMENT TopicMap    (%TMCFC;)*                                           >
<!ATTLIST TopicMap
   xmlns      CDATA    #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap   CDATA    #FIXED "topicmap"
   addthems   CDATA    #IMPLIED                                            >

<!ELEMENT Topic         (TopicNames | Occurrences)*                        >
<!ATTLIST Topic
   xmlns         CDATA    #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap      CDATA    #FIXED "topic"
   id            ID       #REQUIRED
   identity      CDATA    #IMPLIED
   types         CDATA    #IMPLIED
   scope         CDATA    #IMPLIED                                         >

<!ELEMENT TopicNames  (BaseName+, DisplayedAs*, SortName* )                >
<!ATTLIST TopicNames
   xmlns       CDATA    #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap    CDATA    #FIXED "topname"
   scope       CDATA    #IMPLIED                                           >

<!ELEMENT BaseName      (#PCDATA)                                          >
<!ATTLIST BaseName
   TopicMap    CDATA        #FIXED "basename"
   scope       CDATA        #IMPLIED                                       >

<!ELEMENT DisplayedAs (#PCDATA %AddedElements;)*                           >
<!ATTLIST DisplayedAs
   TopicMap    CDATA        #FIXED "dispname"
   scope       CDATA        #IMPLIED                                       >

<!ELEMENT SortName      (#PCDATA)                                          >
<!ATTLIST SortName
   TopicMap    CDATA        #FIXED "sortname"
   scope       CDATA        #IMPLIED                                       >

<!ELEMENT Occurrences  (xlink:locator*)                                    >
<!ATTLIST Occurrences
   xmlns                CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   xmlns:xlink          CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   TopicMap             CDATA                 #FIXED "occurs"
   scope                CDATA                 #IMPLIED
   occrl                CDATA                 #IMPLIED
   type                 CDATA                 #IMPLIED
   xlink:type           (extended)            #FIXED "extended"
   xlink:role           CDATA                 #IMPLIED
   xlink:title          CDATA                 #IMPLIED
   xlink:showdefault    (new|parsed|replace)  #IMPLIED
   xlink:actuatedefault (user|auto)           #IMPLIED                     >

<!ELEMENT Association (Role)+                                              >
<!ATTLIST Association
   TopicMap             CDATA                 #FIXED "assoc"
   scope                CDATA                 #IMPLIED
   linktype             NMTOKEN               #IMPLIED
   type                 CDATA                 #IMPLIED
   xmlns:xlink          CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   xlink:type           (extended)            #FIXED "extended"
   xlink:role           CDATA                 #IMPLIED
   xlink:title          CDATA                 #IMPLIED
   xlink:showdefault    (new|parsed|replace)  #IMPLIED
   xlink:actuatedefault (user|auto)           #IMPLIED                     >

<!ELEMENT Role EMPTY                                                       >
<!ATTLIST Role
   xmlns          CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap       CDATA                 #FIXED "assocrl"
   anchrole       NMTOKEN               #IMPLIED
   type           CDATA                 #IMPLIED
   xmlns:xlink    CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   xlink:type     (arc)                 #FIXED "arc"
   xlink:from     IDREF                 #REQUIRED
   xlink:to       IDREF                 #REQUIRED
   show           (new|parsed|replace)  "replace"
   actuate        (user|auto)           "user"                             >

<!ELEMENT AddedThemes ANY                                                  >
<!ATTLIST AddedThemes
   xmlns          CDATA         #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap       CDATA         #FIXED "addthms"
   addthems       CDATA         #REQUIRED
   tmdocs         ENTITIES      #IMPLIED
   cassign        CDATA         #IMPLIED                                   >

<!ELEMENT Facet (FacetValue+)                                              >
<!ATTLIST Facet
   xmlns          CDATA     #FIXED "http://www.infoloom.com/topicmaps"
   TopicMap       CDATA     #FIXED "facet"
   linktype       NAME      #IMPLIED
   type           CDATA     #IMPLIED                                       >

<!ELEMENT FacetValue (xlink:locator*)                                      >
<!ATTLIST FacetValue
   xmlns                CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   xmlns:xlink          CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   TopicMap             CDATA                 #FIXED "fvalue"
   facetval             NMTOKEN               #IMPLIED
   type                 CDATA                 #IMPLIED
   xlink:type           (extended)            #FIXED "extended"
   xlink:role           CDATA                 #IMPLIED
   xlink:title          CDATA                 #IMPLIED
   xlink:showdefault    (new|parsed|replace)  #IMPLIED
   xlink:actuatedefault (user|auto)           #IMPLIED                     >

<!ELEMENT xlink:locator EMPTY                                              >
<!ATTLIST xlink:locator
   id                   ID                    #REQUIRED
   href                 CDATA                 #REQUIRED
   role                 CDATA                 #IMPLIED
   title                CDATA                 #IMPLIED                     >
]>
<TopicMap addthems="EuropeanArt">
 <Topic id="EuropeanArt"
        identity="http://www.topics.org/subjects/index.xml#Art-Europeen"
        scope="http://www.topics.org/maps/Regions.xml#Europe">
  <TopicNames scope="EnglishNames">
   <BaseName>Art, European</BaseName>
   <BaseName>European Art</BaseName>
   <BaseName>History of European Art</BaseName>
  </TopicNames>
  <TopicNames scope="NomFrancais">
   <BaseName>Art, Europeèn</BaseName>
   <BaseName>Histoire d'Art Europeèn</BaseName>
   <SortName>Art, Europeen</SortName>
  </TopicNames>
 </Topic>
 <Topic id="EnglishNames">
  <TopicNames>
   <BaseName>English Version of Names</BaseName>
   <BaseName>Name in English</BaseName>
  </TopicNames>
 </Topic>
 <Topic id="NomFrancais">
  <TopicNames>
   <BaseName>Nom Français</BaseName>
   <SortName>Nom Francais</SortName>
  </TopicNames>
 </Topic>
 <Topic id="Class">
  <TopicNames scope="EnglishNames NomFrancais">
   <BaseName>Class</BaseName>
  </TopicNames>
 </Topic>
 <Topic id="Member">
  <TopicNames scope="EnglishNames">
   <BaseName>Class Member</BaseName>
   <BaseName>Member (of class)</BaseName>
  </TopicNames>
  <TopicNames scope="NomFrancais">
   <BaseName>Membre</BaseName>
  </TopicNames>
 </Topic>
 <Topic id="Supertype"/>
 <Topic id="Subtype"/>
 <Topic id="ArtistClass">
  <TopicNames scope="EnglishNames">
   <BaseName>Artist</BaseName>
  </TopicNames>
  <TopicNames scope="NomFrancais">
   <BaseName>Artiste</BaseName>
  </TopicNames>
 </Topic>
 <Topic id="Painter">
  <TopicNames scope="EnglishNames">
   <BaseName>Painter</BaseName>
  </TopicNames>
  <TopicNames scope="NomFrancais">
   <BaseName>Painteur</BaseName>
  </TopicNames>
 </Topic>
 <!--Add application-specific topics here -->
 <Association type="ClassMembership">
  <Role type="Supertype" xlink:from="Painter"      xlink:to="ArtistClass">
  <Role type="Subtype"   xlink:from="ArtistClass"  xlink:to="Painter"    >
 </Association>
 <!--Add application specific associations here -->
 <Facet type="Language">
  <FacetValue facetval="English">
   <!--Add locations for resources in English here -->
  </FacetValue>
  <FacetValue facetval="French">
   <!--Add locations for resources in French here -->
  </FacetValue>
 </Facet>
</TopicMap>

As well as defining a set of topics that are relevant for a wide range of topic maps, including empty declarations for the Supertype and Subtype types of association roles, the template also includes placeholders that will allow language identifiers to be associated with resources referenced using the topic map so that users can request views that just show English or French resources.

Using an external entity to store the alternative set of elements with namespaced attributes shown as examples in the specification, the template would take the form:

<DOCTYPE SubjectMap SYSTEM "alternative.dtd"[]>
<SubjectMap TM:addthems="EuropeanArt">
 <Subject id="EuropeanArt"
        TM:identity="http://www.topics.org/subjects/index.xml#Art-Europeen"
        TM:scope="http://www.topics.org/maps/Regions.xml#Europe">
  <Names TM:scope="EnglishNames">
   <Name>Art, European</Name>
   <Name>European Art</Name>
   <Name>History of European Art</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Art, Europeèn</Name>
   <Name>Histoire d'Art Europeèn</Name>
   <SortBy>Art, Europeen</SortBy>
  </Names>
 </Subject>
 <Subject id="EnglishNames">
  <Names>
   <Name>English Version of Names</Name>
   <Name>Name in English</Name>
  </Names>
 </Topic>
 <Subhect id="NomFrancais">
  <Names>
   <Name>Nom Français</Name>
   <SortBy>Nom Francais</SortBy>
  </Names>
 </Subhect>
 <Subject id="Class">
  <Names TM:scope="EnglishNames NomFrancais">
   <Name>Class</Name>
  </Names>
 </Subject>
 <Subject id="Member">
  <Names TM:scope="EnglishNames">
   <Name>Class Member</Name>
   <Name>Member (of class)</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Membre</Name>
  </Names>
 </Subject>
 <Subject id="Supertype"/>
 <Subject id="Subtype"/>
 <Subject id="ArtistClass">
  <Names TM:scope="EnglishNames">
   <Name>Artist</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Artiste</Name>
  </Names>
 </Subject>
 <Subject id="Painter">
  <Names TM:scope="EnglishNames">
   <Name>Painter</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Painteur</Name>
  </Names>
 </Subject>
 <!--Add application-specific topics here -->
 <Relationship TM:type="ClassMembership">
  <Arc TM:type="Supertype" xlink:from="Painter"      xlink:to="ArtistClass">
  <Arc TM:type="Subtype"   xlink:from="ArtistClass"  xlink:to="Painter"    >
 </Relationship>
 <!--Add application specific associations here -->
 <Property TM:type="Language">
  <Value TM:facetval="English">
   <!--Add locations for resources in English here -->
  </Value>
  <Value TM:facetval="French">
   <!--Add locations for resources in French here -->
  </Value>
 </Property>
</SubjectMap>

The instance can be simplified further by defining elements for each property, permitted property value and type of relationship, e.g.

<DOCTYPE SubjectMap SYSTEM "alternative.dtd" [
<!ELEMENT Language (English|French)+                             >
<!ATTLIST Language
   xmlns:TM       CDATA     #FIXED "http://www.infoloom.com/topicmaps"
   TM:TopicMap    CDATA     #FIXED "facet"
   TM:linktype    NAME      #IMPLIED
   TM:type        CDATA     #IMPLIED                             >
<!ELEMENT English (xlink:locator*)                               >
<!ATTLIST English
   xmlns:TM             CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   xmlns:xlink          CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   TM:TopicMap          CDATA                 #FIXED "fvalue"
   TM:facetval          NMTOKEN               #IMPLIED
   TM:type              CDATA                 #IMPLIED
   xlink:type           (extended)            #FIXED "extended"
   xlink:role           CDATA                 #IMPLIED
   xlink:title          CDATA                 #IMPLIED
   xlink:showdefault    (new|parsed|replace)  #IMPLIED
   xlink:actuatedefault (user|auto)           #IMPLIED          >
<!ELEMENT French (xlink:locator*)                               >
<!ATTLIST French
   xmlns:TM             CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   xmlns:xlink          CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   TM:TopicMap          CDATA                 #FIXED "fvalue"
   TM:facetval          NMTOKEN               #IMPLIED
   TM:type              CDATA                 #IMPLIED
   xlink:type           (extended)            #FIXED "extended"
   xlink:role           CDATA                 #IMPLIED
   xlink:title          CDATA                 #IMPLIED
   xlink:showdefault    (new|parsed|replace)  #IMPLIED
   xlink:actuatedefault (user|auto)           #IMPLIED          >
<!ELEMENT Relationship (Supertype|Subtype)                      >
<!ELEMENT Supertype EMPTY                                       >
<!ATTLIST Supertype
   xmlns:TM       CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   TM:TopicMap    CDATA                 #FIXED "assocrl"
   TM:anchrole    NMTOKEN               #IMPLIED
   TM:type        CDATA                 #IMPLIED
   xmlns:xlink    CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   xlink:type     (arc)                 #FIXED "arc"
   xlink:from     IDREF                 #REQUIRED
   xlink:to       IDREF                 #REQUIRED
   xlink:show     (new|parsed|replace)  "replace"
   xlink:actuate  (user|auto)           "user"                  >
<!ELEMENT Subtype EMPTY                                         >
<!ATTLIST Subtype
   xmlns:TM       CDATA                 #FIXED "http://www.infoloom.com/topicmaps"
   TM:TopicMap    CDATA                 #FIXED "assocrl"
   TM:anchrole    NMTOKEN               #IMPLIED
   TM:type        CDATA                 #IMPLIED
   xmlns:xlink    CDATA                 #FIXED "http://www.w3.org/XML/XLink/0.9"
   xlink:type     (arc)                 #FIXED "arc"
   xlink:from     IDREF                 #REQUIRED
   xlink:to       IDREF                 #REQUIRED
   xlink:show     (new|parsed|replace)  "replace"
   xlink:actuate  (user|auto)           "user"                  > 
]>
<SubjectMap TM:addthems="EuropeanArt">
 <Subject id="EuropeanArt"
        TM:identity="http://www.topics.org/subjects/index.xml#Art-Europeen"
        TM:scope="http://www.topics.org/maps/Regions.xml#Europe">
  <Names TM:scope="EnglishNames">
   <Name>Art, European</Name>
   <Name>European Art</Name>
   <Name>History of European Art</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Art, Europeèn</Name>
   <Name>Histoire d'Art Europeèn</Name>
   <SortBy>Art, Europeen</SortBy>
  </Names>
 </Subject>
 <Subject id="EnglishNames">
  <Names>
   <Name>English Version of Names</Name>
   <Name>Name in English</Name>
  </Names>
 </Topic>
 <Subhect id="NomFrancais">
  <Names>
   <Name>Nom Français</Name>
   <SortBy>Nom Francais</SortBy>
  </Names>
 </Subhect>
 <Subject id="Class">
  <Names TM:scope="EnglishNames NomFrancais">
   <Name>Class</Name>
  </Names>
 </Subject>
 <Subject id="Member">
  <Names TM:scope="EnglishNames">
   <Name>Class Member</Name>
   <Name>Member (of class)</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Membre</Name>
  </Names>
 </Subject>
 <Subject id="Supertype"/>
 <Subject id="Subtype"/>
 <Subject id="ArtistClass">
  <Names TM:scope="EnglishNames">
   <Name>Artist</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Artiste</Name>
  </Names>
 </Subject>
 <Subject id="Painter">
  <Names TM:scope="EnglishNames">
   <Name>Painter</Name>
  </Names>
  <Names TM:scope="NomFrancais">
   <Name>Painteur</Name>
  </Names>
 </Subject>
 <!--Add application-specific topics here -->
 <Relationship TM:type="ClassMembership">
  <Supertype xlink:from="Painter"      xlink:to="ArtistClass">
  <Subtype   xlink:from="ArtistClass"  xlink:to="Painter"    >
 </Relationship>
 <!--Add application specific associations here -->
 <Language>
  <English>
   <!--Add locations for resources in English here -->
  </English>
  <French>
   <!--Add locations for resources in French here -->
  </French>
 </Language>
</SubjectMap>