[sc34wg3] RM: Comments on Topic Map Graphs

Tue, 25 Feb 2003 17:04:28 -0500

Greetings!

Another batch of comments on the RM! All of these comments relate to the 
topic map graph section. I hope to complete comments on Properties of 
Nodes tomorrow and hopefully TM Applications by the end of the week.

Hope this finds everyone in good health and spirits!

Patrick

REF: parid0023

TXT: The common structural abstraction for topic maps

FIX: (Strike)

COM: Introductory paragraph, requires no title.

END

REF: parid0024

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

FIX: The topic map graph (TMG) is a structure into which any topic map 
can be interpreted, without regard to its governing TM Application or 
the syntax in which it is represented. A TMG represents all the 
subjects, whether expressed or implied, in a given topic map. This 
section defines the rules to be followed in constructing a TMG for a 
topic map.

COM: Cribbed an earlier suggested revision for the last line. 
(parid0484) With deletion of parid0900 and parid0484, plus rewrite of 
parid0024, 60 words versus 160 in original.

END

REF: parid0900

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

FIX: (strike)

COM: Incorporated into parid0024, note further that the topic map graph 
is not limited to topic maps held in an interchangeable syntax.

END

REF: parid0484

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

FIX: (strike)

COM: Incorporated into parid0024.

END

REF: parid0025

TXT: Topic map graphs consist of nodes and arcs.

FIX: Components of topic map graphs

COM: Revised title to not repeat the content

END

REF: parid0026

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

FIX: A topic map graph is composed of nodes, edges and arcs.

COM: Even if well-formedness is retained, inappropriate here. Define 
each thing once and only when/where appropriate.

END

REF: parid0932

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

FIX: (Strike.)

COM: If there is no data structure implied, let's just say that, full 
stop. Besides, this should be in the TM Application section, reason for 
the strike. Suggested new language at appropriate location: The topic 
map graph does imply any data structure for TM Applications. The 
requirements for a TM Application may be meet using any data structure 
that the TM Application implementer deems appropriate.

END

REF: parid0506

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

FIX: An "arc" in a topic map graph has two different nodes as its 
endpoints and together, the endpoints form two of the arc names set 
forth in parid0077.

COM: Removed the connectedness and collapsed the requirements into one 
sentence.

END

REF: parid0509

TXT: A node that serves as the endpoints of no arcs at all is not 
well-formed unless it exhibits at least one built-in SIDP value.

FIX: A node that serves as the endpoint of no arc at all must exhibit at 
least one a priori SIDP value.

COM: Singular works as well as plural. Changed built-in to a priori. 
Dropped well-formed as a node, arc or whatever, either complies with the 
standard or not. Adding the well-formed language is just excess verbage 
to say that a node, in this case, must comply with the standard.

END

REF: parid0502

TXT: 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 
[parid0220] 4) can be isolated.

FIX: (Strike)

COM: Isolated node has already been defined. Is there some reason why a 
TM Application could not authorize non a priori (formerly built-in) 
nodes to be isolated?

END

REF: parid0503

TXT: 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].)

FIX: The situation of a node is defined as its service as the endpoint 
of all the paths accessible from that node.

COM: Note that all nodes are situated. The isolated node is situated, it 
just does not have any paths to follow so all its situation is limited 
to properties it bears itself. Path is defined in the glossary and 
should not be repeated here.

END

REF: parid0504

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

FIX: Except for the a priori values of properties of a priori nodes, all 
of the values of properties of nodes are determined by their situations.

COM: Changed to use a priori language, deleted last sentence as repetition.

END

REF: parid0928

TXT: Except for the restrictions on the subjects of nodes that have 
special functions within assertion subgraphs (see [parid0185] 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 [parid0253] 
4.7.2.2).

FIX: Except for the subjects of a-nodes and r-nodes in an assertion, TM 
Applications may define "situation features" that affect any property 
(SIDP or OP) of a node in that situation.

COM: Since the subjects that cannot be changed are known, simpler just 
to state them. Likewise, if it is "any property" that can be affected by 
a situation feature, just state that as well.

END

REF: parid0505

TXT: The situation of a node in a topic map graph is always and only as 
visible as the values of its properties make it.

FIX: (question)

COM: What does this mean? It is the only reference to a node's situation 
being visible. No mention in clause 4.

END

REF: parid0904

TXT: 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 [parid0185] 3.6.2.2).

FIX: (strike)

COM: The scope of situation features has already been defined. If 
non-normative tutorial material is planned, that is where this sort of 
expansion would be appropriate.

END

