[sc34wg3] RM Section 4: Properties of Nodes - Comments
Patrick Durusau
sc34wg3@isotopicmaps.org
Wed, 26 Feb 2003 09:49:00 -0500
Greetings!
Finished comments on Section 4: Properties of Nodes. Turning to Section
5: Definitions of TM Applications. Probably will disappear for a day or
two since that section will require incorporation of material that I
have suggested moving from Sections 3 and 4. Most of it on the theory
that information about a particular issue, such as restrictions on
conferral of values should all be located in one place. May just be a
personal dislike but I find standards that send me chasing around for
all the information on a particular subject quite annoying, not to
mention difficult to use.
Hope everyone is having a great day!
Patrick
REF: parid0231
TXT: Only a common framework for properties; no common properties
FIX: (Strike)
COM: This is about the TM Application, which is defined elsewhere.
END
REF: parid0232
TXT: 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.
FIX: (Strike)
COM: This is about TM Applications, which is defined elsewhere.
END
REF: parid0918
TXT: 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.
FIX: Properties of nodes are defined only by TM Applications.
Constraints on the definitions of node properties by TM Applications are
defined by this standard.
COM: State where definitions are found and not where not found.
END
REF: parid0221
TXT: Every property is governed by a single TM Application
FIX: (??)
COM: see parid0222, is this the correct title? parid0222 covers a lot of
ground besides properties
END
REF: parid0222
TXT: 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.
FIX: (??)
COM: OK, I buy the properties, values, requirements, perhaps even
"governed" (although I think we need a better word), but why can every
node have more than one TM Application but every property only one? If I
apply my TM Application to a topic map you created with yours, changing
the way property values are handled, I may get gibberish but I don't
know how we can prevent that. For instance, I could just ignore this
section and allow my TM Application to process your topic map. Unless
there is someway to bind your topic map to a TM Application, which would
by syntax and application specific, don't see why we should try to
prevent this.
END
REF: parid0223
TXT: Subject identity discrimination properties ("SIDPs")
FIX: Subject discrimination properties ("SDPs")
COM: Since the SDPs may or may not relate to the identity of a subject,
such as a name, but may in toto be taken to distinguish one subject from
another, do we need the identity baggage?
END
REF: parid0224
TXT: 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.
FIX: The fact that two nodes have the same subject must be detectable in
order to trigger the merging operations. Subject identity is determined
on the basis of all the SDPs values possesed by a node.
COM: Recall, defining properties of nodes and not how they acquire them
at this point.
END
REF: new
TXT: Note: SDPs are set by the governing TM Application, which is
required to specify at least one SDP for every node. See, Defining TM
Applications.
REF: parid0961
TXT: Subject identity is the values of SIDPs
FIX: (Strike)
COM: title has nothing to do with the following paragraph
END
REF: parid0225
TXT: 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.
FIX: (Strike)
COM: Should be moved to section on TM Applications
END
REF: parid0962
TXT: The merging of nodes
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0497
TXT: When two nodes ("predecessor nodes") governed by a TM Application
are merged:
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0930
TXT: the resulting single node ("result node") serves as the union of
the two sets of arc endpoints of the two predecessor nodes,
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0931
TXT: the resulting single node exhibits the union of the built-in
property values, if any, of the two predecessor nodes, and
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0923
TXT: 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.
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0373
TXT: 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.
FIX: (Strike)
COM: Move to section on merger or under such a section in TM Applications
END
REF: parid0233
TXT: 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.
FIX: The subjects of a-nodes and c-nodes are defined by this RM4TM.
Subjects so defined may not be altered in any way or fail to be used by
TM Applications.
COM: Perhaps close but I thing where a subject is defined is a property
of a node. Note that I removed "how" it was defined, which is a separate
issue, and one that has already been answered.
END
REF: parid0228
TXT: 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.
FIX: (Strike)
COM: Move to section in TM Applications
END
REF: new
TXT: Nodes may possess other properties whose values are not use for
subject discrimination purposes; such properties are called "OPs" (other
properties). OPs, their values and/or their calculation or assignment
are constrained only by TM Applications.
FIX: (add)
COM: Re-write of parid0228 to make it a definition of OPs within the RM.
END
REF: parid0235
TXT: 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 REF: parid0442 Ed.Note 55 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.
FIX: (Strike)
COM: Move to TM Application definition. Question: Do we really want to
get into syntax issues, such as the fields and field separators? Could
simply say it must be distinguishable and let it go at that.
END
REF: new
TXT: Every property of a node is required to have a name.
FIX: (add)
COM: Extracting requirement of properties having names.
END
REF: new
TXT: The name of a property must be distinguishable from all other
property, assertion type, role and node names.
FIX: (add)
COM: Fixing distinguishable name requirement for nodes. Perhaps should
be made more general for nodes, roles, etc.
END
REF: parid0442
TXT: 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:".
FIX: (Strike)
COM: Should not be dealing with syntax, must be distinguishable anything
further must be defined by the TM Application.
END
REF: parid0469
TXT: "built-in" or
FIX: "predefined" or
COM: ok, let's try Martin Bryan's suggestion of predefined to see how it
fits
END
REF: parid0242
TXT: Built-in values of properties of nodes
FIX: Predefined values of node properties
COM: replaced Built-in with predefined
END
REF: parid0243
TXT: 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.
FIX: (Strike)
COM: discuss TM Applications in TM Applications
END
REF: parid0245
TXT: 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.
FIX: Predefined property values of a node cannot be altered by its
situation in the TM graph.
COM: Removed "TM Processing Error" as that is not defined, and, should
be covered under conformance.
END
REF: parid0992
TXT: Conferred property values can be changed or "erased" when, after
the topic map graph has been altered, conferred property values are
recalculated, and a node's situation no longer requires one of its
properties to have the value that had been conferred upon it on account
of its previous situation (see REF: parid0429 6.3). By contrast, as
specified in REF: parid0245 4.7.1 (above), built-in values cannot be
changed or erased.
FIX: (Strike)
COM: should be treated under definition of conferred values, perhaps
even so far as to state that since the value is conferred by a
situation, then if the situation changes, the value may, or may not change
END
REF: parid0246
TXT: Values can be conferred on properties of built-in nodes that do
not have built-in values.
FIX: Values can be conferred on properties of predefined nodes that do
not have predefined values.
COM: Testing Martin's "predefined" language
END
REF: parid0247
TXT: 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.
FIX: (Strike)
COM: This is all TM Application stuff and should be reported in that
location.
END
REF: parid0249
TXT: 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.
FIX: (Strike)
COM: repetition of definition in glossary
END
REF: parid0250
TXT: Overview of requirements governing definitions of conferred
property values
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0251
TXT: With respect to the values conferred on the properties of nodes,
TM Applications must define:
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0471
TXT: the situation features of nodes that call for values to be
conferred upon the properties of such nodes,
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0472
TXT: the properties of such nodes to which the values are assigned,
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0473
TXT: the types of the property values, and
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0474
TXT: how the values are calculated.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0252
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0253
TXT: Situation features that TM Applications define as requiring values
to be conferred on the properties of nodes
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0254
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0255
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0257
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0259
TXT: 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 REF: parid0233 4.3.4).
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0260
TXT: SIDP values cannot be conferred on a-nodes or c-nodes on account
of their situations as role players.
FIX: A SIDP value cannot be conferred on any node that has a role as an
a-node or c-node in any assertion by its situation as a role player in
another assertion.
COM: Trying to make two things clear: 1) nodes have roles in assertions,
i.e., a node may be an a-node in one assertion and yet a x-node in
another, 2) that the determination of whether a SIDP value can be
conferred requires determination of the roles a node plays in all
assertions. The latter is not a question for processing of topic maps
but in the design of the TM Application.
END
REF: parid0261
TXT: 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 REF: parid0374 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).
FIX: SIDP values, which determine the subjects of a-nodes and c-nodes,
can only be conferred by service as a-nodes or c-nodes. That such nodes
may also be role players (x endpoints of Cx arcs) may not be used to
confer SIDP values.
COM: Attempt to shorten and focus the prose.
END
REF: parid0264
TXT: 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.)
FIX: SIDP values are conferred upon r-nodes and t-nodes by virtue of
their situations as role players (i.e., as the x endpoints of Cx arcs).
SIDP values can be predefined for r-nodes and t-nodes.
COM: Probably should expand into sections on predefined and conferred
values, how to set, when prohibited.
END
REF: parid0265
TXT: Internal consistency of the values of a node's SIDPs
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0267
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
REF: parid0268
TXT: 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.
FIX: (Strike)
COM: Belongs in TM Application section
END
--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps