ISO/IEC JTC 1/SC34 N0393rev

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

12 May 2003

JTC 1/SC 34 N 0393rev

Table of Contents

[parid6002] 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 for its subject, then users can find all information about that subject in a single location. The Topic Maps Model — the information structure of all topic maps that is defined by this International Standard — constrains the definitions of Topic Map Applications in order to enable the achievement of this "Subject Location Uniqueness Objective [SLUO]". It specifies a foundation for lossless and uniform treatment of heterogeneous topic map information.

[parid6007] The Topic Maps Model meets the following requirements:

1. [parid0761] It enables an unbounded number of different Topic Map Applications to be created and used.

2. [parid0762] It enables metrics to be developed for arbitrary sets of Topic Map Applications.

3. [parid0763] It enables Topic Map Applications to be expressed as topic maps.

4. [parid0764] It enables the conformance of Topic Map Applications to this International Standard to be verified.

5. [parid0765] It enables rigorous specification and auditing of the process whereby an interchangeable topic map is understood as a set of subjects. It enables specification of conventions for referring to members of that set of subjects by referring to components of interchangeable topic maps.

6. [parid0768] It enables determination of whether two topic maps are identical.

7. [parid0769] It facilitates the specification and determination of subject identity by humans, as well as machines.

8. [parid0770] When two or more topic maps are merged automatically, the Topic Maps Model:

   1. [parid0771] enables the merging process to be consistent across Topic Map Applications and their implementations, and

   2. [parid0772] preserves the integrity of the information contained in the merged topic maps in the resulting single topic map.

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

1. [parid0773] Defining the uniform structure, and the subjects which are the substantive aspects, of all relationships between subjects, and by defining, naming, and constraining the properties that reflect that structure.

2. [parid0774] Requiring TM Applications to define explicitly the properties of topics that are required to determine the identities of their subjects, the rules for assigning values to them, and the rules for comparing them.

[parid6016] This International Standard specifies:

1. [parid6017] the information structure of all topic maps;

2. [parid6018] certain common properties of topics, and constraints on the values of those properties;

3. [parid6019] constraints on the definitions of Topic Map Applications;

4. [parid6407] the definition of the term "fully merged" as it applies to topic maps; and

5. [parid6408] other definitions and specifications that support the foregoing.

[parid2107] An "assertion" topic. The subject of an a-topic is the relationship that is represented by an assertion; an a-topic is the nexus of a specific assertion.

[parid0816] A statement of a relationship between subjects, each of which is a called a "role player" in the relationship. An assertion represents a relationship as a specific set of topics that collectively connect the topics (x-topics) whose subjects are the role players to an "a-topic" whose subject is the relationship itself. Every assertion also includes topics whose subjects are: (i) the type of the relationship (the t-topic), if any, (ii) for each role, the fact that a role player is "cast" in the role in the relationship (the c-topics), and (iii) the roles themselves (r-topics). Within any given assertion, the a-topic, the t-topic (if any), the c-topics, the r-topics, and the x-topics directly or indirectly have each other as the values of their TMM-defined OPs.

[parid0518] As in "built-in property instance value [component]": required by a TM Application Definition and/or Syntax Deserialization Definition to be assigned to a property instance regardless of the situation of the topic. "Built-in" is the opposite of "conferred".

[parid0818] In an assertion, a topic whose subject is one of the castings of the assertion.

[parid0820] The fact that a subject plays a specific role in a relationship; the subject of a c-topic.

[parid0520] As in "conferred property instance value [component]": required by a TM Application Definition and/or Syntax Deserialization Definition to be assigned to a property instance on account of the situation of the topic. "Conferred" is the opposite of "built-in".

[parid2164] The condition of a topic map in which every subject is represented by only one topic. See [parid0810] 9.

[parid6021] Pertaining to the components of a single assertion instance.

[parid0823]

1. [parid0824] The process whereby two topics become a single topic, on account of the fact that they are deemed to have the same subject, in the service of the Subject Location Uniqueness Objective. See [parid0497] 9.5.

2. [parid0825] The process whereby a topic map in which more than one topic has the same subject becomes a "fully merged" topic map, in which every reified subject is reified by only one topic. See [parid0810] 9.

[parid0529] Other Property.

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

[parid0512] A class of name/value pairs defined by either the Topic Maps Model ("TMM-defined") or by a TM Application ("TMA-defined") as being instantiable as components of topics.

[parid0515] A uniquely named component of a topic; a name/value pair that is an instance of a property class. It may be either built-in or conferred.

[parid0867] A "role" topic. The subject of an r-topic is a role in a relationship and/or relationship type.

[parid0828] Represented by a surrogate. (Topics reify subjects.)

[parid0830] A role in a relationship.

[parid0833]

1. [parid0834] A subject that plays a role in a relationship.

2. [parid0835] An x-topic.

[parid0846] Syntax Deserialization Definition.

