The 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.2 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.

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 ways.

Note: Although Topicmaps.net's Processing Model for XTM 1.0 illustrates the meaning of XTM 1.0 syntax in terms of graphs and their component nodes and arcs, there is no intention to constrain all implementations to a graph paradigm. It is possible to implement the relationships and semantics illustrated by this Processing Model accurately using relational databases, for example.

The topic map graph (or other representation of the full understanding of the interchanged information) must be fully completed before any other processing is done. After the topic map graph is constructed, topic map applications may perform additional processing (such as answering queries, rendition of one or more finding aids, etc.), beyond that described in Topicmaps.net's Processing Model for XTM 1.0, to exploit the information conveyed by interchangeable topic map documents; such additional processing is not constrained by Topicmaps.net's Processing Model for XTM 1.0.

2.0 Topic Map Information and <topicMap> Elements are Differently Structured

Topic map information is inherently multidimensional. For interchange, topic map information has to be flattened into a sequence of characters. After interchange, the information must be reconstituted so that it is multidimensional once more. Topicmaps.net's Processing Model for XTM 1.0 is wholly concerned with the reconstitution process, and with the result of the reconstitution process (a "topic map graph").

The W3C DOM API, for example, cannot provide direct access to the topic map information represented by a <topicMap> element. It can only provide access to the syntactic representation of that information -- the <topicMap> element itself. The DOM can be used by applications that reconstitute topic map information from <topicMap> elements, but a DOM tree made from a <topicMap> element is not ready-to-use topic map information.

3.0 What's in a Topic Map Graph?

A topic map graph consists of nodes and arcs which connect the nodes.

3.1 There are three kinds of nodes:

1. "t-node" (for topic node)

2. "a-node" (for association node), and

3. "s-node" (for scope node).

The only thing that characterizes a node is the fact that it serves as the endpoint of one or more arcs. In Topicmaps.net's Processing Model for XTM 1.0, the nodes themselves have no other properties or characteristics.

The three different node types have rules about which ends of how many of which kinds of arcs they are allowed to serve as (see Table 1, "Matrix of constraints on the service of types of nodes as specific endpoints of types of arcs"). Other than these rules, no other formal features distinguish the three kinds of nodes, for purposes of Topicmaps.net's Processing Model for XTM 1.0.

3.2 There are four kinds of arcs:

(1) association member

"association member" arcs have two ends, called the "association" end and the "member" end.

The "association" end is always an a-node. (A-nodes always represent associations.)

The "member" end is a node that represents a player of a specific role in the association represented by the a-node.

The "association member" arc is the only kind of arc that has a label. The label is always a t-node that represents the topic whose subject is the role being played by the member (represented by the node at the "member" end) in the association (represented by the a-node at the "association" end).

(2) association scope

"association scope" arcs have two ends, called the "association" end and the "scope" end.

The "association" end is always an a-node. (A-nodes always represent associations.)

The "scope" end is always an s-node. S-nodes represent the scopes within which associations are valid. In the graph, all associations are represented as a-nodes, and all a-nodes have at least one scope. An "association scope" arc represents the fact that an association (an a-node) has a certain scope. Only a-nodes have scope. In conformance with the XTM Conceptual Model, all topic characteristics, not only including memberships in associations that were syntactically represented as <association> elements, but also including all topic names and topic occurrences, are represented in the graph as a-nodes. Therefore, when the word "association" is used in the context of the XTM Conceptual Model, and in the context of Topicmaps.net's Processing Model for XTM 1.0, it has a somewhat broader definition than it does when used as an element type name (<association>, in the context of the XTM Interchange Syntax).

(3) association template

"association template" arcs have two ends, called the "association" end and the "template" end.

