ISO/IEC JTC 1/SC34 N0243

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title: Topicmaps.net's Processing Model for XTM 1.0, version 1.0.1
Source: Steve Newcomb and Michel Biezunski
Project: ISO/IEC 13250:2000
Project editor: Michel Biezunski, Martin Bryan, and Steve Newcomb
Status: Personal contribution
Action: For Information
Date: 11 August 2001
Summary:
Distribution: SC34 and Liaisons
Refer to:
Supercedes:
Reply to: Dr. James David Mason
(ISO/IEC JTC1/SC34 Chairman)
Y-12 National Security Complex
Information Technology Services
Bldg. 9113 M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
E-mailk: mailto:[email protected]
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm

Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
11 West 42nd Street
New York, NY 10036
Tel: +1 212 642 4976
Fax: +1 212 840 2298
E-mail: [email protected]


TopicMaps.net is an informative Topic Maps website maintained by
Michel Biezunski (InfoLoom) and
Steven R. Newcomb (Coolheads Consulting)

Topicmaps.net's Processing Model for XTM 1.0, version 1.0.1

A Processing Model for XML Topic Maps

Steven R. Newcomb, [email protected] and
Michel Biezunski, [email protected]

This version (1.0.2) is dated July 25, 2001. Changes since version 1.0.1 (March 25, 2001) appear in red. So far, all changes are just clarifications that were suggested by questions raised by implementers of this model.

Topicmaps.net's Processing Model for XTM 1.0 provides an explanation of the meaning of XTM syntax which is entirely true to the vision that has guided the authors in discovering, teaching, developing and testing the topic map paradigm.

This version of Topicmaps.net's Processing Model for XTM 1.0 illustrates only the processing of topic map documents that conform to the XTM 1.0 Specification (i.e., XTM <topicMap> elements). Future efforts will additionally discuss the processing of other syntaxes for interchanging topic map information, including the interchange syntax (meta-DTD) specified by ISO/IEC 13250:2000.

The authors gratefully acknowledge the contributions and counsel of Sam Hunting, Victoria T. Newcomb and Peter Newcomb.

Previous versions of this material once appeared in drafts of the XTM 1.0 Specification published at http://www.topicmaps.org. This version is licensed to the public for all purposes and in every way.

The authors request that all copies and translations of Topicmaps.net's Processing Model for XTM 1.0 be complete and correct, including this and all other notices, and including attribution to the authors by names and e-mail addresses, please. The authors also request that any claims of conformance to Topicmaps.net's Processing Model be accurate. Either a processing system conforms to the model exactly and comprehensively in every detail, or it does not conform, and no claim of conformance is justified.

A verbose tutorial-style glossary is attached.

1.0 Purpose of This Processing Model

Topicmaps.net's Processing Model for XTM 1.0 defines a set of rules for processing topic map documents in order to reconstitute the meaning of the information they are intended to convey to their recipients. It could be used as a partial blueprint for a topic maps application, but that is not its primary purpose. Its primary purpose is merely to illustrate, in a rigorous fashion, the authors' deepest understanding of the meaning of topic map information.

