Topic Navigation Map Architecture

The TNM syntax is a model for the interchange of information relevant to topics, associations, and facets; it uses SGML architectural forms based on HyTime hyperlinks. The Topic Navigation Map (TNM) syntax is defined according to the Architectural Form Definition Requirements of ISO/IEC 10744:1997 annex A.3. The notational conventions used herein are the same as those used in ISO/IEC 10744:1997 and described in clause of that Standard. The TNM syntax makes use of the base, location address, and hyperlinking modules of the HyTime architecture as defined in the same Standard.

The formal definition of the TNM syntax, the TNM meta-DTD, is found in normative Annex A of this Standard.

When interchanged, topic navigation maps are HyTime bounded object sets. The hub document of a bounded object set used as a topic navigation map must contain a TNM architectural support declaration.

An example of a TNM architectural support declaration is given in clause

Only one of the hyperlink syntaxes defined by HyTime is used in the TNM syntax: variable link (varlink). However, the TNM syntax imposes no limitation on the addressing mechanisms that can be used to express the locations of the objects serving as the anchors of the links. In addition to the specific addressing facilities formally defined by HyTime, any addressing scheme can be used, including proprietary mechanisms defined in any notation.

Topic Navigation Map Document Element Architectural Form

The topic map (topicmap) element form is used as the document element of all documents that conform to the Topic Map Architecture.

The added scoping topics (addscopt) attribute is used to acknowledge and document the fact that the document contains only topics that are within the scope that it specifies. The effect of a added scoping topics attribute is equivalent to the addition of scoping topics to scopes.

After a topic map document is merged with other topic maps, 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 scope of the topic specified by the added scoping topics attribute.

This same facility is also provided for external TNM document entities. See clause for additional information.

]]>

Topic link

The Topic Link Architectural Form

The topic link (topic) element form is used to declare a topic. A topic is a concept that is expressed as a set of zero or more names and zero or more relevant pieces of information (occurrences). The anchor roles of the link are used to specify the scope of the group of occurrences forming an anchor.

The type (type) attribute can be used to reference topics which describe the classes of topic of which the topic specified by the topic link is an instance. Topic map applications must consider the generic identifier of the element conforming to the topic link architectural form to be a name attached to the topics specified by the type attribute within the TOPICTYPE scope (see clause ). If there is no topic which explicitly has as one of its full names the generic identifier of the topic element within the scope of the TOPICTYPE public topic, topic map applications shall consider that such a topic exists implicitly.

The public (public) attribute optionally refers to a public topic (see clause ). The referenced public topic is said to be the same concept that the topic link element further describes.

The formal public identifier of the referenced public topic is regarded as a full name of the topic within the scope of the PUBLICTOPIC public topic.

A topic may have zero or more occurrences. If a topic has no occurrences, it must have at least one name. If a topic has one occurrence or more, it may have no name. See clause .

]]>

Topic Name

A topic may have zero or more names.

Each topic name element has up to three forms: full name, display name, and sort key, corresponding to the three element types that it can contain:

• The full name (fullname) is the usual name used to designate a topic. It can be a word or a phrase and should be explicit enough to help users differentiate the topic from others.

• The display name (dispname) is the name expected to be displayed by an application to a user. If it is not specified, applications are intended to display the full name.

  For example, the display name can be used to specify an abbreviated name.

• The name to be used as sort key (sortname) may be used when sorting a list of topics. If it is not specified, applications are intended to use the full name as the sort key.

The display name and sort key are regarded as additional names of the topic, implicitly within the additional scopes of DISPNAME and SORTKEY public topics declared in this Standard, respectively. The full name has no additional implicit scope.

The scope (scope) attribute of the name element is used to limit the context in which a name is attached to a topic. The scope attribute references the scoping topics that collectively define that limited context.

Since this context can be described by the intersection of several criteria, there can be more than one scoping topic that defines that limited context.

]]>

Topic Occurrence

A topic occurrence is any information object that is specified as relevant to the topic. This standard imposes no constraints on the information objects that can be specified as topic occurrences.

Applications may impose such constraints.

Topic occurrences must be categorized by grouping them into sets which share common characteristics, called their occurrence roles. These groupings are specified by topic occurrence (occur) elements; these elements conform to the HyTime anchspec architectural form.

One example of an occurrence role is definition. The names used to designate occurrence roles are left open to the topic map designer.

