[sc34wg3] Section 5 Comments

[Patrick Durusau]

Greetings!

Only two more sections to go! Hopefully will finish those by mid-day 
tomorrow.

Hope everyone is having a great day!

Patrick

REF: parid0269

TXT:  Definitions of TM Applications

FIX: Requirements for Defining TM Applications

COM: Think this captures the intent of the standard better. Setting 
forth the requirements to be meet in defining a TM Application.

END


REF: parid0271

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

FIX: The definition of a TM Application is constrained by the following 
requirements in order to more closely approach the Subject Location 
Uniqueness Objective. While expressed in the language of the topic map 
graph, these constraints do not imply or impose any particular data 
structure or method of processing data upon a TM Application.

COM: I suggest cutting this and other repetition of the amalgamation 
theme. OK for a brief say in the introduction but out of place when 
people want to learn the how and not the why.

END

REF: parid0272

TXT:   Any participating subjects

FIX: (strike)

COM: see parid0273

END


REF: parid0273

TXT: This RM4TM does not constrain the nature or properties of subjects 
that can participate in topic map graphs.

FIX: (strike)

COM: At the very most, we should add to the glossary under subject 
something like: NOTE: The RM4TM does not constrain the nature or 
properties of subjects used by TM Applications or topic maps.

END


REF: parid0275

TXT: Most constraints are imposed by TM Applications

FIX: (strike)

COM: Unnecessary.

END


REF: parid0276

TXT: This RM4TM imposes minimal constraints on the definitions of "Topic 
Maps Applications (TM Applications)," so that the definition of each TM 
Application establishes a context within which the nature of the topic 
map information being represented under its governance is well-defined.

FIX: (strike)

COM: Unnecessary

END


REF: parid0277

TXT:   Purpose of TM Application definition requirements

FIX: (strike)

COM: Unnecessary even in its current location.

END


REF: parid0278

TXT:   This RM4TM does not define any specific TM Applications, nor does 
it define any aspects of any specific TM Applications. Instead, it 
imposes constraints on the definitions of conforming TM Applications. 
The purpose of these constraints is to require TM Applications to be 
defined in sufficient detail, and with sufficient rigor, so that:

FIX: (strike)

COM: redundant

END


REF: parid0279

TXT: conforming implementations and conforming topic maps can be created 
by diverse and independent creators and creative processes,

FIX: (strike)

COM: These are benefits of the requirements, not relevant to the 
requirements.

END

REF: parid0280

TXT: given any conforming topic map created by any conforming 
implementation, the interpretation of that topic map by any other 
conforming implementation will be verifiably consistent with the TM 
Application, and

FIX: (strike)

COM: These are benefits of the requirements, not relevant to the 
requirements.

END


REF: parid0281

TXT:   the effort and expense involved in amalgamating the knowledge 
represented by topic maps that conform to single and multiple TM 
Applications can be minimized, while the consistency of the knowledge 
represented by the resulting amalgamated topic maps can be maximized, 
without information loss, and with the greatest possible achievement of 
the Subject Location Uniqueness Objective by automatic means.

FIX: (strike)

COM: These are benefits of the requirements, not relevant to the 
requirements.

END


REF: parid0282

TXT: Overview of required TM Application definition components

FIX: Overview of Required TM Application Components

COM: We have already said we are defining the components, no reason to 
repeat definition.

END


REF: parid0283

TXT: The definition of a conforming TM Application must include all of 
the following:

FIX: A TM Application shall define:

COM: Just say what the TM Application must define, non-conformance 
should be covered under conformance.

END


REF: parid0284

TXT: A name that is different from the name of any other conforming TM 
Application. (See REF: parid0297 5.2.1.)

FIX: A name that is different from the name of any known TM Application.

COM: In parid0297 it is acknowledged that this is a goal, not a 
requirement. Took out conforming as introducing too much subjective 
judgment in the process. As revised, requires no knowing conflict.

END


REF: parid0285

TXT:   A set of definitions of the properties of nodes and their value 
types, specifying which property values are intended to be used for 
purposes of deciding whether nodes have identical subjects (i.e., 
specifying which are SIDPs, and which are OPs). (See REF: parid0303 5.2.2.)

FIX: Definitions of the properties of nodes and their value types. Such 
definitions must indicate which property values are subject identity 
discrimination properties (SIDPs) and which are other properties (OPs).

COM: Reworded to drop explanation of SIDPs. Define once, use many times.

END


REF: parid0286

TXT: The validity constraints on the values of the properties of nodes. 
(See REF: parid0321 5.2.3.)

