ISO/IEC JTC 1/SC 34N0460

ISO/IEC logo

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

TITLE: Topic Maps - Reference Model, revision 3.10
SOURCE: Mr. Patrick Durusau; Dr. Steven R. Newcomb; Mr. Sam Hunting; Mr. Jan Algermissen
PROJECT: WD 13250-5: Information Technology - Document Description and Processing Languages, Topic Maps - Reference Model
PROJECT EDITOR: Mr. Patrick Durusau; Dr. Steven R. Newcomb
STATUS: Editor's Draft, Revision 3.10
ACTION: For review and comment
DATE: 2003-12-02
DISTRIBUTION: SC34 and liaisons
REPLY TO:

Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Chairman)
Y-12 National Security Complex
Bldg. 9113, M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
Network: masonjd@y12.doe.gov
http://www.y12.doe.gov/sgml/sc34/
ftp://ftp.y12.doe.gov/pub/sgml/sc34/

Mr. G. Ken Holman
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Box 266,
Kars, ON K0A-2E0 CANADA
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: jtc1sc34@scc.ca
http://www.jtc1sc34.org



1 December 2003

Topic Maps -- Reference Model

Version 3.10, 2003/12/01
Go to http://www.isotopicmaps.org/TMRM/TMRM-latest.html to view or contribute to the current editors' working revision.

The previous officially published version (version 1.0) was ISO/IEC JTC1/SC34/N0344.

Table of Contents

0 Introduction (Informative)
1  Scope
2  Glossary
2.1 a-topic
2.2 Application
2.3 assertion
2.4 built-in property value (or built-in property value component)
2.5 c-topic
2.6 component
2.7 conferred property value (or conferred property value component)
2.8 Disclosure
2.9 merging
2.10 Other Property (OP)
2.11 property
2.12 property class
2.13 property instance
2.14 r-topic
2.15 role
2.16 role player
2.17 SIDP
2.18 subject
2.19 Subject Identity Discrimination Property (SIDP)
2.20 t-topic
2.21 topic
2.22 topic map
2.23 Topic Maps Reference Model (TMRM)
2.24 value component
2.25 value type
2.26 x-topic
3  Subjects and topics
4  Properties of Topics
4.1 Property names
4.2 Property Values
4.3 SIDPs and OPs
4.4 Conferred vs. Built-in Property Instances
5  Assertions
5.1 Component Subjects of Relationships
5.2 SIDPs of a-, t-, and c-topics
Annex A TMRM-defined Other Properties (Normative)
A.1  Other Properties of a-topics
A.2  Other Properties of r-topics
A.3  Other Property of t-topics
A.4  Other Property of x-topics
Annex B Diagrams of TMRM-defined Properties (Informative)
B.1  TMRM-defined connections between the t-topic and the r-topics
B.2  TMRM-defined connections between the t-topic and the a-topic
B.3  TMRM-defined connections between the a-topic and the r-topics
B.4  TMRM-defined connections between the a-topic and the c-topics
B.5  TMRM-defined connections between each c-topic and its corresponding r-topic
B.6  TMRM-defined connections between each c-topic and its corresponding x-topic (if any)
B.7  TMRM-defined connections between the a-topic and the x-topics
B.8  TMRM-defined connections: the whole shebang


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

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


1   Scope

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.


2   Glossary

2.1   a-topic

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


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


2.3   assertion

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


2.4   built-in property value (or built-in property value component)

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


2.5   c-topic

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.


2.6   component

  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.


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


2.8   Disclosure

  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.


2.9   merging

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


2.10   Other Property (OP)

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


2.11   property

  1. A property class.

  2. A property instance.


2.12   property class

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

Note 1: 

Instances of such classes are called "property instances".



2.13   property instance

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.


2.14   r-topic

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.


2.15   role

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.


2.16   role player

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


2.17   SIDP

Subject Identity Discrimination Property.


2.18   subject

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.


2.19   Subject Identity Discrimination Property (SIDP)

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

Note 2: 