Any given information object can play zero or more occurrence roles in a single topic.

The occurrence role name of an occur element (or, when its occurrence role name is not specified, the generic identifier of this occur element) declares the limited contexts within which a topic has the occurrences referenced by this occur element.

The optional scope (scope) attribute specifies the limited contexts within which a topic has the occurrences referenced by the element's content, by referencing one or more scoping topics. If the scope attribute is specified, the scope that it specifies is regarded as the specification of the occurrence role declared by the occur element. If the scope attribute is specified, the value of the occrole attribute, if any, is ignored.

Applications may regard each scoping topic specified via the scope attribute as describing a class of occurrence, and each of the occurrences whose locations are specified in the content of the element as an instance conforming to those classes.

If the scope attribute is not specified, the value of the occurrence role name (occrole) attribute specifies the limited contexts within which the information objects referenced in the content of the occur element are regarded as occurrences of the topic. If the occrole attribute is not specified, the generic identifier is regarded as the occurrence role name. The topic link that has the occurrence role name as a full name within the scope of the OCCROLE public topic describes the occurrence role declared by the occur element. If no such topic link exists, such a topic will be automatically created by the TNM application as an implicit topic.

]]>

Association link

Association link architectural form

The association link (assoc) element form is used to express arbitrary relationships between topics. The anchor roles of association links are user-defined.

The scope (scope) attribute optionally references topics that define the scopes within which the association is applicable to the topics that serve as anchors of the association link.

The type (type) attribute can be used to reference topics which describe the classes of association of which the association specified by the association link is an instance. In addition, topic map applications must consider the generic identifier of the element conforming to the association link architectural form to be a name attached to a topic within the ASSOCTYPE scope (see clause ). If there is no topic which explicitly has as one of its full names the generic identifier of the assoc element) within the scope of the ASSOCTYPE public topic, topic map applications shall consider that such a topic exists implicitly.

The public (public) attribute optionally refers to a public association type. The assoc element is considered to be an instance of the class of association defined by an authority (see clause ). ]]>

Association role

The association role (assocrl) element form specifies a user-defined role played by one or more specific topics in the association specified by the containing association link element. The topics that play the role, if any, are referenced by means of the location addresses specified in the content of the association role element.

The type (type) attribute can be used to reference topics which describe the role classes of which the role specified by the association role is an instance. Topic map applications must consider the value of the anchrole attribute (or, if the anchrole attribute is not specified, the generic identifier of the association role element) to be a name attached to a topic within the ASSOCRLTYPE scope (see clause ). If there is no topic which explicitly has as one of its full names the value of the anchrole attribute (or, by default, the generic identifier) of the assocrl element) within the scope of the ASSOCRLTYPE public topic, topic map applications shall consider that such a topic exists implicitly.

]]>

Facet link

By means of the facet link facility, property/value pairs can be added to information objects. The properties are called facet types, and the values are called facet values.

The property/value pairs applied by facet links can be used, for example, as selection criteria to create partial views of the information within a topic map bounded object set. However, this International Standard does not constrain applications of facet links.

Facet types and facet values can be described by topics.

Facet link architectural form

The facet link (facet) element form is used to apply a property/value pair to an object. Facet link types (type) and values (fvalue) are user-defined.

The type (type) attribute can be used to reference a topic which describes the property specified by the facet link. Topic map applications must consider the generic identifier of the element conforming to the facet link architectural form to be a name attached to the topic specified by the type attribute within the FACETTYPE scope (see clause ). If the type attribute is not specified, and if there is no topic which explicitly has as one of its full names the generic identifier of the facet element within the scope of the FACETTYPE public topic, topic map applications shall consider that such a topic exists implicitly.

]]>

Facet value

The facet value (fvalue) element form is used to specify the value of a property being applied to an information object by means of a facet link. The facet value is the string specified by the value of the facet value name (facetval) attribute.

The type (type) attribute can be used to reference a topic which describes the facet value. Topic map applications must consider the value of the facetval attribute (or, by default, the generic identifier of the element conforming to the facet value architectural form) to be a name attached to the topic specified by the type attribute within the FACETVALDESC scope (see clause ). If the type attribute is not specified, and there is no topic which explicitly has as one of its full names the value of the facetval attribute (or, by default, the generic identifier of the fvalue element) within the scope of the facetvaldesc public topic, topic map applications shall consider that such a topic exists implicitly.