FIX: Validity constraints (if any) on the values of the properties of 
nodes. (See REF: parid0321)

COM: Despite "shall" language in the proposed and implied in present 
version, validity constraints are optional. See proposed note that follows.

END

REF: new

TXT: Note: In the absence of definition of constraints on the values of 
properties of nodes, the default constraint is none.

FIX: (add)

COM: add following parid0286

END


REF: parid0287

TXT: A set of situation features other than service as the x endpoints 
of Cx arcs, and the property values that must be conferred on the nodes 
so situated. (The purpose of these property values is to enable arc 
traversals within assertions. Not all intra-assertion arc traversals are 
required to be enabled. See REF: parid0323

FIX: Situation features other than service as the x endpoints of Cx 
arcs, and the property values that must be conferred on the nodes so 
situated.

COM: This is an overview, not overview plus exposition. The purpose of 
the property values should and will be covered in detail in just a 
couple of section.

END


REF: parid0288

TXT:   A set of assertion types, the role types of each assertion type, 
the validation constraints on their instances, and the property values 
that must be conferred upon the role players of their instances. (See 
REF: parid0344 5.2.5.)

FIX: Assertion types, the roles of each assertion type, the validation 
constraints on their instances, and the property values that must be 
conferred upon the role players of their instances. (See REF: parid0344 
5.2.5.)

COM: Minor mod and changed "role types" to "roles."

END



REF: parid0291

TXT: A set of built-in nodes, with built-in property values, that must 
appear in every topic map graph that conforms to the TM Application. 
(See REF: parid0366 5.2.7.)

FIX: A set of predefined nodes, with predefined property values, that 
must appear in every topic map graph that conforms to the TM 
Application. (See REF: parid0366 5.2.7.)

COM: Changed to use "predefined" instead of "built-in."

END


REF: parid0292

TXT: The rules for merging nodes on the basis of their subject identity 
discrimination properties (SIDPs). (See REF: parid0370 5.2.8.)

FIX: Rules for merging nodes on the basis of their subject identity 
discrimination properties (SIDPs). (See REF: parid0370 5.2.8.)

COM: Minor change, "The rules" to "Rules." We have already said these 
must be defined so "The" is unnecessary.

END


REF: parid0293

TXT: The rules for combining the built-in values of the properties of 
built-in nodes during merging, if the designers of the TM Application 
anticipate the need for such combination. (See REF: parid0389 5.2.9.)

FIX: Rules for combining the predefined values of the properties of 
predefined nodes during merging. (See REF: parid0389 5.2.9.)

COM: Not required unless desired by the designer of the TM Application, 
therefore, optional. See inserted note.

END

REF: new

TXT: Note: Optional. May be necessary when predefined nodes are merged 
to meet the Subject Location Uniqueness Objective.

COM: Not the full explanation but enough for people to look to the 
fuller exposition.

END


REF: parid0294

TXT:   If the TM Application defines one or more interchange syntaxes, 
the procedures for constructing topic map graphs from instances of each 
syntax ("Syntax Processing Models"), and "node demander" rules that 
allow topic map graph nodes to be indirectly addressed by addressing 
their corresponding syntactic constructs. (See REF: parid0393 5.2.10.)

COM: Wondering if "Syntax Processing Model" is the right term? I read 
this to mean that a TM Application must provide a "mapping" (sorry, 
could not thing of another word) of the syntax to the nodes, properties 
and arcs of the topic map graph. I suppose you can call that a 
"processing model" but is more nearly a transformation or perhaps simply 
a mapping of the syntax to the topic map graph? If that is the case, 
couldn't we include "node demanders" which must be represented in the 
topic map graph in the definition of that mapping? That is to say, the 
mapping must include... and then list the things the mapping must 
include, such as node demanders. I take that to be the intent of the 
current language, although stated as something separate from the "Syntax 
Processing Model."

END

REF: parid0295

TXT: Constraints on definitions of aspects of TM Applications

FIX: TM Application Components

COM: We have already given an overview of the required components, some 
of which are optional. Don't think we need to keep emphasizing 
constraint, after all, we are defining what constitutes a TM 
Application. If something does not follow these rules, it is by 
definition, not a TM Application.

END


REF: parid0296

TXT:   The following subclauses specify the detailed constraints 
governing each of the required aspects of the definitions of TM 
Applications.

FIX: (strike)

COM: Redundant.

END


REF: parid0297

TXT: Definition of TM Application name

FIX: Definition of TM Application Name

COM: Case change in title for section

END


REF: parid0298

TXT:   The name of the TM Application must be specified. Care should be 
taken to select a name that is unlikely to be used as the name of any 
other TM Application, including other versions and/or conformance levels 
of an evolving or configurable TM Application. (Each version, 
conformance level, or other configuration must be regarded as a distinct 
TM Application for purposes of naming.) This name must be used as the 
first field of all of the property names that it defines. The name must 
not include the "name field separator" symbol shared by all TM 
Applications whose definitions conform to this RM4TM. (See REF: 
parid0442 REF: Ed.Note  55.)

FIX: The name of the TM Application must be specified.

COM: Paragraph conflates serveral requirement that might be easier to 
discern if written separately. See suggested additonal text below.

END


REF: new

TXT: The name of a TM Application must meet the following requirements:

FIX: (add)

COM: Beginning of a section with a list of name requirements for TM 
Application names

END


REF: new

TXT: The name of a TM Application must be unique among known TM 
Applications.

FIX: (add)

COM: Explained  by the following note.

END


REF: new

TXT: Note: Ideally, TM Applications should have universally unique 
names. That being a practical impossibility, designers of TM 
Applications are constrained to use names that do not conflict with any 
known TM Applications. The risk of name conflicts can be minimized by 
use of URIs for Internet domains controlled by the TM Application 
designer or registered TM Application namespaces of public organizations 
such as OASIS, W3C, IDEAlliance, OCLC, Library of Congress or other 
similar bodies.

FIX: (add)

COM: Explanation of requirement and added material from parid0302.

END


REF: parid0299

TXT:   Non-ISO-standard TM Applications are not permitted to use names 
that begin with "IS", irrespective of the cases of the letters, in the 
first field.

COM: What is meant by "Non-ISO-standard TM Applications"? TM 
Applications not issued by ISO or TM Applications that do not conform to 
this standard? If the latter, not sure how we constrain non-conforming 
TM Applications.

END



REF: parid0302

TXT:   One way to minimize the risk of ambiguity that might result from 
coincidental use of identical names for TM Applications created by 
different TM Application designers is for designers to use, as their TM 
Application names, URIs that address the internet domain names that the 
designers themselves control, or that are registered names within 
controlled TM Application namespaces within the internet domains of such 
standards organizations as OASIS, the World Wide Web Consortium, 
IDEAlliance, or such library service organizations as the Online 
Computer Library Center (OCLC), the Library of Congress, etc.

FIX: (strike)

COM: moved in part to new note on unique name

END


REF: parid0304

TXT:   All properties of nodes should be explicitly defined. All 
properties whose values are used to determine whether two nodes have the 
same subject (i.e., all SIDPs) must be explicitly defined.

COM: Is there a reason why it is not being required that all properties 
be defined? As opposed to "should?" Can't think of a case where there is 
a downside to having explicit definition of all properties. Agree on the 
"must" for SIDPs but curious about other properties as well.

END


REF: parid0305

TXT:   Each property definition must specify all of the aspects 
described in the following subclauses:

FIX: Every property definition must include:

COM: Just shortened, same intent.

END


REF: parid0307

TXT:   The property definition must specify a name that is unique among 
the names of all the properties, assertion types, and role types defined 
by the TM Application. The name must not include the "name field 
separator" symbol (see REF: parid0442 REF: Ed.Note  55).

FIX: The property definition must specify a name that is unique among 
the names of all the properties, assertion types, and roles defined by 
the TM Application.

COM: Changed "role types" to "roles." Deleted name constraint, should 
add into defintions as: name (properties, assertion or role types) Names 
may consist of any characters except the "name field separator." also 
need an entry on name field separator and define it as well.

END


REF: parid0309

TXT: The property definition must specify the type of value of which the 
value must be an instance, if the property exhibits a value.

FIX: The property definition must specify a type for a value of the 
property.

COM: By definition, if a property does not exhibit a value, the type of 
the value is irrelevant.

END


REF: parid0310

TXT: Property value types are not constrained by this RM4TM. They can be 
simple and/or complex. They can be data and/or nodes.

FIX: Property value types are not constrained by this RM4TM.

COM: If they are not constrained, isn't that enough? Could toss the 
other stuff into a note if illustration is desired.

END


REF: parid0311

TXT: Constraints on property values

FIX: Validation of Property Value Constraints

COM: From reading parid0312 (following) it appears that this section is 
not talking about constraints on property values but requiring such 
constraints be validated.

END


REF: parid0312

TXT: The property definition may specify validity constraints on the 
value of the property. During the process of converting a well-formed 
topic map graph into a fully merged one, implementations of the TM 
Application must validate all SIDP values for conformance to all of the 
validity constraints defined for them. (See REF: parid0431 6.4.)

FIX: Implementations of the TM Application must validate SIDP values 
against all of the validity constraints defined for them. (See REF: 
parid0431 6.4.)

COM: The first sentence is redundant. Shouldn't TM Applications always 
validate SIDP values against their constraints? (Reason for dropping the 
well-formed to fully merged language.)

END


REF: parid0314

TXT:   Subject identity discrimination properties (SIDPs)

COM: cf. my earlier comment on making this Subject Discrimination 
Properties (SDPs)

END


REF: parid0315

TXT:   The property definition must indicate whether the property being 
defined is a subject identity discrimination property (SIDP).

FIX: A property must be defined as a subject identity discrimination 
property (SIDP).

COM: Reworded to enable the absence of such a definition, see new entry 
following.

END


REF: new

TXT: A property that is not defined as a subject indentity 
discrimination property (SIDP) is an other property (OP).

FIX: (add)

COM: Added to provide the default case where a property is not an SIDP.

END


REF: parid0319

TXT:   Semantics of the property

FIX: Semantics of a Property

COM: Corrected to refer to properties in general.

END



REF: parid0320

TXT:   Each property definition should include an explanation of the 
significance of the property and its values, including an explicit 
indication, where appropriate, of the significance of the condition in 
which no value is exhibited. If the property is a subject identity 
discrimination property (SIDP), such an explanation must be provided.

COM: Had the same question for parid0304, understand the reason to treat 
SIDP properties more strictly, but wouldn't this information be useful 
on the other properties as well?

END


REF: parid0321

TXT:   Definitions of validity constraints on the values of properties

COM: see comments on parid0322

END


REF: parid0322

TXT: If, in order to be considered valid, a property value must conform 
to certain constraints, the TM Application should define such 
constraints for each such property, wherever possible.

COM: Is this a duplicate of the constraints on values of properties, 
treated at parid0309? What other constraints, other than value, could be 
imposed? Should drop "wherever possible" because in order to constrain a 
property it must certainly be possible. Is this meant to treat the idea 
of default, required, inherited values? Or to force a property to have a 
particular value if another property has a certain value?

END


REF: parid0323

TXT:   Definition of assignment of property values conferred on account 
of arc endpoint service other than service as the x endpoints of Cx arcs

FIX: Conferred Property Values from Arc Endpoint Service (excluding x 
endpoints of Cx arcs)

COM: Even the suggested title is too long, best I could do.

END


REF: parid0324

TXT: All TM Applications are required to define subject identity 
discrimination properties (SIDPs) for a-nodes and c-nodes, and rules for 
conferring values upon them, such that all a-nodes and c-nodes will 
exhibit values for those properties that will support the merging of 
assertions in conformance with the assertion merging rules specified in 
REF: parid0374 5.2.8.2.

COM: Isn't this several rules in one? Rule 1) a-node and c-node 
equivalents in the TM Application must have defined SIDPs; Rule 2) rules 
for conferrring values SIDPs of a-nodes and c-nodes; Rule 3) rules #1 
and #2 must support assertion merging rules. Drop the "TM Applications 
required to define..." We are already requiring, restating does not add 
anything.

END


REF: parid0325

TXT:   This RM4TM does not require TM Applications to define properties 
whose values reflect the internal structure of assertions comprehensively.

COM: Sorry, lost me on this one. What would comprehensively look like?

END


REF: parid0344

TXT:   Definitions of assertion types

FIX: Assertion Types

COM: we are in the process of defining the requirements.

END


REF: parid0345

TXT: The definition of each assertion type defined by a TM Application 
must include all of the aspects specified in the following subclauses.

FIX: An assertion type definition shall include:

COM: shortened.

END


REF: parid0346

TXT: Definitions of names of assertion types

FIX: Assertion Type Names

COM: shortened

END


REF: parid0347

TXT: For each assertion type, a name that is unique among all the names 
of assertion types, role types, and properties defined by the TM 
Application must be specified. The names of assertion types have two 
fields, in the same manner as property names, with the name of the TM 
Application in the first field, and the name of the assertion type in 
the second field. The name must not include the "name field separator" 
symbol defined in REF: parid0442 Ed.Note  55.

COM: needs revision after adding name and name constraints to the glossary.

END


REF: parid0361

TXT: Definition of the semantics of the assertion type

FIX: Semantics of Assertion Types

COM: already in definitions

END


REF: parid0348

TXT: Definitions of role types

FIX: Roles

COM: changed to use Role and not role types

END


REF: parid0349

TXT: A set of role types must be specified, each member of which will 
always be represented in all instances of the assertion type in the 
topic map graph, regardless of whether they have role players.

FIX: A minimum of two (2) roles must be specified for any assertion.

COM: Isn't the definition of an assertion type applicable for every 
instance of the assertion type? Not sure why that is being repeated here.

END


REF: parid0350

TXT: This RM4TM does not prohibit multiple assertion types from 
incorporating the identical role type(s).

FIX: Multiple assertion types can use identical roles.

COM: Just say what the RM says, don't characterize it.

END
 

REF: parid0940

TXT:   The designs of TM Applications may be inherently more robust if 
all of the role types defined as components of their assertions types 
are regarded as unique subjects, even when they share the same names. 
For example, the father-daughter relationship type and the father-son 
relationship type may, in some cultures, be different in character, and 
the role of fatherhood may therefore also turn out to be different. If a 
TM Application defines both the father-daughter and father-son 
relationship types in such a way as to regard the role type of "father" 
as the same subject in both relationship types, then no distinction can 
ever be made between the two kinds of fatherhood, other than by defining 
a new TM Application.

FIX: (strike)

COM: Like the example but I am not sure here is the place for it. 
Doubtful that its relationship to the prior paragraph could be made 
clearer without a lot more room.

END


REF: parid0352

TXT: Each role type definition includes all of the aspects specified in 
the following subclauses.

FIX: A role type definition includes: 1) the role name, 2) property 
values conferred on role players, 3) semantics of role; rules for 
consistency of SIDPs, and definition of predefined nodes and values of 
predefined property values.

COM: Slightly alternative style of enumeration with details following.

END


REF: parid0353

TXT: Definitions of names of role types

FIX: Names of Roles

COM: Change of "role type" to "role."

END


REF: parid0354

TXT:   For each role type, a name which is unique among all the names of 
assertion types, role types, and properties defined by the TM 
Application must be specified. The names of role types have two fields, 
in the same manner as property names, with the name of the TM 
Application in the first field, and the name of the role type in the 
second field. The name must not include the "name field separator" 
symbol defined in REF: parid0442 REF: Ed.Note  55.

COM: needs revision after adding name and name constraints to the glossary.

END


REF: parid0355

TXT: Definitions of property values conferred on role players of 
assertion instances

FIX: Property Values Conferred on Role Players in Assertions

COM: Took out definitions, changed case.

END


REF: parid0356

TXT:   If, in instances of the assertion type being defined, role 
players of the role being defined are required to have property values 
conferred upon them, the procedure required to calculate such values 
should be defined. It must be defined for subject identity 
discrimination properties (SIDPs).

REF: parid0357

TXT:  TM Applications must not allow values to be conferred on the SIDPs 
of any of the role players of assertions whose assertion types are 
unspecified.

COM: Note possible revision required if all assertions are required to 
have a type.

END


REF: parid0359

TXT: Definition of semantics of role type

FIX: Role Semantics

COM: deleted definition and substituted role for role type

END


REF: parid0360

TXT: The semantics of each role type must be explained.

FIX: The semantics of each role must be explained.

COM: role for role type


REF: parid0363

TXT: Definition of consistency of the values of SIDPs of a node

FIX: Consistency of SIDP Values

COM: dropped definition, only nodes have SIDPs so redundant

END


REF: parid0364

TXT: The rules for detecting conditions in which the subject identity 
discrimination properties (SIDPs) of a node have conflicting values must 
be defined.

FIX: Rules for detecting conflict in values of subject identity 
discrimination properties (SIDPs) must be defined.

COM: restated.

END


REF: parid0366

TXT: Definitions of built-in nodes and their built-in property values

FIX: Predefined Nodes and Property Values.

COM: Only a predefined node can have a predefined value so no reason to 
restate here. Predefined value does make sene in an isolated context.

END


REF: parid0367

TXT: Some of the subjects defined by a Topic Maps Application - at least 
enough to bootstrap at least some of its assertion types and role types 
into existence - must be represented by "built-in" nodes that are 
logically present in all topic map graphs at the moment that they begin 
to be constructed.

FIX: Some of the subjects defined by a Topic Maps Application - at least 
enough to bootstrap at least some of its assertion types and role types 
into existence - must be represented by "predefined" nodes that are 
logically present in all topic map graphs at the moment that they begin 
to be constructed.

COM: changed built-in to predefined

END


REF: parid0368

TXT: These built-in nodes and their built-in subject identity 
discrimination property values must be defined.