In Topicmaps.net's Processing Model for XTM 1.0, the result of processing <topicMap> elements is described in terms of "topic map graphs" that consist of "nodes" and "arcs" which connect the nodes in certain ing Rule, it is irrelevant whether two subject indicator resources, or two subject constituting resources, contain the same data or are the same string. A simple string comparison of the two subject indicator resources is not, in the general case, a reliable indication of whether or not the same subject is being described. For example, different products in different sales catalogs may coincidentally have the same catalog number, and a comparison of the two catalog numbers does not indicate that they are the same product. Therefore, the Subject-based Merging Rule is not based on comparing the data content of the resources that serve as identity points. Merging must occur if and only if:

  1. either both subject identity points are subject indicators, or both subject identity points are subject constituters (i.e., they can't be mixed), and

  2. they are one and the same resource, meaning that they exist in exact same addressable context, even though there may be multiple different equivalent addressing expressions that can arrive at that same resource in that same addressable context.

Note: No merging should occur if the addressed information turns out to be different, because in such a case, it's obvious that the two resources are not the same resource. However, the point of this discussion is that the fact that the addressed information turns out to be the same string cannot be regarded as an indication that merging should occur.

Note: If merging on the basis of string comparisons is desired, exploitation of the Name-based Merging Rule should be considered. That, after all, is its purpose!

Topicmaps.net's Processing Model for XTM 1.0 requires topic map applications to be able to compare internet addresses, under the normal rules of internet addressing, in order to determine whether they address the same resource. For example, when, in an internet address, case is universally nonsignificant (as in the case of internet domain names), topic map processing systems are required to ignore case differences when comparing internet addresses in order to determine whether they address the same resource.

Note: Topic map processors may, but are not required, also to apply various heuristics, such as automatically assuming that an address that is not prefixed by a scheme name, but begins with the characters "www.", should be regarded as beginning with "http://". Topic map processors may also take advantage of cataloging services and resources in order to establish whether or not two addresses are equivalent. This is an appropriate arena for competition between system vendors whose systems conform to Topicmaps.net's Processing Model for XTM 1.0.

During topic map processing, it may be necessary to apply the Subject-based Merging Rule repeatedly. This is because merging may also occur on the basis of the Name-based Merging Rule, and the effect of such merging may require further merging under the Subject-based Merging Rule.

Note: And vice versa.

8.0 The Name-based Merging Rule

The "topic naming constraint", which applies to all topic maps and on which the "Name-based Merging Rule" is based, can be expressed in terms of Topicmaps.net's Processing Model for XTM 1.0 in the following way:

No two t-nodes and/or a-nodes can have the same basename in the same topic namespace (i.e., the same scope). (To "have a basename" is to play the "topic" role in a "topic-basename" association in which the resource that plays the "basename" role is the addressable subject (the subject constituting resource) of the topic that plays the "basename" role. The scope of the "topic-basename" association is, in effect, a namespace consisting of all of the topic-basename associations that have that scope.)

The Name-based Merging Rule requires that if, during topic map processing, two or more t-nodes (and/or a-nodes) are found to have the same basename in the same scope, the two nodes must be merged to become a single node, which will become the only t-node or a-node that has that name in that scope (topic namespace).

Syntactically (i.e., within a <topicMap> element), each basename is the content of a <baseNameString> element.

Note: Remember, as with all other subject identity points, the nature of the connection, if any,

from

the topic whose subject is the content of a <baseNameString> element (and that also plays the "basename" role in a "topic-basename" association),

to

the actual content of the <baseNameString> element

is not defined by Topicmaps.net's Processing Model for XTM 1.0.

In the topic map graph, the scope of a "topic-basename" association (i.e., the ">s-node whose set of "component" topics constitutes the scope of the "topic-basename" association) is the set of topics specified via the <scope> element that is the child of the <baseName> element.

Note: Other basenames for other topics, as well as other names for the same topic, may also appear in this same topic namespace. When a topic namespace is used by a user of the topic map graph to find a t-node or a-node by means of one of its basenames, the act of selecting a basename in that topic namespace is, in fact, the act of selecting the topic that has that basename in that namespace, because only one topic can have any given name in any given namespace.

All "topic-basename" associations are templated in an XTM-defined "topic-basename" association template whose published subject indicator may or may not still be available at http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-topic-basename. (The handling of basenames and variant names is fully described later in Topicmaps.net's Processing Model for XTM 1.0.)

During topic map processing, it may be necessary to apply the Name-based Merging Rule repeatedly. This is because merging may also occur on the basis of the Subject-based Merging Rule, and the effect of such merging may require further merging under the Name-based Merging Rule.

Note: And vice versa.

9.0 The "No Redundancies" Rule

The primary purpose of topic maps is to enhance the exploitability and manageability of a superabundance of information. Among other things, this means minimizing redundancy.

When topic map graph construction is complete, there are no duplicate entries in any set. Here is a list of sets of things in which duplicate entries are forbidden:

  • The set of subject indicator resources of any given t-node.

  • The set of s-nodes. No two s-nodes can represent the same scope. That is, no two s-nodes can serve as the "scope" ends of a set of a "scope component arcs", the set of whose "component" ends is the same set of topics. If, as a side-effect of some benighted implementation algorithm, after all scoping specifications in some (set of) interchangeable <topicMap> element(s) have been fully understood and accounted for, two s-nodes represent the same scope, they must be merged, becoming a single s-node.

    Note: By definition, then, there can also be no duplication of topic namespaces, because s-nodes define topic namespaces.
    Note: S-nodes also define topic occurrence "spaces", and "spaces" for every other kind of association, too. This raises interesting information-management possibilities. In the minds of the authors of Topicmaps.net's Processing Model for XTM 1.0, anyway, the way in which s-nodes gather all kinds of resource relationships together is one of the most interesting features of Topicmaps.net's Processing Model for XTM 1.0.

  • The set of a-nodes. Two a-nodes are different (not redundant) if any one or more of the following statements is true:

    • There are any differences in the sets of topics that play each of the roles.

    • The associations have different association templates. Association templates are different if they are represented by different t-nodes.

    • The associations have different roles. Roles are different if they correspond to different t-nodes.

    If none of the above statements are true, the two a-nodes must be merged into a single a-node, even if they have different scopes. If they do have different scopes, the resulting merged a-node will serve as the "association" end of the union of the sets of "association scope" arcs of which the two a-nodes had been the "association" ends.

  • The set of t-nodes and a-nodes that play any given role as members of any given a-node.

  • The set of t-nodes and a-nodes that comprise any given scope.

  • The set of roles defined for a given association template. Two roles are different if the roles are the subjects of different t-nodes.

10.0 The "Node Demander is a Subject Indicator" Rule

One of the features of the correspondences between

  • all of the syntactic constructs found in instances of <topicMap> elements, and

  • the "topic map graph" described in Topicmaps.net's Processing Model for XTM 1.0

can be expressed as follows:

"Every node demander is a subject indicator."

This means that when a topic map construct, when encountered by a topic map graph building process, demands that that process create (or add characteristics to) a t-node or an a-node, that t-node or a-node must regard that syntactic topic map construct as one of its subject indicators. This mechanism enables the handling of every addressable resource (for example) as a topic (i.e., a t-node), even if no <topic> element corresponds to that t-node. Thus, every information resource that serves as an occurrence of a topic is in fact itself a topic whose subject is the information resource, and the connection that binds the topic with one of its occurrence is seen as a "topic-occurrence" association between two topics:

  1. the topic element itself, playing the "topic" role, and

  2. the topic whose subject is the occurrence, playing the "occurrence" role.

    Note: One effect of this rule is to make every a-node and t-node, in effect, syntactically addressable in such a way as to permit characteristics to be added to it -- regardless of whether it happens to be represented syntactically as a <topic> or as an <association>. Such additional characteristics can be added by providing a <topic> or <association> element that regards the node demander as one of its subject indicator resources.

    Note: Another effect of this rule is to make it unnecessary to make any special provision for the XTM semantic rule that, when a <topicRef> or <subjectIndicatorRef> refers to a <topic> or <association> element that forms part of the input to the topic map graph construction process, it is referring to the subjects that they indicate, and it regards them, therefore, as subject identity points. The reason that no special provision needs to be made is that <topic> and <association> elements are node demanders.

11.0 Impact of Each XTM Element on the Topic Map Graph

The following is an element-type-by-element-type discussion of the handling of <topicMap> elements that conform to the DTD provided in the XTM 1.0 Specification.

11.1 <topicMap> and <mergeMap> Elements

All XTM graph construction processes begin with a single "initial" <topicMap> element. The entire content of the initial <topicMap> element is processed in accordance with Topicmaps.net's Processing Model for XTM 1.0.

The initial <topicMap> element may contain <mergeMap> elements, in which case the <topicMap> elements referenced by such <mergeMap> elements also become inputs to the graph construction process, recursively. This is the means whereby topic maps are merged.

Note: The order in which the referenced <topicMap> elements are processed is not constrained by Topicmaps.net's Processing Model for XTM 1.0.

Such <mergeMap>-referenced <topicMap> elements are called "subordinate" <topicMap> elements in Topicmaps.net's Processing Model for XTM 1.0, while the main <topicMap> element which serves as wrapper for the <mergeMap> elements is called the "initial" <topicMap> element.

The processing of subordinate <topicMap> elements is exactly like the processing of initial <topicMap> elements, except that if a <mergeMap> element has children, the t-nodes and/or a-nodes that correspond to the references made in that content are added to the scopes of all of the topic characteristics declared in the <topicMap> element referenced by the xlink:href attribute of the applicable <mergeMap> elements, recursively.

11.2 <topic> Elements and Their Descendants

11.2.1 Handling of <topic> Element as a Whole

Each <topic> element demands the existence of a corresponding t-node.

11.2.2 Handling of <instanceOf> Element in <topic> Element

Each <instanceOf> element that is the child of a <topic> element implicitly demands the existence of an a-node whose association template is an instance of the "class-instance" association template. (One of this template's published subject indicators must be http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-class-instance, which is a template for class-instance associations.)

In each such a-node, the t-node whose existence is explicitly demanded by the containing <topic> element plays the "instance" role, and the t-node or a-node whose existence is implicitly demanded by the referencing element contained in the <instanceOf> element plays the "class" role; the subject of this topic is said to be the "topic type". The scope of the "class-instance" a-node is the unconstrained (null set) scope, plus any additional scoping topics specified by any applicable <mergeMap> elements.

Note: The exact same class-instance relationship, resulting in the same impact on the graph, can be expressed via an <association> element that is templated by the same class-instance template. The advantage of using an explicit <association> element is that this makes to possible to specify a scope, and this scope need not be the unconstrained scope.

11.2.3 Handling of <subjectIdentity> Element in <topic> Element

The t-node whose existence is explicitly demanded by a <topic> element may have either:

Note: The above two bullet points are intended to say that a topic's subject can either be addressable or non-addressable, but not both. (A topic always has exactly one subject, and no single subject can be both addressable and non-addressable.) If the subject is addressable, then exactly one of the topic's subject identity points must be the addressable subject (i.e., the subject-constituting resource) itself, and, in addition, there will also be one or more subject indicators for the same addressable subject. (The "node demander is a subject indicator" rule guarantees that there is always at least one subject indicator, even if the subject is addressable.) If the subject of a topic is not addressable, then none of the identity points of the topic can be a subject-constituting resource. Again, however, because of the "node demander..." rule, there is always at least one subject indicator, and there may be any number of additional subject indicators.

When the children of the <subjectIdentity> element include a <resourceRef> element, the subject of the t-node is the referenced resource itself -- not what the resource can be interpreted to mean; the reference resource is a "subject constituting resource", because the resource itself constitutes the subject. The referenced resource is a subject identity point for the t-node.

It is a reportable error if topic map processing results in a t-node having more than one subject constituting resource.

If a t-node's subject identity points do not include a subject-constituting resource (also known as an "addressable subject"), then the subject is a "non-addressable subject" which can only be "indicated" by each of the resources referenced by the <subjectIndicatorRef> elements that are the children of the <subjectIdentity> element. Each of the referenced resources is considered to be capable of separately and compellingly indicating the subject of the topic.

If any of the resources referenced by a <subjectIndicatorRef> element is itself a <topic> element, the subject of the referenced <topic> element is considered to be the same subject as the subject of the <topic> element that contains the <subjectIdentity> element that contains the <subjectIndicatorRef> element, and the two t-nodes whose existence is explicitly demanded by the two <topic> elements will be merged under the governance of the Subject-based Merging Rule. If one or more <topicRef> elements appear within a <subjectIdentity> element contained in a <topic> element, each of them is treated as if it were a <subjectIndicatorRef> element (see the beginning of this paragraph). Whether or not there is a <subjectIdentity> element, there is at least one subject indicator, which is the <topic> element (or whatever element demanded the existence of the node, implicitly or explicitly).

11.2.4 Handling of <baseName> Element in <topic> Element

11.2.4.1 Handling of <baseNameString> Element in <baseName> Element

Each <baseNameString> child element of a <baseName> element implicitly demands the existence of a t-node. The resource constituting the subject of that t-node is the content of that <baseNameString> element. In Topicmaps.net's Processing Model for XTM 1.0, such a t-node is called a "baseNameString t-node."

11.2.4.2 Handling of <baseName> Element as a Whole

Each <baseName> element child of a <topic> element implicitly demands the existence of an a-node (the "topic-basename a-node") whose association template is the XTM-defined "topic-basename" association template. (The published subject indicator of the template may or may not still be available at http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-topic-basename.) In this a-node, the t-node whose existence is explicitly demanded by the parent <topic> element plays the role of "topic", and the baseNameString t-node plays the role of "basename". The scope of the topic-basename a-node is the set of topics specified via the <scope> element child of the <baseName> element, plus any topics required to be added to that scope by virtue of any applicable <mergeMap> elements. If no <scope> element is specified, and no scoping topics are added to the scope by <mergeMap> elements, the scope is the unconstrained (null set) scope. (As always in the topic map graph, the scope is represented by an s-node that is connected to the a-node by an "association scope" arc.)

11.2.4.3 Handling of <variant> and <variantName> Elements in <baseName> Elements

The variant names specified via <variantName> elements within the same <baseName> element do not become basenames in the graph, and the topic naming constraint does not apply to variant names.

Each <variantName> element implicitly demands the existence of a t-node whose subject identity is that <variantName> element, considered as a resource (i.e., not considered in terms of the subject it might be interpreted to mean). In Topicmaps.net's Processing Model for XTM 1.0, such a node is called a "variant name t-node".

Like all a-nodes, each "topic-basename" a-node can play roles in (i.e., have membership in) the relationships represented by other a-nodes. In the topic map graph, each variant name t-node plays the role of "variantname" in an a-node of class "basename-variantname" in which the "topic-basename" a-node plays the "basename" role. As with all a-nodes, the scope of each such "basename-variantname" a-node is represented in the graph as an s-node that is connected to the a-node via an "association scope" arc. The s-node represents a scope that includes all of the topics in the scope of the "topic-basename" a-node whose existence is implicitly demanded by the containing <baseName> element, and, in addition, the scope also includes all of the t-nodes and a-nodes whose existence is demanded by the referencing elements contained in all of the <parameters> elements that appear within all of the <variant> elements within which the <variantName> element that corresponds to the variant name t-node appears as a direct descendant.

11.2.5 Handling of <occurrence> Elements in <topic> Elements

11.2.5.1 Handling of <resourceRef> and <resourceData> Elements in <occurrence> Element

Each <resourceRef> and <resourceData> child of an <occurrence> element implicitly demands the existence of a t-node. For a <resourceRef> element, the t-node whose existence is implicitly demanded has the resource that is referenced by that element as its subject constituting resource. For a <resourceData> element, the t-node whose existence is implicitly demanded has the <resourceData> element's content as its subject constituting resource. (Cf. the discussion of the handling of <baseNameString> elements.)

11.2.5.2 Handling of <occurrence> Element as a Whole

Each <occurrence> element child of a <topic> element implicitly demands the existence of an a-node of class "topic-occurrence". In this association, the t-node whose existence is explicitly demanded by the parent <topic> element plays the role of "topic". The "occurrence" role is played by the t-nodes whose existence is implicitly demanded by the <occurrence> element's <resourceRef> and/or <resourceData> children. The scope of the "topic-occurrence" a-node is the scope specified by the <scope> element child of the <occurrence> element, plus any topics specified by any applicable <mergeMap> elements.

11.2.5.3 Handling of <instanceOf> Element in <occurrence> Element

The <instanceOf> element, if any, that is a child of an <occurrence> element implicitly demands the existence of an a-node of class "class-instance". In this class-instance association, the "topic-occurrence" a-node whose existence is implicitly demanded by the parent <occurrence> element plays the role of "instance". The role of "class" is played by the t-node whose existence is implicitly demanded by the child of the <instanceOf> element. The scope of the "class-instance" a-node is the unconstrained scope (the null set), plus any topics specified by any applicable <mergeMap> elements.

11.3 <association> Elements and Their Descendants

Each <association> element explicitly demands the existence of an a-node. The scope of the a-node is the scope specified by the scope element that appears as a child of the <association>, plus any topics added to the scope by any applicable <mergeMap> elements.

11.3.1 Handling of <instanceOf> Element in <association> Element

There are two possibilities:

  1. The <instanceOf> contains a <topicRef> or <subjectIndicatorRef> to an association template topic. This is true if and only if the referenced topic plays the "template" role in one or more "template-role-rpc" associations.

    In this case, there must be an "association template" arc in the graph. In this arc, the association template t-node must serve as the "template" end, and the a-node whose existence is demanded by the <association> element that contains the <instanceOf> element must serve as the "association" end.

  2. The topic referenced within the <instanceOf> is not an association template topic.

    In this case, a "class-instance" a-node must be created in the graph, in which the "instance" role is played by the a-node whose existence was explicitly demanded by the containing <association> element, and the "class" role is played by the t-node whose existence is demanded by the reference made in the content of the <instanceOf>. It is a reportable error if the "class" role is played by an a-node.

11.3.2 Handling of <member> Element in <association> Element

Each referencing element (a <topicRef>, a <resourceRef>, or a <subjectIndicatorRef>) that is the child of a <member> element demands the existence of an "association member" arc, in which the a-node whose existence is explicitly demanded by the containing <association> element serves as the "association" end, and in which the "member" end is the t-node or a-node whose existence is demanded by the referencing element that is a child of the <member> element.

In the case of <resourceRef> elements, the t-node that serves as the "member" end of the "association member" arc has the referenced resource as its subject constituting resource.

In the case of <subjectIndicatorRef> elements, the t-node or a-node that serves as the "member" end of the "association member" arc has the referenced resource as one of its subject indicator resources. If the <subjectIndicatorRef> element references a <topic> element, the t-node whose existence is explicitly demanded by that <topic> element serves as the "member" end of the "association member" arc.

In the case of <topicRef> elements, just as in the case of <subjectIndicatorRef> elements, the t-node whose existence is explicitly demanded by that <topic> element serves as the "member" end of the "association member" arc.

It is a reportable error if a <topicRef> element references any resource that is not a <topic> element that is subject to topic map processing such that it explicitly demands the existence of a t-node in the graph. (In other words, <topicRef> elements must reference <topic> elements that appear in <topicMap> elements that are used as input to the topic map graph construction process.)

The label of an "association member" arc whose existence is demanded by the content of a <member> element is the t-node (the "role t-node") whose existence is implicitly demanded by the referencing element (<topicRef> or <subjectIndicatorRef>) that is the child of the <roleSpec> element whose parent is the <member> element. The subject of the referenced topic is the role played by the t-node or a-node that serves as the "member" end of the "association member" arc. In the case of a <subjectIndicatorRef> element that is the child of the <roleSpec> element, the role t-node has the referenced resource as at least one of its subject indicator resources. If the <subjectIndicatorRef> references a <topic> element, the t-node whose existence is explicitly demanded by that <topic> element is the role t-node. In the case of a <topicRef> element, just as in the case of <subjectIndicatorRef> elements, the t-node whose existence is explicitly demanded by the referenced <topic> element is the role t-node.

It is a reportable error if the a-node whose existence is explicitly demanded by an <association> element is the "association" end of an "association template" arc (i.e., if an association template is in effect), and either:

  • any <member> element contained in the <association> element fails to specify, by means of a child <roleSpec> element, which role that member corresponds to in the template, or

  • the <roleSpec> element does not reference one of the topics that the template specifies as a role, or

  • the <roleSpec> element references any topic other than a topic that the template specifies as a role, or

  • any of the members of the association fails to meet the template-specified constraints for members playing the roles they are specified as playing.

Glossary

a-node (association node)

[Synonym: association.] An a-node is a node in a topic map graph that represents an association. Like t-nodes, a-nodes may serve as the "member" ends of "association member" arcs, and as the "component" ends of "scope component" arcs. A-nodes never serve as the "template" ends of "association template" arcs (only t-nodes can do that), nor as the "scope" ends of "association scope" arcs (only s-nodes can do that). In a topic map graph, topic names and topic occurrences are connected to their respective topics by a-nodes which are instances of the "topic-basename" association template and the "topic-occurrence" association template, respectively. (These templates may or may not still have corresponding PSIs maintained by TopicMaps.Org; they did not appear in the second version of the XTM 1.0 Specification.)

Note: Not all a-nodes are demanded by <association> elements. A-nodes are also demanded by other element types.

addressable information resource

[Synonym: resource.] An information resource that is retrievable by some systematic means, using one or more addresses expressed in one or more rigorous formal addressing schemes. Implementations of the topic maps paradigm should determine, to the maximum extent possible, whether two addressable information resources are in fact the same or different (i.e., whether they both have the same addressing context; the fact that they are the same data cannot serve as an indication that they are the same resource, but if they return different data, they are definitely not the same resource.

At minimum, topic map implementations are required to be able to compare two addresses of information resources (e.g., two URIs) and determine whether the resources being addressed are one and the same resource, according to the syntactic rules of the addressing expression language itself. For example, in the case of URI expressions on the Web, the URIs "http://www.TOPICMAPS.net" and "http://www.topicmaps.net" necessarily address, because the case of the characters used in Internet domain names is always nonsignificant. They are one and the same resource if and only if it is true that the two addressing expressions will always resolve to one and the same copy (to whatever extent "copy" is an applicable notion in some application context).

The ability to recognize that non-identical addressing expressions are in fact equivalent is highly desirable, but necessarily optional. Topicmaps.net's Processing Model for XTM 1.0 does not constrain additional means whereby the fact that two different addressing expressions resolve to the same resource is established, as long as these additional means actually work. However, such additional means must never decide that two different resources are the same resource.

Every addressable resource can itself be regarded as a subject. If it is, it is called an "addressable subject", or, synonymously, a "resource constituting a subject", or a "subject-constituting resource".

addressable subject

(See "resource constituting a subject".)

association

A representation of a relationship between subjects, where each of the subjects is itself represented as a topic (see "topic").

  1. In the content of a <topicMap> element, an association can be represented via an <association> element. Depending on its context, therefore, the word "association" can mean "<association> element".

  2. In a topic map graph, an association is always represented as an a-node. Depending on its context, therefore, the word "association" can mean "a-node".

Associations (relationships) have "roles"; the topics that play those roles are called the "members" of the association. Associations are always themselves regardable as topics, because, just like topics, they represent specific subjects; the subject of an association is always the relationship that it represents.

association member role

The role played in an association by a topic that is a member of that association.

association template

  1. Set of constraints used to validate instances of a given association type.

  2. A topic whose subject is a set of constraints used to validate instances of a given association type. Such a topic always plays the "template" role in one or more "template-role-rpc" associations, each of which defines a membership role of the type of association being templated.

association type

  1. A class of associations.

  2. A topic whose subject is a class of association.

  3. One of the classes of associations of which a particular association is an instance.

  4. The class of association specified by an <association> element's <instanceOf> child element.

basename

  1. A child element (<baseName>) of a <topic> element used to specify a name for the topic, including variants. (Each basename can have variant forms for use in various processing contexts.)

  2. A name characteristic of a topic that is the string that is the content of a <baseNameString> element. In the topic map graph, it is the addressable subject of a topic that plays the "basename" role in a "topic-basename" association in which the topic that has the name characteristic plays the "topic" role.

identity point

(See subject identity point.)

merging

topic merging

Topic merging is a process that, during topic map graph construction, begins with two or more t-nodes (and/or a-nodes) and ends with one t-node (or a-node) whose topic characteristics are the union of the topic characteristics of the original topics. In other words, the resulting single t-node (or a-node) is the single endpoint of the union of the sets of arcs of which the formerly separate nodes were the endpoints. The resulting single node also has the union of the set of identity points of the formerly separate nodes. There is really only one reason to merge topics: that they have the same subject; both of the merging rules are designed to make it possible and economical to control and maintain the merging process. (Fundamentally, the topic map paradigm is the use of computer constructs, called topics, to represent subjects -- notions, things, ideas, etc. The reliability and usefulness of a topic map graph depends on there being a one-to-one correspondence between topics and subjects. Topic map applications that conform to Topicmaps.net's Processing Model for XTM 1.0 merge topics whenever they know that they have the same subject. In the context of interchangeable topic map information, such as XTM <topicMap> elements, on the other hand, there may be more than one <topic> element for a single subject.)

The "Name-based Merging Rule", which is applied at topic map graph construction time, and which requires the merger of any two topics that have the same name in the same scope, might lead one to believe that this rule constitutes a reason for merging topics. In fact, however, this is not a reason for merging, even though such mergers are required. They are required because topic namespaces would not be usable (i.e., topics could not be reliably addressed by means of their names) if two topics could have the same name in the same scope (i.e., in the same topic namespace). Even so, such mergers are desirable if and only if the two topics have one and the same subject, and such mergers must be prevented if the two topics do not, in fact, have the same subject. Such undesirable mergers can be avoided by adjusting one or both of the scopes of the two identical basenames of the two different topics in such a way as to make the two names appear in two different topic namespaces.

topic map merging

Topic map merging is a process that begins with two or more <topicMap> elements and ends with a single topic map graph. All of the topics in all of the <topicMap> elements are merged, to whatever extent the topic map application is able to recognize that they have the same subjects (the Subject-based Merging Rule), and to whatever extent the Name-based Merging Rule forces the merging of topics on account of having the same name in the same namespace. Topic map merging occurs automatically at graph-building time, if the <topicMap> element from which the graph is being constructed identifies one or more other topic maps via <mergeMap> elements.

Note: Topicmaps.net's Processing Model for XTM 1.0 does not specify anything about how a <topicMap> element should or can be created in support of any specific purpose. It also says nothing about how applications might create <topicMaps>s whose purpose is to specify the merging of other about merging <topicMap>s. These are examples of areas where competitive effort may result in improved global knowledge interchange.

non-addressable subject

A subject that is not itself an addressable information resource, but is indicated by a resource. This resource, called a subject indicator, is a subject identity point. Examples of non-addressable subjects include the notion of love, the Statue of Liberty, Minnie Mouse's high-heeled shoes, all relationships, and all Platonic forms (see Plato's Republic for more information).

occurrence

(See topic occurrence.)

occurrence type

  1. A class of topic occurrence.

  2. A topic whose subject is class of topic occurrence.

  3. The class of topic occurrence specified by an <occurrence> element's <instanceOf> child element.

published subject indicator

A subject indicator that is designed and maintained at an advertised address in order to facilitate its use as a subject identity point for topics in topic maps created by various people and organizations. In order to preserve the value of topic maps that use them, the addresses of published subject indicator resources must not change. In order to be as useful as possible, published subject indicators should indicate their subjects unambiguously and compellingly. A published subject indicator may or may not be published as a <topic> element in a <topicMap> element. If it is published as a <topic> element, such an element can, like any other addressable information resource, be used as an identity point regardless of whether the <topicMap> element in which it is contained is merged into the topic map graph. If and only if the containing <topicMap> element is merged, the basenames and other characteristics of the topic represented by the published-subject-indicating <topic> element will be merged with those of the t-node that regards that topic as one of its subject indicator resources. (This suggests that, in order to minimize the overhead required to fully exploit them, some published subject indicators will appear in very brief <topicMap> elements which may contain as few as one <topic> element - the <topic> element that serves as the published subject indicator resource.)

reportable error

A consistency error or other error condition that conforming processors (topic map graph builders) must be capable of reporting to their users.

resource

(See addressable information resource.)

resource constituting a subject

[Synonyms: addressable subject; subject constituting resource; subject constituter.] An addressable information resource, itself considered as a subject regardless of any subject which it may discuss, describe, or otherwise represent. (Cf. "subject indicator", also known as "resource indicating a subject", and "nonaddressable subject".)

resource indicating a subject

[Synonyms: subject indicator; subject-indicating resource.] A resource used to describe, define, or otherwise express a subject. Such a resource is a subject identity point for any topic that regards it as its subject indicator.

(Normally, the indicated subject is a non-addressable subject. If the subject were addressable, i.e., if the subject were itself an addressable information resource, it could be addressed directly as a subject-constituting resource. This is easier and more reliable than using a subject-indicating resource to indicate the subject. It is not an error to use a subject-indicating resource to indicate an addressable subject; it is, however, hard to justify the use of an intermediary subject indicator to indicate it, since the subject indicator itself must be examined, only to discover that the subject could have been addressed directly.)

s-node

A node in a topic map graph that potentially or actually represents the scope of one or more a-nodes. Each s-node is connected to zero or more topics (t-nodes and/or a-nodes) via "scope component" arcs; each such topic is regarded as a "component" of the scope that the s-node represents; the represented scope is the set of these topics. Each s-node uniquely represents a scope, i.e., no other s-node can have the same set of component topics. When an a-node's scope is the scope represented by a given s-node, the a-node serves as the "association" end of an "association scope" arc, while the given s-node serves as the "scope" end of that arc. This is how topic map graphs represent the fact that an association represented by an a-node has the scope represented by an s-node.

scope

  1. The extent of the validity of a topic characteristic assignment. A context in which a name or an occurrence is assigned to a given topic, or a context in which topics are related through associations.

  2. The set of topics specified via a <scope> element (or, in a topic map graph, via an s-node).

    (See also "unconstrained scope").

subject

The organizing principle or essence of a topic. Every topic has exactly one subject: the idea or notion that the topic represents.

subject constituting resource

(See resource constituting a subject.)

subject identity

  1. A subject (as in "subject of conversation") or notion, as distinguished from all other subjects or notions, regardless of how, or in how many different ways, that particular subject may be defined, expressed, or otherwise indicated (i.e., regardless of how many subject identity points it may have). Every topic has exactly one subject, and every subject has unique identity.

    Note: The above statement could be interpreted as a philosophical position, but it need not be. Topic maps are merely a tool, and all tools, in order to be useful, must have limitations. One of the limitations of topic maps is that, in order to enable the federation of finding information, topic map authors are required to limit their subjects to clear and distinct ideas. Ideally, each and every subject is capable of being communicated ("indicated") by one or more information resources, but this is not a requirement. It is perfectly OK for a topic map author to have a clear and distinct idea of the subject of a topic, even if that clear and distinct idea is a slippery or fuzzy concept, "the unknown", or "the unknowable". However, a topic map author must never change the subject of a topic, and he must never be unclear, at least in his own mind, about the subject of any topic he authors and/or maintains.

  2. The <subjectIdentity> child of a <topic> element. (The <subjectIdentity> element type is so named because it is used to reference subject identity points, which in turn establish the subject identities of the topics that reference them. A single subject can have an unbounded number of subject identity points, each of which is capable of independently establishing the unique identity of the subject.)

subject identity point

[Synonym: identity point.] One of two possible ways of regarding a single addressable information resource, for purposes of controlling whether topics will be merged. An addressable information resource can be regarded as either a resource that constitutes the subject of a topic, or as a resource that indicates the subject of a topic. Multiple topics that regard the same addressable information resource as their subject-constituting resource are always merged by topic map applications, because it is always assumed that they all have the same subject. Similarly, multiple topics that regard the same addressable information resource as their subject indicating resource are always merged by topic map applications, again because it is always assumed that they all have the same subject. However, if one topic regards a resource as a subject-constituting resource, and another topic regards the same resource as a subject-indicating resource, the two topics are not merged merely on account of the fact that they both refer to the same resource, because it is not assumed that they both have the same subject. Thus, every addressable information resource is potentially usable as two different subject identity points: one as a subject-constituting resource, and the other as a subject-indicating resource.

subject indicating resource

(See resource indicating a subject.)

subject indicator

(See resource indicating a subject.)

t-node (topic node)

A node in a topic map graph that represents some subject, and that, unlike an a-node, does not serve as the "association" end of any "association scope" arcs, "association member" arcs, or "association template" arcs. Like a-nodes, t-nodes may serve as the "member" ends of "association member" arcs, and as the "component" ends of "scope component" arcs. Unlike a-nodes, t-nodes may serve as the "template" ends of "association template" arcs. T-nodes never serve as the "scope" ends of "association scope" arcs (only s-nodes can do that).

Note: Not all t-nodes are demanded by <topic> elements. T-nodes are also demanded by other element types.

topic

The fundamental building block of a topic map; the computer representation of a subject. Fundamentally, the topic map paradigm is the use of computer constructs, called topics, to represent subjects -- notions, things, ideas, etc. The reliability and usefulness of a topic map graph depends on there being a one-to-one correspondence between topics and subjects.

  1. In the content of a <topicMap> element, a topic can be represented via a <topic> element (and in other ways). Depending on its context, therefore, the word "topic" can mean "<topic> element". It can also mean "the topic whose existence is asserted by any other 'node demander' syntactic construct.

  2. In a topic map graph, a topic is always represented either as a t-node or an a-node. Depending on its context, therefore, the word "topic" can mean "t-node or a-node".

topic characteristic

Topics are comprised of topic characteristics. There are three kinds of topic characteristics:

  1. basenames,

  2. occurrences, and

  3. memberships (i.e., roles played) in relationships ("associations") with other topics.

Each basename of a topic is a "name characteristic", each occurrence is an "occurrence characteristic", and each role that the topic plays in each association is an "association membership characteristic" of that topic. In a topic map graph, the topic characteristics of a given t-node or a-node (node X) are represented by the "association member" arcs of which node X is the "member" end. The a-nodes at the "association" end of each of those "association member" arcs represent the "topic characteristic assignments" -- the connections between a topic and each of its characteristics.

topic characteristic assignment

  1. In the content of a <topicMap> element, the fact that a syntactic mechanism (an element, attribute, or combination thereof) causes a topic characteristic to become a characteristic of a topic.

  2. In a topic map graph, the fact that a t-node or a-node serves as the "member" end of an "association member" arc.

  3. The fact that a topic has a topic characteristic.

  4. The a-node that represents the fact that a topic has a topic characteristic.

topic map

A topic map is a set of topics and the associations between them. Topics are computer representations of subjects. The creators of topic maps determine the subjects of topics, and, for each topic, some set of names, occurrences, and memberships in associations. The term "topic map" is abstract. According to Topicmaps.net's Processing Model for XTM 1.0, a single topic map can exist in two different forms:

  1. The interchangeable form of a topic map: a <topicMap> element, including all of the <topic>, <association>, and other elements that it contains, and including the elements contained in any other <topicMap> elements that are referenced by <mergeMap> elements in the content of the original <topicMap> element.

  2. The application-internal form of a topic map: a topic map graph, including all of the t-nodes, a-nodes, and s-nodes that appear in the graph, and the arcs that connect these nodes to one another. Topicmaps.net's Processing Model for XTM 1.0 constrains the nature of topic map graphs, and the manner in which topic map graphs are created. A topic map graph "reconstitutes", rationalizes, and makes explicit all of the explicit and implicit information conveyed by the set of <topicMap> elements (and their contents) from which it was created. Topic map graphs may be used interactively and directly by applications, or they may be rendered (formatted) for use by applications that cannot use topic map graphs directly; there is an unbounded number of ways of implementing and using topic map graphs.

topic map graph

According to Topicmaps.net's Processing Model for XTM 1.0, the set of nodes and arcs that results from processing one or more <topicMap> elements using an application that conforms to Topicmaps.net's Processing Model for XTM 1.0.

topic map merging

(See merging.)

topic merging

(See merging.)

topic name

  1. A basename characteristic of a topic.

  2. A string of characters specified as a name of a topic using a <baseNameString> element.

topic namespace

A set of basenames of one or more topics, each of which is unique, and all of which are the names of their respective topics within a single, common scope.

topic naming constraint

The constraint, imposed by the topic map paradigm, that no two different subjects can have corresponding topics that have the same basename within the same scope (i.e., the same topic namespace). This constraint necessitates the Name-based Merging Rule, which provides that, when a topic map graph is constructed, since no two t-nodes (and/or a-nodes) can have the same name in the same scope, any such pair of nodes must be merged.

The impact of the topic naming constraint can be both positive and negative. On the one hand, it may be useful and appropriate for the topic map application to infer, in effect, that, since two topics have the same name in the same scope, they also have the same subject. On the other hand, such an inference may be incorrect and inappropriate because the two topics actually have different subjects. The latter situation must be avoided. One way to avoid it is to define the scopes of the colliding name characteristics in such a way that each of the two names is a name characteristic within a distinct scope.

topic occurrence

[Synonym: occurrence.]

  1. Information that is specified as relevant to a given subject.

  2. The address or location of information that is specified as relevant to a given subject.

  3. An <occurrence> element.

  4. A Topic-Occurrence a-node in a topic map graph.

topic type

  1. A class of topics.

  2. The subject of a topic referenced by an <instanceOf> child element of a <topic> element.

  3. The subject of a topic specified as playing the class role in a "class-instance" association whose template is the XTM-defined "class-instance" association template. (This template was defined in the original December 4, 2000 version of the XTM 1.0 Specification, but it may not appear in the February 17, 2000 version.)

unconstrained scope

The scope comprised of the null set of topics -- the "no-topic" scope. When no applicable <scope> child elements are explicitly specified as governing a topic characteristic assignment, the scope within which the topic characteristic assignment is made defaults to the unconstrained scope.

Note: Even if no <scope> element specifies the scope of a characteristic assignment, the scope of that characteristic assignment in the topic map graph may nevertheless not be the uncontrained scope, on account the impact of any applicable <mergeMap> elements.

variant

(See variant name.)

variant name

[Synonym: variant.] An alternative form of a basename, intended for use in a particular processing context, such as sorting or display.

Variant names are not subject to the Name-based Merging Rule; they are not found in topic namespaces.