Topic maps are sets of subject proxies, each of
which is a surrogate for a single subject. In the language of ISO
13250:2002, the general notion of subject proxies was divided into
"topics," "associations," and "occurrences," despite all three being
surrogates for subjects in any given topic map. The Topic Maps
Reference Model (TMRM) concerns itself with surrogates for all kinds
of subjects, including but not limited to subjects that fall
strictly into one of the three traditional categories; it defines
the notion of "subject proxy".

The TMRM also specifies requirements for
disclosing how to determine whether two or more subject proxies are
proxies for the same subject, and how to view all of them as a
single proxy. In a topic map, if a subject proxy is the only proxy
for its subject, then users can access all information about that
subject through that proxy's single (virtual) "location".

Topic maps are useful ways of viewing
information because, as in all kinds of maps (including geographic
maps), every specific location is unique, and all information that
is relevant to a given geographic location is available at the
corresponding location in the map. For example, in a map of Russia
that depicts cities and elevations, the elevation of St. Petersburg
can be found at the place where St. Petersburg is depicted, but one
would not expect to find this information at the place where Moscow
is depicted. The idea of a unique location within the framework of
a geographic map corresponds to the use of "subject proxy" within
the TMRM.

All maps are written within specific
frameworks of expression. In the case of geographic maps, the
nature of the correspondence between locations on the map and actual
geographic locations is determined by the framework within which the
map is expressed. Often a projection technique, such as the
Mercator projection technique, is an important aspect of the
frameworks of geographic maps. Other aspects of framework design
include decisions about what to depict and what not to depict, the
symbols that will be used, and so on; the framework of a map can
have many aspects and dimensions. No map can be understood in
the absence of at least some understanding of its framework of
expression. When people share the same understanding of the
framework of a given map, they can understand that map in the same
way.

Any map, regardless of its framework, can be
seen in terms of any other mapping framework, but only if both
frameworks are understood. Maps can be combined ("merged") if
their frameworks are known, and if their contents can be understood
in terms of a framework capable of encompassing the combination of
their contents.

In the TMRM, the framework of expression of a
topic map is called a "Topic Map Application (TMA)". The TMRM
requires TMA disclosures to disclose, among other things:

the definitions of the kinds of properties
("property classes") that subject proxies can have,

the rules for determining when multiple
proxies are surrogates for the same subject, and

the rules for merging the values of the
properties of proxies, when it has been determined that the
proxies are surrogates for the same subject and they need to be
viewable as a single proxy.

The TMRM's disclosure requirements are designed
to facilitate the uniform understanding and merging of diverse topic
maps, so that all of the diverse, independently expressed
information about each subject can be viewed as if it were available
at that subject's unique virtual "location" -- its unique subject
proxy.

The abstract definition of Topic Map
Application (TMA), and requirements to be met by disclosures
of TMAs.

Other definitions and specifications in
support of the above.

This International Standard does not specify:

The subjects of subject proxies nor
constraints on such subjects.

The classes of the properties of subject
proxies nor constraints on such classes.

The values of the properties of subject
proxies nor constraints on such values.

The supporting algorithms and data models
that may be used to represent subjects, to detect when two or more
subject proxies are proxies for the same subject, or to merge the
values of Subject Identity Properties or Other
Properties.

(Said of the value of a property of a subject
proxy:) Unsupported by a disclosed conferral rule; given;
axiomatic. The opposite of conferred (the values of
properties of subject proxies can be either built-in or
conferred).

Note 1:

The TMRM does not
constrain the rules, if any, whereby built-in values are calculated
and assigned, nor does it require or constrain their disclosure.
Such rules are not a part of any TMA. Nevertheless, the operation
of such rules results in subject proxies whose properties are
governed by one or more TMAs, so, by establishing disclosure
requirements for TMAs, the TMRM facilitates the expression of such
rules.

(Said of the value of a property of a subject
proxy:) Existing because of the operation of a conferral rule that
is defined by the Topic Map Application (TMA) that defines the
class of the property. The opposite of built-in (the values of
properties of subject proxies can be either built-in or
conferred).

Information that, either within itself and/or
by reference to other information, comprehensively defines (or is
part of a comprehensive definition of) a Topic Map Application
(TMA). Optionally, a disclosure may also define one or more
interchange syntaxes, data models, implementations, and/or
implementation strategies, along with unambiguous and comprehensive
instructions as to how instances of each such syntax, data model,
etc. are intended to be interpreted in terms of the defined Topic
Map Application.