The "association" end is always an a-node. (A-nodes always represent associations. Remember: we're using the word "association" here in a sense that covers not only the kinds of things that are represented syntactically by <association> elements, but also the kinds of things that are represented syntactically by <occurrence> elements and <name> elements.)

The "template" end is always a t-node that represents the subject that is the model with which the a-node at the "association" end will be validated for conformance. (The model is represented in the graph by a set of a certain kind of a-node and their members; all of these a-nodes have this t-node as a member playing a certain role; this will be described later.)

(4) scope component

"scope component" arcs have two ends, called the "scope" end and the "component" end.

The "scope" end is always an s-node. The scope represented by the s-node is the set of t-nodes (and/or a-nodes) that serve as the "component" ends of the set of "scope component" arcs of which the s-node serves as the "scope" end.

Topicmaps.net's Processing Model for XTM 1.0 constrains the construction of topic map graphs in such a way as to allow only certain node types to serve as certain endpoints of certain arc types. In some cases, there are also numeric constraints on the number of arc endpoints that a given node can serve as. The following table sets forth these constraints:

3.3 Table 1 - Matrix of constraints on the service of types of nodes as specific endpoints of types of arcs.

Legend for the above table:

¹Topicmaps.net's Processing Model for XTM 1.0 neither prohibits nor requires the existence of s-nodes that are not used as the scope of any a-nodes.

3.4 Elements vs. Nodes

In a topic map graph, <topic> elements are represented by t-nodes. Similarly, <association> elements are represented by a-nodes.

The number of t-nodes that appears in the topic map graph constructed from a <topicMap> element is typically not the same as the number of <topic> elements in that <topicMap>. Similarly, but for different reasons, the number of a-nodes in the topic map graph constructed from a <topicMap> element is not the same as the number of <association> elements in that <topicMap>.

For example, there can be more nodes than elements:

The contents of a <topicMap> element may demand the existence of t-nodes and a-nodes by means other than (and in addition to) <topic> and <association> elements. The existence of such nodes is said to be "implicitly demanded". Only <topic> and <association> elements explicitly demand the existence of corresponding t-nodes and a-nodes; the existence of all other t-nodes and a-nodes is implicitly demanded. For example, when an information resource is referenced by means of a <resourceRef> element, the existence of a corresponding t-node is implicitly demanded. (Its subject is the referenced information resource; i.e., in the case of <resourceRef> elements, the subject is the resource itself -- not what the resource signifies.) In the case of associations, the existence of a-nodes may be implicitly demanded by <instanceOf>, <occurrence>, and <baseName> elements.

For example, there can be fewer nodes than elements:

Topic map processing may also create a single t-node by merging topic characteristics declared via multiple <topic> elements. This must happen whenever the processing system has determined that the two elements have the same subject. (For more about topic merging rules, see the sections, "Subject-based Merging Rule" and "Topic Naming Constraint-based Merging Rule".) Multiple <association>s and other a-node demanders that represent the exact same association are also merged into a single a-node.

For any given t-node or a-node, the total number of "node demanders" is always greater than or equal to one.

3.5 t-nodes and subjects

A t-node always represents ("reifies") exactly one subject, just as does a <topic> element in an <topicMap> element.

In a <topicMap> element, there can be any number of <topic> elements that have the same subject. In a topic map graph, however, there can only be one t-node that has that subject. (See the "merging" glossary entry for more information.)

3.6 Comparison of t-nodes vs. a-nodes

In some sense, there isn't very much difference between t-nodes and a-nodes. For purposes of participating in associations, an a-node is treatable as a t-node. In fact, just like a t-node, an a-node always represents (reifies) exactly one subject. In the case of an a-node, however, the subject is always a specific relationship between other subjects, each of which is represented in the graph by either a t-node or an a-node.

Since they represent subjects, a-nodes can be members of other associations (i.e., to serve as the "member" endpoints of "association member" arcs). (Indeed, it is perfectly possible for a single a-node to serve as both ends of a single "association member" arc; in this case, the association itself is participating in the relationship that it represents.)

Under certain circumstances, it is even possible for a t-node to be merged with an a-node. The result is always an a-node.

These are the differences between t-nodes and a-nodes:

1. Only an a-node can serve as the "association" end of one or more "association member" arcs.

2. Only a-nodes can represent relationships in which the members are represented by topics in the topic map. (It's possible for a t-node to represent a subject that is a relationship, because it's possible for a t-node to represent any subject. However, if the relationship has members that are represented by topics in the topic map, then an a-node must be used to represent the relationship, because only a-nodes can serve as the "association" end of one or more "asssociation member" arcs. Without such arcs, there can be no representation of the connection between the relationship and the participants in that relationship.)

3. Only a-nodes can have scope (i.e., can serve as the "association" end of one or more "association scope" arcs). (Indeed, every a-node must have scope, i.e., it must serve as the "association" end of at least one "association scope" arc.)

4. Only t-nodes can be association templates. It is a reportable error if a situation exists in which an a-node (i.e., a node that serves as the "association" end of any arc type) also serves as the "template" end of an "association template" arc.

5. Only t-nodes can have addressable subjects. A-nodes cannot have, as any of their subject identity points, subject constituting resources. (The subject of an a-node is always non-addressable because it is a relationship; it is not a piece of information.) It is a reportable error if, when a t-node merges with an a-node, the resulting a-node has an addressable subject.

4.0 Subject identity points

In addition to serving as the endpoints of arcs, t-nodes and a-nodes have sets of subject identity points. Subject identity points are always addressable resources that are outside the topic map graph. In other words, for purposes of Topicmaps.net's Processing Model for XTM 1.0, the connections between the nodes and their identity points are not arcs, and the identity points themselves are not nodes. Subject identity points, and the connections between t-nodes (and a-nodes) and their subject identity points, are entirely in the realm of implementations; they are not constrained by Topicmaps.net's Processing Model for XTM 1.0 except to note that implementers must provide for them in such a way as to support the merging requirements set forth herein. (See the glossary entry for "subject identity points" for more information.)

Note: It seems reasonable to implement t-nodes and a-nodes in such a way that users can retrieve the addresses, perhaps including all of the addresses that were used to reference each subject identity point. It also seems reasonable to implement topic map applications in such a way as to support traversal to any subject indicator or subject constituting resource. Indeed, it seems consistent with the implicit promise of the name of the "topic maps" paradigm to implement topic map applications in such a way as to support the initiation of traversal from any subject identity point, as well as to any subject identity point. Topicmaps.net's Processing Model for XTM 1.0, however, imposes no such requirement.

It is a reportable error if a situation exists in which a single t-node appears to have more than one subject constituting resource.

5.0 Association templates

Associations are not required to have association templates. In topic map graph terms, this means that an a-node is not required to serve as an endpoint of any association template arc.

If a t-node serves as the "template" end of one or more "association template arcs", then it is called an "association template t-node". An association template t-node establishes all of the roles that members of an a-node can play. If an a-node has a template (i.e., if it serves as the "association" end of an "association template" arc), it is a reportable error if a member of that a-node does not play one of the roles specified by the template.

Association template t-nodes must play the role of "template" in one or more "template-role-rpc" associations. It is a reportable error if a t-node that serves as the "template" end of any "association template" arc does not also play the role of "template" in one or more "template-role-rpc" associations.

All "template-role-rpc" association a-nodes were themselves templated in the original version of the XTM 1.0 Specification, which may or may not still be available at http://www.topicmaps.org/xtm/1.0/core.html#xtmmaps. The published subject indicator is http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-template-role-rpc.

Each of the "template-role-rpc" associations in which an association template t-node plays the role of "template" establishes:

1. (the subject that is) the template itself, represented by exactly one t-node that plays the "template" role in the "template-role-rpc" association;

2. (the subject that is) one of the member roles of the template, represented by exactly one t-node that plays the "role" role in the "template-role-rpc" association; and

3. (the subject that is) the class of topic of which all players of the role must be instances, optionally represented by exactly one t-node that plays the "rpc" ("role player constraints") role in the "template-role-rpc" association.

(Note: The following incredibly convoluted sentence has been deliberately formatted in a broken-up fashion in order to make it easier to parse. If you must re-format this difficult material, please take pity on our readers and figure out some way to make it at least as clear, and hopefully clearer.)

The fact that

a topic that plays the role being templated is an instance of the topic that plays the "rpc" role in the template

must be represented in the topic map by a class-instance association in which

the topic that plays the role being templated also plays the "instance" role, and the topic that plays the "class" role is either:

the topic that plays the "rpc" role in the template, or

a superclass of the topic that plays the "rpc" role in the template.

The "class-instance" association mentioned in the above paragraph must be an instance of the XTM-defined "class-instance" association template, whose published subject indicator may or may not still be available at http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-class-instance.

If many classes of topics must be allowed play the role, the topic that plays the "rpc" role must be a subclass of all of them, so that any appropriate topic that plays the role being templated will, in effect, be known to be appropriate by virtue of the fact that it is an instance of at least one of them.

The fact that a topic that plays the rpc role is a subclass of any other topic must be represented by an association (a-node) that is an instance of the XTM-defined "superclass-subclass" association template, whose published subject indicator may or may not still be available at http://www.topicmaps.org/xtm/1.0/psi1.xtm#at-superclass-subclass, and whose "subclass" role is played by the topic that also plays the "rpc" role.

If any of the superclasses of the topic that plays the rpc role is an instance of the XTM-defined "Apply to Set" class, the constraints imposed by such superclasses apply to the entire set of topics that play the role being templated and that are instances of such superclasses. If any of the superclasses of the topic that plays the rpc role is not an instance of the XTM-defined "Apply to Set" class, the constraints imposed by such superclasses apply to each of the topics that play the role being templated and that are instances of such superclasses.

Note: As of this writing, no one has yet provided published subject indicators for the purpose of constraining the number of topics that must (or may) play a particular role in a templated association. Users of Topicmaps.net's Processing Model for XTM 1.0 are free to do that in whatever way they desire. To be consistent with Topicmaps.net's Processing Model for XTM 1.0, though, such topics should be instances of the "Apply to Set" topic.

If no topic plays the "rpc" role in the template-role-rpc association that specifies a particular role in an association template, then there are no validation constraints on the topics that are permitted to play the role in associations that are instances of the template.

At minimum, the act of checking conformance of a role player to its role player constraints is the act of checking for the existence of a class-instance association between the topic that plays the role and the topic whose subject is the role player constraints. All other role player constraints, and all other processing to check the conformance of role players to their respective constraints is necessarily application-defined.

6.0 S-nodes and Topic Namespaces

S-nodes are, in effect, topic namespaces. Topic namespaces are like topical indexes, in which topics can be "looked up" if the user knows their names. In a given topic namespace, each name corresponds to exactly one topic. The set of topic-basename association a-nodes which serve as the "association" ends of "association scope" arcs whose "scope" end is a given s-node is, in effect, the set of topic basenames, and the t-nodes that have those basenames, in the topic namespace represented by that given s-node. Topic namespaces are like topical indexes, in which topics can be "looked up" if the user knows their names.

Note: The authors believe that, for the sake of global knowledge interchange, there must be a minimum basename string length that is required to be supported by all applications that support a given topic map interchange syntax. They suggest that those responsible for the creation and maintenance of such interchange syntaxes consider two possible values:

31 (the maximum key field length in some RDBMS implementations), or

255 (a nice long name length that happens to be the maximum field length in some RDBMS implementations).

If the minimum guaranteed-to-be-supported basename length is too short, there is a danger that topic map authors will be forced to abbreviate names in the basenames, which will compromise the intent of the Spec. On the other hand, if the minimum supported basename length is too long, the support of topic namespaces will incur an unfortunate amount of overhead in some implementations.

7.0 The Subject-based Merging Rule

A fully-processed topic map graph should have exactly one t-node per subject. This is an ideal state that may or may not be fully achievable automatically, due to limitations on the information available to the topic map processing system. The Subject-based Merging Rule requires conforming topic map processing systems to merge t-nodes that are known to such systems to have the same subject, on the basis of whatever information is available to them. In addition, the Subject-based Merging Rule requires conforming topic map processing systems to conclude, on the basis of certain conditions, that two t-nodes have the same subject, and that they therefore must be merged into a single t-node.

There are many situations in which a human being, on the basis of the human being's knowledge, must intervene in order to cause two t-nodes to be merged. An example of such a situation is when two topics have no subject indicator resources, but one of them has "Buster Keaton" as a basename topic characteristic, and the other has "The Great Stone Face" as a basename topic characteristic. A human being with considerable knowledge of the history of American cinema might reasonably conclude that the two topics both have the same subject (the Hollywood actor whose name was "Buster Keaton"), and, accordingly, intervene in topic map processing to cause these two t-nodes to be merged into a single t-node.

Conforming topic map processing systems are not required to provide for such human intervention, but implementers of topic map applications are strongly encouraged to consider how best to account for the need to include human beings in the creation, interchange, processing, use, and maintenance of topic map information. This will have the effect of minimizing the need for such human intervention, and to maximally leverage the minimum automated merging capabilities that must be supported by all topic map processing systems, topic map authors are strongly encouraged to use common Published Subject Indicators. Organizations that serve communities of interest are strongly encouraged to create and promulgate the use of Published Subject Indicators for the subjects that their communities use, so that there will be common subject identity points around which relevant materials can be automatically "gathered" via merging operations performed by topic map processing systems that conform to Topicmaps.net's Processing Model for XTM 1.0. Such organizations should commit themselves to preserving the longterm validity of the published addresses of such identity points, in order to protect the value and mergeability of the topic maps that use them.

According to Topicmaps.net's Processing Model for XTM 1.0, the minimum merging operations that must be performed by all conforming topic map processing systems under the Subject-based Merging Rule are:

• Whenever two t-nodes both have identity points that are subject constituting resources, they must be merged if and only if the two subject constituting resources are known to the processing system to be one and the same resource, regardless of how that resource may have been differently addressed. In other words, merging is required if and only if the two addresses are known to the processing system to be equivalent.

• All t-nodes have at least one subject indicator resource. (If nothing else, a t-node must at least have the syntactic construct that demanded its existence as one of its subject indicators.) Two t-nodes that do not have subject constituting resources shall be merged if and only if:

  either:

  one of the two t-nodes has at least one subject indicator resource that is known to the processing system to be the same resource that serves as one of the subject indicators of the other t-node,

  or:

  the two subject indicator resources indicating the subject are known (on account of machine intelligence or human intervention) to the processing system to describe the same subject.

  For purposes of the Subject-based Merging 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:

• a subject that is constituted by a resource (such a resource is also called a "subject constituting resource" or an "addressable subject"), or

• a subject that is not a subject constituting resource, and that can therefore only be indicated by one or more subject indicator resources.

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

[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.

[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".

(See "resource constituting a subject".)

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.

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

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.

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.

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.

(See subject identity point.)

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 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.

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

(See topic occurrence.)

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.

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

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

(See addressable information resource.)

[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".)

[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.)

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.

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").

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

(See resource constituting a subject.)

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

[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.

(See resource indicating a subject.)

(See resource indicating a subject.)

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.

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".

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.

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.

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.

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.

(See merging.)

(See merging.)

1. A basename characteristic of a topic.

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

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.

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.

[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.

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

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.

(See 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.