Unlike other type attributes, this type attribute can reference only one topic.

]]>

Common data attributes

Added scoping topics

The added scoping topics (addscopt) common data attribute allows scopes to be added throughout a TNM document entity. If specified, the attribute appears on an entity declaration of a TNM document entity. Its 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 implicit scopes on all names of topics, occurrences of topics, and topic association links throughout the referenced TNM document. However, regardless of any applicable addscopt data attribute, no implicit scopes are added to topic names for which no explicit scopes are already directly specified; each such name remains in its own namespace.

When topic maps have been merged, this facility can be used 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 the addscopt data attribute, that topic can be used as an additional scope within which everything specified by the topic map is implicitly said to exist. After the topic map is merged with other topic maps, 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.

This facility extends to external documents the added scoping capability afforded by the addscopt attribute of the topicmap TNM document element architectural form; see clause .

At the time of adoption of this International Standard, XML did not support data attributes. This feature for facilitating the automatic merging of topics maps is not, therefore, available to XML applications, which will be required to merge topic maps manually.

> ]]>

TNM Resources

Public Topics

A public topic is a concept identified by means of a formal public identifier, and referenced by means of the public attribute on a topic element. The concept is defined by the authority specified in the formal public identifier; the authority controls the namespace in which the topic has the name which also appears in the formal public identifier.

Public topics can be unambiguously used in many contexts, wherever the authority is recognized.

There are two reasons why public topics are needed:

1. to allow authors of topic navigation maps to indicate that certain topics are defined authoritatively.

   This ability can facilitate the merging of topic maps that share certain concepts.

2. to qualify, using the public identifiers defined in those topics which play a specific role in the TNM architecture.

When a topic specifies a value for its public attribute, and also has names and/or occurrences, the names and/or occurrences are considered to further elucidate the concept referenced by the public attribute; they do not alter or override any aspect of the concept as defined by the authority.

This Standard can be used as the authority for certain public topics. See clause .

Public Topic References

Formal public identifiers used to reference public topics have the following format:

In the above format specification, the registration indicator, public text class and language fields are as specified for formal public identifiers in ISO/IEC 8879:1986. The topic authority is the owner of the information resource that defines the concept. The TOPIC keyword indicates that the formal public identifier specifies a public topic. The namespace of topic names identifies the resource in which the topic name is the unique name given to the concept.

When a value is specified for the public attribute of a topic element, it is the name of a public topic entity.

For example, a topic which is a product of an unregistered company might be referenced as follows:

... ]]>

The public identifier can also be expressed in terms of the Internet Domain Name (IDN) identifier of the topic authority, as the following example shows:

... ]]>

Public Topics defined by this Standard

DISPNAME

The DISPNAME public topic defines the additional and implicit scope in which the names specified in display name elements are attached to their respective topics. Names attached to topics within this scope are expected by topic map authors to be displayed by applications to users.

References to the DISPNAME public topic can be made in entity declarations using the following formal public identifier:

SORTKEY

The SORTKEY public topic defines the additional and implicit scope in which the names specified in name to be used as sort key elements are attached to their respective topics. Names attached to topics within this scope are expected by topic map authors to be used in sorting lists of topic.

References to the SORTKEY public topic can be made in entity declarations using the following formal public identifier:

TOPICTYPE

The TOPICTYPE public topic is defined by this Standard in order to make explicit the scope in which the generic identifiers of topic link elements are assigned as names to the topics that define classes of topics.

References to the TOPICTYPE public topic can be made in entity declarations using the following formal public identifier:

OCCTYPE

The OCCTYPE public topic is defined by this Standard in order to make explicit the scope in which occurrence role names are assigned to the topics that define their meanings.

References to the OCCTYPE public topic can be made in entity declarations using the following formal public identifier:

PUBLICTOPIC

The PUBLICTOPIC public topic is defined by this Standard in order to to be used as a scoping topic in the scope in which the formal public identifiers of public topics are assigned as names to those topics.

References to the OCCTYPE public topic can be made in entity declarations using the following formal public identifier:

ASSOCTYPE

The ASSOCTYPE public topic is defined by this Standard in order to make explicit the scope in which the generic identifiers of association links are assigned as names to the topics that define their meanings.

References to the ASSOCTYPE public topic can be made in entity declarations using the following formal public identifier:

ASSOCRLTYPE