FIX: Predefined nodes and their subject identity discrimination property 
values must be defined.

COM: changed built-in to predefined, plus minor re-wording.


REF: parid0369

TXT: If there are any built-in assertions, the built-in property values 
that correspond to their arcs must be defined, and their built-in 
a-nodes and c-nodes must be provided with built-in values for their 
subject identity discrimination properties (SIDPs) such that the merging 
of the built-in assertions in conformance with the assertion merging 
rules specified in parid0374 5.2.8.2 will occur. The definitions of the 
properties that have built-in values in the built-in nodes defined by 
the TM Application must be such that, when topic map graphs governed by 
the TM Application are constructed, any assertions that are implicit in 
the built-in property values will be unambiguously recognized, so that 
they can be represented explicitly in the graph.

FIX: If there are any predefined assertions, then property values that 
correspond to their arcs must be defined, and their a-nodes and c-nodes 
must be provided with values for their subject identity discrimination 
properties (SIDPs) such that the merging of the predefined assertions in 
conformance with the assertion merging rules specified in parid0374 
5.2.8.2 will occur.

COM: As re-written, second sentence is explanatory and therefore 
redundant. Note that I removed built-in from various places where it is 
already implied from having a predefined assertion. Since an assertion 
has required components and values, does it not stand to reason that to 
predefine an assertion also means those properties and values are also 
predefined?

END

REF: parid0922

TXT:   Whenever two or more topic maps that are governed by the same TM 
Application are merged, some of their built-in nodes, such as the nodes 
whose subjects are the bootstrapping assertion types, will always be 
duplicated in every topic map, and therefore will always merge. Others, 
such as the built-in nodes whose SIDP values are derived from data 
contained in different syntactic instances, may not be duplicated, and 
therefore may not merge.

COM: Should this be a note? Reason I ask is because these are the normal 
merging rules but applied to predefined nodes.

END


REF: parid0370

TXT:   Definition of merging rules

FIX: Merging Rules

COM: removed "Definition of," corrected case

END


REF: parid0371

TXT: Node merging is based only on SIDP values

FIX: Node Merging

COM: Should not repeat the content of the rule in the header

END


REF: parid0372

TXT: TM Applications must define node merging rules that determine 
whether any two nodes must be merged, and these rules must operate 
solely on the basis of the values of subject identity discrimination 
properties (SIDPs).

FIX: Node merging rules are required and must operate solely on the 
basis of the values of subject identity discrimination properties (SIDPs).

COM: Defining rules for TM Applications so reference to TM Applications 
is unnecessary.


REF: parid0374

TXT: Merging rules for assertions

FIX: Assertion Merging

COM: Changed to be consistent with proposed change for parid0372

END


REF: parid0450

TXT: Definition of subject identity of a-nodes

FIX: (strike)

COM: Subject identity of a-nodes is defined elsewhere, what (should) 
follow are the rules for merging assertions.

END


REF: parid0375

TXT: In all conforming TM Applications, two assertions are merged to 
become a single assertion when their respective a-nodes are deemed to 
represent the same subject. All TM Applications are required to define 
merging rules that apply uniformly to all assertions, such that they 
will always be merged during the process of converting a well-formed 
topic map graph into a fully merged topic map graph under the conditions 
described in the following subclauses, and such that they will be 
automatically merged under no other conditions and on no other basis:

FIX: Both assertions represent the same subject.

COM: Shouldn't uniform application of merger rules be handled separately 
from rules for assertion merger? Assertions are said elsewhere to 
represent their subjects by the a-node.

END

REF: new

TXT: Both assertions have the same assertion type.

FIX: (add)

COM: State the positive requirement for merger to occur.

END


REF: parid0377

TXT: If neither assertion specifies its assertion type, it cannot be 
assumed that the lack of an assertion type itself constitutes a specific 
assertion type which is the same for both.

FIX: If both assertions fail to specify an assertion type, it is 
conclusively presumed that the assertion type are different.

COM: State in positive terms, not "cannot be presumed" simply say it is 
not presumed.

END


REF: parid0451

TXT:   Merging process for assertions

FIX: Merging Process for Assertions

COM: Should this go with list of requirements for merger?

END


REF: parid0385

TXT:   The human factor in merging

FIX: (strike)

COM: Argumentative, does not express something we can constrain.

END

REF: parid0386

TXT:   The merging rules defined by TM Applications are intended be 
exploited by creators of topic maps, so that the topic maps they create 
can incorporate other topic maps by reference, and so that when such 
references are resolved, the resulting merged topic map graph will be 
identical to the one that the creator intended.