[parid0522] Subject Identity Discrimination Property.

[parid0842] Subject Location Uniqueness Objective

[parid0838] A topic's status as an a-topic, c-topic, r-topic, t-topic, and/or x-topic in one or more assertions, and the status of each of the topics whose subjects are aspects of those assertions, recursively.

[parid0840] A path from a situated topic to one of the topics in its situation that has defined characteristics that trigger the conferring of a value or value component on one of its properties.

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

[parid0648]

1. [parid0524] A property instance which specifies the subject of the topic of which it is a component, and which independently serves as the only basis for any applicable merging rule(s). The opposite of Other Property (OP).

2. [parid0525] A property class designed so that each instance independently and comprehensively specifies the subject of a topic, and in terms of which any applicable merging rules are defined. The opposite of Other Property (OP).

[parid2224] The objective of the topic map paradigm, which is to enable everything that is known about a subject to be accessible from one place.

[parid0849] A definition of the mapping process whereby each kind of construct found in instances of a specific syntax must, when encountered, deterministically result in the addition of topics with certain property values to the topic map that the syntactic instance is intended to represent.

[parid0869] Topic Map Application

[parid0873] The definition of a TM Application.

[parid0871] Topic Map Application

[parid0530] Defined by a Topic Map Application (the opposite of TMM-defined).

[parid6023] Defined for all topic maps by this Topic Maps Model (TMM) in [parid6062] 4.2, regardless of their governing TM Applications (the opposite of TMA-defined).

[parid6028] A non-empty set of property instances that serves as a surrogate of a subject.

[parid0851] A construct in an instance of an interchangeable topic map which can be referenced as a way of referencing the topic to which, by convention, it corresponds in the deserialized topic map that the interchangeable topic map is intended to represent.

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

[parid2236] A defined set of assertion types, properties, merging rules, and their supporting definitions that is intended to govern the expression and merging behaviors of a set of topic maps. It is not a "software application"; it is a world view, expressed in a way that enables it to be implemented uniformly.

[parid0875] This International Standard.

[parid6034] Regarded (as a list) in such a way as to ignore both the order of the items in the list, and any duplicates that appear in the list.

[parid0467] When the values of two property instances of the same property class include lists that are required to be treated as sets, their equality or inequality can be determined by any procedure that yields the same results as the following procedure:

1. [parid0459] Make each item in each list unique in that list, i.e., delete all duplicate items from each list.

2. [parid0460] Apply the same comprehensively deterministic order-normalization algorithm to both lists.

3. [parid0466] Compare each item in one list for identity with the item in the corresponding position in the other list.

[parid0486] If all the pairs of items in corresponding positions in the two lists are identical, the two sets are equal. If any pair of corresponding items are not identical to each other, or if the lengths of the two lists are not the same, the two sets are not equal.

[parid0853] A distinct portion of a single property value, such as a member of a complex value or a member of set.

[parid6035] In a topic map, all subjects that are defined, and/or about which any information is conveyed, are represented by topics. The number of topics in a topic map is finite; in order to create a topic map it is necessary to choose the subjects that will be represented in it.

[parid6009] Topics consist of property instances. Each is an instance of a property class. A single topic can be comprised of properties defined by multiple TM Applications. In a topic, no two properties can be instances of the same class (can have the same name).

[parid6041] Some properties are Subject Identity Discrimination Properties (SIDPs). All others are called "Other Properties (OPs)".

[parid6500] Some property instances are "built-in". All others are "conferred".

[parid6501] Some properties are "TMM-defined". All other properties are "TMA-defined".

[parid6037] Every property has a name; the name is different from that assigned to all other properties, assertion types, and roles.

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

[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 nested within it). The values may be or include lists and lists treated as sets.

[parid6419] Every topic has at least one SIDP instance. Each SIDP instance independently specifies the subject of the topic, for all purposes of subject identification. SIDP values are the only basis for automatically recognizing when two topics have the same subject or different subjects, and should therefore either be merged or left unmerged. No topic can have more than one SIDP instance whose property class is defined by any single TM Application.

[parid6420] The values of OPs do not influence the automated merging process defined by the Topic Maps Model.

[parid6052] Subjects have relationships with each other. These relationships are themselves subjects, and they have substantive aspects which are also subjects.

[parid6064] When a topic represents a relationship among subjects, such a topic is called an "assertion topic" or "a-topic". Every a-topic is the nexus of a set of topics, called an "assertion". Each member of the set (including the a-topic) represents a subject which is a substantive aspect of the relationship.

[parid0665] An a-topic cannot also be a c-topic, r-topic, or t-topic; the subjects of a-, c-, r-, and t- topics are all mutually exclusive (no topic can have more than one subject).

[parid6054] When a relationship exists among subjects, each subject so related is called a "role player". In the context of any specific assertion, each topic that represents a role player in that assertion is called an "x-topic".