The process whereby two subject proxies that
are surrogates for the same subject become viewable as a single
resulting subject proxy. The single proxy that results from such a
merger has instances of all of the property classes of which either
or both of the original two proxies have instances. If an instance
of a given property class appears in only one of the original two
proxies, then that property instance appears unchanged in the
resulting single proxy. If both of the original subject proxies
have instances of a given property class, the values of those
instances are combined in conformance with the rule for combining
the values of instances of that class that is disclosed by the TMA
that governs the class, and the resulting value becomes the value
of the instance of that property class that appears in the
resulting single proxy.

One of the named values that comprise a subject
proxy: an instance of a Subject Identity Property (SIP) or Other
Property (OP). Its name is the same as the name of the property
class of which it is an instance. In the subject proxy in which
it appears, it is the only instance of its class.

The question of what has or has not been
reified in a topic map view can be answered by examining the SIPs
of its subject proxies. In every subject proxy, at least one
Subject Identity Property (SIP) must appear, and no more than one
SIP that was defined by any given single TMA can appear in a given
subject proxy.

Any thing whatsoever, regardless of whether it
exists or has any other specific characteristics, about which
anything whatsoever may be asserted by any means whatsoever. A
potential or actual subject of conversation.

A property class whose instances
specify the subjects of the subject proxies in which they appear.

A property instance that specifies the
subject of the subject proxy in which it appears.

Note 3:

In every subject proxy, there is always at
least one SIP. As with all properties, both SIPs and OPs, the
nature and structure of the value of an SIP is defined and
constrained by the TMA that defines the corresponding SIP class.
The value of an SIP or OP may be a single value, or it may have
multiple named and/or unnamed components, and the components
themselves may have multiple named and/or unnamed components,
recursively. Property values may be other subject proxies and/or
any kinds of data; the TMRM does not constrain the designs of
property values.

A surrogate for a subject. Subject proxies
consist of property instances, at least one of which must be a
Subject Identity Property (SIP). In a subject proxy, there cannot
be more than one SIP whose class is defined by the same Topic Map
Application (TMA).

A set of subject proxies that is treated
as a unit. The classes of the properties (both SIPs and OPs)
that comprise the subject proxies, and the rules for recognizing
when multiple proxies are surrogates for the same subject, are
both disclosed by one or more TMAs (called the "governing TMAs").
The governing TMAs also disclose the rules for viewing the values
of multiple instances of each property class as a single value of
that class; these rules enable multiple proxies for the same
subject to be viewed as if they were a single proxy with a single
instance of each property class.

An document written in a topic map
syntax; an interchangeable expression of a set of subject
proxies.

Note 4:

The first definition of "topic map" given
above is a restatement of the definition in ISO 13250:2002, clause
3.26 a). (That clause is expressed in terms of ISO/IEC
10744:1997.)

The second definition for "topic map" reflects
the definition in ISO 13250:2002, clause 3.26 b): "Any topic map
document conforming to the SGML Architecture defined by this
International Standard, or the document element (topicmap) of such
a document."

A subject-oriented view of a corpus of
information, via a set of subject proxies that are governed by a
TMA. By conforming to the TMA's rules for recognizing subject
sameness, for merging the properties of proxies, etc., a topic map
view can provide the convenience of subject-oriented access to the
contents of the corpus.

In a topic map view, all subjects for which a
single virtual "location" can be established have a surrogate, that
is, a subject proxy. Every subject proxy is a surrogate for a
single unique subject.

The constraint that every subject proxy must
have, among its properties, one SIP per governing TMA, fulfills two
related but independent functions:

the SIP instances collectively identify
the subjects that the author of a particular topic map view chose
to reify; and

the classes of the SIP instances reveal
how the author chose to distinguish those subjects from one
another, or, in other words, how the author chose to recognize
when two or more proxies have the same subject.

The function of SIP instances (that is,
specifying the subjects of the subject proxies created by an author)
enables interchange of topic map views with the expectation that the
view as authored can be the same view seen by a user. The user is
not constrained to take that view, but, since the ability to
interchange topic map views is a requirement, this International
Standard must enable authors to give users of topic map views the
ability to replicate the views as authored.