REF: parid0080 parid0081 parid0082 parid0083 parid0084 parid0085 
parid0086 parid0087 parid0088 parid0089 parid0090 parid0091 parid0092 
parid0093 parid0094 parid0095 parid0096 parid0097 parid0098 parid0099 
parid0100 parid0101 parid0102 parid0103 parid0104 parid0105 parid0106 
parid0107 parid0108 parid0109 parid0113 parid0114 parid0115 parid0116 
parid0117 parid0118 parid0119 parid0120 parid0121 parid0914 parid0122 
parid0123 parid0124 parid0125 parid0126 parid0127 parid0128 parid0129 
parid0130 parid0131 parid0132 parid0133 parid0134 parid0135 parid0136 
parid0137 parid0138 parid0139 parid0140 parid0141 parid0142 parid0143 
parid0144 parid0145 parid0146

TXT: (all)

FIX: (Strike)

COM: All allowable nodes are defined in the glossary. Properties of 
Nodes, parid0220 and following is the proper place to cover node 
properties and should be the only place where such properties are 
treated. Definitions, properties, behavior should be explained once and 
only once, with later usages making reference to that single place in 
the standard where the one definitive statement can be found. Otherwise 
we risk creating ambiguity and having users chasing over the standard to 
find all the information on a particular concept.

END

REF: parid0455

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

FIX: Assertions are subgraphs of topic map graphs.

COM: Removed references to well-formed topic map graph. This section 
treats assertions and statements about the topic map graph in general 
are inappropriate. Similarly, the requirement that "every arc" be a 
specific component of a single assertion should occur under arcs, not here.

END

REF: parid0489

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

FIX: Each assertion represents (asserts the existence of) a single 
relationship among the subjects that are its "role players."

COM: Removed strongly-typed. Subjects, such as role players, role should 
be covered separately. The type of relationship of which the 
relationship is an instance should be made by a separate assertion, 
which itself would be a subject, since all assertions may be subjects.

END

REF: new

TXT: The relationship represented by an assertion is a subject.

FIX: (add)

COM: derived from parid0489, stated to make all the subjects in an 
assertion, including the assertion itself, clear.
END

REF: new

TXT: Each role player in an assertion is a subject.

FIX: (add)

COM: Separated out the idea of role player as a subject. From parid0489

END

REF: new

TXT: Every role player plays a specific role in an assertion.

FIX: (add)

COM: Separated out the function of a role player in an assertion. From 
parid0489

END

REF: new

TXT: The roles in an assertion are themselves subjects.

FIX: (add)

COM: Separated out the idea of roles in an assertion as subjects. From 
parid0489

END

REF: parid0207

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

FIX: (Strike)

COM: In defining the properties of assertions it is inappropriate to 
discuss the "why" of the design of assertions.

END

REF: parid2915

TXT: each of the original topic map graphs is a subgraph of the result, and

FIX: (Strike)

COM: Discussing properties of assertions, not the operation of merger.

END

REF: parid2916

TXT: each such subgraph is structurally identical to the corresponding 
original, even when one of them makes assertions about assertions in the 
other, about which the other made no assertions. Thus, the integrity of 
the original topic map graphs is maintained as subgraphs of the result.

FIX: (Strike)

COM: Should be treated under operations on topic map graphs.

END

REF: parid0209

TXT: 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").

FIX: (Strike)

COM:  Need to revisit definition of arc to say that it is an unreified 
attribution of roles in an assertion. Thus, both arcs and edges in an 
assertion are unreified, versus reified aspects.

END

REF: parid0172

TXT: Inventory of the components of assertions

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0174

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

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0175

TXT: Inventory of the arcs in an assertion

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0176

TXT: The inventory of arcs that an assertion may have are defined in the 
subclauses that follow.

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0177]

TXT: One or zero AT arcs

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0178

TXT: The assertion type of an assertion may be specified or unspecified.

FIX: (Strike)

COM: see Rules for Assertions

REF: parid0179

TXT: Two or more AC arcs

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0180

TXT: In every assertion, there must be at least two role types, and 
therefore there must be at least two casting nodes.

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0181

TXT: Exactly as many RC arcs as there are AC arcs

FIX: (strike)

COM: see Rules for Assertions

END

REF: parid0182

TXT: Every casting node must have a role type, as well as belong to a 
single assertion.

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0183

TXT: At least one Cx arc

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0184

TXT: Every assertion must have at least one role player.

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0185

TXT: Inventory of the nodes in an assertion

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0186

TXT: Nodes whose subjects are never dependent on their situation with 
respect to a given assertion:

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0187

TXT: Assertion type nodes (t-nodes; i.e., T endpoints of AT arcs)

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0188

TXT: Role type nodes (r-nodes; i.e., R endpoints of CR arcs)

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0189

TXT: Nodes whose subjects are always dependent on their situation with 
respect to a given assertion:

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0190