[parid0008] All subjects, without exception, are eligible to be role players in relationships; therefore all topics are eligible to be x-topics, regardless of whether or not they are a-topics, t-topics, r-topics, c-topics.

[parid6059] Each role player plays a specific role in the relationship, and each such specific role is itself a subject. In the context of any specific assertion or assertion type, each topic that represents a role is called an "r-topic".

[parid6060] The fact that a specific role player (or the fact that no role player) plays a specific role in a specific relationship is called a "casting". Topics whose subjects are castings are called "c-topics".

[parid0667] Within a single assertion, no two castings can cast role players in the same role.

[parid6061] When a relationship has been classified explicitly as an instance of a specific type of relationship, the type is itself a subject. Such a subject, which may be called a "relationship type" or an "assertion type", must be defined in such a way as to specify the roles and the significance (semantics) of all instances of the type. Assertion type definitions (relationship type definitions) may also specify the qualifications that should be met by the players of the roles. Topics whose subjects are assertion types are called "t-topics".

[parid6063] The topics in the set of topics that comprise an assertion refer to each other by means of certain of their properties. These properties, called "TMM-defined properties", are the only properties defined for all topic maps by the Topic Maps Model. (All other properties are "TMA-defined properties".) The behavior of implementations must not be inconsistent with the assertion structure and the rules for merging assertions, as that structure and those merging rules are expressed in this International Standard in terms of the TMM-defined properties.

[parid0670] The value is a composite that comprehensively specifies the relationship that is subject of the a-topic, in order to support the automatic determination of whether the subject is the same as, or different from, the subject of any other a-topic, in accordance with the Topic Maps Model's merging rule for a-topics.

[parid0541] The values of the components of the IS13250::a-sidp property (IS13250::a-sidp.t and IS13250::a-sidp.castingPairs{ }) must meet the constraints specified for them (see [parid0544] 4.2.2.2 and [parid0549] 4.2.2.3).

[parid0543] Any topic that has an IS13250::a-sidp property is regarded as an a-topic.

[parid0660] Every a-topic:

1. [parid0671] must have all of the TMM-defined properties whose names begin with IS13250::a-.

2. [parid0672] must not have any properties whose names begin with IS13250::c-, IS13250::r-, or IS13250::t-.

3. [parid0673] must not have any TMM-defined or TMA-defined SIDPs other than IS13250::a-sidp.

[parid0546] The value must be the same as the value of the IS13250::a-type property of the same topic (see [parid0569] 4.2.2.7).

[parid0551] The value is a set of pairs of topics. Each pair must uniquely correspond to one of the castings of the assertion of which the a-topic is the nexus; each pair consists of the r-topic and x-topic (if any) of the casting to which the pair corresponds. The number of pairs must be the same as the number of members in the set of c-topics that constitute the value of the a-castings{ } property.

[parid0659] The values of the components of each member pair (IS13250::a-sidp.castingPairs{?}.r and IS13250::a-sidp.castingPairs{?}.x) must meet the constraints specified for them (see [parid0554] 4.2.2.4 and [parid0559] 4.2.2.5).

[parid0556] The value must be the same as the value of the IS13250::c-role property of the c-topic whose subject is the casting to which the pair uniquely corresponds.

[parid0561] The value must be the same as the value of the IS13250::c-rolePlayer property of the c-topic whose subject is the casting to which the pair uniquely corresponds.

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

[parid0566] Each of the c-topics in the value must uniquely correspond to one of the pairs in the value of the IS13250::a-sidp.castingPairs{ } property component (see [parid0659] 4.2.2.3.1, [parid0554] 4.2.2.4 and [parid0559] 4.2.2.5).

[parid0468] Each of the c-topics in the value of the IS13250::a-castings{ } property:

1. [parid0677] must have, as the value of its IS13250::c-role property, an r-topic that is included in the value of the IS13250::a-roles{ } property of the a-topic.

2. [parid0678] must reciprocally have the a-topic as the value of its IS13250::c-assertion property.

[parid0568] Any topic that has an IS13250::a-castings{ } property is regarded as an a-topic (see [parid0660] 4.2.2.1.2).

[parid0652] The value, if any, is the t-topic whose subject is the type of the assertion which is the subject of the a-topic.

[parid0651] The value may be empty. If the value is empty, the type of the assertion is unspecified.

[parid0571] The value must be the same as the value of the IS13250::a-sidp.t property component of the same topic.

[parid0105] If the value is non-empty (i.e., if the value is a t-topic):

1. [parid0682] each of the r-topics in the value of the IS13250::a-roles{ } property of the a-topic must have the same t-topic as the value of their IS13250::r-type properties.

2. [parid0681] the a-topic must reciprocally be a member of the set of a-topics that is the value of the IS13250::t-assertions{ } property of the t-topic.

