ISO/IEC JTC 1/SC34 N (no official status)

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

1 December 2003

JTC 1/SC 34 N (no official status)

Table of Contents

[parid3001] 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".

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

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

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

[parid3003] The Topic Reference Model meets the following requirements:

1. [parid3004] 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. [parid3007] 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.

[parid3009] The Topic Maps Model meets the above requirements by:

1. [parid3155] 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. [parid3156] 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. [parid3158] 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:

   • [parid3160] The type of the relationship is the subject of the "t-topic" (assertion type topic). There is always exactly one t-topic.

   • [parid3161] Each role in the relationship is the subject of an "r-topic" (role topic). There are always at least two r-topics.

   • [parid3162] 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.

   • [parid3163] The relationship itself is the subject of the "a-topic" (assertion topic). There is always exactly one a-topic.

   • [parid3164] 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.

   [parid3254] 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 [parid3274] Annex B for an illustrated discussion.)

4. [parid3165] 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. [parid3166] 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. [parid3167] 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. [parid3168] 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. [parid3169] 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.

[parid3012] This International Standard specifies:

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

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

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

4. [parid3016] other definitions and specifications that support the foregoing.

[parid3017] This International Standard does not constrain:

1. [parid3019] the properties that topics may include; or

2. [parid3020] 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. [parid3018] 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.

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

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

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

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

[parid3023] 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).

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

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

[parid3266]

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

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

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

4. [parid3270] 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. [parid3271] 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. [parid3272] value component (or property value component): See [parid0852] 2.24.

[parid3026] 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".

[parid3273]

1. [parid3259] [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. [parid3260] 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.

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

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

[parid6032]

1. [parid6049] A property class.

2. [parid6050] A property instance.

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

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

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

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

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

[parid0522] Subject Identity Discrimination Property.

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

[parid0648]

1. [parid0524] 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. [parid0525] A property class designed so that each of its instances uniquely specifies the subject of a topic. The opposite of Other Property (OP).

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

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

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

[parid0875] This International Standard.

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

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

[parid3178] 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.)

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

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

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

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

[parid3182] No topic can have more than one instance of any property class.

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

[parid6043] Property instances exist only if values have been assigned to them.

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

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

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

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

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

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

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

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

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

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

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

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

[parid3036] 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.)

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

[parid3056] 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. [parid3057] 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. [parid3060] 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. [parid3059] 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. [parid3058] 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. [parid3061] 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.

[parid3073] 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 [parid3193] 5.2. Some of these property classes are OPs; these are defined in [parid3104] 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.

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

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

[parid3216] The name of the property that is always and exclusively the SIDP of all a-topics is a-sidp.

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

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

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

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

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

2. [parid3223] 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.