FIX: (strike)

COM: Argumentative, does not express something we can constrain.

END


REF: parid0387

TXT:   In all cases, and regardless of their governing Application(s), 
when two nodes represent the same subject, they must be merged. In other 
words, the Subject Location Uniqueness Objective always applies. It is 
the responsibility of the creator of every topic map to see to it that 
all such mergers will occur when the topic map is processed in 
conformance with the rules defined by its governing TM Applications.

FIX: (strike)

COM: Argumentative, does not express something we can constrain.

END

REF: parid0388

TXT:   Topic map creators must accept responsibility for the fully 
merged topic map graphs represented by the interchangeable topic maps 
that they create, even when their interchangeable topic maps incorporate 
topic maps that were created by others. When interchangeable topic maps 
incorporate other topic maps by reference, they must also contain (or 
incorporate by reference) subjects and assertions that cause the merging 
process to yield a satisfactory result in which no two nodes have the 
same subject, even when, in the absence of any special arrangements made 
by the creator of the topic map, no governing TM Application would cause 
the two nodes to merge. It is the responsibility of topic map creators 
to make such special arrangements, by adding assertions that will cause 
the nodes that must be merged to have SIDP values that will be 
recognized as requiring their merger. (See REF: parid0463 7.4.)

FIX: (strike)

COM: Argumentative, does not express something we can constrain.

END


REF: parid0453

TXT:   Such special arrangements may involve indirectly addressing the 
nodes of the topic map graph represented by the interchangeable forms of 
the topic maps that are incorporated by reference, by addressing the 
syntactic "node demanders" of the nodes that must be merged. See REF: 
parid0401 5.2.10.3.

COM: Possibly because of the suggested deletions, perhaps not, this does 
not appear, even with the preceeding paragraph, to really fit under 
normative rules for merger. Basically says topic map creators are 
responsible for making necessary mergers happen. OK, so now what? 
Without more, not really helpful.

END


REF: parid0389

TXT:   Definitions of rules for merging property values when merging nodes

FIX: Merging Property Values When Merging Nodes

COM: removed "definitions of"

END


REF: parid0976

TXT:   Merging built-in property values

FIX: Merging Predefined Property Values

COM: deleted built-in, corrected case

END

REF: parid0390

TXT:   The Subject Location Uniqueness Objective may demand that 
built-in nodes be merged, but the effect of merging their built-in 
values cannot be determined by the situation features of the node that 
results from their merger. Therefore, TM Applications must define rules 
for combining the built-in values of built-in nodes.

FIX: (strike)

COM: The TM Application must define what the standard says it must 
define. Argument about why something is required is inappropriate here.

END


REF: parid0977

TXT: Merging conferred property values

REF: parid0391

TXT:   In order to optimize the merging process, TM Applications may 
also define procedures for combining the conferred property values of 
two nodes in the conferred property values of the single node that 
results from merging them. All such rules must be such that the result 
of applying these procedures is indistinguishable from the result of 
recalculating the merged node's conferred property values on the basis 
of its new situation.

FIX: Procedures may be defined for combining the conferred property 
values of two nodes in the conferred property values of the single node 
that results from merging them. All such rules must be such that the 
result of applying these procedures is indistinguishable from the result 
of recalculating the merged node's conferred property values on the 
basis of its new situation.

COM: took out explanation, split into two requirements, see following 
new entry

END


REF: new

TXT: Procedures for combining conferred property values of two nodes 
merged into the conferred property values of one node, must be  must be 
the same as the merged node's conferred property values in its situation.

FIX: (add)

COM: reworded second sentence from parid0391. note that the merged node 
does not have a new situation. that implies it had an old situation. a 
merged node should be considered a "new" node shouldn't it?

END



REF: parid0935

TXT:   In any case, whenever two nodes are merged, the situations of 
other nodes may also be affected, necessitating recalculation of their 
property values, as well.

FIX: Whenever two nodes are merged, the situations of other nodes may 
also be affected and their property values must be recalculated.

COM: Stated this in the affirmative and as a "must." Assuming it is not 
possible to determine if situtations have been changed without 
recalculation of the property values and comparison to the original.

END


REF: parid0393

TXT:   Definitions of interchange syntaxes

FIX: Interchange Syntaxes

COM: wording change

END


REF: parid0394

TXT:   The definition of a Topic Maps Application may or may not define 
one or more syntaxes for the interchange of the topic maps it governs. 
The constraints on the definitions of such syntaxes are specified in the 
following subclauses.

FIX: TM Application may define one or more interchange syntaxes.

COM:

END


