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, r