The ASSOCRLTYPE public topic is defined by this Standard in order to make explicit the scope in which association role names (specified via the anchrole attribute of assocrl elements, or, by default, via their generic identifiers) are assigned as names to the topics that define their meanings.

References to the ASSOCRLTYPE public topic can be made in entity declarations using the following formal public identifier:

FACETTYPE

The FACETTYPE public topic is defined by this Standard in order to make explicit the scope within which the generic identifiers of facet links are assigned as names to the topics that define their meanings.

References to the FACETTYPE public topic can be made in entity declarations using the following formal public identifier:

FACETVALDESC

The FACETVALDESC public topic is defined by this Standard in order to make explicit the scope within which facet values (specified via the facetval attribute of fvalue elements, or, by default, via their generic identifiers) are assigned as names to the topics that define their meanings.

References to the FACETVALDESC public topic can be made in entity declarations using the following formal public identifier:

Public Association Types

A public association type is a class of association identified by means of a formal public identifier, and referenced by means of the public attribute on an association link element. The public association type is defined by the authority specified in the formal public identifier; the authority controls the namespace in which the association type has the name which also appears in the formal public identifier.

Public association types can be unambiguously used in many contexts, wherever the authority is recognized. Public association types are needed to allow authors of topic maps to indicate that certain associations are defined authoritatively by others.

The use of public association types can facilitate the merging of topic maps.

When an association link specifies a value for its public attribute, the anchrole names of enclosed occurrence roles that are the same as those that appear in the formal public identifier of the public association attribute correspond to the anchroles authoritatively defined by the public association type. Other anchroles, if present, do not alter or override any aspect of the public relationship type as defined by the authority. Similarly, if an association link also specifies a type attribute, the topic(s) referenced by the type attribute further elucidate, but do not alter or override, the character of the association type as defined by the authority.

Public Association Type References

Formal public identifiers used to reference public association types have the following format:

In the above format specification, the registration indicator, public text class and language fields are as specified for formal public identifiers in ISO/IEC 8879:1986. The association type authority is the owner of the information resource that defines the concept. The ASSOCTYPE keyword indicates that the formal public identifier specifies a public association type. The namespace of association type names identifies the resource in which the association name is the unique name given to the concept. There must be two or more colon-delimited association role names. These are the names that will be used as association role names in the topic map document, and they are not necessarily the association role names given to the association roles by the association type authority. However, there must be the same number of them as the authority defines in its canonical definition of the association type, and the order in which they appear in the formal public identifier will be regarded by topic map applications as corresponding to the order in which the authority specifies them in its canonical definition.

The topic map designer has complete freedom in naming both associations and association roles, even if the association is said to conform to a public association type.

When a value is specified for the public attribute of an association link element, it is the name of a public association type entity.

For example, an association type defined by an unregistered company might be referenced as follows:

... ... ... ]]>

As a practical matter, it is vital that the authority's definition of the public association type declare the order in which the anchroles will appear in any formal public identifier used to refer to that public association type, and that it clearly define the meaning of the association type and the significance of each of its anchroles. This can be done in many ways, and the representation need not be machine-processable. The following example, an excerpt from the imaginary Lawyer's Topic Mapping Manual referenced in the above formal public identifier, demonstrates one way to do it:

It is worth noting that the above exemplary definition of an association type suggests different names for the association roles than were used in the previous example, which shows this imaginary public association type in actual use. They are still exactly the same roles, and there is no possibility of confusion because they still occur in the same order. This flexibility allows public association types that are defined in one natural language to be used conveniently in topic maps maintained by authors whose primary language is another. Similarly, while it is true that the name of the association type (PRECEDENT) must appear verbatim in the formal public identifier, this, too, need have no effect on the topic map; the local entity name given to the public association type can be any name in any language.

Public association types defined by this Standard

(No public association types are defined by this Standard.)

Commercial interests, knowledge management experts, and domain experts are encouraged to develop useful sets of public association types.

Conformance

If a TNM document complies with all provisions of this International Standard, is a conforming SGML document as defined in ISO 8879, and is a conforming HyTime document as defined in ISO/IEC 10744, it is a conforming TNM document.

A conforming application intended to use existing topic maps must be able to:

• parse the interchange syntax,

• identify the TNM constructs defined by this Standard, 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 Standard.

A conforming application intended to create topic maps must be able to export the information expressible using the constructs defined by this International Standard in conformance with the syntax of those constructs.

A conforming application intended to read and write 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.

This Standard 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).