[parid0713] Any topic that has an IS13250::a-type property is regarded as an a-topic (see [parid0660] 4.2.2.1.2).

[parid6436] The value is the set of r-topics whose subjects are the roles of the assertion of which the a-topic is the nexus. There must be two or more r-topics in the set.

[parid0720] If the value of the IS13250::a-type property of the a-topic is a t-topic (i.e., is non-empty), then the value of the IS13250::t-roles{ } property of that t-topic must be the same as the value of the a-topic's IS13250::a-roles{ } property.

[parid0684] Each of the r-topics in the value:

1. [parid0721] must also be the value of the IS13250::c-role property of one of the c-topics in the value of the IS13250:a-castings{ } property.

2. [parid0722] must reciprocally include the a-topic in the value of its IS13250::r-assertions{ } property.

[parid0717] Any topic that has an IS13250::a-roles{ } property is regarded as an a-topic (see [parid0660] 4.2.2.1.2).

[parid0685] The value is a composite that comprehensively specifies the casting that is subject of the c-topic, in order to support the automatic determination of whether the subject is the same as, or different from, the subject of any other c-topic, in accordance with the Topic Maps Model's merging rule for c-topics.

[parid0588] The values of the components of the IS13250::c-sidp property (IS13250::c-sidp.c-assertion, IS13250::c-sidp.c-role and IS13250::c-sidp.rolePlayer) must meet the constraints specified for them.

[parid0590] Any topic that has an IS13250::c-sidp property is regarded as a c-topic.

[parid0661] Every c-topic:

1. [parid0686] must have all of the TMM-defined properties whose names begin with IS13250::c-.

2. [parid0687] must not have any properties whose names begin with IS13250::a-, IS13250::r-, or IS13250::t-.

3. [parid0688] must not have any TMM-defined or TMA-defined SIDPs other than IS13250::c-sidp.

[parid0593] The value must be the same as the value of the IS13250::c-assertion property of the same c-topic.

[parid0598] The value must be the same as the value of the IS13250::c-role property of the same c-topic.

[parid0604] The value must be the same as the value of the IS13250::c-rolePlayer property of the same c-topic.

[parid0609] The value is the r-topic whose subject is the role in which the role player (the subject of the x-topic, if any, that is the value of the IS13250::c-rolePlayer property) is being cast in the assertion (the subject of the a-topic that is the value of the IS13250::c-assertion property).

[parid0723] The value must be the same as the value of the IS13250::c-sidp.r property component of the same c-topic.

[parid0724] The r-topic that is the value:

1. [parid0725] must be included in the value of the IS13250::a-roles{ } property of the a-topic that is the value of the IS13250::c-assertion property of the c-topic.

2. [parid0726] must be included in the value of the IS13250::t-roles{ } property of the t-topic, if any, that is the value of the IS13250::a-type property of the a-topic that is the value of the c-topic's IS13250::c-assertion property.

3. [parid0727] must reciprocally include the c-topic in the value of its IS13250::r-castings{ } property.

[parid0611] No two c-topics within the same assertion can have the same topic as the value of their respective IS13250::c-role properties.

[parid0653] Any topic that has an IS13250::c-role property is regarded as a c-topic (see [parid0661] 4.2.3.1.2).

[parid0614] The value is the x-topic, if any, whose subject is the role player that is being cast in the role (the subject of the r-topic that is the value of IS13250::c-role property) in the assertion (the subject of the a-topic that is the value of the IS13250::c-assertion property).

[parid0689] The value must be the same as the value of the IS13250::c-sidp.x property component of the same c-topic.

[parid0690] The value may be empty. If the value is empty, the role is not played.

[parid0728] The x-topic that is its value, if any, must reciprocally include the c-topic in the value of its IS13250::x-castings{ } property.

[parid0729] In any given assertion, at least one of the castings must have a role player. In other words, at least one of the c-topics must have a non-empty IS13250::c-rolePlayer property.

[parid0714] Any topic that has an IS13250::c-rolePlayer property is regarded as a c-topic (see [parid0661] 4.2.3.1.2).

[parid0621] The value is the a-topic whose subject is the assertion in which the role player (the subject of the x-topic that is the value of the IS13250::c-rolePlayer property) is being cast in the role (the subject of the topic that is the value of IS13250::c-role property).

[parid0619] The value must be the same as the value of the IS13250::c-sidp.a property component of the same c-topic.

[parid0730] The a-topic that is the value:

1. [parid0731] must include the r-topic that is the value of the IS13250::c-role property of the c-topic in the value of its IS13250::a-roles{ } property.

2. [parid0732] must have the same value for its IS13250::a-type property as the value of the IS13250::r-type property of the r-topic that is the value of the IS13250::c-role property of the c-topic. Both values must either be empty, or be the same t-topic.

3. [parid0734] must reciprocally include the c-topic in the value of its IS13250::a-castings{ } property.

[parid0718] Any topic that has an IS13250::c-assertion property is regarded as a c-topic (see [parid0661] 4.2.3.1.2).

[parid0656] The value is the set of c-topics whose subjects are the other castings of the same assertion.

[parid0658] The value must be the same as the value of the IS13250::a-castings{ } property of the a-topic that is the value of the IS13250::c-assertion property of the same c-topic, minus the c-topic. (Therefore, the value must be at least one c-topic.)

[parid0735] Each of the c-topics in the value:

1. [parid0736] must have the same a-topic for the value of their IS13250::c-assertion properties as the a-topic that is the value of the c-topic's IS13250::c-assertion property.

2. [parid0691] must have a reciprocal IS13250::otherCasting{ } property which includes the c-topic in its value.

[parid0657] Any topic that has an IS13250::c-otherCastings{ } property is regarded as a c-topic (see [parid0661] 4.2.3.1.2).

[parid0050] The value is the set of all c-topics whose subjects are castings of the role that is the subject of the r-topic.

[parid0693] The value may be empty. If the value is empty, there is no instance of an assertion in which the subject of the r-topic is a role.

[parid0051] A topic is considered an r-topic if it has an IS13250::r-castings{ } property, even if the value of the property is empty.

[parid0662] Every r-topic:

1. [parid0694] must have all of the TMM-defined properties whose names begin with IS13250::r-.

2. [parid0695] must not have any properties whose names begin with IS13250::a-, IS13250::c-, or IS13250::t-.

3. [parid0696] may have an empty value for either its IS13250:r-castings{ } property or its IS13250:r-type} property, but it must not have an empty value for both.

[parid0737] Each of the c-topics in the value:

1. [parid0738] must have a different value for its IS13250::c-assertion property than all of the other c-topics in the value. In other words, no two members of the set can be different castings of the same assertion.

2. [parid0739] must have, as the value of its IS13250::c-assertion property, an a-topic which is included in the value of the r-topic's IS13250::r-assertions{ } property. That a-topic's IS13250::a-type property must have the same value as the value of the r-topic's IS13250::t-roles{ } property. Both values must either be empty, or be the same t-topic.

3. [parid0053] must have a reciprocal IS13250::c-role property whose value is the r-topic.

[parid0699] The value is the set of all a-topics whose subjects are assertions that have the role that is the subject of the r-topic as one of their roles.

[parid0700] The value may be empty. If the value is empty, there is no assertion in which the subject of the r-topic is a role.

[parid0704] A topic is considered an r-topic if it has an IS13250::r-assertions{ } property, even if the value of the property is empty (see [parid0662] 4.2.4.1.2).

[parid0740] If the value is empty, the value of the IS13250::r-castings{ } property must also be empty.

[parid0741] If the value is non-empty, each of the a-topics in the value:

1. [parid0701] must include, in the value of its IS13250::a-castings{ } property, one of the c-topics that is included in the value of the IS13250::r-castings{ } property of the r-topic.

2. [parid0702] must have the same value for its IS13250::a-type property as the r-topic has for its IS13250::r-type property. (The values may both be the same t-topic, or they may both be empty.)

3. [parid0705] must have a reciprocal IS13250::a-roles{ } property whose value includes the r-topic.

[parid0059] The value, if any, is the t-topic whose subject is the assertion type whose role set includes the role which is the subject of the r-topic.

[parid0742] The value may be empty. If the value is empty, there is no assertion type that includes the subject of the r-topic among its roles, and the r-topic cannot be a role in a typed assertion.

[parid0743] If an r-topic's IS13250::r-type property is empty, then its IS13250::r-otherATRoles{ } property must also be empty.

[parid0744] If an r-topic has a non-empty IS13250::r-type property (i.e., if the value is a t-topic), then the t-topic:

1. [parid0745] must have a IS13250::t-assertions{ } property whose value is the same as the value of the r-topic's IS13250::r-assertions{ } property.

2. [parid0079] must have a reciprocal IS13250::t-roles{ } property whose value includes the r-topic.

[parid0715] A topic is considered an r-topic if it has an IS13250::r-type property, even if the value of the property is empty (see [parid0662] 4.2.4.1.2).

[parid0708] The value, if any, is the set of r-topics whose subjects are the other roles of the same assertion type.

[parid0746] The value may be empty. If the value is empty, there is no assertion type that includes the r-topic among its roles, and the r-topic cannot be a role in a typed assertion.

[parid0747] If the value is non-empty, then the value must be the same as the value of the IS13250::t-roles{ } property of the t-topic that is the value of the IS13250::r-type property of the same r-topic, minus the r-topic.

[parid0748] If an r-topic's IS13250::r-otherATRole{ } property is empty, then its IS13250::r-type property must also be empty.

[parid0749] If an r-topic's IS13250::r-otherATRoles{ } property is non-empty, then each of the r-topics in the value:

1. [parid0750] must have the same t-topic for their IS13250::r-type properties as the value of the r-topic's IS13250::r-type property.

2. [parid0710] must have an IS13250::otherATRole{ } property which reciprocally includes the r-topic in its value.

[parid0719] Any topic that has an IS13250::r-otherATRoles{ } property is regarded as an r-topic (see [parid0662] 4.2.4.1.2).

[parid0148] The value is the set of all a-topics whose subjects are assertions that are instances of the assertion type that is the subject of the t-topic.

[parid0751] The value may be empty. If the value is empty, there are no instances of the assertion type.

[parid0437] A topic is considered a t-topic if it has an IS13250::t-assertions{ } property, even if the value of the property is empty.

[parid0663] Every t-topic:

1. [parid0711] must have all of the TMM-defined properties whose names begin with IS13250::t-.

2. [parid0712] must not have any properties whose names begin with IS13250::a-, IS13250::c-, or IS13250::r-.

[parid0752] If the value is non-empty, each of the a-topics in the value:

1. [parid0753] must have the same value for its IS13250::a-roles{ } property as the value of the t-topic's IS13250::t-roles{ } property.

2. [parid0754] must have a reciprocal IS13250::a-type property whose value is the t-topic.

[parid0173] The value is the set of all r-topics whose subjects are the roles defined for the assertion type that is the subject of the t-topic. There must be two or more.

[parid0755] If the value of the t-topic's IS13250::t-assertions{ } property is a set of one or more a-topics (i.e., is non-empty), then the values of the IS13250::a-roles{ } properties of those a-topics must be the same as the value of the IS13250::t-roles{ } property.

[parid0206] Each of the r-topics in the value of the IS13250::t-roles{ } property:

1. [parid0756] must have the same value for its IS13250::r-assertions{ } property as the value of the t-topic's IS13250::t-assertions{ } property.

2. [parid0757] must have a reciprocal IS13250::r-type property whose value is the t-topic.

[parid0507] A topic is considered a t-topic if it has an IS13250::t-roles{ } property, even if the value of the property is empty (see [parid0663] 4.2.5.1.2).

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

[parid0758] The value may be empty. If the value is empty, the subject of the x-topic does not play any roles in any assertions, the topic is not an x-topic, and the IS13250::x-castings{ } property is ignored.

[parid0478] Each of the c-topics in the value of the IS13250::x-castings{ } property must reciprocally have the x-topic as the value of its IS13250::c-rolePlayer property.

[parid0496] A topic's "situation" is defined in terms of its status as an a-topic, c-topic, r-topic, t-topic, and/or x-topic in one or more assertions. (When a topic is none of the foregoing, it is called an "isolated topic"; such topics are not "situated". Their SIDP values must be built-in.). Each TMM-defined OP value or value component of a topic that indicates that the topic is an a-, c-, r-, t-, or x-topic can be regarded as the beginning of a "path" of connections from that topic to another topic, either directly or via intervening topics. Each intervening topic has a TMM-defined OP value or value component that is that next topic in the path.

[parid0778] "Situation features" are paths whose characteristics satisfy a definition (specified in a TM Application Definition or Syntax Deserialization Definition) that requires that a value or value component be "conferred" on a property of the situated topic.

[parid0779] Properties can also have values or value components that are not conferred on them on account of the features of their situations. Instead, such values are required to be "built-in" by an applicable TM Application Definition or Syntax Deserialization Definition.

[parid0780] TM Application Definitions and Syntax Deserialization Definitions define how the SIDP values of isolated topics, r-topics, t-topics, and x-topics are built into or conferred upon them. In all definitions that require values to be conferred, the value is conferred on a topic on account of a situation feature in which the topic plays a specific role in an instance of a specific assertion type.

[parid0876] Built-in property values or value components are "read-only". Values and value components must specify whether they are built-in or conferred, so that, during the merging process, built-in values will not automatically be superseded (i.e., erased or overwritten) by conferred values or value components. The definition of a TM Application may or may not allow value components to be conferred on a property in addition to existing built-in value components. Conflicts that arise between definitions of built-in property value components and definitions that require value components to overwrite them must be reported by implementations.

[parid0782] The definition of a TM Application must include all of the following:

[parid0784] Every TM Application Definition must specify the name of the TM Application it defines. The name must be different from the name of any known TM Application. If the TM Application is evolving or configurable, each version, conformance level, or other configuration must be regarded as a distinct TM Application for purposes of naming.

[parid0299] All TM Application names that begin with "IS", irrespective of the cases of the letters, are reserved for International Standard TM Applications.

[parid0786] All property classes of topics must be defined. Every property instance of every topic must either be TMM-defined or defined by a single TM Application. Each property definition must indicate whether its value is for the purpose of distinguishing subjects, i.e., whether it is an SIDP or an OP. Every topic that has a TMA-defined property to which a value has been assigned (conferred or built-in) is said to be "governed" by that TM Application.