Within the context of a single Application, every topic has exactly one SIDP. However, a single topic can have multiple SIDPs; see 4.3.



2.20   t-topic

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


2.21   topic

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.


2.22   topic map

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


2.23   Topic Maps Reference Model (TMRM)

This International Standard.


2.24   value component

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.


2.25   value type

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.


2.26   x-topic

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


3   Subjects and topics

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.


4   Properties of Topics

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.


4.1   Property names

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.

Note 3: 

In other words, no two properties can have the same name.



4.2   Property Values

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.

Note 4: 

A property instance may exhibit a null or empty value if that value has significance with respect to the value type.



4.3   SIDPs and OPs

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.

Note 5: 

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.


Note 6: 

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.


4.4   Conferred vs. Built-in Property Instances

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.

Note 7: 

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:

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

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



4.4.1   Conferred property values

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.

Note 8: 

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.

Note 9: 

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.



4.4.2   Built-in property values

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.

Note 10: 

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.


Note 11: 

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 5 and Annex A). 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.

Note 12: 

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.


Note 13: 

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.


5   Assertions

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.

Note 14: 

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.


Note 15: 

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.



5.1   Component Subjects of Relationships

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.

Note 16: 

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.



5.2   SIDPs of a-, t-, and c-topics

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.

Note 17: 

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


Note 18: 

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.

Note 19: 

The subjects, and therefore the SIDPs, of r-topics are always Application-specific. Like the definitions of all other SIDPs, they can be Disclosed.


Note 20: 

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.


5.2.1   The a-sidp SIDP class of a-topics

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.

Note 21: 

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:

  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.

Note 22: 

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.

Note 23: 

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.

Note 24: 

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



5.2.2   The t-sidp property class of t-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.


5.2.3   The c-sidp property class of c-topics

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:

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.


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


A.1   Other Properties of a-topics

A.1.1   a-castings

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.


A.1.2   a-type

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


A.2   Other Properties of r-topics

A.2.1   r-castings

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.


A.2.2   r-type

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.


A.3   Other Property of t-topics

A.3.1   t-assertions

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.


A.4   Other Property of x-topics

A.4.1   x-castings

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


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


B.1   TMRM-defined connections between the t-topic and the r-topics

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

Diagram of a         2-role assertion with one role player, depicting the t-roles         and r-type properties of its t-topic and r-topics,         respectively.


B.2   TMRM-defined connections between the t-topic and the a-topic

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

Diagram of a         2-role assertion with one role player, depicting the         t-assertions and a-type properties of its t-topic and a-topic,         respectively.


B.3   TMRM-defined connections between the a-topic and the r-topics

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.

Diagram of a         2-role assertion with one role player, depicting the         a-sidp{}.r property value components of its a-topic.

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.

Diagram of a         2-role assertion with one role player, depicting the         r-castings and c-sidp.a properties of its r-topics and         c-topics, respectively.


B.4   TMRM-defined connections between the a-topic and the c-topics

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.

Diagram of a         2-role assertion with one role player, depicting the         a-castings and c-sidp.a properties of its a-topic and         c-topics, respectively.


B.5   TMRM-defined connections between each c-topic and its corresponding r-topic

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.

Diagram of a         2-role assertion with one role player, depicting the         t-assertions and a-type properties of its t-topic and a-topic,         respectively.


B.6   TMRM-defined connections between each c-topic and its corresponding x-topic (if any)

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.

Diagram of a         2-role assertion with one role player, depicting the         t-assertions and a-type properties of its t-topic and a-topic,         respectively.


B.7   TMRM-defined connections between the a-topic and the x-topics

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

Diagram of a         2-role assertion with one role player, depicting the         a-sidp{}.x property value components of its a-topic.

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.

Diagram of a         2-role assertion with one role player, depicting the         x-castings and c-sidp.a properties of its x-topic and its         corresponding c-topic, respectively.


B.8   TMRM-defined connections: the whole shebang

Figure 10:

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

Diagram of a         2-role assertion with one role player, depicting all of the         TMRM-defined properties.