REF: new

TXT: A TM Application interchange syntax must meet the following 
requirements:

FIX: (add)

COM: probably need list of requirements to follow

END


REF: parid0396

TXT:   Syntactic rigor

COM: not sure about this requirement, see below

END


REF: parid0397

TXT:   The syntax itself must be defined in such a way that instances of 
it can be validated for conformance with its syntactic rules before any 
attempt is made to render it as a topic map graph.

COM: Not sure what a non-validatable syntax would look like?

END


REF: parid0398

TXT:   Syntax Processing Models

COM: understand the need, not certain about the prose

END


REF: parid0399

TXT:   A "Syntax Processing Model" must be defined that specifies, in 
terms of the definition of each such syntax, how the information 
represented by instances of the syntax must be comprehensively 
represented as topic map graphs.

COM: Confusion - instance of the syntax or from the rules of the syntax?

END


REF: parid0970

TXT:   In other words, a Syntax Processing Model specifies how to 
construct topic map graphs from instances of the syntax, without 
omitting any information represented in the instances. Syntax Processing 
Models may specify that instances of specific syntactic constructs 
require the addition to the graph of nodes with values that are 
built-in, as well as conferred. The built-in values may be derived from 
data contained in the syntactic instance.

COM: Curious why it is "may specify" ...addition to the graph of nodes 
with values that are built-in...(predefined)? seems like that would be 
required

END


REF: parid0989

TXT:   For each value that a Syntax Processing Model requires to be 
assigned to a property of a node, the definition of the Syntax 
Processing Model must state whether the value is to be regarded as a 
built-in value, or it is to be regarded as a conferred value.

FIX: Every value that is assigned to a node must be specified as 
predefined or conferred.

COM: reworded, same intent

END


REF: parid0991

TXT:   Built-in values cannot be overridden by virtue of the node's 
situation in the graph. See REF: parid0245 4.7.1.

FIX: (strike)

COM: suggest that syntax definitions must follow all the rules 
previously stated for TM Applications, which I seem to recall says the 
same thing. (may be under properties of nodes)

END


REF: parid0401

TXT:   Facilities for indirect node addressing via syntactic constructs

FIX: (strike)

COM: just list the requirements

END


REF: parid0973

TXT:   Node demanders

COM: Not sure this is the best name but don't have an alternative. 
Understood to mean a construct in the syntax that should be represented 
as a node in the topic map graph

END


REF: parid0402

TXT:   A list of syntactic constructs ("node demanders") whose instances 
can be unambiguously addressed within the instances of the syntax must 
be provided. Each such node demander must be defined as being associated 
with a specific node whose existence in the topic map graph that the 
instance represents can reasonably be regarded as being "demanded" by 
the existence of the demander.

FIX: An addressable syntactic construct in the syntax must be 
represented as a node in the topic map graph.

COM: Is there such a thing as ambiguously addressed syntactic 
constructs? Shortened.

END


REF: parid0404

TXT:   The list of node demanders may or may not provide a facility for 
comprehensively addressing every node in the topic map graph constructed 
from a syntactic instance.

COM: If it has been represented in the topic map graph, what sort of 
addressing is being contemplated here?

END


REF: parid0974

TXT:   "Same subject as demanded node" assertion type

REF: parid0971

TXT:   Each TM Application that defines one or more Syntax Processing 
Models must also define at least one assertion type of which one of the 
role types can be played by a node demander, that confers one or more 
SIDP values on the player of another of its role types such that its 
subject will be recognized by the merging process as being the same as 
the subject of the node whose existence is demanded by the node demander.

COM: Not sure of the intent of this statement as written.

END


REF: parid0403

TXT:   The "node demander" facilities defined for the interchange 
syntaxes of TM Applications allow interchangeable topic maps to refer to 
each other in ways that guarantee the merging of nodes that are 
separately demanded by each of them.

COM: Isn't this argumentation node demanders and not a rule for node 
demanders?


REF: parid0405

TXT:   Borrowed definitions

COM: is this like include in schemas?

END


REF: parid0406

TXT:   TM Applications can include, as portions of themselves, other TM 
Applications, by reference, but only in their entirety. The names of 
borrowed properties, assertion types and role types are not affected by 
being borrowed; each remains as defined in the definition of its TM 
Application of origin.

FIX: TM Applications can include other TM Applications in their 
entirety, by reference.

COM: shortened, broken into second rule

END


REF: new

TXT: Names of borrowed properties, assertion and role types are not 
affected by inclusion by another TM Application.

FIX: (add)

COM: Stated in the affirmative.

END

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