TXT: Assertion nodes (a-nodes; i.e., A endpoints of AT and AC arcs)

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0191

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

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0192

TXT: Casting nodes (c-nodes; i.e., C endpoints of AC, CR, and Cx arcs)

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0193

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

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0194]

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

FIX: (Strike)

COM: We are still in the inventory of nodes in an assertion. This is 
misplaced (at best).

END

REF: parid0195

TXT: 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 [parid0928] 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.

FIX: (Strike)

COM: Misplaced, this is still inventory of nodes.

END

REF: parid0980

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

FIX: (Strike)

COM: Misplaced, this is still inventory of nodes.

END

REF: new

TXT: Edges in an assertion

FIX: (add)

COM: new section on inventory of edges in an assertion

END

REF: new

TXT: Between every two nodes that serve as the endpoints of arcs in an 
assertion, there exists an edge.

FIX: (add)

COM: new section stating the occurrence of edges in an assertion. note 
that there are NOT edges between every two nodes but only between those 
that are the endpoints of two arcs (the arc and its mirror case)

END

REF: parid0196

TXT: What's in and what's not in an assertion

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0197 parid0198 parid0199 parid0200 parid0201 parid0202 
parid0203 parid0204 parid0205

TXT: (all)

FIX: (Strike)

COM: see Rules for Assertions

END

REF: new

TXT: Rules for Assertions

FIX: (add)

COM: New section following the inventory of arcs, nodes and edges that 
sets forth the rules for assertions.

END

REF: new

TXT: Every assertion has one and only one a-node. cf. parid0191

FIX: (add)

COM: New sub-section under Rules for Assertions stating that assertion 
has only one a-node.

END

REF: new

TXT: Every assertion may have one t-node.

FIX: (add)

COM: New sub-section under Rules for Assertions stating that an 
assertion may have one t-node. parid0178

END

REF: new

TXT: If an assertion has a t-node, then it has a AT-arc and a TA-arc 
with the a-node and t-node as endpoints.

FIX: (add)

COM: New sub-section under Rules for Assertions stating the arcs that 
are present if a t-node exists in the assertion. cf. parid0177

END

REF: new

TXT: Every assertion must have at least two c-nodes.

FIX: (add)

COM: New sub-section under Rules for Assertions stating that an 
assertion must have at least two c-nodes. Note that I have not seen a 
answer to Bernard Valant's question about why two or more AC arcs? 
Posted 16 November 2002, Bernard asks: "Why "two or more"? There are 
many cases of assertions with a single role type (take "sibling" for 
example)" Is this a symptom of conflating instances and classes? cf. my 
comments on role type in parid2260. (on this rule, cf. parid0180)

END

REF: new

TXT: Every assertion must have an AC-arc and CA-arc for each c-node in 
the assertion.

FIX: (add)

COM: New sub-section under Rules for Assertions stating the arcs that 
must be present between the a-node and c-nodes in an assertion. cf. 
parid0179

END

REF: new

TXT: Note: In a minimum assertion, there exist two (2) AC-arcs and two 
(2) CA-arcs between the a-node and the minimum required c-nodes. cf. 
parid0180

FIX: (add)

COM: Note (for immediately preceding REF) to clarify any lingering doubt 
about the arcs that are present in a minimal assertion. Not really 
necessary but notes rarely are. ;-)

END

REF: new

TXT: Every assertion must have a unique r-node for each c-node.

FIX: (add)

COM: New sub-section under Rules for Assertions stating that an r-node 
must exist for every c-node in an assertion. cf. parid0182

END

REF: new

TXT: Note: The requirement of a unique r-node is to make it explicit 
that c-nodes can never share an r-node via CR-arcs.

FIX: (add)

COM: add as note to preceeding new entry.

END

REF: new

TXT: Every assertion must have an CR-arc and RC-arc for each c-node in 
the assertion.

FIX: (add)

COM: This is the equivalent of requiring the number of RC-arcs to match 
the number of AC-arcs, but via requiring an r-node for every c-node and 
then requiring the arcs to be present. cf. parid0181

END

REF: new

TXT: Every assertion must have at least one x-node.

FIX: (add)

COM: Sets up requirement for at least one Cx arc and to have at least 
one role player. cf. parid0184

END

REF: new

TXT: Every assertion must have at least one Cx-arc and xC-arc for at 
least one c-node.

FIX: (add)

COM: Builds on x-node requirement to require arc to role player.

END

REF: parid0494

TXT: Identity of assertions

FIX: (Strike)

COM: Out of place in rules on assertions. Should be moved to Defintion 
of TM Application or perhaps separate treatment of merger.

END

REF: parid0110

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

