Version 3 is a complete redraft that narrows
the focus to nomenclature and Disclosure.Version 2 is a major revision of Version 1.
The ideas of Version 1 are preserved, but they are now all
explained in terms of the properties of topics. There are also
some terminological changes; for example, what in Version 1 was
called a "node" is called a "topic" in Version 2. Made IS13250::t-roles{ } an SIDP
instead of an OP. According to the TMRM paradigm, it is
inescapable that the subject of a t-node is its roles, at least
for all purposes of merging topics.Introduction
(Informative)Topic maps are bodies of
information that consist of "topics", each of which is a surrogate
for a single subject. If every
topic in a topic map is the only surrogate (or "proxy") for its
subject, then users can find all information about that subject in
a single (virtual) "location".The number of possible subjects is unbounded,
but the number of subject proxies in a given map is necessarily
finite. Therefore, whenever a topic map is created, choices are
necessarily made as to which subjects will be provided with
proxies, and which will not. The Topic Maps Reference Model
(TMRM) does not constrain these choices. Instead, the TMRM
provides the basis on which such choices can be unambiguously
disclosed. Disclosure makes it possible
for the users of a topic map to make informed decisions about how
to process the information in the topic map. In order to support
such Disclosures, the TMRM provides a nomenclature for the
features of subject proxies, including the proxies of
relationships between other subjects.The TMRM neither extends nor alters ISO
13250:2002. The notions for which the TMRM provides terms and
definitions are all implicit in the HyTime and XML syntaxes of
ISO/IEC 13250:2002.The Topic Reference Model
meets the following requirements:
It answers the question: "What is a
topic map?" It defines what a topic (or "subject
proxy") is, and what a topic map is, at the highest level of
abstraction, independently of any interchange syntax, data
model, implementation, etc.
It enables meaningful disclosure of
the choices and assumptions that govern the designs of
existing and future topic maps, interchange syntaxes, data
models, and systems that implement them. It provides a
uniform conceptual and terminological foundation for
disclosing their policies and features with respect to
subject reification, subject identification, and internal
consistency, as well as their other semantics. Such
Disclosures can assist users and system implementers to
understand and process topic maps in ways that are
consistent with the intentions and/or designs of their
creators, even in the absence of the implementations, data
models, interchange syntaxes, etc. that were used to create,
maintain, and interchange them. Such Disclosures can assist
the potential adopters of specific system solutions to
evaluate the ability of such systems to meet specific
requirements.
The Topic Maps Model meets the above
requirements by:
Defining what a topic is.
Topics are surrogates for subjects. Every topic represents
one subject, and every topic consists entirely of a set of
properties (i.e., a set of name/value pairs). Property
values are typed. Their value types can be arbitrarily
complex. The names of properties must be unique.
Distinguishing between two kinds of
property classes: SIDPs and OPs. The subject that a
topic represents is independently specified by each of its
Subject Identity Discrimination Properties (SIDPs). Merger
of topics occurs solely on the basis of their SIDPs. Two
topics merge when their respective SIDPs are deemed to
specify the same subject. A topic may also have Other
Properties (OPs); OPs can be used for any purpose other than
subject identity discrimination.
Establishing a uniform way of
representing relationships between subjects. Topics
may participate in assertions. Each assertion
specifies a relationship between subjects. Just as a
relationship consists of a set of component subjects
(the type of relationship, the roles, the role players, the
relationship itself, and the castings), an assertion
consists of a set of corresponding component topics.
Each such set of topics collectively represents the
component subjects of a single relationship, as follows:
The type of the
relationship is the subject of the "t-topic"
(assertion type topic). There is always exactly one
t-topic.
Each role in the
relationship is the subject of an "r-topic" (role
topic). There are always at least two
r-topics.
Within the context of the
assertion, each role player in the relationship
is the subject of an "x-topic" (role player
topic). There is always at least one
x-topic.
The relationship itself
is the subject of the "a-topic" (assertion
topic). There is always exactly one a-topic.
Each role player, seen as the
player of its role, is the subject of a
"c-topic" (casting topic). If the role is
unplayed, the subject of the corresponding c-topic is
the fact that the role is unplayed.
The component topics of each assertion
are connected to each other; these connections are
represented by their being the values (or value components) of certain of
their respective property
instances. Most of these connections are reciprocal.
(See for an illustrated
discussion.)
Establishing a uniform method for
detecting when two assertions represent the same
relationship. Two assertions are regarded as
representing the same relationship if, in both of them, the
same role players play the same roles. Accordingly, the
SIDP of every a-topic is a
structured value whose value components are the r-topics and
x-topics of the assertion. Two assertions are merged,
becoming a single assertion, if the values of the SIDPs of
their a-topics are equivalent. (When such a merger occurs,
their respective c-topics also necessarily merge; the SIDPs
of c-topics are composed of the a-topic, an r-topic, and the
x-topic that plays the role, if any.)
Establishing that, in order to allow
a topic map to be understood accurately, certain things
about it must be disclosed. In order to disclose the
way in which a topic map is intended to be understood and
processed, the following must be specified:
The classes of properties
of which the topics consist. For each property class, its semantics,
its unique name, its value type, the direct and indirect
ways in which its instances receive their values, and,
if the property is for subject identity discrimination
(i.e, if it is an SIDP), the criteria for deciding
whether the values of two such properties specify the
same subject, must be specified.
The set of roles that can
be played in each kind of relationship, the semantics of
each role, and the impacts, if any, on the properties of
any topic that plays the role.
The "built-in" property
instance values of the topics that are assumed to be
present in every instance of the kind of topic map that
a given Disclosure describes.
ScopeThis International Standard specifies:
a nomenclature to describe the
information structure of statements about subjects (assertions
about topics) in topic maps;
a nomenclature for essential aspects
of the properties of topics;
a nomenclature to describe the
conditions for merger of topics in a topic map;
other definitions and specifications
that support the foregoing.
This International Standard does not
constrain:
the properties that topics may
include; or
the algorithms and data models used to
represent, recognize, and distinguish the subjects of topics
(such algorithms and data models are sometimes called
merging rules); or
the kinds of statements that can be
made about topics, nor the inferences that may be made on the
basis of them, nor their impacts, if any, on the properties of
the topics that play roles in such statements.
Such constraints can only be specified in the
contexts of specific Applications. Syntaxes, data models,
etc. always necessarily reflect such constraints. From the
perspective of the TMRM, all assertions are Application-specific.
The TMRM defines no assertion types whatsoever, and the only
properties it defines are common to all statements ("assertions"),
regardless of their types, and regardless of the Application
context(s) within which such statements are made.Glossarya-topicIn an assertion, the
component topic whose subject is the relationship represented by
the assertion.Application[When capitalized:] A complete and
independent system of property classes, assertion roles, and
built-in topics that is designed to meet specific information
representation and processing requirements by means of topic
maps. An Application is a "syntax" or "language" in the most
abstract senses of the latter terms, i.e., the senses that do
not necessarily imply specific symbols, symbol sequences, or
rules for parsing them. An Application is a context -- a
universe of discourse -- within which the kinds of statements
that it allows to be made are meaningful, and within which
certain logical inferences are licensed. Every Application must
enable and require the subjects of topics to be discriminated,
such that when two topics have the same subject, such a
situation can be recognized, and the two topics can be merged in
the same way by all implementations of that Application. Every
Application must therefore provide SIDPs for all of the subjects
that topics can represent by means of the properties it defines,
and/or that can be players of the assertion roles that it
defines.Any number of representations (interchange
syntaxes, data models, etc.) and any number of system
implementations can be associated with a single Application.
The ways in which instances of such syntaxes and data models are
intended to be understood in terms of an Application can be
Disclosed.assertionA statement of a
relationship between the subjects of topics. Each assertion is
a set of connected topics that represent the following subjects:
(i) the subject of the assertion (one a-topic); (ii) the type of the
relationship (one t-topic); (iii)
the roles in the assertion (at least two r-topics); (iv) the role players in the
assertion (at least one x-topic);
and that each role player present plays a particular role in the
relationship (one c-topic for
each role in the assertion). built-in property value (or built-in
property value component)A value (or value component)
of a property instance that is not conferred.c-topicIn an assertion, a component topic that
represents the subject that is a subject -- one of the
role players in the relationship represented by the assertion --
seen as the player of its role in the assertion.component
component (of an assertion):
Same as component
topic.
component (of a
relationship): Same as component
subject.
component (of a
topic): Same as property
instance. (Not to be confused with component topic.)
component topic: An instance
of one of the five kinds of component topics of a assertion:
a t-topic, an r-topic, an x-topic, an a-topic, or a
c-topic.
component subject: An
instance of one of the five kinds of component subjects of a
relationship: a type of relationship, a role, a role player,
a relationship, or a casting.
value component (or
property value component): See .
conferred property value (or
conferred property value component)In a topic, a property
value(or property value
component) that exists by virtue of that topic playing a
specific role in one of the assertions in which it is an
x-topic. "Conferred" is the opposite of "built-in".Disclosure
[When capitalized:] Information that,
either within itself and/or by reference to other
information, comprehensively defines (or is part of a
comprehensive definition of) an Application, including all
of that Application's property classes, assertion roles,
and built-in topics, in conformance with the nomenclature,
concepts, and constraints specified by the TMRM. 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 Application.
The provision of such information, for
example, along with an interchangeable topic map, in order
to facilitate the interpretation of that topic map in
accordance with the intent of its creator.
mergingThe process whereby two
topics become a single topic because they are deemed to have the
same subject.Other Property (OP)A property class or property instance that
is not a Subject Identity Discrimination
Property (SIDP).property
A property
class.
A property
instance.
property classA uniquely-named class of
name/value pair defined as being instantiable as a component of
a topic.Instances of such classes are called
"property instances".property instanceA uniquely named component of a topic; a
name/value pair that is an instance of a property class. The value may be
either built-in or conferred.r-topicIn an assertion, a component
topic whose subject is one of the roles that can be played in
all instances of assertions of the same type.roleA specific part that a
subject can play in an instance of a specific kind of
relationship. The subject of an r-topic in an assertion.role playerA subject
that plays a part in a relationship. The subject of an x-topic
in an assertion.SIDPSubject Identity
Discrimination Property.subjectAny 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.Subject Identity Discrimination
Property (SIDP)
A property
instance which uniquely specifies the subject of the topic of which it is
a component, and which serves as the only basis for
recognizing when two topics have the same subject, and
should therefore either be merged or left unmerged. The
opposite of Other Property
(OP).
A property
class designed so that each of its instances uniquely
specifies the subject of a
topic. The opposite of Other
Property (OP).
Within the context of a single
Application, every topic has exactly one SIDP. However, a
single topic can have multiple SIDPs; see .t-topicIn an assertion, the component topic whose
subject is the type of relationship of which the assertion is an
instance.topicA non-empty set of property instances that
serves as a surrogate of a subject. At least one of the
properties must be an SIDP.topic mapA body of information consisting of a
non-empty set of topics.Topic Maps Reference
Model (TMRM)This International Standard.value componentA distinct portion of a single property
value, such as a member of a complex value or a member of set.
Also called property value component.value typeA set of values. More precisely, it is the
set of all possible values for the type in question. In some
contexts, value type may be regarded as synonymous with
data type and domain.x-topicIn an assertion, a topic that plays the role
that is the subject of one of the r-topics. A topic that is an
x-topic in the context of one assertion may or may not be an
a-topic, r-topic, t-topic, c-topic, or x-topic in another
assertion. (All topics are eligible to be x-topics in the
context of any number of assertions.)Subjects and topicsIn a topic map,
all subjects about which anything
is stated are represented by topics. Every topic represents one
subject. The number of topics in a topic map is finite; every
topic map necessarily reveals which subjects its creator chose,
from an unbounded number of possible subjects, to represent by
means of topics.In a topic map, a single subject may be
represented by more than one topic. Given the same input topic
map and the same Disclosure(s) of the relevant Application(s),
implementations that conform to such Disclosures uniformly merge
the topics that, according to the applicable Disclosure(s), must
be deemed to share the same subject.Properties of TopicsIn Disclosures of topic map
Applications (including Disclosures of how interchange syntaxes,
data models, etc. should be interpreted in terms of Applications),
topics are understood as consisting of property instances. Each is an instance
of a Disclosed property
class.Property namesEvery property class has a name that is
unique in the namespace of property classes defined by a given
Application. The TMRM places no other constraints on the names
of properties.No topic can have more than one instance of
any property class.In other words, no two properties can have
the same name.Property ValuesThe definitions of property classes specify
the types of the values of their instances. The value type of a
property may be simple (without substructure) or complex (having
substructure, each branch and leaf of which is a so-called value component). The TMRM
constrains neither the types nor the structures of property
values that are defined by Applications. Property instances exist only if values have
been assigned to them.A property instance may exhibit a null or
empty value if that value has significance with respect to the
value type.SIDPs and OPsInstances of certain property classes are used as the basis
for determining whether two topics must be deemed to have the
same subject. Such properties are called "subject identity
discrimination properties (SIDPs)". SIDP values are the
only basis for automatically recognizing when two topics
are deemed to have the same subject and should therefore either be
merged or left unmerged. For each SIDP, it is necessary to
Disclose the criteria and/or procedure that must be uniformly
applied in order to compare the values of two instances of it,
whenever it is necessary to decide whether their respective
topics should be merged or left unmerged.When a topic has any properties defined by
an Application, and/or if it plays a role defined by it, it has
exactly one SIDP that is defined by that same Application.
However, a single topic can have multiple SIDPs, each of which
is meaningful in the context of a distinct Application. When
this occurs, it reflects the fact that the subject of the topic
(which is always, after all, a single invariant subject) is
reified in terms of each of the Applications that define one of
its SIDPs.All properties that are not SIDPs are "Other
Properties (OPs)". The Disclosure of an Application must not
specify that any OP of any topic is used for the purpose of
determining whether it has the same subject as any other topic
and should therefore be merged or left unmerged.Theoretically, at least, a given
representation of an instance of a topic map can be
interpreted in terms of multiple Disclosed Applications.
However, Disclosures that differ from one another in any
substantive way, such as by having different names or value
types for their otherwise-corresponding SIDPs, or different
instructions for the interpretation of the same interchange
syntax, must be considered to disclose different Applications,
and such different Applications should have different
names.Applications may define situations in
which OP values are used to calculate the values to be
conferred on the SIDPs of other topics. Thus, OPs may have
indirect impacts on the merging of topics.Each disclosed property class definition
must specify whether the property is an SIDP or OP.Conferred vs. Built-in Property
InstancesProperties exist if and only if values have
been assigned to them. The ways in which properties (i.e.,
property values and property value components) are assigned are
unconstrained by the TMRM, but the TMRM requires that
Disclosures specify the bases on which all such assignments
occur. The TMRM requires Disclosures to distinguish between two
different categories of property value assignments: assignments
of so-called built-in property values, and assignments of
conferred property values, in a manner that allows all
property value assignments to be recognized as falling into
either one category or the other. The distinction between
built-in and conferred applies to the assignments
of values to property instances. It does not apply to property
classes or their value types. Experience shows that inattention to the
latter point, and particularly the use of conversational
shorthand, can easily lead to the propagation of
misunderstandings, especially in the following cases:
Cases in which the design of an
Application is such that all instances of a particular
property class are necessarily always built-in (or,
alternatively, always conferred): It makes a kind of
sense to say, of such a property class, that it is
built-in (or conferred). Those who understand the real
significance of the distinction between built-in
and conferred may thus reasonably say "built-in
property" to each other. But if their listeners do not
understand that "built-in property" is shorthand for
"property class the values of whose instances are always
built-in", confusion about the nature of the
built-in/conferred distinction is probably
inevitable.
Cases in which property
instances exist only because of a single specific value
assignment: It is normal and meaningful for the term
property to be used
ambiguously, so that the concepts of property class and property instance are both
invoked at the same time. (For example, when we say
"property name", we mean, at the same time, both
the name of a property class and the name that
identifies each of the instances of that class, in all the
topics that include an instance of the class.) Although
such ambiguity is often essential for clarity and
readability, it also sometimes causes confusion. For
example, it may be perfectly reasonable to speak of a
"conferred property", instead of using the longer, more
precise phrase, "conferred property value", because the
topic on which the value is conferred may not have any
other value assigned to that property, and properties to
which no value has been assigned are not considered to
exist. Conferring the value, therefore, means conferring
the property. But it is not a property class that is
being conferred; it is only a property instance. In this
situation, the phrase "conferred property instance" is
much less likely to cause confusion than the phrase
"conferred property".
Conferred property
valuesA property value is said to be
conferred when it is assigned to the property of a
topic because the topic plays a specific role in some
assertion.Disclosures must specify all of the rules
that govern the conferral of property values. All
implementations that claim conformance to an Application must
apply its rules uniformly.A Disclosure may specify the rules for
property conferral as an aspect of each of the roles that it
defines, or the Disclosure may be structured in any other
way. (Conventions for the expression of Disclosures are
beyond the scope of the TMRM.)When a value is conferred, the value is
calculated according to a Disclosed uniform procedure, the
nature of which is not constrained by the TMRM.The notion of value conferral allows
properties of topics, including their SIDPs, to be
determined on the basis of their networks of connections to
other topics, and the semantics of the assertion roles that
comprise those connections. A conferred property value can
be calculated on the basis of the values of the properties
of the topics to which it is connected via one or more
assertions.To confer an SIDP upon a topic is to
bring that topic into existence. The notion of conferral
allows combinations of assertions about subjects to bring
other subjects into existence -- to endow them with topics
that represent them. A similar phenomenon is a normal
feature of ordinary human conversation: to make an assertion
about a subject is to make it part of the conversation, even
if it wasn't already. Whatever is said about it establishes
its nature, for all conversational purposes.Built-in property
valuesWhen a property value is built-in,
it is not on account of the fact that the topic on which the
value is conferred plays a specific role in some assertion.
Instead, the property value or value component (and possibly
the whole property instance) exists because (i) it is required
by a Disclosed rule that has been applied to the
interpretation of an interchangeable representation of the
topic map, or (ii) because the Disclosure requires both the
topic and its property to exist in all topic maps that conform
to the Disclosed Application, or (iii) on account of any other
Disclosed rule, operation, or convention.Such an "other" Disclosed rule,
operation, or convention might be that the value is built in
if the same topic has other properties that are present in
accordance with the operation of one or more other Disclosed
Applications.Since the TMRM defines no assertion
types (and therefore no roles) whatsoever, it cannot require
that any values be conferred on (as opposed to being
built-into) the properties that it defines (see and ).
Therefore, in the absence of Disclosed assertion roles that
confer values upon the TMRM-defined properties of their
players, it is safe to assume that the values of all of the
instances of TMRM-defined properties are necessarily
built-in.Every topic map must have at least some
built-in properties.In order for any property values to be
conferred, there must be assertions. In order for there to
be assertions, there must be r-topics. Therefore, if a
topic map has any assertions in it, the Disclosure of the
Application to which it conforms must have at least some
roles whose SIDPs are built-in. And if a topic map has no
assertions, the only topics it can have must have built-in
SIDPs; every topic must have an SIDP.It is possible for a topic to exist in a
topic map without having any connection to any other topic,
i.e., without participating in any assertion in any way.
The SIDPs of such "isolated topics" are necessarily
built-in.A single property value can consist of
components that are all built-in, all conferred, or some
conferred and some built-in. It is possible for conflicts to
occur between the conferred and built-in values of a single
property; in the absence of any Disclosed rules for handling
such conflicts to the contrary (such rules must be aspects of
the rules for conferring property values), topic maps that
include such conflicts must be regarded as self-contradictory.
In any case, no rule can require built-in property values or
value components to be superseded by conferred values. No
conflict exists if a Disclosed rule requires a value or value
component to be conferred that is the same as the one that is
already built-in.AssertionsSubjects can participate in
relationships with each other. In the TMRM, and in Disclosures,
all relationships are understood in a single, uniform manner. Each
relationship is understood as a set of connected subjects, where
each subject corresponds to a single, unique structural function
in the relationship. These component subjects are the
relationship itself, its type, its roles, its role players, and
the castings of the role players in the roles. This connected set
of subjects is regarded as being represented by a corresponding
set of component topics: each instance of such a set of
topics is called an assertion. Such a set of topics
"asserts" the relationship that it represents.The TMRM defines names for the properties of
topics that represent their functions in assertions, in order to
allow meaningful disclosure of the intended interpretations of
particular syntaxes, data models, etc. However, no syntax, data
model, etc. is required to use the names defined by the TMRM for
these properties. (Neither does the TMRM constrain the
definitions of any additional properties of topics,
regardless of whether their subjects are components of
assertions.)A subject can be a role player in an assertion
if and only if it is represented as a topic. All topics,
including topics that are components of assertions, can be role
players in assertions.However, Applications typically impose
eligibility requirements on the players of specific roles. For
example, designers of an Application may choose not to allow the
"husband" role in a marriage assertion to be played by anything
other than a human being. Disclosures of Applications should
comprehensively specify all such role-player eligibility
requirements.Implementers, data model designers, and
syntax designers are not required make the models they use to
represent relationships reflect the assertion model provided by
the TMRM. Any differences between their assertion models and
the TMRM's assertion model can be explained in their
Disclosures, by specifying how the constructs defined in their
designs are intended to be understood in terms of the assertion
model provided by the TMRM.Component Subjects of
RelationshipsIn the TMRM, relationships are understood as
complexes of subjects, each of which, from the perspective of
the relationship (called "this relationship" in the list below),
is one of the following five kinds of subjects:
The subject that is this
relationship itself. This subject is the set of
component subjects, including itself, that comprise this
relationship, including the structural relationships that
the component subjects have with each other within the
context of this relationship. Topics that represent such
subjects are called a-topics. The a
stands for assertion. Every assertion has exactly
one a-topic.
The subject that is the type of
relationship of which this relationship is an instance.
The identity of a relationship type is comprehensively and
exclusively specifiable as a set of roles. Topics that
represent such subjects are called t-topics. The t
stands for type. Every assertion has exactly one
t-topic.
The subjects that are the roles
that can be played in this relationship. Topics that
represent such subjects are called r-topics. The r
stands for role. Every assertion has two or more
r-topics. No two relationship types have any roles in
common.
The subjects that are the players
of the roles in this relationship. When a relationship
exists among subjects, each subject so related is called a
role player. Within the context of a relationship,
the topics that represent the role-playing subjects are
called x-topics. The
x connotes exceptional variability: while the other
four kinds of component subjects are constrained by the TMRM
relationship model (for example, the subject of an a-topic
is always a relationship), the model does not constrain the
subjects of role players in any way. Every assertion has at
least one x-topic.
The subjects that are the
castings of the role players in their roles in this
assertion. A specific role player seen as the player of
a specific role in a specific assertion (or, if the role is
unplayed, the fact that no role player plays the role) is a
"casting" subject. Topics that represent casting subjects
are called c-topics.
(The c stands for casting.) In an assertion,
there is one casting per role, and within a single
assertion, no two castings can cast role players in the same
role.
In other words, in an assertion, no role
can be played by more than one subject. However, A set of
subjects can be a subject, and such a set can be a role
player. The TMRM does not provide or constrain set semantics,
nor does it constrain the playing of roles by sets.SIDPs of a-, t-, and
c-topicsThe topics in the set of
topics that comprise an assertion have property instances that
specify their participation in assertions. Some of these
property classes are SIDPs; these are defined in this Section
. Some of these property classes
are OPs; these are defined in . No
syntax, data model, Application definition, or implementation is
constrained to implement these property classes, nor to use the
names defined for them by the TMRM. The TMRM defines these
property classes solely for the purpose of providing a
"reference model" that permits the intended interpretations of
topic maps that conform to Applications, syntaxes, or data
models to be Disclosed in explicit, unambiguous and uniform
terms.A diagram of instances of the SIDPs and
OPs defined by the TMRM, as they might appear in a two-role
assertion, is provided in .Disclosures of the mappings between
implementation-defined properties and TMRM-defined properties
necessarily highlight the design decisions of implementers
with respect to the reification of the component subjects of
relationships. They also shed valuable light on the ability
of a given Application (and/or implementation thereof) to meet
specific user requirements while avoiding undue overhead.
They can be used to port knowledge from one implementation to
another, without having to resort to guesswork that might
compromise the integrity of their information content, by
interpreting them in ways that were not explicitly licensed by
their designers. Similarly, Disclosures can also provide
essential guidance to designers of Applications that are
intended to encompass the logic of multiple other
Applications, in order to combine diverse topic maps, again
without compromising the integrity of their information
content.The TMRM defines the SIDPs of a-topics,
t-topics, and c-topics. It does not define the SIDPs of
r-topics and x-topics.The subjects, and therefore the SIDPs, of
r-topics are always Application-specific. Like the
definitions of all other SIDPs, they can be Disclosed.Topics that are regarded as x-topics in
the context of one assertion may or may not also be a-topics,
t-topics, or c-topics in the context of another assertion. If
they are a-topics, t-topics, or c-topics, their SIDPs are
defined by the TMRM; otherwise, their SIDPs are
Application-defined.In a Disclosure of the intended
interpretation of a data model, syntax, etc., no topic can have
more or less than one SIDP, and every SIDP specifies the subject
of its topic, for all purposes of triggering the merging of
topics. No Disclosure can override or replace the TMRM-defined
SIDPs of a-topics, t-topics, and c-topics; these SIDPs must be
incorporated in the Disclosed interpretation of each data model,
syntax, etc. The intended method(s) for mapping the constructs
found in instances a data models, interchange syntaxes, etc. to
the value components of each TMRM-defined SIDP must be
Disclosed. Implementations of Disclosed mappings must apply
them uniformly.The a-sidp SIDP class of
a-topicsThe name of the property that is always
and exclusively the SIDP of all a-topics is
a-sidp.The value of every a-sidp
property is a set of so-called "casting pairs". Each such
pair associates a role (one of the roles in the relationship
that is the subject of the a-topic) with the player, if any,
of that role in the relationship. The number of casting pairs
is equal to the number of roles that can be played in the
relationship.The name of the property value component
whose value is a role in each casting pair is a-sidp{
}.r. Its value is always an r-topic that is one of the
r-topics that comprise the assertion of which the a-topic is
the nexus.a-sidp{ }.x is the name of the
property value component whose value is the topic whose
subject is the role player in a casting pair. Thus, the two
members of the pair are named a-sidp{ }.r and
a-sidp{ }.x.At the level of abstraction at which the
TMRM operates, the instrumentality that makes it possible
for a topic to be the "value of" a property is both
invisible and irrelevant. When the TMRM says that a topic
is the value of a property (or of a property value
component), such a statement must be understood literally.
The value must not, for example, be understood to be a
pointer to an object which is a topic; the value must be
understood to be the topic itself. However, Applications
and their implementations are unconstrained. Application
designers, data model designers and/or their implementers
may, for example, choose to implement the idea that a topic
is the value of a property by using a pointer to an object
that is an implementation of a topic, or in any other way.
When they Disclose their designs, however, it is vital that
they recognize that, in TMRM terms, when a topic is said to
be the value of a property, there is, logically speaking, no
pointer involved.The notation { }. that appears
within the property name a-sidp{ }.r is a TMRM
convention that, in this case, means:
that the value of the
a-sidp property is a set ({ }) of
value components, and
that each member of such a set
has a value component (.) whose name, by
virtue of the fact that it immediately follows the dot, is
declared to be r.
It is beyond the scope of the TMRM to
establish a conventional notation for declaring the value
types of properties in Disclosures, or for addressing the
values of property instances. The TMRM provides its own
conventions for notating the names of property value
components, including "{ }" and ".",
solely in order to meet its own self-description
requirements. Conventions for interchanging Disclosures are
free to establish their own notational conventions, and to
adopt or ignore any or all of the names and naming
conventions used by the TMRM.When the notations established by such
conventions differ from those of the TMRM, they should
include declarations of the properties defined by the TMRM,
using their own notations in order to permit the names and
notational conventions used for property names (and property
value component names) to be uniform.Such conventions may also provide
notations for addressing property values and property value
components. For example, if the notation used by the TMRM
were incorporated in such a convention, a specific member of
a set might be addressed by inserting a member-selection
specification between the braces. For example, the role
player member of a specific casting pair might be specified:
a-sidp{(member selection expression
here).x}.If, in a relationship specified by an
assertion, a role has no role player, in the corresponding
casting pair, the role value (a-sidp{ }.r) is paired
with a null value for the corresponding a-sidp{ }.x
member of the pair; the lack of a value indicates that there
is no role player. In other words, when a role is unplayed,
the corresponding a-sidp{ }.x value component exists
but has no value.It would be incorrect to supply such a
topic in order to avoid the need for a special, non-topic
way of indicating that a role is unplayed. In TMRM terms,
all topic maps consist of topics, all of which are processed
in such a way that, when any two topics have the same
subject, they are merged. If topics whose subject is "the
absence of a subject" were used as "unplayed role
indicators", all unplayed roles would necessarily appear to
be played by the same subject -- an outcome very unlikely to
be expected or desired.Two a-topics are always deemed to have the
same subject if the values of their respective a-sidp
properties is the same set of casting pairs. As is the case
whenever two topics are deemed to have the same subject, they
must be merged before the topic map can be deemed to be ready
to use, in conformance with its creators' intentions.When two a-topics are deemed to have the
same subject and are merged, the resulting single a-topic has
a value for its a-sidp property that is equivalent to
the value of both of the a-sidp values of the
original a-topics.Readers of the TMRM may ask, at this
point, "What if two assertions have the same role players
playing the same roles, but they are not the same type of
assertion? Should the two assertions be merged?" Such a
situation cannot occur, because no single role can appear in
two different types of relationship, and, therefore, every
role implicitly specifies the only type of relationship in
which it appears; see .The t-sidp property class
of t-topicsThe name of the property that is always
and exclusively the SIDP of all t-topics is
t-sidp.The value of every t-sidp
property is the set of r-topics whose subjects are the roles
that can be played in every instance of the type of
relationship that is the subject of the t-topic.Two t-topics are always deemed to have the
same subject if and only if the values of their respective
t-sidp properties is the same set of r-topics.When two t-topics are deemed to have the
same subject and are merged, the resulting single a-topic has
the same value for its SIDP as both of the original t-topics
did.The c-sidp property class
of c-topicsThe name of the property that is always
and exclusively the SIDP of all c-topics is
c-sidp.The value of every c-sidp
property is a composite that specifies the casting that is
subject of the c-topic. Each c-sidp property
consists of three value components, all of which are always
present:
c-sidp.a: The value is the
a-topic of the assertion in which the c-topic represents a
casting.
c-sidp.r: The value is the
r-topic whose subject is a role, one casting of which role
is the subject of the c-topic.
c-sidp.x: The value is the
x-topic, if any, whose subject is the role player, one of
whose castings is the subject of the c-topic. If, in a
relationship specified by an assertion, a role has no role
player, in the c-topic whose subject is the casting of
that role, the c-sidp.x property value component
exists but has no value.
Two c-topics are always deemed to have the
same subject if and only if their values are the same.When two c-topics are deemed to have the
same subject and are merged, the resulting single c-topic has
the same value for its SIDP as both of the original c-topics
did.TMRM-defined Other Properties
(Normative)Properties called Other Properties (OPs) are defined
for purposes other than determining whether two topics should be
merged or left unmerged. The purpose of the properties defined in
this is to provide conventional
names for the non-SIDP properties of a-topics, r-topics, t-topics,
and x-topics that connect together all of the component topics of
individual assertions.Other Properties of
a-topicsa-castingsThe value is the set of two or more
c-topics whose subjects are the castings of the assertion of
which the a-topic is the nexus.a-typeThe value is the
t-topic whose subject is the type of the assertion which is
the subject of the a-topic.Other Properties of
r-topicsr-castingsThe value is the set of all
c-topics whose subjects are castings of the role that is the
subject of the r-topic. The set may be empty.r-typeThe value is the t-topic
whose subject is the relationship type whose roles include the
role which is the subject of the r-topic.Other Property of
t-topicst-assertionsThe value is the set of
all a-topics whose subjects are relationships that are
instances of the relationship type that is the subject of the
t-topic.Other Property of
x-topicsx-castingsThe value is the set of all c-topics that
cast the subject of the x-topic in a role in an
assertion.Diagrams of TMRM-defined Properties
(Informative)The following diagrams are intended to aid the
reader's understanding of the ways in which the component topics
of assertions are connected to each other. The component topics
have TMRM-defined properties, and these properties have, as their
values, other component topics of the assertion.The t-topic, r-topics and x-topics of an
assertion may or may not also be components of other assertions.
This is one of the reasons why the value types of their properties
(for example, the x-castings property of all x-topics)
are sets of topics. In the diagrams below, however, we are
concerned only with the single assertion that they depict.In all of the following diagrams, the
TMRM-defined Subject Identity Discrimination Properties (SIDPs) of
each component topic are depicted in red, while the Other
Properties (OPs) are depicted in black. No Application-defined
properties are shown, even though, at the very least, the x-topic
and the r-topics must have Application-defined SIDPs.All of the following diagrams depict the same
assertion. It is a two-role assertion. Only one of the roles
(the one on the left) has a role player (an x-topic).TMRM-defined connections between the
t-topic and the r-topicsTMRM-defined connections between the
t-topic and the a-topicTMRM-defined connections between the
a-topic and the r-topicsTMRM-defined connections between the
a-topic and the c-topicsTMRM-defined connections between each
c-topic and its corresponding r-topicTMRM-defined connections between each
c-topic and its corresponding x-topic (if any)TMRM-defined connections between the
a-topic and the x-topicsTMRM-defined connections: the whole
shebang