[parid0854] The names, value types and semantics of all properties must be specified in their definitions. If the value type is complex, the name of each member of each complex must be unique among the value components of the property.

[parid0787] Every TM Application must be defined in such a way that all topics governed by the TM Application will have a single SIDP instance that is governed by that TM Application. However, different topics may have instances of different SIDP classes; the number of SIDP classes defined by a single TM Application is not constrained. All SIDPs, and the values that are built into them and/or conferred upon them, must be defined in such a way that, under the merging rules defined by the TM Application, all topics that have the same subject will be merged, and topics that do not have the same subject will not be merged (see [parid6446] 9.5).

[parid0789] If there are any constraints on the values of the properties of subjects, they must be stated in the TM Application Definition. Implementations of TM Applications must report all violations of such constraints (see [parid6445] 9.4).

[parid0855] The names and semantics of all assertion types must be defined.

[parid0792] Each assertion type definition must include a complete list of the roles (the r-topics) that must appear in all instances of the type. A minimum of two roles must be defined for each type. No two assertion types can include the same role.

[parid0856] For each role, any applicable validity constraints on players of the role should be specified.

[parid0857] For each role, the property value components that must be conferred on the players of that role must be defined. The only way in which TM Applications can require property values to be conferred upon (as opposed to being built into) topics is to define assertion types whose instances confer them on their role players.

[parid0877] The procedure whereby each conferred property value or value component must be calculated must be specified. The calculation may involve the properties of any topics that are included in any of the role player's situation features.

[parid0243] For bootstrapping reasons, all TM Applications must define at least some topics to be present in all topic maps that contain topics that are governed by the TM Application. Such topics are called "built-in" topics, and they must be defined as having "built-in values" for their SIDPs.

[parid0797] For every SIDP class that it defines, a TM Application must define one or more rules for determining whether to merge the topic with any other topics that have instances of the same SIDP class, solely on the basis of the values of those SIDP instances. Every such rule must be designed to serve the Subject Location Uniqueness Objective.

[parid0799] Sometimes, topics that have built-in values must be merged. The rules for merging all property values that can be built-in must be specified.

[parid0801] The names of assertion types, roles, and properties must be different from each other. Each must begin with the name of the TM Application, followed by a sequence of two colons (the field separator, "::"), followed by a string that makes the name unique among the names of all other assertion types, roles, and properties defined for the TM Application. Neither the name of the TM Application, nor the second field of the names of its assertion types, roles, or properties, may contain any period ("."), any pair of consecutive colons ("::"), left or right braces ("{" or "}"), or left or right brackets ("[" or "]"). The double-colon symbol is reserved for use as the separator between the name of the TM Application (the first field of each name) and the unique portion (i.e., the second field) of the name of each of the properties, assertion types, and roles that are governed by it. The period symbol is reserved as a separator between the names of the defined components of property values. The braces are reserved as set selection operators. The brackets are reserved as list selection operators.

[parid0860] TM Application Definitions must not replace or optionalize the assertion structure defined by this International Standard. All relationships between the subjects of topics must be represented by a-topics.

[parid6368] TM Application Definitions can include other TM Applications in their entirety, by reference to their definitions. All of the definitions and constraints of such "included" TM Applications become, without exception, part of the "including" TM Application. The names of included properties, assertion and role types are not affected by inclusion by another TM Application, and they retain, as their first field, the name of the included TM Application. If the included TM Application itself includes other TM Applications, recursively, they, too, are included.

[parid0803] Every instance of an interchangeable topic map must implicitly or explicitly declare the Syntax Deserialization Definition that is intended to govern its interpretation. If a topic map interchange syntax is known to be interpreted or is designed to be interpretable under more than one SDD, then instances of that syntax must explicitly declare the SDD that is intended to be applied to it.

[parid0804] Every SDD must declare the TM Application(s) to which the topic maps whose deserializations it governs will conform.

[parid0492] Every SDD must unambiguously define how each kind of construct found in instances of a specific syntax must, when encountered by any implementation of the SDD, deterministically result in the addition of topics (with specific built-in and/or conferred property values) to the topic map that the syntactic instance is intended to represent.

[parid0863] An SDD may define one or more "topic demander" conventions that allow topics to be addressed in terms of their corresponding syntactic constructs.

[parid0878] Every implementation that claims conformance to this International Standard must also explicitly claim conformance to at least one conforming TM Application Definition. For each syntax, if any, that the implementation deserializes, it must explicitly claim conformance to at least one SDD for that syntax.