FIX: (strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0495

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

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0493

TXT: unless the assertion's type is unspecified, the t-node (whose 
subject is the type of relationship of which is the subject of the 
a-node is an instance) attached to the a-node by an AT arc in which the 
a-node serves as the A endpoint; and

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0491

TXT: the set of role-player castings that are the subjects of the 
c-nodes that serve as the C endpoints of the AC arcs for which the 
a-node serves as the A endpoints,

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0972

TXT: including the role player node attached to each c-node by a Cx arc 
in which the c-node serves as the C endpoint, or the lack thereof, and

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0975

TXT: including the r-node (whose subject is a role type) attached to 
each c-node by a CR arc in which the c-node serves as the C endpoint.

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0981

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

FIX: (Strike)

COM: move to TM Application or separate section on merger.

END

REF: parid0162

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

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

COM: The first sentence is redundant with the glossary. The third 
sentence appears to say that the subject of a t-node incorporates "all 
the role types that can have role players in instances of the assertion 
type," but there is only one assertion type (the t-node) so it is not 
clear what is being gathered up as "all of the role types...?"

END

REF: parid0490

TXT: 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 [parid0248] 4.7.2).

FIX: (Strike)

COM: Should be covered in discussion of SIDPs.

END

REF: parid0165

TXT:  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 [parid0227] 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 [parid0357] 5.2.5.3.2).

FIX: The semantics of an untyped assertion are determined by its role 
types, i.e., by the subjects of its r-nodes.

COM: The first sentence is redundant with the glossary. The OPs and SIDP 
issues should be dealt with elsewhere.

END

REF: parid0168

TXT: The subjects of assertion types and role types are never affected 
by their instances

FIX: (Strike)

COM: Should appear in section on SIDPs. Judging from parid0169, the 
correct word should be "situations" and not "instances"

END

REF: parid0169

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

FIX: (Strike)

COM: Should appear in section on SIDPs.

END

REF: parid0170

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

FIX: (Strike)

COM: Should appear in section on conferring of SIDP values.

END

REF: parid0171

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

FIX: (Strike)

COM: Should appear in section on conferring of OP values.

END

REF: parid0157

TXT:  No multiple role players of a single role type

FIX: (Strike)

COM: lose following paragraphs so not required.

END

REF: parid0158

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

FIX: (Strike)

COM: Node are already required to represent a single subject. So, 
multiple subjects could not play the same role in the same assertion by 
definition. Yes, roles are either played or not, not sure I need a 
section on that idea. Note use of role and not role type.

END

REF: parid0159

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

FIX: (Strike)

COM: Cover under TM Applications.

END

REF: parid0929

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

FIX: (Strike)

COM: Better to include under node properties.

END

REF: parid0155

TXT: Semantics of nodes' situations as role players

FIX: (Strike)

COM: Without the following paragraph, not required.

END

REF: parid0156

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

FIX: (Strike)

COM: I may be terribly mistake but I don't read anything here that is 
not stated elsewhere. Should not be restating things since that can 
cause confusion.

END

REF: parid0166

TXT: All role types are always represented in any assertion of a given type

FIX: (Strike)

COM: lost following paragraph, not required

END

REF: parid0167

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

FIX: (Strike)

COM: If this is a reference to the "assertion type's definition" in a 
Topic Map Application, that should go under that section.

END

REF: parid0210]

TXT: Well-formedness constraints on Assertions

FIX: (strike)

COM: Dropping well-formedness

END

REF: parid0211

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

FIX: (Strike)

COM: dropping well-formed

END

REF: parid0917

TXT:  No two role types the same; each has zero or one role player

FIX: (Strike)

COM: in Rules for Nodes.

END

REF: parid0212]

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

FIX: (Strike)

COM: covered under rules for assertions.

END

REF: parid0213

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

FIX: (Strike)

COM: covered in rules for assertions. Should be role has only one role 
player. Class characteristics should be asserted about the role by a 
separate assertion.

END

REF: parid0915]

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

FIX: (Strike)

COM: cover under TM applications

END

REF: parid0214

TXT: There must be at least one role player

FIX: (Strke)

COM: see Rules for Assertions

END

REF: parid0916

TXT: The set of arcs that are members of the set of arcs that specify 
the assertion must include at least one Cx arc.

FIX: (Strike)

COM: see Rules for Assertions

END

REF: parid0216

TXT: Well-formedness constraints on topic map graphs

FIX: (Strike)

COM: Drop well-formedness in favor of either it complies and therefor 
can merge or it does not and can't.

END

REF: parid0217

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

FIX: (Strike)

COM: Define minimal topic map graph under topic map graph, not here.

END

REF: parid0218

TXT: There is at least one node.

FIX: (Strike)