ISO/IEC JTC 1/SC34 N0344
ISO/IEC JTC 1/SC34
Information Technology --
Document Description and Processing Languages
12
November 2002
JTC
1/SC 34 N 344
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.
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.
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.
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.
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.
This RM4TM defines:
-
an abstract graph structure for the representation of
relationships between subjects;
-
rules for defining Applications of the Topic Maps paradigm;
and
-
rules for processing the information contained in topic maps.
| Note 1: |
See Annex A
for a brief informal overview of this RM4TM.
| |
| Editor's Note 1: |
(The glossary hasn't been drafted yet.)
|
| 3.1 |
The common structural
abstraction for topic maps |
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.
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.
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 |
Topic map graphs consist
of nodes and arcs. |
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: |
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.
| |
| Note 3: |
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.
| |
An "arc" in a topic map graph is a two-ended
connectedness between nodes that satisfies all of the following criteria:
-
it has two different nodes serving as its two
endpoints, and
-
it is one of the eight forms of connectedness enumerated in 3.3.3
between the nodes that serve as its two endpoints. (This necessarily means
that it is one of the four arc types enumerated in 3.3.1.)
There are four arc types, named "AT", "AC", "CR",
and "Cx". The significance of each type of arc is different.
| 3.3.2 |
Names of arc types and arc
endpoint types |
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: |
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 |
Eight forms of
connectedness are possible |
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.
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.
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.)
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.
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.)
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.
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.)
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.
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: |
The above list of Forms of
Connectedness can be represented in tabular form as follows:
|
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: |
The above enumeration of the Forms of
Connectedness serves two purposes in this RM4TM:
-
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.
-
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.1 |
One subject for each node
|
In topic map graphs, only nodes can represent
subjects, and every node represents a single subject.
| 3.4.2 |
Situations and
subjects |
A node serves as one endpoint of zero or more arcs.
| Note 7: |
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.)
| |
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.
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].)
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.
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: |
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: |
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.1 |
Six cases of well-formed
nodes |
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.1 |
Defining Characteristics
of Case 1 nodes |
| 3.5.1.1.1.2 |
The node has at least one
built-in SIDP value (see Clause 4).
|
Case 1 nodes do not have a node type name.
The subjects of Case 1 nodes are not constrained by
this RM4TM.
| 3.5.1.2.1 |
Defining characteristics
of Case 2 nodes |
| 3.5.1.2.1.1 |
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 |
The node does not serve as
any other endpoint type of any instance of any arc type.
|
| 3.5.1.2.1.3 |
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. |
Case 2 nodes do not have a node type name.
The subjects of Case 2 nodes are not constrained by
this RM4TM.
| 3.5.1.3 |
Well-formed node Case 3
("a-node") |
| 3.5.1.3.1 |
Defining characteristics
of Case 3 nodes |
| 3.5.1.3.1.1 |
The node serves as zero or
more of the x endpoints of any number of Cx arcs.
|
| 3.5.1.3.1.2 |
The node serves as the A
endpoint of two or more AC arcs. |
| 3.5.1.3.1.3 |
The node may or may not serve
as the A endpoint of one AT arc. |
| 3.5.1.3.1.4 |
The node does not serve as
any other endpoint of any instance of any arc type.
|
A Case 3 node is called an "a-node" (where "a"
stands for "assertion").
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 |
Well-formed node Case 4
("c-node") |
| 3.5.1.4.1 |
Defining characteristics
of Case 4 nodes |
| 3.5.1.4.1.1 |
The node serves as zero or
more of the x endpoints of any number of Cx arcs.
|
| 3.5.1.4.1.2 |
The node serves as the C
endpoint of a single AC arc. |
| 3.5.1.4.1.3 |
The node serves as the C
endpoint of a single CR arc. |
| 3.5.1.4.1.4 |
The node may or may not serve
as the C endpoint of a single Cx arc.
|
| 3.5.1.4.1.5 |
The node does not serve as
any other endpoint of any instance of any arc type.
|
A Case 4 node is called a "c-node" (where "c"
stands for "casting").
| Note 10: |
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.
| |
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.
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 |
Well-formed node Case 5
("r-node") |
| 3.5.1.5.1 |
Defining characteristics
of Case 5 nodes |
| 3.5.1.5.1.1 |
The node serves as zero or
more of the x endpoints of any number of Cx arcs.
|
| 3.5.1.5.1.2 |
The node serves as the R
endpoint of one or more CR arcs. |
| 3.5.1.5.1.3 |
The node does not serve as
any other endpoint of any instance of any arc type.
|
A Case 5 node is called an "r-node" (where "r"
stands for "role type").
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.1 |
Defining characteristics
of Case 6 nodes ("t-node") |
| 3.5.1.6.1.1 |
The node serves as zero or
more of the x endpoints of any number of Cx arcs.
|
| 3.5.1.6.1.2 |
The node serves as the T
endpoint of one or more AT arcs. |
| 3.5.1.6.1.3 |
The node does not serve as
any other endpoint of any instance of any arc type.
|
A case 6 node is called a "t-node" (where "t"
stands for assertion "type").
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: |
The above well-formedness requirements
for nodes can be summarized in tabular form as follows:
| |
| Table 1: |
The Six Cases of Well-formed
Nodes |
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 |
| 0 |
1+ |
0 |
0 |
0 |
0 |
0 |
0 |
(none) |
(unconstrained) |
no |
| 0 |
0+ |
0 |
0 |
0 |
2+ |
0 |
1? |
"a-node" |
assertion |
no |
| 0 |
0+ |
1? |
0 |
1 |
1 |
0 |
0 |
"c-node" |
casting |
no |
| 0 |
0+ |
0 |
1+ |
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.1 |
Introduction to assertions
|
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).
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.
The design of assertions in this RM4TM enables
diverse multiple topic map graphs to be amalgamated into a single topic map
graph, such that:
-
each of the original topic map graphs is a subgraph of the
result, and
-
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.
| Note 12: |
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 |
Inventory of the
components of assertions |
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 |
Inventory of the arcs in
an assertion |
The inventory of arcs that an assertion may have
are defined in the subclauses that follow.
| Note 13: |
The assertion type of an assertion may
be specified or unspecified.
| |
| Note 14: |
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 |
Exactly as many RC arcs as
there are AC arcs |
| Note 15: |
Every casting node must have a role
type, as well as belong to a single assertion.
| |
| Note 16: |
Every assertion must have at least one
role player.
| |
| 3.6.2.2 |
Inventory of the nodes in
an assertion |
| 3.6.2.2.1 |
Nodes whose subjects are
never dependent on their situation with respect to a given assertion:
|
| 3.6.2.2.1.1 |
Assertion type nodes
(t-nodes; i.e., T endpoints of AT arcs) |
| 3.6.2.2.1.2 |
Role type nodes (r-nodes;
i.e., R endpoints of CR arcs) |
| 3.6.2.2.2 |
Nodes whose subjects are
always dependent on their situation with respect to a given assertion:
|
| 3.6.2.2.2.1 |
Assertion nodes (a-nodes;
i.e., A endpoints of AT and AC arcs) |
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 |
Casting nodes (c-nodes;
i.e., C endpoints of AC, CR, and Cx arcs)
|
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 |
Nodes whose subjects may
or may not be dependent on their situation with respect to a given
assertion (role player nodes): |
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: |
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 |
What's in and what's not
in an assertion |
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 |
All of the AC arcs of which
the given a-node serves as the A endpoint. |
| 3.6.2.3.2 |
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.4 |
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.6 |
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 |
The AT arc, if any, of which
the given a-node serves as the A end. |
| 3.6.2.3.8 |
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 |
Identity of
assertions |
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.
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:
-
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
-
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,
-
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
-
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.
| Note 18: |
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 |
Assertion
semantics |
| 3.6.4.1 |
Semantics of assertion
typing |
| 3.6.4.1.1 |
When the assertion type is
specified |
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.
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 |
When the assertion type is
not specified |
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 |
The subjects of assertion
types and role types are never affected by their instances
|
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: |
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: |
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.1 |
No multiple role players
of a single role type |
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: |
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.
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 |
Semantics of nodes'
situations as role players |
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 |
All role types are always
represented in any assertion of a given
type |
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 |
Well-formedness
constraints on Assertions |
An assertion that does not conform to all of the
following rules is not well-formed:
| 3.7.1 |
No two role types the
same; each has zero or one role player |
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.
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: |
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 |
There must be at least one
role player |
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 |
Well-formedness
constraints on topic map graphs |
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 |
There is at least one node.
|
| 3.8.2 |
There are no arcs that do not
participate in a single well-formed assertion.
|
| 3.9 |
Well-formed and fully
merged topic map graphs |
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.
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.
A well-formed topic map graph may or may not be
fully merged, but a fully merged topic map graph is always well-formed.
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: |
The process whereby well-formed topic
map graphs are converted into fully merged topic map graphs is
defined in Clause 6.
| |
| 4.1 |
Only a common framework
for properties; no common properties |
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: |
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 |
Every property is governed
by a single TM Application |
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 |
Subject identity
discrimination properties ("SIDPs") |
| 4.3.1 |
Identical subjects must be
recognizably identical |
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 |
Subject identity is the
values of SIDPs |
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 |
The merging of
nodes |
When two nodes ("predecessor nodes") governed by a
TM Application are merged:
-
the resulting single node ("result node") serves as the union
of the two sets of arc endpoints of the two predecessor nodes,
-
the resulting single node exhibits the union of the built-in
property values, if any, of the two predecessor nodes, and
-
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: |
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 |
RM4TM constrains the SIDPs
and SIDP values of a-nodes and c-nodes |
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 |
Other properties
("OPs") |
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 |
Names of properties of
nodes |
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 2: |
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 |
Values of properties of
nodes |
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 |
Assignment of values of
properties of nodes |
The values of the properties of nodes are assigned
in two ways. They are either:
-
"built-in" or
-
"conferred".
| 4.7.1 |
Built-in values of
properties of nodes |
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.
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: |
Values can be conferred on properties
of built-in nodes that do not have built-in values.
| |
| Note 27: |
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 |
Conferred values of
properties of nodes |
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 |
Overview of requirements
governing definitions of conferred property values
|
With respect to the values conferred on the
properties of nodes, TM Applications must define:
-
the situation features of nodes that call for values to be
conferred upon the properties of such nodes,
-
the properties of such nodes to which the values are assigned,
-
the types of the property values, and
-
how the values are calculated.
| Note 28: |
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 |
Situation features that TM
Applications define as requiring values to be conferred on the properties
of nodes |
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.
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 29: |
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 30: |
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 |
SIDP values cannot be
conferred on a-nodes or c-nodes on account of their situations as role
players. |
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 |
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. |
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 |
Internal consistency of
the values of a node's SIDPs |
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 31: |
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 |
Definitions
of TM Applications |
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.