Title: | Topicmaps.net's Processing Model for XTM 1.0, version 1.0.1 |
Source: | Steve Newcomb and Michel Biezunski |
Project: | ISO/IEC 13250:2000 |
Project editor: | Michel Biezunski, Martin Bryan, and Steve Newcomb |
Status: | Personal contribution |
Action: | For Information |
Date: | 11 August 2001 |
Summary: | |
Distribution: | SC34 and Liaisons |
Refer to: | |
Supercedes: | |
Reply to: | Dr. James David Mason (ISO/IEC JTC1/SC34 Chairman) Y-12 National Security Complex Information Technology Services Bldg. 9113 M.S. 8208 Oak Ridge, TN 37831-8208 U.S.A. Telephone: +1 865 574-6973 Facsimile: +1 865 574-1896 E-mailk: mailto:mxm@y12.doe.gov http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat American National Standards Institute 11 West 42nd Street New York, NY 10036 Tel: +1 212 642 4976 Fax: +1 212 840 2298 E-mail: shafele@ansi.org |
TopicMaps.net is an informative Topic Maps website maintained by Michel Biezunski (InfoLoom) and Steven R. Newcomb (Coolheads Consulting) | |
Topicmaps.net's Processing Model for XTM 1.0, version 1.0.1A Processing Model for XML Topic MapsSteven R. Newcomb, srn@coolheads.com and This version (1.0.2) is dated July 25, 2001. Changes since version 1.0.1 (March 25, 2001) appear in red. So far, all changes are just clarifications that were suggested by questions raised by implementers of this model. |
Topicmaps.net's Processing Model for XTM 1.0 provides an explanation of the meaning of XTM syntax which is entirely true to the vision that has guided the authors in discovering, teaching, developing and testing the topic map paradigm.
This version of Topicmaps.net's Processing Model for XTM 1.0
illustrates only the processing of topic map documents that
conform to the XTM 1.0 Specification (i.e., XTM
<topicMap>
elements). Future efforts will additionally
discuss the processing of other syntaxes for interchanging
topic map information, including the interchange syntax
(meta-DTD) specified by ISO/IEC 13250:2000.
The authors gratefully acknowledge the contributions and counsel of Sam Hunting, Victoria T. Newcomb and Peter Newcomb.
Previous versions of this material once appeared in drafts of the XTM 1.0 Specification published at http://www.topicmaps.org. This version is licensed to the public for all purposes and in every way.
The authors request that all copies and translations of Topicmaps.net's Processing Model for XTM 1.0 be complete and correct, including this and all other notices, and including attribution to the authors by names and e-mail addresses, please. The authors also request that any claims of conformance to Topicmaps.net's Processing Model be accurate. Either a processing system conforms to the model exactly and comprehensively in every detail, or it does not conform, and no claim of conformance is justified.
A verbose tutorial-style glossary is attached.
Topicmaps.net's Processing Model for XTM 1.0 defines a set of rules for processing topic map documents in order to reconstitute the meaning of the information they are intended to convey to their recipients. It could be used as a partial blueprint for a topic maps application, but that is not its primary purpose. Its primary purpose is merely to illustrate, in a rigorous fashion, the authors' deepest understanding of the meaning of topic map information.
In Topicmaps.net's Processing Model for XTM 1.0, the result of
processing <topicMap>
elements is described in
terms of "topic map graphs" that consist of "nodes" and "arcs"
which connect the nodes in certain ing Rule, it
is irrelevant whether two subject indicator
resources, or two subject constituting resources,
contain the same data or are the same string. A
simple string comparison of the two subject
indicator resources is not, in the general case, a
reliable indication of whether or not the same
subject is being described. For example,
different products in different sales catalogs may
coincidentally have the same catalog number, and a
comparison of the two catalog numbers does not
indicate that they are the same product.
Therefore, the Subject-based Merging Rule is not
based on comparing the data content of the
resources that serve as identity points. Merging
must occur if and only if:
either both subject identity points are subject indicators, or both subject identity points are subject constituters (i.e., they can't be mixed), and
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.
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.
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.
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:
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.
<topicMap>
and <mergeMap>
ElementsAll 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.
<topic>
Elements and Their Descendants<topic>
Element as a WholeEach <topic>
element demands the existence of a
corresponding t-node.
<instanceOf>
Element in <topic>
ElementEach <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.
<subjectIdentity>
Element in <topic>
ElementThe 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.
Note: The above two bullet points are intended to say that a topic's subject can either be addressable or non-addressable, but not both. (A topic always has exactly one subject, and no single subject can be both addressable and non-addressable.) If the subject is addressable, then exactly one of the topic's subject identity points must be the addressable subject (i.e., the subject-constituting resource) itself, and, in addition, there will also be one or more subject indicators for the same addressable subject. (The "node demander is a subject indicator" rule guarantees that there is always at least one subject indicator, even if the subject is addressable.) If the subject of a topic is not addressable, then none of the identity points of the topic can be a subject-constituting resource. Again, however, because of the "node demander..." rule, there is always at least one subject indicator, and there may be any number of additional subject indicators.
When the children of the <subjectIdentity>
element include a <resourceRef>
element, the
subject of the t-node is the referenced resource
itself -- not what the resource can be
interpreted to mean; the reference resource is a
"subject constituting resource", because the
resource itself constitutes the subject. The
referenced resource is a subject identity point
for the t-node.
It is a reportable error if topic map processing results in a t-node having more than one subject constituting resource.
If a t-node's subject identity points do not include
a subject-constituting
resource (also known as an "addressable
subject"), then the subject is a "non-addressable
subject" which can only be "indicated" by
each of the resources referenced by the
<subjectIndicatorRef>
elements
that are the children of the
<subjectIdentity>
element.
Each of the referenced resources is considered to
be capable of separately and compellingly
indicating the subject of the topic.
If any of the resources referenced by a
<subjectIndicatorRef>
element is itself a <topic>
element, the subject of the referenced <topic>
element is considered to be the same subject as
the subject of the <topic>
element that contains
the <subjectIdentity>
element that contains the
<subjectIndicatorRef>
element, and the two
t-nodes whose existence is explicitly demanded by
the two <topic>
elements will be merged under the
governance of the Subject-based Merging Rule. If
one or more <topicRef>
elements appear within a
<subjectIdentity>
element contained in a <topic>
element, each of them is treated as if it were a
<subjectIndicatorRef>
element (see the beginning
of this paragraph). Whether or not there is a
<subjectIdentity>
element, there is at least one
subject indicator, which is the <topic>
element
(or whatever element demanded the existence of
the node, implicitly or explicitly).
<baseName>
Element in <topic>
Element<baseNameString>
Element in <baseName>
ElementEach <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."
<baseName>
Element as a WholeEach <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.)
<variant>
and <variantName>
Elements
in <baseName>
ElementsThe 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.
<occurrence>
Elements in <topic>
Elements<resourceRef>
and <resourceData>
Elements in <occurrence>
ElementEach <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.)
<occurrence>
Element as a WholeEach <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.
<instanceOf>
Element in <occurrence>
ElementThe <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.
<association>
Elements and Their DescendantsEach <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.
<instanceOf>
Element in <association>
ElementThere 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.
<member>
Element in <association>
ElementEach 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.
[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".
addressable subject(See "resource constituting a subject".)
associationA 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 roleThe role played in an association by a topic that is a member of that association.
association templateSet of constraints used to validate instances of a given association type.
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.
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.
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.
(See subject identity point.)
mergingtopic merging
Topic merging is a process that, during topic map
graph construction, begins with two or more t-nodes
(and/or a-nodes) and ends with one t-node (or
a-node) whose topic characteristics are the union
of the topic characteristics of the original
topics. In other words, the resulting single
t-node (or a-node) is the single endpoint of the
union of the sets of arcs of which the formerly
separate nodes were the endpoints. The resulting
single node also has the union of the set of
identity points of the formerly separate nodes.
There is really only one reason to merge topics:
that they have the same subject; both of the
merging rules are designed to make it possible and
economical to control and maintain the merging
process. (Fundamentally, the topic map paradigm is
the use of computer constructs, called topics, to
represent subjects -- notions, things, ideas, etc.
The reliability and usefulness of a topic map graph
depends on there being a one-to-one correspondence
between topics and subjects. Topic map
applications that conform to Topicmaps.net's
Processing Model for XTM 1.0 merge topics whenever
they know that they have the same subject. In the
context of interchangeable topic map information,
such as XTM <topicMap>
elements, on the other hand,
there may be more than one <topic>
element for a
single subject.)
The "Name-based Merging Rule", which is applied at topic map graph construction time, and which requires the merger of any two topics that have the same name in the same scope, might lead one to believe that this rule constitutes a reason for merging topics. In fact, however, this is not a reason for merging, even though such mergers are required. They are required because topic namespaces would not be usable (i.e., topics could not be reliably addressed by means of their names) if two topics could have the same name in the same scope (i.e., in the same topic namespace). Even so, such mergers are desirable if and only if the two topics have one and the same subject, and such mergers must be prevented if the two topics do not, in fact, have the same subject. Such undesirable mergers can be avoided by adjusting one or both of the scopes of the two identical basenames of the two different topics in such a way as to make the two names appear in two different topic namespaces.
topic map merging
Topic map merging is a process that begins with two
or more <topicMap>
elements and
ends with a single topic map graph. All of the
topics in all of the <topicMap>
elements are merged, to whatever extent the topic
map application is able to recognize that they have
the same subjects (the Subject-based Merging Rule),
and to whatever extent the Name-based Merging Rule
forces the merging of topics on account of having
the same name in the same namespace. Topic map
merging occurs automatically at graph-building
time, if the <topicMap>
element
from which the graph is being constructed
identifies one or more other topic maps via
<mergeMap>
elements.
Note: Topicmaps.net's Processing Model for XTM 1.0
does not specify anything about how a
<topicMap>
element should or can be created
in support of any specific purpose. It also
says nothing about how applications might
create <topicMaps>
s whose purpose is to
specify the merging of other about merging
<topicMap>
s. These are examples of areas
where competitive effort may result in
improved global knowledge interchange.
A subject that is not itself an addressable information resource, but is indicated by a resource. This resource, called a subject indicator, is a subject identity point. Examples of non-addressable subjects include the notion of love, the Statue of Liberty, Minnie Mouse's high-heeled shoes, all relationships, and all Platonic forms (see Plato's Republic for more information).
occurrence(See topic occurrence.)
occurrence typeA class of topic occurrence.
A topic whose subject is class of topic occurrence.
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.
resource(See addressable information resource.)
resource constituting a subject[Synonyms: addressable subject; subject constituting resource; subject constituter.] An addressable information resource, itself considered as a subject regardless of any subject which it may discuss, describe, or otherwise represent. (Cf. "subject indicator", also known as "resource indicating a subject", and "nonaddressable subject".)
resource indicating a subject[Synonyms: subject indicator; subject-indicating resource.] A resource used to describe, define, or otherwise express a subject. Such a resource is a subject identity point for any topic that regards it as its subject indicator.
(Normally, the indicated subject is a non-addressable subject. If the subject were addressable, i.e., if the subject were itself an addressable information resource, it could be addressed directly as a subject-constituting resource. This is easier and more reliable than using a subject-indicating resource to indicate the subject. It is not an error to use a subject-indicating resource to indicate an addressable subject; it is, however, hard to justify the use of an intermediary subject indicator to indicate it, since the subject indicator itself must be examined, only to discover that the subject could have been addressed directly.)
s-nodeA 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.
scopeThe 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.
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.
subject constituting resource(See resource constituting a subject.)
subject identityA 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.)
[Synonym: identity point.] One of two possible ways of regarding a single addressable information resource, for purposes of controlling whether topics will be merged. An addressable information resource can be regarded as either a resource that constitutes the subject of a topic, or as a resource that indicates the subject of a topic. Multiple topics that regard the same addressable information resource as their subject-constituting resource are always merged by topic map applications, because it is always assumed that they all have the same subject. Similarly, multiple topics that regard the same addressable information resource as their subject indicating resource are always merged by topic map applications, again because it is always assumed that they all have the same subject. However, if one topic regards a resource as a subject-constituting resource, and another topic regards the same resource as a subject-indicating resource, the two topics are not merged merely on account of the fact that they both refer to the same resource, because it is not assumed that they both have the same subject. Thus, every addressable information resource is potentially usable as two different subject identity points: one as a subject-constituting resource, and the other as a subject-indicating resource.
subject indicating resource(See resource indicating a subject.)
subject indicator(See resource indicating a subject.)
t-node (topic node)A node in a topic map graph that represents some subject, and that, unlike an a-node, does not serve as the "association" end of any "association scope" arcs, "association member" arcs, or "association template" arcs. Like a-nodes, t-nodes may serve as the "member" ends of "association member" arcs, and as the "component" ends of "scope component" arcs. Unlike a-nodes, t-nodes may serve as the "template" ends of "association template" arcs. T-nodes never serve as the "scope" ends of "association scope" arcs (only s-nodes can do that).
Note: Not all t-nodes are demanded by
<topic>
elements. T-nodes are
also demanded by other element types.
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".
Topics are comprised of topic characteristics. There are three kinds of topic characteristics:
basenames,
occurrences, and
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 assignmentIn 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.
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.
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.)
topic merging(See merging.)
topic nameA basename characteristic of a topic.
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.
topic naming constraintThe 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.
An <occurrence>
element.
A Topic-Occurrence a-node in a topic map graph.
A class of topics.
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.)
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.)
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.