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

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.

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.

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.

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.1 There are three kinds of nodes:

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

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

3.4 Elements vs. 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 mergingtopic
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:

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

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

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

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.

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.

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:

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

(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

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

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.

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:

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

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:

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

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.

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.

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

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

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:

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.

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

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

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

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.

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

A class of associations.

A topic whose subject is a class of association.

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

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

basename

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

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.

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.

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

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.

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

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.

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.

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.

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.

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:

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

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.

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

The fact that a topic has a topic characteristic.

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:

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.

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.

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

Information that is specified as relevant to a
given subject.

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

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

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.