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

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

TITLE: Reference Model for ISO 13250 Topic Maps (RM4TM)
SOURCE: Steven R. Newcomb, Sam Hunting and Jan Algermissen
PROJECT: Topic Maps
PROJECT EDITORS: Michel Biezunski, Martin Bryan, Steven R. Newcomb
STATUS: Editor's Draft, Revision 1.11
ACTION: For review and comment
DATE: 18 January 2003
SUMMARY:
DISTRIBUTION: SC34 and Liaisons
REFER TO:
SUPERCEDES:
REPLY TO: Dr. James David Mason
(ISO/IEC JTC1/SC34 Chairman)
Y-12 National Security Complex
Information Technology Services
Bldg. 9113 M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
E-mail: mailto:mxm@y12.doe.gov
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm

Ms. Sara Hafele Desautels, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
25 West 43rd Street
New York, NY 10036
Tel: +1 212 642-4937
Fax: +1 212 840-2298
E-mail: sdesaute@ansi.org

18 January 2003

JTC 1/SC 34 N (no official status)

Reference Model for ISO 13250 Topic Maps (RM4TM)

Version 1.11, 2003/01/18 (The current editors' working copy is available at http://www.isotopicmaps.org/TMMM/TMMM-latest.html.)

Please mention the paragraph id number (e.g. "parid2902") when commenting about any particular paragraph. Don't use the section numbers; they are subject to change.

Click on red, underlined parids (e.g., [parid0000]) to see existing comments.


0    [parid2001] Introduction
Editor's Note 1: 

[parid0000] This is a test of the hyperlink-to-comments system.

[parid2902] This Reference Model for ISO 13250 Topic Maps (RM4TM) provides a framework for the definitions of Topic Map Applications (TM Applications). Diverse topic maps that conform to diverse TM Applications that are defined in keeping with this framework can be interpreted and amalgamated automatically by independently implemented systems, without losing information, and with predictable results.

[parid2901] Many of the key advantages of the Topic Maps paradigm derive from the achievement of its primary objective, the "Subject Location Uniqueness Objective", which is to make everything known about every subject in a topic space accessible from a single location within that space. The achievement of the Subject Location Uniqueness Objective means that the efficiency with which users can find information is maximized, not only because the subject's single location, once found, acts as a comprehensive catalog of the things that are known about it, but also because the subject's location can be found in terms of any of its relationships to other subjects.

[parid2004] This RM4TM facilitates the development of TM Applications and systems that can achieve the Subject Location Uniqueness Objective with respect to all subjects, including those that are only implicit in interchangeable topic map instances, as well as with respect to subjects that are relationships (and aspects of relationships) among other subjects.

[parid0941] Moreover, this RM4TM facilitates the development of TM Applications and implementations that can amalgamate the topic spaces represented by topic maps that conform to diverse Topic Maps Applications into a single resulting topic space in which each subject has a single location, there is no redundant information, and all of the information represented by the comprising topic maps is preserved.

[parid2005] This RM4TM provides definition requirements for user-defined Topic Map Applications that allow such definitions to serve as contracts between topic map creators, users, and system implementers, such that when the interchange or amalgamation of topic maps fails due to nonconformance to the definition of a Topic Maps Application, the nonconforming aspects of the topic maps or system implementations can be identified.


1   [parid0001] Scope

[parid0005] This RM4TM defines:

  1. [parid0481] an abstract graph structure for the representation of relationships between subjects;

  2. [parid0482] rules for defining Applications of the Topic Maps paradigm; and

  3. [parid0483] rules for processing the information contained in topic maps.

Note 1: 

[parid0952] See Annex A for a brief informal overview of this RM4TM.



2   [parid0441] Glossary
Editor's Note 2: 

[parid0936] (The glossary hasn't been drafted yet.)


3   [parid0022] Topic map graphs

3.1   [parid0023] The common structural abstraction for topic maps

[parid0024] This RM4TM defines an abstract structure, called a "topic map graph", in terms of which all kinds of topic maps can be uniformly interpreted, regardless of their governing TM Applications, and regardless of the TM Application-defined interchange syntaxes in which they may be representable.

[parid0900] The "topic map graph" form of any given topic map represents all of the subjects that participate in the topic map explicitly, even if they were only implicitly represented in the interchangeable form of the given topic map.

[parid0484] The following subclauses name and define the rules and cases to which topic map graph components and entire topic map graphs must conform in order to be considered "well formed", and the additional rules to which topic map graphs must conform in order to be considered "fully merged". Topic map graphs that are under construction may or may not be well-formed, but only well-formed topic map graphs are eligible to become fully merged, in addition to being well-formed.


3.2   [parid0025] Topic map graphs consist of nodes and arcs.

[parid0026] A topic map graph consists of nodes and arcs. In a well-formed topic map graph, every arc is a typed, oriented connectedness of two nodes, and every node is one of the two endpoints of zero or more arcs.

Note 2: 

[parid0932] This RM4TM uses the neologism "connectedness" in order to avoid implying that TM Applications must be implemented in such a way that arcs are represented as a data structure. For example, The arc abstraction can be fully honored by the property values of the nodes that serve as its endpoints.



3.3   [parid0042] Arcs
Note 3: 

[parid0938] The reader's understanding of the remainder of this clause 3 is likely to be aided by referring to the informative "Assertion Diagrams" Annex B.


[parid0506] An "arc" in a topic map graph is a two-ended connectedness between nodes that satisfies all of the following criteria:


3.3.1   [parid0045] Four arc types

[parid0046] There are four arc types, named "AT", "AC", "CR", and "Cx". The significance of each type of arc is different.


3.3.2   [parid0047] Names of arc types and arc endpoint types

[parid0048] The first letter of an arc type's name is the name of one of its endpoint types. The second letter of the arc type's name is the name of its other endpoint type. That is, an AT arc has two endpoints, one of endpoint type "A" and the other of endpoint type "T".

Note 4: 

[parid0927] In a well-formed topic map graph, only a-nodes serve as "A" endpoint types, only c-nodes serve as "C" endpoint types, only r-nodes serve as the "R" endpoint types, and only t-nodes serve as the "T" endpoint types. There is no such thing as an "x-node", because all kinds of nodes are eligible to serve as the x endpoints of Cx arcs. The exceptional character of the x endpoints of Cx arcs is the reason why "x" is the only endpoint type name that is always rendered in lower case.



3.3.3   [parid0058] Eight forms of connectedness are possible

[parid0056] In all instances of each type of arc, the significance of a node's service as one of the endpoints is different from the significance of a node's service as the other endpoint. Given two nodes, N1 and N2, there are eight possible forms of connectedness between them, since there are four types of arcs. They are enumerated in the following subclauses.


3.3.3.1   [parid0060] Form 1: "A" to "T"

[parid0061] The connectedness of N1 and N2 is an instance of an AT arc type in which N1 is the A endpoint, and N2 is the T endpoint.


3.3.3.2   [parid0062] Form 2: "T" to "A"

[parid0063] The connectedness of N1 and N2 is an instance of an AT arc type in which N1 is the T endpoint, and N2 is the A endpoint. (This is the reverse of Form 1.)


3.3.3.3   [parid0064] Form 3: "A" to "C"

[parid0065] The connectedness of N1 and N2 is an instance of an AC arc type in which N1 is the A endpoint, and N2 is the C endpoint.


3.3.3.4   [parid0066] Form 4: "C" to "A"

[parid0067] The connectedness of N1 and N2 is an instance of an AC arc type in which N1 is the C endpoint, and N2 is the A endpoint. (This is the reverse of Form 3.)


3.3.3.5   [parid0068] Form 5: "C" to "R"

[parid0069] The connectedness of N1 and N2 is an instance of a CR arc type in which N1 is the C endpoint, and N2 is the R endpoint.


3.3.3.6   [parid0070] Form 6: "R" to "C"

[parid0071] The connectedness of N1 and N2 is an instance of an CR arc type in which N1 is the R endpoint, and N2 is the C endpoint. (This is the reverse of Form 5.)


3.3.3.7   [parid0072] Form 7: "C" to "x"

[parid0073] The connectedness of N1 and N2 is an instance of a Cx arc type in which N1 is the C endpoint, and N2 is the x endpoint.


3.3.3.8   [parid0074] Form 8: "x" to "C"

[parid0075] The connectedness of N1 and N2 is an instance of a Cx arc type in which N1 is the x endpoint, and N2 is the C endpoint.

Note 5: 

[parid0076] The above list of Forms of Connectedness can be represented in tabular form as follows:

Table 1:  The Eight Forms of Connectedness
[parid0077]
N1 N2
1
A T
T A
A C
C A
C R
R C
C x
x C
2
3
4
5
6
7
8

Note 6: 

[parid0908] The above enumeration of the Forms of Connectedness serves two purposes in this RM4TM:

  1. [parid0910] It establishes a name ("Form n", where n is an integer in the sequence 1..8) for each of the Forms of Connectedness that an arc can represent, as a convenience for use elsewhere in this document, and possibly in the definitions of TM Applications.

  2. [parid0909] It establishes that the orientation of the connectedness represented by an arc is an essential aspect of the definition of "arc" in this RM4TM. For purposes of a TM Application's definition of a "situation feature" (see 3.4.2), for example, it is insufficient merely to say that two nodes are connected by a certain type of arc. The specification of the arc must also include information as to which node serves as which endpoint type. In order to represent connectedness equivalent to the connectedness represented by an RM4TM arc in some "directed graph" paradigms, at least two directed graph arcs must be used, plus whatever additional machinery may be required to associate the two directed graph arcs in order to represent that both represent different directional aspects of the same connectedness. By contrast, RM4TM arcs are nondirectional, but oriented.



3.4   [parid0032] Nodes and subjects

3.4.1   [parid0033] One subject for each node

[parid0034] In topic map graphs, only nodes can represent subjects, and every node represents a single subject.


3.4.2   [parid0036] Situations and subjects

[parid0037] A node serves as one endpoint of zero or more arcs.

Note 7: 

[parid0509] A node that serves as the endpoints of no arcs at all is not well-formed unless it has at least one built-in SIDP value. (See 3.4.2.)


[parid0502] A node that is the endpoint of zero arcs is said to be "isolated." In a well-formed topic map graph, only "built-in" nodes (see Clause 4) can be isolated.

[parid0503] A node that is the endpoint of one or more arcs is said to be "situated." A node's "situation" is its service as one of the endpoints of all of the "connected paths" through the graph to all other nodes accessible via such paths. (Given node n[0], a "connected path" is a finite alternating sequence n[0], arc[1], n[1], arc[2], n[3]... n[n] such that each arc[i] in the sequence connects node[i-1] and node[i].)

[parid0504] Except for the built-in values of the properties of built-in nodes, all of the values of the properties of nodes are determined by their situations. Thus, except for the built-in subjects of built-in nodes, the subjects of all nodes are entirely determined by their situations.

[parid0928] Except for the restrictions on the subjects of nodes that have special functions within assertion subgraphs (see 3.6.2.2), TM Applications are free to define "situation features" (features of the situations of nodes) and how those features, when they occur, affect the values of the properties of the nodes whose situations include those situation features. The values of all properties can be affected by such situation features, including both Subject Identity Discriminating Propertes (SIDPs) and Other Properties (OPs), in accordance with the specifications provided in the definition of the TM Application that defines the properties and the situation features (see 4.7.2.2).

Note 8: 

[parid0505] The situation of a node in a topic map graph is always and only as visible as the values of its properties make it. See Clause 4.


Note 9: 

[parid0904] The definition of a situation feature can include, but is not limited to, the situated node's status as a role player in one or more assertions. The definition of a situation feature can also include the situated node's status as another kind of assertion component node, such as an r-node component of one or more assertions (see 3.6.2.2).



3.5   [parid0080] Well-formed nodes

3.5.1   [parid0081] Six cases of well-formed nodes

[parid0082] A node that satisfies all the criteria in the subclauses of one of the six cases described in the following subclauses is well formed. A node that does not satisfy the criteria of one of the six cases is not well formed.


3.5.1.1   [parid0083] Well-formed node Case 1

3.5.1.1.1   [parid0084] Defining Characteristics of Case 1 nodes

3.5.1.1.1.1   [parid0085] The node serves as no endpoint of any arc.

3.5.1.1.1.2   [parid0086] The node has at least one built-in SIDP value (see Clause 4).

3.5.1.1.2   [parid0087] Node type name of Case 1 nodes

[parid0088] Case 1 nodes do not have a node type name.


3.5.1.1.3   [parid0089] Subjects of Case 1 nodes

[parid0090] The subjects of Case 1 nodes are not constrained by this RM4TM.


3.5.1.2   [parid0091] Well-formed node Case 2

3.5.1.2.1   [parid0092] Defining characteristics of Case 2 nodes

3.5.1.2.1.1   [parid0093] The node serves as one or more of the x endpoints of any number of well-formed Cx arcs.

3.5.1.2.1.2   [parid0094] The node does not serve as any other endpoint type of any instance of any arc type.

3.5.1.2.1.3   [parid0095] The node either has at least one built-in SIDP value, or its situation as a role player causes at least one SIDP value to be conferred upon it.

3.5.1.2.2   [parid0096] Node type name of Case 2 nodes

[parid0097] Case 2 nodes do not have a node type name.


3.5.1.2.3   [parid0098] Subjects of Case 2 nodes

[parid0099] The subjects of Case 2 nodes are not constrained by this RM4TM.


3.5.1.3   [parid0100] Well-formed node Case 3 ("a-node")

3.5.1.3.1   [parid0101] Defining characteristics of Case 3 nodes

3.5.1.3.1.1   [parid0102] The node serves as zero or more of the x endpoints of any number of Cx arcs.

3.5.1.3.1.2   [parid0103] The node serves as the A endpoint of two or more AC arcs.

3.5.1.3.1.3   [parid0104] The node may or may not serve as the A endpoint of one AT arc.

3.5.1.3.1.4   [parid0105] The node does not serve as any other endpoint of any instance of any arc type.

3.5.1.3.2   [parid0106] Node type name of Case 3 nodes

[parid0107] A Case 3 node is called an "a-node" (where "a" stands for "assertion").


3.5.1.3.3   [parid0108] Subjects of Case 3 nodes

[parid0109] The subject of an a-node is always the relationship that is specified via the assertion for which it serves as the unique nexus. The relationship is an instance of the type of relationship which is the subject of the node that serves as the T endpoint of the AT arc of which the a-node is the A endpoint, if any. If the a-node is not the A endpoint of an AT arc, the type of the relationship is unspecified.


3.5.1.4   [parid0113] Well-formed node Case 4 ("c-node")

3.5.1.4.1   [parid0114] Defining characteristics of Case 4 nodes

3.5.1.4.1.1   [parid0115] The node serves as zero or more of the x endpoints of any number of Cx arcs.

3.5.1.4.1.2   [parid0116] The node serves as the C endpoint of a single AC arc.

3.5.1.4.1.3   [parid0117] The node serves as the C endpoint of a single CR arc.

3.5.1.4.1.4   [parid0118] The node may or may not serve as the C endpoint of a single Cx arc.

3.5.1.4.1.5   [parid0119] The node does not serve as any other endpoint of any instance of any arc type.

3.5.1.4.2   [parid0120] Node type name of Case 4 nodes

[parid0121] A Case 4 node is called a "c-node" (where "c" stands for "casting").

Note 10: 

[parid0914] The term "casting" is consistent with the theatrical metaphor invoked by the term "role player". In an assertion, the role players are like the actors in a stage play. Each c-node represents the "casting" of an actor (a role player) in a specific role (a role type) in a specific stage production (a specific assertion), which may or may not be a production of a specific stage play (a specific assertion type). See 3.6.1.



3.5.1.4.3   [parid0122] Subjects of Case 4 nodes

3.5.1.4.3.1   [parid0123] Case 4 nodes with role players

[parid0124] If a c-node serves as the C endpoint of a Cx arc, then its subject is the playing of a specific role type by a specific subject in a specific relationship.


3.5.1.4.3.2   [parid0125] Case 4 nodes without role players

[parid0126] If a c-node does not serve as the C endpoint of a Cx arc, then its subject is the fact that a specific role type in a specific relationship is not played by any subject.


3.5.1.5   [parid0127] Well-formed node Case 5 ("r-node")

3.5.1.5.1   [parid0128] Defining characteristics of Case 5 nodes

3.5.1.5.1.1   [parid0129] The node serves as zero or more of the x endpoints of any number of Cx arcs.

3.5.1.5.1.2   [parid0130] The node serves as the R endpoint of one or more CR arcs.

3.5.1.5.1.3   [parid0131] The node does not serve as any other endpoint of any instance of any arc type.

3.5.1.5.2   [parid0132] Node type name of Case 5 nodes

[parid0133] A Case 5 node is called an "r-node" (where "r" stands for "role type").


3.5.1.5.3   [parid0134] Subjects of Case 5 nodes

[parid0135] The subject of an r-node is a role type that can be played by subjects in relationships. The subjects of the c-nodes that serve as the C endpoints of the CR arcs whose R endpoints are the r-node are the role-player castings of role players that play the role type.


3.5.1.6   [parid0136] Well-formed node Case 6

3.5.1.6.1   [parid0137] Defining characteristics of Case 6 nodes ("t-node")

3.5.1.6.1.1   [parid0138] The node serves as zero or more of the x endpoints of any number of Cx arcs.

3.5.1.6.1.2   [parid0139] The node serves as the T endpoint of one or more AT arcs.

3.5.1.6.1.3   [parid0140] The node does not serve as any other endpoint of any instance of any arc type.

3.5.1.6.2   [parid0141] Node type name of Case 6 nodes

[parid0142] A case 6 node is called a "t-node" (where "t" stands for assertion "type").


3.5.1.6.3   [parid0143] Subjects of Case 6 nodes

[parid0144] The subject of a t-node is a class of relationship, including the roles that can be played in instances of the class, and the values that are conferred on the properties of role players by virtue of their situations as players of specific roles in instances of the class. The subjects of all of the a-nodes that serve as the A endpoints of all of the AT arcs of which a t-node serves as the T endpoint are instances of the class of relationship that is the subject of the t-node.

Note 11: 

[parid0145] The above well-formedness requirements for nodes can be summarized in tabular form as follows:


Table 2:  The Six Cases of Well-formed Nodes
[parid0146]
Form of
Connectedness
(node N2)
node N1
N1 Case 1
N1 Case 2
N1 Case 3
N1 Case 4
N1 Case 5
N1 Case 6
8
.........
C
x
7
.........
x
C
6
.........
C
R
5
.........
R
C
4
.........
A
C
3
.........
C
A
2
.........
A
T
1
.........
T
A
node type
name
(if any).
Subject
constraint
(if any).
Subject is:
requires
built-n
SIDP
value(s)?
0 0 0 0 0 0 0 0 (none) (unconstrained) yes
1+ 0 0 0 0 0 0 0 (none) (unconstrained) no
0+ 0 0 0 0 2+ 0 1? "a-node" assertion no
0+ 1? 0 1 1 0 0 0 "c-node" casting no
0+ 0 1+ 0 0 0 0 0 "r-node" role type no
0+ 0 0 0 0 0 1+ 0 "t-node" assertion type no
Legend:
0 In order to conform to the well-formed node case described on this row, node N1 is not permitted to serve as the arc endpoint designated by this column.
0+ In order to conform to the well-formed node case described on this row, node N1 may serve as zero or more of the arc endpoints designated by this column.
1 In order to conform to the well-formed node case described on this row, node N1 must serve as exactly one of the arc endpoints designated by this column.
1? In order to conform to the well-formed node case described on this row, node N1 may serve as exactly one of the arc endpoints designated by this column.
1+ In order to conform to the well-formed node case described on this row, node N1 must serve as at least one of the arc endpoints designated by this column.
2+ In order to conform to the well-formed node case described on this row, node N1 must serve as at least two of the arc endpoints designated by this column.

3.6   [parid0154] Assertions

3.6.1   [parid0454] Introduction to assertions

[parid0455] Assertions are subgraphs of topic map graphs. In a well-formed topic map graph, every arc is a specific component of a single assertion, so well-formed topic map graphs consist entirely of assertions (except, possibly, for isolated "built-in" nodes).

[parid0489] Each assertion represents (asserts the existence of) a single strongly-typed relationship among the subjects that are its "role players". Each role player is a subject that plays a specific role in the relationship. The roles ("role types") themselves are subjects, and so is the type of relationship of which the relationship is an instance.

[parid0207] The design of assertions in this RM4TM enables diverse multiple topic map graphs to be amalgamated into a single topic map graph, such that:

Note 12: 

[parid0209] In order to maintain the integrity of merged topic maps, it is necessary to establish a common structure for all assertions. In this RM4TM, the decisions as to which aspects of the structure of assertions should be "reified" as nodes, and which aspects should remain "unreified" as arcs, were made by distinguishing between the aspects of assertions that are substantive with respect to the relationships that they assert (and that could conceivably, therefore, need to become role players in other assertions about those relationships), as opposed to the aspects of assertions that nobody would want to make other assertions about unless they were discussing the design of assertions in general. In the structure of assertions set forth in this RM4TM, the former aspects are represented by a-nodes and c-nodes, while the latter aspects are represented as the four types of arcs (the "eight forms of connectedness").



3.6.2   [parid0172] Inventory of the components of assertions

[parid0174] An assertion is a subgraph of a topic map graph that consists of certain arcs and the nodes that serve as their endpoints, constructed in conformance to the rules set forth in this clause. Every node, regardless of its node type, is eligible to be a role player (i.e., to serve as the x endpoint of a Cx arc) in any number of assertions. Every arc is a component of a single assertion. The entire significance of every arc is its service as a unique component of a single assertion.


3.6.2.1   [parid0175] Inventory of the arcs in an assertion

[parid0176] The inventory of arcs that an assertion may have are defined in the subclauses that follow.


3.6.2.1.1   [parid0177] One or zero AT arcs
Note 13: 

[parid0178] The assertion type of an assertion may be specified or unspecified.



3.6.2.1.2   [parid0179] Two or more AC arcs
Note 14: 

[parid0180] In every assertion, there must be at least two role types, and therefore there must be at least two casting nodes.



3.6.2.1.3   [parid0181] Exactly as many RC arcs as there are AC arcs
Note 15: 

[parid0182] Every casting node must have a role type, as well as belong to a single assertion.



3.6.2.1.4   [parid0183] At least one Cx arc
Note 16: 

[parid0184] Every assertion must have at least one role player.



3.6.2.2   [parid0185] Inventory of the nodes in an assertion

3.6.2.2.1   [parid0186] Nodes whose subjects are never dependent on their situation with respect to a given assertion:

3.6.2.2.1.1   [parid0187] Assertion type nodes (t-nodes; i.e., T endpoints of AT arcs)

3.6.2.2.1.2   [parid0188] Role type nodes (r-nodes; i.e., R endpoints of CR arcs)

3.6.2.2.2   [parid0189] Nodes whose subjects are always dependent on their situation with respect to a given assertion:

3.6.2.2.2.1   [parid0190] Assertion nodes (a-nodes; i.e., A endpoints of AT and AC arcs)

[parid0191] An assertion always includes a single well-formed a-node which serves as its unique nexus. The a-node's subject is the relationship that the assertion represents.


3.6.2.2.2.2   [parid0192] Casting nodes (c-nodes; i.e., C endpoints of AC, CR, and Cx arcs)

[parid0193] An assertion always includes at least two c-nodes. The subject of every c-node is that a specific role player (or that no role player at all) plays a specific role type in a specific assertion.


3.6.2.2.3   [parid0194] Nodes whose subjects may or may not be dependent on their situation with respect to a given assertion (role player nodes):

[parid0195] The governing TM Application defines situation features and their effects on the values of the SIDPs of role players. Except in cases where a subject (specified by a set of SIDP values) has been defined by the governing TM Application as being built into a node, a node's subject depends entirely on the features of its situation (its "situation features" - see 3.4.2), on account of which the governing TM Application requires values to be conferred on the values of one or more of its SIDPs. Therefore, the situations of nodes as players of certain roles in instances of certain assertion types may or may not determine their subjects.

Note 17: 

[parid0980] For example, the subject of a node may be determined by its situation as a role player in a single assertion, even though it is also a role player in many others. For another example, the subject may be collectively determined by multiple assertions, perhaps by virtue of playing a role type or set of role types in a set of assertions, or perhaps by playing a role in an assertion in which another roleplayer's subject is collectively determined.



3.6.2.3   [parid0196] What's in and what's not in an assertion

[parid0197] The assertion of which a given a-node is the unique nexus includes all of the nodes and arcs enumerated in the following subclauses, and it does not include any other nodes and arcs:


3.6.2.3.1   [parid0198] All of the AC arcs of which the given a-node serves as the A endpoint.

3.6.2.3.2   [parid0199] The well-formed c-nodes that serve as the C endpoints of the AC arcs identified in 3.6.2.3.1.

3.6.2.3.3   [parid0200] The RC arcs that have the c-nodes identified in 3.6.2.3.2 as their C endpoints.

3.6.2.3.4   [parid0201] The well-formed r-nodes that serve as the R endpoints of the RC arcs identified in 3.6.2.3.3.

3.6.2.3.5   [parid0202] The Cx arcs that have the c-nodes identified in 3.6.2.3.2 as their C endpoints.

3.6.2.3.6   [parid0203] The well-formed nodes that serve as the x endpoints of the Cx arcs identified in 3.6.2.3.5.

3.6.2.3.7   [parid0204] The AT arc, if any, of which the given a-node serves as the A end.

3.6.2.3.8   [parid0205] The well-formed t-node that serves as the T endpoint of the AT arc, if any, identified in 3.6.2.3.7.

3.6.3   [parid0494] Identity of assertions

[parid0110] Two assertions are always considered identical if they have the same assertion type, and the same role players (or the absences of role players) play the same roles. Two assertions are never considered identical, even if they have the same role players playing the same roles, if either or both of their assertion types are unspecified. This clause provides the operational definitions of these concepts.

[parid0495] The identity of the relationship instance that is the subject of an a-node is defined by that a-node's situation as the nexus of an assertion subgraph. For all a-nodes, every TM Application is required to define a situation feature and a set of one or more SIDPs that unambiguously, comprehensively and exclusively reflects the combination of the following:

Note 18: 

[parid0981] One of the key features of this RM4TM is that the merging process does not need to understand the semantics of assertion types in order to merge identical assertions. If two assertions have the same type, regardless of what it is, and the same role players playing the same role types, regardless of what they are, they can be seen to be identical and automatically merged.



3.6.4   [parid0160] Assertion semantics

3.6.4.1   [parid0510] Semantics of assertion typing

3.6.4.1.1   [parid0161] When the assertion type is specified

[parid0162] A "typed" assertion is an assertion that specifies its assertion type (i.e., that has an AT arc and t-node). The semantics of a typed assertion are determined by the subject of its t-node, which is the assertion type of which the typed assertion is an instance. The subject of the t-node incorporates the semantics of all of the role types that can have role players in instances of the assertion type, all of which must be specified in the definition of the subject of the assertion type, either by reference or inclusion.

[parid0490] The semantics of a typed assertion may determine or affect the subjects of some or all of its role players, i.e., the existence of such an assertion may affect the values assigned to the SIDPs of its role players (see 4.7.2).


3.6.4.1.2   [parid0164] When the assertion type is not specified

[parid0165] An "untyped" assertion is an assertion that does not specify its assertion type (i.e., that has no AT arc). The semantics of an untyped assertion are determined by its role types, i.e., by the subjects of its r-nodes. The semantics of its role types may be such that the players of the role types have values conferred on their OPs (Other Properties -- see 4.4). However, the role types of untyped assertions must not be defined in such a way as to require values to be conferred upon the SIDPs of their players (see 5.2.5.3.2).


3.6.4.1.3   [parid0168] The subjects of assertion types and role types are never affected by their instances

[parid0169] The existence of a given assertion never implies anything about the subject which is the assertion type (if any) of which the assertion is an instance, or about the subjects that are the assertion's role types. No values can be conferred upon the SIDPs of assertion types or role types by virtue of their situations, respectively, as the T endpoints of AT arcs, or as the R endpoints of CR arcs.

Note 19: 

[parid0170] Like all other nodes, the t-node and r-nodes that represent the subjects that are an assertion's type and role types, respectively, may have their subjects (i.e., the values of their SIDPs) built into them, or their subjects may be conferred upon them by virtue of their situations as role players in other assertions.


Note 20: 

[parid0171] TM Applications may confer values on the OPs of t-nodes and r-nodes by virtue of their situations as t-nodes and r-nodes.



3.6.4.2   [parid0508] Semantics of role playing

3.6.4.2.1   [parid0157] No multiple role players of a single role type

[parid0158] In any given assertion, each role type is either played by a single subject, represented by a single node, or the role type is "unplayed", i.e., the role type has no role player. Multiple subjects cannot play the same role in the same assertion.

Note 21: 

[parid0159] However, the subject of a role player can be a group of subjects, if the governing TM Application defines the assertion types required to allow the subjects of nodes to be groups of subjects.

[parid0929] No grouping semantics of any kind are defined by this RM4TM. This RM4TM requires all groups to be explicitly represented as nodes. Any other approach would open the possibility for knowledge about a group to fail to be connected to the single node whose subject is the group, and that would be contrary to the Subject Location Uniqueness Objective.



3.6.4.2.2   [parid0155] Semantics of nodes' situations as role players

[parid0156] A node's situation as a role player in any given assertion indicates that the subject represented by that node participates in the relationship that is the subject of the assertion, as represented by the assertion's a-node. In an asserted relationship, each role player plays a distinct role; the nature of each role is the subject (called a "role type") of one of the assertion's r-nodes. The relationship itself is an instance of the kind of relationship that is the subject of the assertion's t-node, if any. If the assertion has no t-node, the subject of which the relationship is an instance is not specified.


3.6.4.2.3   [parid0166] All role types are always represented in any assertion of a given type

[parid0167] In the topic map graph, the representation of every assertion always includes the representation of all of the role types defined by its assertion type's definition, regardless of whether they are played or unplayed. (If the assertion type is unspecified, then the set of role types that the assertion specifies is assumed to be comprehensive for that assertion.)


3.7   [parid0210] Well-formedness constraints on Assertions

[parid0211] An assertion that does not conform to all of the following rules is not well-formed:


3.7.1   [parid0917] No two role types the same; each has zero or one role player

[parid0212] No two c-nodes that participate in the assertion are connected to the same r-node via the CR arcs for which the c-nodes serve as the C endpoints.

[parid0213] The role types that participate in any given assertion instance must always constitute a set, i.e., within any single assertion, no two role types can be the same. Each role type has a maximum of one role player.

Note 22: 

[parid0915] If the governing Application defines assertion types that allow nodes to have subjects that are groups of subjects, such a group of subjects can be a role player. Still, even in such cases, there is still only one role player: the group.



3.7.2   [parid0214] There must be at least one role player

[parid0916] The set of arcs that are members of the set of arcs that specify the assertion must include at least one Cx arc.


3.8   [parid0216] Well-formedness constraints on topic map graphs

[parid0217] A topic map graph that conforms to the criteria specified in both of the following clauses is well-formed. A topic map graph that does not satisfy either or both criteria is not well-formed.


3.8.1   [parid0218] There is at least one node.

3.8.2   [parid0219] There are no arcs that do not participate in a single well-formed assertion.

3.9   [parid0028] Well-formed and fully merged topic map graphs

[parid0029] When a topic map takes the form of a topic map graph, all of the subjects that participate in the topic map are represented as nodes.

[parid0500] In a well-formed topic map graph, every node represents a single subject, but some subjects may be represented by more than one node. In a fully merged topic map graph, every subject is represented by a single node.

[parid0501] A well-formed topic map graph may or may not be fully merged, but a fully merged topic map graph is always well-formed.

[parid0030] A topic map graph that does not meet this RM4TM's criteria for well-formedness is not eligible to undergo the merging process.

Note 23: 

[parid0031] The process whereby well-formed topic map graphs are converted into fully merged topic map graphs is defined in Clause 6.



4   [parid0220] Properties of nodes

4.1   [parid0231] Only a common framework for properties; no common properties

[parid0232] This RM4TM defines a framework within which each TM Application defines all of the properties of the nodes that it governs. The framework is designed to constrain the definitions of TM Applications in such a way that they can be implemented independently, with each implementation able to demonstrate the conformance of its behavior to the definition of the TM Application, and, therefore, with the behavior of all other conforming implementations.

Note 24: 

[parid0918] This RM4TM defines no properties of nodes. It does, however, impose certain constraints on the definitions of such properties within the definitions of TM Applications.



4.2   [parid0221] Every property is governed by a single TM Application

[parid0222] All of the properties of nodes, their value types, and the requirements for assigning values to them are defined by TM Applications. Every property defined by a TM Application, and every node that exhibits values for any of the properties defined by that TM Application, is said to be "governed" by that TM Application. Every node must be governed by one or more TM Applications. Every property is governed by a single TM Application.


4.3   [parid0223] Subject identity discrimination properties ("SIDPs")

4.3.1   [parid0960] Identical subjects must be recognizably identical

[parid0224] The fact that two nodes have the same subject must be detectable in order to trigger the merging operations that transform a well-formed topic map graph into a fully merged one. Therefore, at least one property of every node must be defined by its governing TM Application for the express purpose of allowing the subject of the node to be distinguishable from all other subjects, and in order to allow the subjects of nodes, when they are identical, to be recognizable as identical by the topic map graph merging process. Such properties are called "Subject Identity Discrimination Properties" (SIDPs). The values of SIDPs, and no other data of any kind, are used in TM Application-defined calculations to determine whether any two nodes should be merged.


4.3.2   [parid0961] Subject identity is the values of SIDPs

[parid0225] All merging rules defined by a TM Application must serve the Subject Location Uniqueness Objective, and all must be expressed entirely in terms of the values of the SIDPs defined by that TM Application. TM Applications must define sufficient SIDPs, and constrain the calculations and assignments of their values, in sufficient detail to support all of the merging rules defined by the TM Application.


4.3.3   [parid0962] The merging of nodes

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

  1. [parid0930] the resulting single node ("result node") serves as the union of the two sets of arc endpoints of the two predecessor nodes,

  2. [parid0931] the resulting single node exhibits the union of the built-in property values, if any, of the two predecessor nodes, and

  3. [parid0923] all of the property values of the result node, and of all other nodes whose situation features are changed as a result of the merger, are adjusted in such a way as to reflect their new situations, in accordance with the definition(s) of the TM Application(s) that govern the properties.

Note 25: 

[parid0373] Nodes never merge for any reason other than the fact that they are regarded as having the same subject; all merging operations must serve the Subject Location Uniqueness Objective. However, TM Applications may require the application of any number of rules for determining whether two nodes have the same subject. Such merging rules may be based on diverse combinations of subject property values, each of which may be based on a complex situation feature definition, possibly involving intermediary assertions and nodes through which the situated node is connected to many other nodes.



4.3.4   [parid0963] RM4TM constrains the SIDPs and SIDP values of a-nodes and c-nodes

[parid0233] The subjects of a-nodes and c-nodes are comprehensively and exclusively defined by this RM4TM in terms of their situations in the assertions of which they are components. The properties and value-assignment rules of TM Applications are not permitted to override, obscure, add to, or fail to expose these subjects.


4.4   [parid0227] Other properties ("OPs")

[parid0228] TM Applications may also define properties whose values are not used for subject discrimination purposes; such properties are called "OPs" (other properties). TM Applications define the purposes of OPs, and the processes by which their values are calculated and assigned.


4.5   [parid0234] Names of properties of nodes

[parid0235] Each property has a name that is unique, within the TM Application, among all the names of the properties, assertion types, and role types defined by the TM Application. In a topic map graph, however, property names may be defined by multiple TM Applications, so different TM Applications may define the same property name. Therefore, each property name consists of two fields, separated by the field separator symbol defined in 4.5. The first field is the name of the TM Application itself, and the second field is the property name which is unique within the TM Application.

Editor's Note 3: 

[parid0442] TO DO: Select a field separator symbol, so everybody knows what not to use in the name of a TM Application, property, assertion type, or role type. It can't be a colon (":") if we expect people to use IETF scheme names in their TM Application-name URIs, such as "http:".


4.6   [parid0237] Values of properties of nodes

[parid0238] The values of properties of nodes, the types of their values, and the methods whereby their values are calculated and assigned, are all defined by their governing TM Applications.


4.7   [parid0240] Assignment of values of properties of nodes

[parid0241] The values of the properties of nodes are assigned in two ways. They are either:

  1. [parid0469] "built-in" or

  2. [parid0470] "conferred".


4.7.1   [parid0242] Built-in values of properties of nodes

[parid0243] For bootstrapping reasons, TM Applications must define at least some nodes to be present in all topic map graphs that contain nodes that are governed by the TM Application, regardless of whether they appear explicitly in any interchangeable topic map governed by that TM Application. Such nodes are called "built-in" nodes, and they must be defined as having "built-in values" for at least one of their SIDPs.

[parid0245] A node's built-in property values cannot be overridden by virtue of its situation in the topic map graph. It is a Reportable TM Processing Error if a built-in node's situation requires any of its properties that have built-in values to have values conferred upon them that are different than their built-in values.

Note 26: 

[parid0992] Conferred property values can be changed or "erased" when, after the topic map graph has been altered, conferred property values are recalculated, and a node's situation no longer requires one of its properties to have the value that had been conferred upon it on account of its previous situation (see 6.3). By contrast, as specified in 4.7.1 (above), built-in values cannot be changed or erased.


Note 27: 

[parid0246] Values can be conferred on properties of built-in nodes that do not have built-in values.


Note 28: 

[parid0247] The determination of the ontological basis of a TM Application, how that ontological basis is bootstrapped, and how self-documenting (in terms of the topic map) the ontology is, are all in the realm of TM Application design. For example, a TM Application may be designed in such a way that all of its assertion types are represented by built-in nodes. Alternatively, a TM Application may be designed in such a way that only enough "bootstrap" assertion types (with built-in SIDPs) are required to be present to allow external definitions of all other assertion types to be used to confer the SIDP values of such assertion type subjects upon the nodes that represent them.



4.7.2   [parid0248] Conferred values of properties of nodes

[parid0249] The properties of nodes can have values that are conferred upon them by their nodes' situations in the topic map graph. These values are called "conferred" values.


4.7.2.1   [parid0250] Overview of requirements governing definitions of conferred property values

[parid0251] With respect to the values conferred on the properties of nodes, TM Applications must define:

  1. [parid0471] the situation features of nodes that call for values to be conferred upon the properties of such nodes,

  2. [parid0472] the properties of such nodes to which the values are assigned,

  3. [parid0473] the types of the property values, and

  4. [parid0474] how the values are calculated.

Note 29: 

[parid0252] The definitions of the processing steps involved in calculating property values are not constrained by this RM4TM. Such processing may, for example, involve resolving addresses and using whatever information is addressed in further processing steps.



4.7.2.2   [parid0253] Situation features that TM Applications define as requiring values to be conferred on the properties of nodes

[parid0254] For all purposes of defining situation features that require values to be conferred on the properties of nodes, such situation features may be described in terms of whole assertions, or in terms of specific nodes and arcs, or both. In any case, however, for a given node, a situation feature is always fundamentally describable as the given node's service as the endpoints of some set of paths whose characteristics are defined by the TM Application as constituting a situation feature that requires values to be conferred.

[parid0255] When a node's service as the x endpoint of one or more Cx arcs (i.e., when a node's situation as a role player) is an aspect of a TM Application-defined situation feature that requires values to be assigned to one or more of its properties, the definitions of such situation features, the properties to which the values are assigned, the types of the values, and how the values are calculated, must all be defined as part of, or at least with respect to, the definition of the type of assertion of which the assertion that has the node as a role player is an instance.

Note 30: 

[parid0257] For example, if the TM Application defines an assertion type for the purpose of expressing set memberships, in which one role is played by the node whose subject is the set, and the other role is played by a node whose subject is a member of the set, then the value of the corresponding property of the node can be a node set which is the set of all the nodes whose subjects are members of the set.


Note 31: 

[parid0259] Not all situation features that require property values to be conferred are situations in which the conferred-upon node is a role player. Some situation features are within a single assertion subgraph. For example, all TM Applications must define a property for all the a-nodes they govern, whose value is the assertion type of the a-node; this property value is conferred upon it on account of its service as the A endpoint of an AT arc (see 4.3.4).



4.7.2.3   [parid0260] SIDP values cannot be conferred on a-nodes or c-nodes on account of their situations as role players.

[parid0261] The SIDP values that reflect the subjects of a-nodes and c-nodes, and that, therefore, determine whether they should be merged, can only be conferred upon them by virtue of their service as the A and C endpoints of arcs. This RM4TM defines the merging rules for assertions (see 5.2.8.2), and conforming TM Applications cannot violate these rules. Therefore, TM Applications cannot require the values of the subject identity discrimination properties (SIDPs) of a-nodes or c-nodes to be conferred upon them on the basis of their situations as role players (i.e. on the basis of their service as the x endpoints of Cx arcs).


4.7.2.4   [parid0263] SIDP values cannot be conferred on either r-nodes or t-nodes on account of their situations as R or T endpoints of CR or AT arcs, respectively.

[parid0264] The SIDP values that reflect the subjects of r-nodes and t-nodes are not, and cannot be, conferred upon them by virtue of their service as the R endpoints of any CR arcs, or the T endpoints of AT arcs, respectively. SIDP values can only be conferred upon r-nodes and t-nodes by virtue of their situations as role players (i.e., as the x endpoints of Cx arcs. (Alternatively, their SIDP values can be built-in.)


4.8   [parid0265] Internal consistency of the values of a node's SIDPs

[parid0267] TM Applications must define consistency rules regarding the combinations of values that any given node's SIDPs can exhibit in order for that node to be regarded as exhibiting a valid combination of SIDP values. Merging processes must be implemented in such a way as to detect and report (as Reportable TM Processing Errors) conditions that violate these consistency rules.

Note 32: 

[parid0268] For example, if one of a node's SIDP values indicates that the node's subject is a name, and another SIDP value indicates that the node's subject is a set of subjects, the definition of the TM Application can require such a node to be regarded as exhibiting an invalid combination of SIDP values. By stating such a constraint, the TM Application's definition can reflect its designers' conviction that there can never be a single subject that is both a name and a set.



5   [parid0269] Definitions of TM Applications

5.1   [parid0270] Introduction

[parid0271] This RM4TM constrains the definitions of "Topic Maps Applications (TM Applications)", establishing the criteria that such definitions must meet in order to facilitate the achievement of the Subject Location Uniqueness Objective, and to assure that topic maps can be interchanged, understood, and amalgamated predictably, regardless of their governing TM Applications, and regardless of the combinations of TM Applications that may govern the subjects represented by any single topic map graph that may result from amalgamating multiple topic maps.


5.1.1   [parid0272] Any participating subjects

[parid0273] This RM4TM does not constrain the nature or properties of subjects that can participate in topic map graphs.


5.1.2   [parid0275] Most constraints are imposed by TM Applications

[parid0276] This RM4TM imposes minimal constraints on the definitions of "Topic Maps Applications (TM Applications)," so that the definition of each TM Application establishes a context within which the nature of the topic map information being represented under its governance is well-defined.


5.1.3   [parid0277] Purpose of TM Application definition requirements

[parid0278] This RM4TM does not define any specific TM Applications, nor does it define any aspects of any specific TM Applications. Instead, it imposes constraints on the definitions of conforming TM Applications. The purpose of these constraints is to require TM Applications to be defined in sufficient detail, and with sufficient rigor, so that:


5.1.3.1   [parid0279] conforming implementations and conforming topic maps can be created by diverse and independent creators and creative processes,

5.1.3.2   [parid0280] given any conforming topic map created by any conforming implementation, the interpretation of that topic map by any other conforming implementation will be verifiably consistent with the TM Application, and

5.1.3.3   [parid0281] the effort and expense involved in amalgamating the knowledge represented by topic maps that conform to single and multiple TM Applications can be minimized, while the consistency of the knowledge represented by the resulting amalgamated topic maps can be maximized, without information loss, and with the greatest possible achievement of the Subject Location Uniqueness Objective by automatic means.

5.1.4   [parid0282] Overview of required TM Application definition components

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

  1. [parid0284] A name that is different from the name of any other conforming TM Application. (See 5.2.1.)

  2. [parid0285] A set of definitions of the properties of nodes and their value types, specifying which property values are intended to be used for purposes of deciding whether nodes have identical subjects (i.e., specifying which are SIDPs, and which are OPs). (See 5.2.2.)

  3. [parid0286] The validity constraints on the values of the properties of nodes. (See 5.2.3.)

  4. [parid0287] A set of situation features other than service as the x endpoints of Cx arcs, and the property values that must be conferred on the nodes so situated. (The purpose of these property values is to enable arc traversals within assertions. Not all intra-assertion arc traversals are required to be enabled. See 5.2.4.)

  5. [parid0288] A set of assertion types, the role types of each assertion type, the validation constraints on their instances, and the property values that must be conferred upon the role players of their instances. (See 5.2.5.)

  6. [parid0290] Rules for determining whether the values of any given node's subject identity discrimination properties (SIDPs) are consistent with each other. (See 5.2.6.)

  7. [parid0291] A set of built-in nodes, with built-in property values, that must appear in every topic map graph that conforms to the TM Application. (See 5.2.7.)

  8. [parid0292] The rules for merging nodes on the basis of their subject identity discrimination properties (SIDPs). (See 5.2.8.)

  9. [parid0293] The rules for combining the built-in values of the properties of built-in nodes during merging, if the designers of the TM Application anticipate the need for such combination. (See 5.2.9.)

  10. [parid0294] If the TM Application defines one or more interchange syntaxes, the procedures for constructing topic map graphs from instances of each syntax ("Syntax Processing Models"), and "node demander" rules that allow topic map graph nodes to be indirectly addressed by addressing their corresponding syntactic constructs. (See 5.2.10.)


5.2   [parid0295] Constraints on definitions of aspects of TM Applications

[parid0296] The following subclauses specify the detailed constraints governing each of the required aspects of the definitions of TM Applications.


5.2.1   [parid0297] Definition of TM Application name

[parid0298] The name of the TM Application must be specified. Care should be taken to select a name that is unlikely to be used as the name of any other TM Application, including other versions and/or conformance levels of an evolving or configurable TM Application. (Each version, conformance level, or other configuration must be regarded as a distinct TM Application for purposes of naming.) This name must be used as the first field of all of the property names that it defines. The name must not include the "name field separator" symbol shared by all TM Applications whose definitions conform to this RM4TM. (See 4.5.)

[parid0299] Non-ISO-standard TM Applications are not permitted to use names that begin with "IS", irrespective of the cases of the letters, in the first field.

Note 33: 

[parid0302] One way to minimize the risk of ambiguity that might result from coincidental use of identical names for TM Applications created by different TM Application designers is for designers to use, as their TM Application names, URIs that address the internet domain names that the designers themselves control, or that are registered names within controlled TM Application namespaces within the internet domains of such standards organizations as OASIS, the World Wide Web Consortium, IDEAlliance, or such library service organizations as the Online Computer Library Center (OCLC), the Library of Congress, etc.



5.2.2   [parid0303] Definition of properties and property values

[parid0304] All properties of nodes should be explicitly defined. All properties whose values are used to determine whether two nodes have the same subject (i.e., all SIDPs) must be explicitly defined.

[parid0305] Each property definition must specify all of the aspects described in the following subclauses:


5.2.2.1   [parid0306] Property name

[parid0307] The property definition must specify a name that is unique among the names of all the properties, assertion types, and role types defined by the TM Application. The name must not include the "name field separator" symbol (see 4.5).


5.2.2.2   [parid0308] Property value type

[parid0309] The property definition must specify the type of value of which the value must be an instance, if the property exhibits a value.

Note 34: 

[parid0310] Property value types are not constrained by this RM4TM. They can be simple and/or complex. They can be data and/or nodes.



5.2.2.3   [parid0311] Constraints on property values

[parid0312] The property definition may specify validity constraints on the value of the property. During the process of converting a well-formed topic map graph into a fully merged one, implementations of the TM Application must validate all SIDP values for conformance to all of the validity constraints defined for them. (See 6.4.)


5.2.2.4   [parid0314] Subject identity discrimination properties (SIDPs)

[parid0315] The property definition must indicate whether the property being defined is a subject identity discrimination property (SIDP).


5.2.2.5   [parid0319] Semantics of the property

[parid0320] Each property definition should include an explanation of the significance of the property and its values, including an explicit indication, where appropriate, of the significance of the condition in which no value is exhibited. If the property is a subject identity discrimination property (SIDP), such an explanation must be provided.


5.2.3   [parid0321] Definitions of validity constraints on the values of properties

[parid0322] If, in order to be considered valid, a property value must conform to certain constraints, the TM Application should define such constraints for each such property, wherever possible.


5.2.4   [parid0323] Definition of assignment of property values conferred on account of arc endpoint service other than service as the x endpoints of Cx arcs

[parid0324] All TM Applications are required to define subject identity discrimination properties (SIDPs) for a-nodes and c-nodes, and rules for conferring values upon them, such that all a-nodes and c-nodes will exhibit values for those properties that will support the merging of assertions in conformance with the assertion merging rules specified in 5.2.8.2.

Note 35: 

[parid0325] This RM4TM does not require TM Applications to define properties whose values reflect the internal structure of assertions comprehensively.


Note 36: 

[parid0921] See Annex C for an informative example of a set of property definitions that reflect the internal structure of assertions.



5.2.5   [parid0344] Definitions of assertion types

[parid0345] The definition of each assertion type defined by a TM Application must include all of the aspects specified in the following subclauses.


5.2.5.1   [parid0346] Definitions of names of assertion types

[parid0347] For each assertion type, a name that is unique among all the names of assertion types, role types, and properties defined by the TM Application must be specified. The names of assertion types have two fields, in the same manner as property names, with the name of the TM Application in the first field, and the name of the assertion type in the second field. The name must not include the "name field separator" symbol defined in 4.5.


5.2.5.2   [parid0361] Definition of the semantics of the assertion type

[parid0362] The semantics of each assertion type must be explained.


5.2.5.3   [parid0348] Definitions of role types

[parid0349] A set of role types must be specified, each member of which will always be represented in all instances of the assertion type in the topic map graph, regardless of whether they have role players.

[parid0350] This RM4TM does not prohibit multiple assertion types from incorporating the identical role type(s).

Note 37: 

[parid0940] The designs of TM Applications may be inherently more robust if all of the role types defined as components of their assertions types are regarded as unique subjects, even when they share the same names. For example, the father-daughter relationship type and the father-son relationship type may, in some cultures, be different in character, and the role of fatherhood may therefore also turn out to be different. If a TM Application defines both the father-daughter and father-son relationship types in such a way as to regard the role type of "father" as the same subject in both relationship types, then no distinction can ever be made between the two kinds of fatherhood, other than by defining a new TM Application.


[parid0352] Each role type definition includes all of the aspects specified in the following subclauses.


5.2.5.3.1   [parid0353] Definitions of names of role types

[parid0354] For each role type, a name which is unique among all the names of assertion types, role types, and properties defined by the TM Application must be specified. The names of role types have two fields, in the same manner as property names, with the name of the TM Application in the first field, and the name of the role type in the second field. The name must not include the "name field separator" symbol defined in 4.5.


5.2.5.3.2   [parid0355] Definitions of property values conferred on role players of assertion instances

[parid0356] If, in instances of the assertion type being defined, role players of the role being defined are required to have property values conferred upon them, the procedure required to calculate such values should be defined. It must be defined for subject identity discrimination properties (SIDPs).

[parid0357] TM Applications must not allow values to be conferred on the SIDPs of any of the role players of assertions whose assertion types are unspecified.


5.2.5.3.3   [parid0359] Definition of semantics of role type

[parid0360] The semantics of each role type must be explained.


5.2.6   [parid0363] Definition of consistency of the values of SIDPs of a node

[parid0364] The rules for detecting conditions in which the subject identity discrimination properties (SIDPs) of a node have conflicting values must be defined.


5.2.7   [parid0366] Definitions of built-in nodes and their built-in property values

[parid0367] Some of the subjects defined by a Topic Maps Application - at least enough to bootstrap at least some of its assertion types and role types into existence - must be represented by "built-in" nodes that are logically present in all topic map graphs at the moment that they begin to be constructed.

[parid0368] These built-in nodes and their built-in subject identity discrimination property values must be defined.

[parid0369] If there are any built-in assertions, the built-in property values that correspond to their arcs must be defined, and their built-in a-nodes and c-nodes must be provided with built-in values for their subject identity discrimination properties (SIDPs) such that the merging of the built-in assertions in conformance with the assertion merging rules specified in 5.2.8.2 will occur. The definitions of the properties that have built-in values in the built-in nodes defined by the TM Application must be such that, when topic map graphs governed by the TM Application are constructed, any assertions that are implicit in the built-in property values will be unambiguously recognized, so that they can be represented explicitly in the graph.

Note 38: 

[parid0922] Whenever two or more topic maps that are governed by the same TM Application are merged, some of their built-in nodes, such as the nodes whose subjects are the bootstrapping assertion types, will always be duplicated in every topic map, and therefore will always merge. Others, such as the built-in nodes whose SIDP values are derived from data contained in different syntactic instances, may not be duplicated, and therefore may not merge.



5.2.8   [parid0370] Definition of merging rules

5.2.8.1   [parid0371] Node merging is based only on SIDP values

[parid0372] TM Applications must define node merging rules that determine whether any two nodes must be merged, and these rules must operate solely on the basis of the values of subject identity discrimination properties (SIDPs).


5.2.8.2   [parid0374] Merging rules for assertions

5.2.8.2.1   [parid0450] Definition of subject identity of a-nodes

[parid0375] In all conforming TM Applications, two assertions are merged to become a single assertion when their respective a-nodes are deemed to represent the same subject. All TM Applications are required to define merging rules that apply uniformly to all assertions, such that they will always be merged during the process of converting a well-formed topic map graph into a fully merged topic map graph under the conditions described in the following subclauses, and such that they will be automatically merged under no other conditions and on no other basis:


5.2.8.2.1.1   [parid0376] Both assertions specify the same assertion type.
Note 39: 

[parid0377] If neither assertion specifies its assertion type, it cannot be assumed that the lack of an assertion type itself constitutes a specific assertion type which is the same for both.



5.2.8.2.1.2   [parid0378] Both assertions have the same role player, or both have no role player, for each of the same role types.

5.2.8.2.2   [parid0451] Merging process for assertions

[parid0380] When two assertions are merged, the two a-nodes become a single a-node, and each pair of c-nodes that are connected to the same r-node and a-node become a single c-node. (Nodes are merged as described in 4.3.3.)


5.2.8.3   [parid0385] The human factor in merging

[parid0386] The merging rules defined by TM Applications are intended be exploited by creators of topic maps, so that the topic maps they create can incorporate other topic maps by reference, and so that when such references are resolved, the resulting merged topic map graph will be identical to the one that the creator intended.

[parid0387] In all cases, and regardless of their governing Application(s), when two nodes represent the same subject, they must be merged. In other words, the Subject Location Uniqueness Objective always applies. It is the responsibility of the creator of every topic map to see to it that all such mergers will occur when the topic map is processed in conformance with the rules defined by its governing TM Applications.

[parid0388] Topic map creators must accept responsibility for the fully merged topic map graphs represented by the interchangeable topic maps that they create, even when their interchangeable topic maps incorporate topic maps that were created by others. When interchangeable topic maps incorporate other topic maps by reference, they must also contain (or incorporate by reference) subjects and assertions that cause the merging process to yield a satisfactory result in which no two nodes have the same subject, even when, in the absence of any special arrangements made by the creator of the topic map, no governing TM Application would cause the two nodes to merge. It is the responsibility of topic map creators to make such special arrangements, by adding assertions that will cause the nodes that must be merged to have SIDP values that will be recognized as requiring their merger. (See 7.4.)

Note 40: 

[parid0453] Such special arrangements may involve indirectly addressing the nodes of the topic map graph represented by the interchangeable forms of the topic maps that are incorporated by reference, by addressing the syntactic "node demanders" of the nodes that must be merged. See 5.2.10.3.



5.2.9   [parid0389] Definitions of rules for merging property values when merging nodes

5.2.9.1   [parid0976] Merging built-in property values

[parid0390] The Subject Location Uniqueness Objective may demand that built-in nodes be merged, but the effect of merging their built-in values cannot be determined by the situation features of the node that results from their merger. Therefore, TM Applications must define rules for combining the built-in values of built-in nodes.


5.2.9.2   [parid0977] Merging conferred property values

[parid0391] In order to optimize the merging process, TM Applications may also define procedures for combining the conferred property values of two nodes in the conferred property values of the single node that results from merging them. All such rules must be such that the result of applying these procedures is indistinguishable from the result of recalculating the merged node's conferred property values on the basis of its new situation.

Note 41: 

[parid0935] In any case, whenever two nodes are merged, the situations of other nodes may also be affected, necessitating recalculation of their property values, as well.



5.2.10   [parid0393] Definitions of interchange syntaxes

[parid0394] The definition of a Topic Maps Application may or may not define one or more syntaxes for the interchange of the topic maps it governs. The constraints on the definitions of such syntaxes are specified in the following subclauses.


5.2.10.1   [parid0396] Syntactic rigor

[parid0397] The syntax itself must be defined in such a way that instances of it can be validated for conformance with its syntactic rules before any attempt is made to render it as a topic map graph.


5.2.10.2   [parid0398] Syntax Processing Models

[parid0399] A "Syntax Processing Model" must be defined that specifies, in terms of the definition of each such syntax, how the information represented by instances of the syntax must be comprehensively represented as topic map graphs.

Note 42: 

[parid0970] In other words, a Syntax Processing Model specifies how to construct topic map graphs from instances of the syntax, without omitting any information represented in the instances. Syntax Processing Models may specify that instances of specific syntactic constructs require the addition to the graph of nodes with values that are built-in, as well as conferred. The built-in values may be derived from data contained in the syntactic instance.


[parid0989] For each value that a Syntax Processing Model requires to be assigned to a property of a node, the definition of the Syntax Processing Model must state whether the value is to be regarded as a built-in value, or it is to be regarded as a conferred value.

Note 43: 

[parid0991] Built-in values cannot be overridden by virtue of the node's situation in the graph. See 4.7.1.



5.2.10.3   [parid0401] Facilities for indirect node addressing via syntactic constructs

5.2.10.3.1   [parid0973] Node demanders

[parid0402] A list of syntactic constructs ("node demanders") whose instances can be unambiguously addressed within the instances of the syntax must be provided. Each such node demander must be defined as being associated with a specific node whose existence in the topic map graph that the instance represents can reasonably be regarded as being "demanded" by the existence of the demander.

[parid0404] The list of node demanders may or may not provide a facility for comprehensively addressing every node in the topic map graph constructed from a syntactic instance.


5.2.10.3.2   [parid0974] "Same subject as demanded node" assertion type

[parid0971] Each TM Application that defines one or more Syntax Processing Models must also define at least one assertion type of which one of the role types can be played by a node demander, that confers one or more SIDP values on the player of another of its role types such that its subject will be recognized by the merging process as being the same as the subject of the node whose existence is demanded by the node demander.

Note 44: 

[parid0403] The "node demander" facilities defined for the interchange syntaxes of TM Applications allow interchangeable topic maps to refer to each other in ways that guarantee the merging of nodes that are separately demanded by each of them.



5.2.11   [parid0405] Borrowed definitions

[parid0406] TM Applications can include, as portions of themselves, other TM Applications, by reference, but only in their entirety. The names of borrowed properties, assertion types and role types are not affected by being borrowed; each remains as defined in the definition of its TM Application of origin.


6   [parid0413] Constructing fully-merged topic map graphs from well-formed topic map graphs

[parid0414] This RM4TM is designed to allow all well-formed topic map graphs, regardless of their governing TM Application(s), to be processed in essentially the same way, in order to achieve the result of a fully-merged topic map graph. The process is designed to allow modular implementation of systems for processing topic maps that are governed by multiple TM Applications.

[parid0416] Conforming implementations of tools that build fully-merged topic map graphs are free to construct fully merged topic map graphs from well-formed topic map graphs in any way that, in any instance, results in a graph that is indistinguishable from the graph that would theoretically result by applying the process described in the following subclauses. The subclauses (and the paragraphs within them) appear in the order in which the steps must be performed (at least theoretically, for purposes of this RM4TM's definition of the merging process in terms of its required results).


6.1   [parid0418] Construct the topic map graph

[parid0419] The first step is to construct a well-formed topic map graph. The process of constructing well-formed topic map graphs is only partly constrained by this RM4TM.


6.1.1   [parid0420] Endow the graph with built-in bootstrap nodes

[parid0421] When constructing a new topic map graph, it must first be endowed with all of the built-in nodes and arcs that are required to bootstrap the logic of the governing TM Application's ontology.

Note 45: 

[parid0924] Built-in arcs are implicitly represented by the built-in property values that correspond to them. See 5.2.7.



6.1.2   [parid0422] Interpret interchangeable topic map as topic map graph

[parid0423] If the graph is being constructed from an instance of an interchange syntax, the Syntax Processing Model defined by the governing TM Application must be applied to the instance, with the output being added to the well-formed topic map graph that is under construction.


6.1.3   [parid0424] Add nodes and assertions

[parid0425] This RM4TM does not constrain any other aspects of the original construction of a well-formed topic map graph.

Note 46: 

[parid0426] The well-formed topic map graph can be interactively constructed, or constructed from sources that are not instances of interchange syntaxes of TM Applications, or in any other way.


Note 47: 

[parid0427] Any notation or schema for any kind of information can have a TM Application built around it, so that, in effect, it becomes a topic map interchange syntax.



6.2   [parid0476] Validate assertion instances for conformance to definitions

[parid0477] All of the assertions must be validated for conformance to the definitions of their assertion types specified by their governing TM Applications. (See 5.2.5.)


6.3   [parid0428] Assign values to properties of nodes

[parid0429] All of the nodes that appear in situations that have situation features that are defined by any of the governing TM Applications as demanding that values be conferred upon their SIDPs must be discovered, and the appropriate values must be calculated and assigned to the designated SIDPs, as specified by the definition of the TM Application.

Note 48: 

[parid0993] Depending on the definition of the TM Application, it is possible that, during the course of this iterative (see 6.6) merging process, some conferred property values will be "erased" altogether, that is, that some properties that had exhibited values will no longer exhibit values. Other conferred property values may change, while still others will remain unchanged. This "assign values to properties of nodes" step (6.3) at least theoretically involves recalculating all the conferred property values of each node, so that they accurately reflect the node's present situation. However, built-in property values are never affected (see 4.7.1).



6.4   [parid0431] Validate the values of the SIDPs of nodes

[parid0432] Each SIDP value of each node must be examined individually, to see whether it conforms to the constraints defined for it by the definition of its governing TM Application. Any values that are not of the defined type (see 5.2.2.2), or that do not conform to other constraints defined for them by the governing TM Application (see 5.2.2.3), must be detected and reported as Reportable Topic Map Processing errors.

[parid0433] For each node, and for each TM Application that governs it, all of the property values governed by that TM Application, including properties defined in "borrowed" TM Applications, must be examined for consistency with each other, as such consistency is defined by the governing TM Application (see 5.2.6). If there are any inconsistencies among the values of its SIDPs, they must be reported as Reportable Topic Map Processing Errors.

[parid0434] If any errors are reported, the conditions that required the report must be changed in such a way as to rectify the problem, and the merging process must (at least theoretically, for purposes of this RM4TM's definition of the merging process in terms of its required results) be restarted at the step described in 6.2.


6.5   [parid0435] Merge nodes according to the defined merging rules

[parid0436] The values of the subject identity discrimination properties (SIDPs) of each pair of nodes must be compared, and the merging rules defined by each of the governing TM Applications must be used to determine whether the two nodes should be merged. When a rule indicates that the nodes should be merged, they must be merged in accordance with 4.3.3.

[parid0438] Assertions that represent the same relationships must always be merged in accordance with 5.2.8.2.


6.6   [parid0439] Conditionally stop or repeat

[parid0440] If any nodes were merged in the steps described in 6.5, then the steps described in 6.3, 6.4, and 6.5 must be repeated. When this same sequence of steps has been repeated and no merging occurs in the step described in 6.5, the topic map graph has been fully merged, and processing must stop.


7   [parid0443] Conformance

7.1   [parid0444] Conforming TM Applications

[parid0461] Topic Maps Applications must not claim conformance to this RM4TM if their designs are inconsistent, in any way, with the constraints imposed by this RM4TM on the designs of conforming Topic Maps Applications.

[parid0464] Each TM Application must have a conforming Topic Map Application Definition (see 7.2).


7.2   [parid0445] Conforming TM Application definitions

[parid0462] Each conforming Topic Map Application Definition must include comprehensive and explicit definitions of all of the components of Topic Maps Applications, as specified by this RM4TM.

Note 49: 

[parid0465] If the design (ontology) of a TM Application permits the subjects of nodes to be conferred upon them by assertions that connect these nodes to pieces of addressable information that are regarded as their "subject indicators" (the Standard Application is an example of such a TM Application), then it seems only natural to make the components of the TM Application's design document(s) that define the TM Application's assertion types and role types conveniently addressable, and to make the addresses of these components the built-in values of the appropriate SIDPs of some of the built-in nodes defined by the TM Application. In this way, the topic maps governed by the TM Application can be authoritatively self-documenting with respect to their assertion types and role types.



7.3   [parid0446] Conforming implementations of TM Applications

[parid0925] The behaviors of conforming implementations must be consistent with all of the behavioral constraints imposed on them by this RM4TM and by the TM Application definitions they claim to implement.

[parid0447] Implementations must report Reportable Topic Map Processing Errors when they encounter assertion types, role types, or properties that are not defined by their governing TM Applications, or for which they cannot perform the property value calculations, and when they cannot apply the property value calculations or merging rules required by those definitions.


7.4   [parid0448] Conforming interchangeable topic maps

[parid0933] Conforming interchangeable topic maps conform in all respects to the syntactic and semantic constraints imposed by the definitions of the TM Applications that govern them.

[parid0463] When interpreted in accordance with their governing TM Applications, conforming topic maps yield topic map graphs in which all subjects are represented as nodes, in which no node is treated as having, or apparently has, more or less than a single subject, and in which the Subject Location Uniqueness Objective is honored, i.e., in which no two nodes represent the same subject.


Annex A   [parid0951] Brief informal overview (informative)

A.1   [parid2007] The structure of topic spaces: topic map graphs

[parid2008] Every topic map defines a multidimensional "topic space" -- a space in which the only locations are topics, and in which the distances between topics are measurable in terms of the number of intervening topics which must be visited in order to get from one topic to another, and the kinds of relationships that define the path from one topic to another, if any, through the intervening topics, if any.

[parid2009] This RM4TM describes the abstract structure of topic spaces, which it calls "topic map graphs". It allows Topic Map Applications to be described in terms of this abstract structure. All topic maps, regardless of the diversity of their ontologies, interchange syntaxes, subject discrimination rules, implementation interfaces, etc., can be understood in terms of this common abstraction.


A.2   [parid2010] One subject per node; one node per subject

[parid2011] In all topic maps, every topic represents a single subject. In the topic space represented by a topic map, every location (in Greek, every topos) represents exactly one subject; this is the case in the "well-formed topic map graph" abstraction defined by this RM4TM. In a "fully merged topic map graph," the Subject Location Uniqueness Objective has been achieved; every subject has a single location. This RM4TM specifies the process whereby a fully merged topic map graph is constructed from well-formed topic map graph.

[parid0953] Well-formed topic map graphs consist of subgraphs, called "assertions," that represent relationships between subjects. (See Annex B for a very brief introduction to assertions.)


A.3   [parid2012] All subjects are represented by nodes

[parid2013] Even though every interchangeable topic map is a map of a topic space, there is a key difference between an interchangeable topic map and the topic map graph that it represents: in a topic map graph, every subject, in order to exist in the topic space, must be represented as a node. By contrast, in an interchangeable topic map, some subjects are not explicitly represented by syntactic constructs. Instead, these subjects are present only by virtue of the implicit semantics that are built into the syntax, as defined by the Topic Map Application that governs that syntax.

[parid2014] In order to eliminate ambiguity as to the contents of the topic spaces they represent, this RM4TM requires the definitions of conforming Topic Map Applications to define "Syntax Processing Models" for their topic map interchange syntaxes. A Syntax Processing Model for a topic map interchange syntax constrains the construction of topic map graphs such that all subjects that participate, implicitly or explicitly, in instances of that syntax are explicitly represented in the topic map graph by nodes.


A.4   [parid2912] Nodes have properties

[parid2913] The subjects (and all other characteristics) of nodes are expressed by the values of their properties. The properties, their value types, and the rules for conferring values on the properties are all defined by TM Applications. The rules for conferring property values are expressed in terms of the relationships in which the node participates in the graph.

[parid2914] The values of the properties of nodes are used to determine whether they represent the same subjects. The rules for comparing property values, in order to make this determination, are defined by TM Applications. These rules are applied when a fully merged topic map graph is constructed from well-formed topic map graph. Thus, there is a sense in which the property values are determined by the graph structure, and a different sense in which the graph structure is determined by the property values; the merging process iteratively applies the two senses in sequence until no further merging occurs.


Annex B   [parid0488] Assertion diagrams (informative)

Figure 1:

[parid0467] This diagram shows an instance of an assertion. Each of the eight participating subjects is shown as a black dot, and each arc is shown as a colored stripe, each end of which is labeled with an endpoint type name. For example, on the left, a Cx arc appears with its x endpoint on the left end, and its C endpoint on the right end. The subject of this assertion is the idea that George (the "role player" on the left) has an MD degree from Harvard (the "role player" on the right). It is a relationship between George and Harvard in which Harvard plays the role of a degree-conferring institution (the "institution" role type), and George plays the role of the person upon whom the degree is conferred (the "MD degree holder" role type). The assertion is an instance of a "medical qualification" assertion type.

diagram of 2-role assertion with 'George has an MD degree from Harvard' semantics

[parid0990] In addition to the six different subjects already discussed, there are still two more, each of which is shown as a black dot where the C endpoints of three different arcs converge; these are called "casting" nodes. The subject of the left-hand casting node is the fact that George plays the "MD degree holder" role in this particular assertion. The subject of the right-hand casting node is the fact that Harvard plays the "institution" role in this particular assertion. Every assertion asserts a relationship among its role players, which are always and only found at the x endpoints of Cx arcs. Every node (here, every black dot) can play any number of roles in any number of assertions. In the very small, single-assertion topic map graph depicted here, there are only two role players (George and Harvard), and each of them plays only one role in one assertion.

Figure 2:

[parid0466] This diagram shows the structure of all assertions that have a specified assertion type, two role types, and two role players. The structure of a 2-role, 2-role-player assertion with an unspecified assertion type is the same, except that the AT arc and the t-node are not present. The structure of a 2-role, 1-role-player assertion is the same except that one of the Cx arcs, and the node at its x endpoint, are not present. Assertions that have more than two role types have the same structure, except that for each additional role type, there is an additional AC arc, an additional c-node, an additional CR arc, an additional r-node, and possibly an additional Cx arc with a role player node serving as its x endpoint.

diagram of 2-role assertion without semantics


Annex C   [parid0926] Sample properties that reflect assertion structure (informative)

[parid0327] The following list of property definitions is intended to illustrate how the internal structure of assertions could be reflected in a set of property definitions within the definition of a TM Application.

Editor's Note 4: 

[parid0919] Consider: should there be a DTD for TM Application Definitions? If so, should it be normative or informative?

Editor's Note 5: 

[parid0920] Consider: How often will TM Applications borrow the definitions provided here (or definitions like them)? If we anticipate that they are going to be borrowed, should we present these definitions as a normative TM Application? Should the SAM define them as a separate TM Application module so that they can be borrowed by TM Applications that don't want to borrow the entire SAM? If the SAM defines them (or something like them), should they appear in the RM at all, even informatively?

[parid0937] On the other hand, maybe the SAM won't include such a comprehensive set of properties for reflecting the structure of assertions, with full traversibility of all the arc types. In that case, does it make more sense for these definitions to appear in the RM, as they do here?

[parid0934]
    * Properties for which only a-nodes can exhibit
      values:

        Name: roleCastings
        Value type: node set
        Constraints on values: Only a-nodes exhibit values for this
          property, and all a-nodes must exhibit a value for this property.
          The value must be a set of c-nodes.
        SIDP or OP?: SIDP
        Semantics: The value is the node set which is the set of c-nodes
          that serve as the C endpoints of the set of AC arcs of which the
          a-node serves as the A endpoint.

        Name: assertionType
        Value type: node
        Constraints on values: Only a-nodes exhibit values for this
          property.  The value must be a t-node.
        SIDP or OP?: SIDP
        Semantics: The value is the node, if any, that serves as the T
          endpoint of the AT arc of which the a-node serves as the A
          endpoint.  If no value is exhibited, the assertion type of the
          assertion of which the a-node serves as the nexus is unspecified.

        Name: roleTypes
        Value type: node set
        Constraints on values: Only a-nodes exhibit values for this
          property.  The value must be a set of r-nodes.
        SIDP or OP?: OP
        Semantics: The value is the node set which is the set of r-nodes
          that serve as the R endpoints of the set of RC arcs of which the
          set of c-nodes serve as the C endpoints, which set of c-nodes
          serve as the C endpoints of the set of AC arcs of which the
          a-node serves as the A endpoint.

        Name: players
        Value type: node set

        Constraints on values: Only a-nodes exhibit values for this
          property.  (There are no other constraints; any nodes can be
          members of the node set.)
        SIDP or OP?: OP
        Semantics: The value is the node set which is the set of nodes that
          serve as the x endpoints of the set of Cx arcs of which the set
          of c-nodes serve as the C endpoints, which set of c-nodes serve
          as the C endpoints of the set of AC arcs of which the a-node
          serves as the A endpoint.

    * Properties for which only c-nodes can exhibit
      values:

        Name: rolePlayer
        Value type: node

        Constraints on values: Only c-nodes exhibit values for this
          property.  There are no other constraints; any node can be the
          value.
        SIDP or OP?: SIDP
        Semantics: This property may or may not exhibit a value.  If it
          does, the value is the node, if any, that serves as the x
          endpoint of the Cx arc of which the c-node serves as the C
          endpoint.

        Name: roleType
        Value type: node
        Constraints on values: Only c-nodes exhibit values for this
          property, and all c-nodes must exhibit a value for this property.
          The value must be an r-node.
        SIDP or OP?: SIDP
        Semantics: The value is the node that serves as the R endpoint of
          the CR arc of which the c-node serves as the C endpoint.

        Name: assertion
        Value type: node
        Constraints on values: Only c-nodes exhibit values for this
          property, and all c-nodes must exhibit a value for this property.
          The value must be an a-node.
        SIDP or OP?: SIDP
        Semantics: The value is the node that serves as the A endpoint of
          the AC arc of which the c-node serves as the C endpoint.

    * Properties for which only r-nodes can exhibit
      values:

        Name: castingsOfRole
        Value type: node set

        Constraints on values: Only r-nodes exhibit values for this
          property.  All members of the node set must be c-nodes.
        SIDP or OP?: OP
        Semantics: The value is the node set which is the set of c-nodes
          that serve as the C endpoints of the set of CR arcs of which the
          r-node serves as the R endpoint.

    * Properties for which only t-nodes can exhibit
      values:

        Name: assertionsOfType
        Value type: node set

        Constraints on values: Only t-nodes exhibit values for this
          property, and all t-nodes must (by definition) exhibit a value
          for this property.  All members of the node set must be a-nodes.
        SIDP or OP?: OP
        Semantics: The value is the node set which is the set of a-nodes
          that serve as the A endpoints of the set of AT arcs of which the
          t-node serves as the T endpoint.

    * Properties for which all kinds of nodes
      (including but not limited to a-nodes, c-nodes,
      r-nodes, and t-nodes) can exhibit values:

        Name: rolePlayings
        Value type: node set
        Constraints on values: All nodes in the set must be c-nodes.
        SIDP or OP?: OP
        Semantics: The node set whose members are the c-nodes at the C
          endpoints of the Cx arcs whose x endpoints are the node.  If no
          value is exhibited, then the node plays no roles in any
          assertions.

    * Properties for which only a-nodes, c-nodes,
      r-nodes, and t-nodes can exhibit values:

        Name: nodeType
        Value type: enumeration
        Constraints on values: Value must be one of "assertion", "casting",
          "roleType", or "assertionType"
        SIDP or OP?: SIDP
        Semantics: Exhibits a corresponding value ("assertion", "casting",
          "roleType", or "assertionType") when the node is an a-node,
          c-node, r-node or t-node.  When it exhibits no value, the node is
          neither an a-node, nor a c-node, nor an r-node, nor a t-node.