The function of SIP classes (that is, revealing
how the topic map view's author chose to distinguish the subjects of
subject proxies) facilitates the merging of independently authored
topic map views, not only when the views are expressed in terms
defined by the same TMAs, but also when the TMAs are different. In
the latter case, each independent TMA's Disclosure of its means for
distinguishing the subjects of subject proxies can provide a useful
basis for designing rules for combining the proxies governed by the
independent TMAs.

Each Disclosure of a Topic Map Application (TMA)
must disclose the following things:

Topic Map Application Name. The
name of the TMA.

Property Class Names. The names of
all of the TMA's Subject Identity Property (SIP) and Other
Property (OP) classes. Every TMA must define at least one SIP
class, but OP classes are optional. Within a given TMA, the names
of all SIP and OP classes must be unique; they all share the same
namespace.

Property Value Constraints.
Definitions of the constraints on the values of instances of each
SIP class and OP class. These constraints may include, for
example, their value types.

Property Instance Merging Rules.
For each SIP class and OP class, a definition of the rule for
combining the values of multiple instances of it into the value of
a single instance.

Note 5:

Whenever two subject
proxies have been determined to have the same subject and each of
them has an instance of a given property class, the values of the
two property instances are combined into the value of a single
instance of the same property class. (Each subject proxy has only
one instance of each property class.) TMA-defined property
instance merging rules disclose how that calculation should be
made for all of the instances of each property class.

Note 6:

When combining two or
more subject proxies, if there is a single instance of a property,
then that instance is preserved in the merged subject proxy. (See
the definition of merging.)

Note 7:

Designers of TMAs are
free to define rules for combining the values of multiple
instances of property classes in such a way that they must raise
exceptions or have other special behaviors when combining the
values is impossible, or when combining them would violate the
logic of the TMA. Such exceptional behaviors are unconstrained by
the TMRM; they are left to the discretion of TMA
designers.

Subject Sameness Detection Rules.
For each SIP class, the rule for comparing any two instances of
the class in order to determine whether they specify the same
subject, i.e., whether the subject proxies in which two instances
of the same SIP class appear can be viewed as a single subject
proxy in which their respective property instances have been
merged.

Conferral Rules. If the TMA
includes rules (called "conferral rules") that require values or
value components to be conferred upon property instances, then,
for each conferral rule, the property/value conditions that
trigger the operation of the rule, and the effects of its
operation on property values, must be disclosed. Conferral rules
can require the conferral of values or value components on
property instances that do not have any built-in value components,
and therefore would not exist without their conferred values; such
property instances are said to be "conferred into existence".
Property instances that are conferred into existence may appear in
subject proxies that would not otherwise have any property
instances, and therefore would not otherwise exist; such subject
proxies are also said to be "conferred into existence".

Note 8:

Individual topic maps may
or may not have any proxies whose property values are conferred
(as opposed to built-in). For example, a topic map can be
governed by a TMA that has no conferral rules, or that has
conferral rules whose triggering conditions are unmet in the topic
map. However, every a topic map must have at least one built-in
property value; without it, there would be nothing to trigger the
operation of any conferral rule.

The following grammatical productions are
expressed in a notation similar to that of Clause 5 of ISO 8879.
They summarize what the TMRM requires TMA Disclosures to disclose,
and how the property instances that appear in the subject proxies of
topic map views invoke the disclosures that apply to them by means
of the names of TMAs, SIP classes, and OP classes.

(7) conferralRule = [unconstrained by the TMRM, except that
only instances of property classes
defined by the same TMA that defines the
conferral rule can have values conferred
upon them by that conferral rule.]

While extremely interesting as an implementation
strategy or model, the Tau model has no concept of identity (by
design), preferring to leave that issue to other parts of the topic
maps standard.

For the TMRM, on the other hand, the question of
identity lies at the core of having a topic map view. That is, in
order to have interchangeable, mergeable, or even useful topic map
views, one must know what was authored as a subject proxy (in TMRM
terms, what possesses an SIP) and on what basis that SIP was to be
compared to others for purposes of detecting subject sameness, and
what to do when subject sameness is detected. Knowledge of how such
processing will be performed is of vital interest to promote use of
topic maps, but is not the same as formulation of a the requirements
for disclosing those choices.