[sc34wg3] RM: Sections 6 and 7 comments

[Patrick Durusau]

Greetings!

Finally, the end of the RM (save for the annexes which I am not going to 
comment on until the main part is done).

Patrick

REF: parid0413

TXT: Constructing fully-merged topic map graphs from well-formed topic 
map graphs

COM: General comment on section 6: shouldn't we separate out the 
construction of the topic map graph from the merger operations? Seems 
like it would be clearer to treat it in two steps, first build the 
graph, second do the merging? Not a fully-merged topic map graph at the 
end of step 1, but does get people the basics if building the graph.

END


REF: parid0414

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

FIX: (strike)

COM: argue for the design eleswhere

END


REF:: parid0416

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

FIX: (strike)

COM: If this is illustration and not required, then shouldn't this be a 
non-normative appendix? The requirements of mapping to topic map graph 
is normative, this particular illustration appears to not be normative 
by the terms of this section. Merging is normative but that should be 
treated separately as noted above.

END


REF:: parid0419

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

COM: Is this a heading? or a step? The next "step" parid0420 looks like 
the first step to me.

END



REF: parid0420

TXT:  Endow the graph with built-in bootstrap nodes

FIX: Record predefined nodes.

COM: We have already said that predefined nodes are required for 
bootstrapping.

END


REF:: parid0421

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

FIX: (strike)

COM: This is supposed to be the steps to building the topic map graph, 
not an argument for why it is done this way.

END


REF:: parid0924

TXT:  Built-in arcs are implicitly represented by the built-in property 
values that correspond to them. See REF: parid0369  5.2.7.


FIX: Predefined arcs are represented by property (and their values) on 
predefined nodes.

COM: Sorta stands to reason doesn't it? Hard to have a predefined arc 
without a place to put the information.

END



6.1.2   REF: parid0422

TXT:  Interpret interchangeable topic map as topic map graph

COM: ?? Thought we were already doing the topic map graph?

END


REF:: parid0423

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

COM: If this is going to the graph, this should be first.

END



REF:: parid0425

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

COM: Shouldn't we just say what we do constrain?

END


REF:: parid0426

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

FIX: (strike)

COM: If we don't care, why should we say?

END


REF:: parid0427

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

FIX: (strike)

COM: again, if it doesn't matter, we should not say is does not matter, 
what we don't constrain is ok.

END


REF:: parid0477

TXT:  All of the assertions must be validated for conformance to the 
definitions of their assertion types specified by their governing TM 
Applications. (See REF: parid0344 5.2.5.)

COM: isn't this a repetition of conforming to the definition of an 
assertion? see parid0476



REF:: parid0429

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

FIX: All nodes must be assigned SIDP values required by their definitions.

COM: Shouldn't we just say it? I take requiring it to also require 
discovery of the nodes where it is required.

END


REF:: parid0993

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

FIX: (strike)

COM: isn't this all defined elsewhere?

END


REF: parid0431

TXT:  Validate the values of the SIDPs of nodes

FIX:

COM:

END


REF:: parid0432

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

FIX: (strike)

COM: isn't this a duplicate of parid0431? At least break out the error 
reporting to a more appropriate location.

END


REF:: parid0433

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

FIX: (strike)

COM: isn't consistency part of being defined and as such, should be 
checked when checking the definition? Perhaps not, but then we need a 
catch all, observes all the other constraints placed on the nodes or 
their values.

END


REF:: parid0434

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

FIX: (strike)

COM: move to separate error reporting section, or simply delete. If 
reportable topic map processing errors for merger are all fatal, merger 
simply fails, what more need we say than that. If an application wants 
to start up from where merger failed, it can do so but generally not our 
problem.

END


REF: parid0435

TXT:  Merge nodes according to the defined merging rules

FIX: (strike)

COM: unnecessary title

END


REF:: parid0436

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

FIX: Nodes must be merged.

COM: All TM Applications are required to conform to this standard and to 
specify merging rules. Merger on the basis of SIDPs has been defined.

END


REF:: parid0438

TXT:  Assertions that represent the same relationships must always be 
merged in accordance with REF: parid0374 5.2.8.2.

FIX: Assertions must be merged.

COM: Merger required that only assertions representing the same 
relationship can be merged.

END


REF: parid0439

TXT:  Conditionally stop or repeat

COM: perhaps title when appears in separate illustration of merger

END


REF:: parid0440

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

COM: not sure of better language but seems rather awkward.

END

<-- section 7 -->


REF:: parid0461

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

FIX: If a Topic Maps Application complies with all the provisions of 
this standard, then it is a conforming Topic Maps Application.

COM: cobbled from ISO 8879, but also illustrates that we need to say 
quite clearly what those are.

END


REF:: parid0462

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

FIX: (strike)

COM: we have already defined what it must have, why repeat?

END


REF:: parid0465

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

FIX: (strike)

COM: I am not sure what this is, but it sure isn't anything to do with 
conformance.

END



REF:: parid0925

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

FIX: (strike)

COM: we should be constraining TM Applications and only indirectly 
applications.

END


REF:: parid0447

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

FIX: (strike)

COM: Require TM Applications to define reportable errors for the 
applications.

END


7.4   REF: parid0448

TXT:  Conforming interchangeable topic maps

FIX: (strike)

COM: we are defining TM Applications, which in turn constrain TMs right?

END


REF:: parid0933

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

FIX: (strike)

COM: the answer to my question under parid0448, so if we aren't 
constraining TM's why parid0448?

END


REF:: parid0463

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

FIX: (strike)

COM: Need to focus on TM Applications, which govern TMs, not switch from 
one to the other.

END

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps