ISO/IEC JTC 1/SC 34N0460

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

1 December 2003

Table of Contents

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:

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

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

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

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

3. 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 Annex B for an illustrated discussion.)

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

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

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

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

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

This International Standard specifies:

1. a nomenclature to describe the information structure of statements about subjects (assertions about topics) in topic maps;

2. a nomenclature for essential aspects of the properties of topics;

3. a nomenclature to describe the conditions for merger of topics in a topic map;

4. other definitions and specifications that support the foregoing.

This International Standard does not constrain:

1. the properties that topics may include; or

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

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

In an assertion, the component topic whose subject is the relationship represented by the assertion.

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

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

A value (or value component) of a property instance that is not conferred.

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

1. component (of an assertion): Same as component topic.

2. component (of a relationship): Same as component subject.

3. component (of a topic): Same as property instance. (Not to be confused with component topic.)

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

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

6. value component (or property value component): See 2.24.

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

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

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

The process whereby two topics become a single topic because they are deemed to have the same subject.

A property class or property instance that is not a Subject Identity Discrimination Property (SIDP).

1. A property class.

2. A property instance.

A uniquely-named class of name/value pair defined as being instantiable as a component of a topic.

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

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

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

A subject that plays a part in a relationship. The subject of an x-topic in an assertion.

Subject Identity Discrimination Property.

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.

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

2. A property class designed so that each of its instances uniquely specifies the subject of a topic. The opposite of Other Property (OP).

In an assertion, the component topic whose subject is the type of relationship of which the assertion is an instance.

A non-empty set of property instances that serves as a surrogate of a subject. At least one of the properties must be an SIDP.

A body of information consisting of a non-empty set of topics.

This International Standard.

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

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

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

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

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

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

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

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

Each disclosed property class definition must specify whether the property is an SIDP or OP.

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

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

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.

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

Every topic map must have at least some built-in properties.

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.

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

In 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:

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

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

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

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

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

The 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 5.2. Some of these property classes are OPs; these are defined in Annex A. 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.

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.

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

The notation { }. that appears within the property name a-sidp{ }.r is a TMRM convention that, in this case, means:

1. that the value of the a-sidp property is a set ({ }) of value components, and

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

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.

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.

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

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

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

The value is the t-topic whose subject is the type of the assertion which is the subject of the a-topic.

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

The value is the t-topic whose subject is the relationship type whose roles include the role which is the subject of the r-topic.

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

The value is the set of all c-topics that cast the subject of the x-topic in a role in an assertion.

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

Figure 1:

The t-topic of an assertion is reciprocally connected to each of its r-topics. The t-topic's t-roles property is shown in red in order to highlight the fact that it is used to discriminate the subjects of t-topics -- it is a "Subject Identity Discrimination Property (SIDP)". The value of the t-roles property is the set of r-topics that are components of all instances of the type of assertion that is the subject of the t-topic. In the relationship represented by the assertion depicted in this diagram, there are two roles, each of which is the subject of an r-topic. Each of the r-topics is a member of the set that is the value of the t-roles property of the t-topic.

The connections between the t-topic and the r-topics of an assertion are reciprocal: the value of each r-topic's r-type property is the t-topic, the value of whose t-roles property includes the r-topic as one of its value components. The r-type property is an "Other Property (OP)"; it is shown in black here in order to highlight the fact that it is not used for discriminating the subjects of r-topics; it is not an SIDP. (The SIDPs of r-topics are not shown. They are Application-defined, not TMRM-defined.)

Figure 2:

The t-topic of an assertion is reciprocally connected to the a-topic. The t-topic's t-assertions property is shown in black, rather than red, in order to highlight the fact that it is not used to discriminate the subjects of t-topics -- it is an "Other Property (OP)". The value of the t-assertions property is the set of a-topics that represent instances of the type of relationship that is the subject of the t-topic. One of these relationships is the subject of the a-topic depicted in this diagram, which is why the a-topic is a component of the value of the t-topic's t-assertions property.

The connection between the t-topic and the a-topic of an assertion is reciprocal: the value of the a-topic's a-type property is the t-topic, the value of whose t-assertions property includes the a-topic as one of its value components. The a-type property is an "Other Property (OP)"; it is shown in black here in order to highlight the fact that it is not used for discriminating the subjects of a-topics; it is not an SIDP. (The name of the SIDP of every a-topic is a-sidp; see below.)

Figure 3:

The a-topic of an assertion is connected to each of the r-topics. The a-topic's a-sidp property consists of a set of so-called casting pairs, one for each of the roles of the assertion. Each of the casting pairs has an r value component, the value of which is one of the r-topics of the assertion. The a-sidp property's value components are used collectively to discriminate the subjects of all a-topics; they are all shown in red in order to highlight the fact that they collectively constitute a Subject Identity Discrimination Property (SIDP). In the diagram, the first casting pair (a-sidp{1}) is one of the value components of the a-sidp property, and the value of one of the pair's components (a-sidp{1}.r) is the r-topic on the left.

Figure 4:

The TMRM does not define any direct reciprocal connection from r-topics to a-topics. (Applications are free to do so, of course.) In order to access the a-topic of an assertion that includes a given r-topic, starting from that r-topic and using only the TMRM-defined properties, it is possible to select a c-topic from among the value components of the r-topic's r-castings property, and then to access the a-topic that is the value of the c-sidp.a component of the value of the c-topic's c-sidp property.

Figure 5:

The a-topic of an assertion is reciprocally connected to each of the c-topics. The a-topic's a-castings property is shown in black, rather than red, in order to highlight the fact that it is not used to discriminate the subjects of a-topics -- it is an "Other Property (OP)". The value of the a-castings property is the set of c-topics that represent the assertion's castings of its role players in their respective roles. Since there are two roles in this assertion, there are two castings, even though one of the castings (the c-topic on the right) casts no role player in its corresponding role (the subject of the r-topic on the right).

The connection between the a-topic and each of the c-topics of an assertion is reciprocal: the value of each c-topic's c-sidp.a property is the a-topic, the value of whose a-castings property includes the c-topic as one of its value components. The c-sidp property is a "Subject Identity Discrimination Property"; its three components (c-sidp.r, c-sidp.a, and c-sidp.x, are collectively used to discriminate the subject of each c-topic from that of any other.

Figure 6:

Each c-topic of an assertion is reciprocally connected to one of the assertion's r-topics. The subject of the r-topic to which each c-topic is connected is the role of which the subject of the c-topic is the casting. The c-topic's c-sidp.r property value component makes the connection; its value is the r-topic.

The connection between a c-topic and its corresponding r-topic is reciprocal: the value of each r-topic's r-castings property has, as one of its value components, the c-topic whose c-sidp.r value component is the r-topic.

Figure 7:

Each c-topic of an assertion is reciprocally connected to one of the assertion's x-topics. The subject of the x-topic to which each c-topic is the role player (if any) of which the subject of the c-topic is the casting. The c-topic's c-sidp.x property value component makes the connection; its value is the x-topic.

The connection between a c-topic and its corresponding x-topic (if any) is reciprocal: the value of each x-topic's x-castings property has, as one of its value components, the c-topic whose c-sidp.x value component is the x-topic.

Figure 8:

The a-topic of an assertion is connected to each of the x-topics. The a-topic's a-sidp property consists of a set of so-called casting pairs, one for each of the roles of the assertion. Each of the casting pairs has an x value component, the value of which is one of the x-topics of the assertion. In the diagram, the first casting pair (a-sidp{1}) is one of the value components of the a-sidp property, and the value of one of the pair's components (a-sidp{1}.x) is the x-topic on the left. (Since there is no role player of the role on the right side of the diagram, the a-sidp{2}.x component has no value.)

Figure 9:

The TMRM does not define any direct reciprocal connection from x-topics to a-topics. (Applications are free to do so, of course.) In order to access the a-topic of an assertion, starting from one of its role player topics (x-topics) and using only the TMRM-defined properties, it is possible to select a c-topic from among the value components of the x-topic's x-castings property, and then to access the a-topic that is the value of the c-sidp.a component of the value of the c-topic's c-sidp property.

Figure 10:

For reference purposes, all of the TMRM-defined properties are depicted below