[parid0806] In order to respect the SLUO, it is necessary for TM Applications and their implementations to distinguish between the subjects they regard as role players, and all others. If the TM Application Definition to which an implementation claims conformance allows a given subject to exist implicitly and unreifiedly as a property value, but does not provide a way for it to be the subject of a topic that, via an instance of some defined assertion type, is involved in conferring that property value, then the implementation must not behave in any way that would lead one to think that the subject is, in fact, reified or reifiable under the TM Application Definition. Conversely, implementations of TM Applications must not refuse to honor the playing of any role by any subject, unless it would violate the constraints imposed by any TM Application to which the implementation claims conformance or this International Standard.

[parid0807] All implementations of all TM Applications must:

1. [parid0808] Allow a-topics, r-topics, t-topics, and c-topics to be role players.

2. [parid0809] Always merge a-topics and c-topics as specified in this International Standard.

[parid0500] In a topic map, every topic represents a single subject, but some subjects may be represented by more than one topic. In a "fully merged" topic map, every subject is represented by a single topic. A process whereby a topic map automatically becomes a fully merged topic map is defined in this section. Conforming implementations may use any process that achieves the same result as the process defined in this section, but all implementations must achieve that result.

[parid6448] The topic map must be constructed from one or more interchangeable topic maps, in conformance with an applicable Syntax Deserialization Definition, or by any other process or method that yields a topic map that conforms to one or more TM Applications. The resulting topic map must represent all reified subjects as topics, and all relationships between topics as assertions, each of which has an a-topic as its nexus, in conformance with this International Standard. Except for a-topics and c-topics, all of the topics in the topic map must have at least one TMA-defined SIDP.

[parid6449] All assertions that are instances of assertion types must conform to the constraints imposed by the definitions of their types, as defined by their governing TM Applications. Any conflicts between the assertions and their definitions must be reported and remedied.

[parid6450] The values of all the properties of all topics must be adjusted to conform to the requirements imposed by the definitions of all applicable TM Applications. Any conflicts with built-in values must be remedied.

[parid6219] Conferred property values or value components must be overridden (changed or erased) when, after the topic map has been altered in a previous iteration of the merging process, conferred property values are recalculated, and a topic's situation no longer requires one of its properties to have the value that had been conferred upon it on account of its situation in the previous iteration.

[parid0859] Values cannot be conferred on the SIDPs of a-topics or c-topics on account of TMA-defined situation features. When such a conflict arises, it must be reported and remedied.

[parid6498] Any conflicts between the values of the properties and the constraints imposed on them by their governing TM Applications must be remedied.

[parid6452] All pairs of topics that both have had values assigned (including empty values) to SIDPs that have the same name must have the values of those SIDPs compared with each other in accordance with the applicable comparison algorithm defined by the applicable TM Application Definition or, in the case of a-topics and c-topics, defined by this International Standard. If the applicable comparison algorithm reveals that the two topics should be merged, they must be merged. No information, other than the values of instances of identical SIDP classes of the topics to be merged or left unmerged, can affect the merging process.

[parid0497] When two topics ("predecessor topics") governed by a TM Application are merged:

1. [parid0930] The resulting single topic ("result topic") serves as the union of the two situations of the two predecessor topics, and all TMM-defined property values are adjusted to reflect that unification.

2. [parid0931] The resulting single topic exhibits the union of the built-in property values, if any, of the two predecessor topics, in accordance with the rules for merging built-in property values defined by the TM Applications that govern the affected properties.

3. [parid0923] all of the conferred property value and value components of the result topic, and of all other topics whose situation features are changed as a result of the merger, are adjusted in such a way as to reflect their new post-merger situations, in accordance with the definition(s) of the TM Application(s) that govern those properties.

[parid0865] When two a-topics have the same value for their IS13250::a-sidp properties, and their IS13250::a-sidp.t value components are non-empty, they must be merged; in all other cases, they are not merged. When two c-topics have the same value for their IS13250::c-sidp properties, they must be merged; in all other cases, they are not merged.

[parid0440] If any topics were merged in the steps described in [parid6446] 9.5, then the steps described in [parid6443] 9.2, [parid6444] 9.3, [parid6445] 9.4 and [parid6446] 9.5 must be repeated. When an iteration of these steps results in no (further) merging, the topic map has been fully merged, and processing must stop.

[parid6482] If a Topic Map Application Definition or Syntax Deserialization Definition complies with all the provisions of this International Standard, then it is a conforming Topic Map Application or Syntax Deserialization Definition.

[parid0777] If an implementation of a conforming Topic Map Application and/or Syntax Deserialization Definition complies with all the provisions of this International Standard and with the constraints imposed by the Topic Map Application(s) and/or Syntax Deserialization Definition(s) to which it claims conformance, it is a conforming implementation.

[parid0812] If the interchangeable form of a topic map implicitly or explicitly declares the Syntax Deserialization Definition (SDD) that is intended to govern its interpretation, and if it is unambiguously interpretable in terms of that SDD, then it is a conforming interchangeable topic map.

[parid0813] If a topic map conforms to the specifications of this International Standard and to the constraints imposed by all of its governing Topic Map Applications, it is a conforming topic map.