Disposition of comments on N710 (13250-5 CD ballot)
Comments received during the Topic Maps Reference Model CD ballot can be found in the Summary of Voting.
Comments from the Canada National Body
1. Numbered page 4, first paragraph, last sentence, suggest it read "This
primitive path is denoted by PM".
Rejected. The reference in question is to a path language and not a single
path.
2. Numbered page 4, first Note, "...only serves as *a* minimal
baseline...", and "It can also be used as *the* basis for
a...".
Accepted.
3. It may be helpful to readers with less maths background to write out the
mathematical statements in English. Perhaps this could be done in
non-normative notes for each statement or in a non-normative
appendix.
Rejected.
Comments from the Japanese National Body
1.1 In order to identify the properties, proxies, subjects, etc., Published
Subjects should be used.
Rejected. The TMRM permits all identifiers to be used without limitation.
1.2 Clause 3 There are possibilities of polysemy problem in the keys. It
should be mentioned how to handle it in the keys.
Rejected. Keys are labels and by definition every proxy has one unique
lablel.
1.3 In order to exchange the Legends between subject maps, the Legends
should be identified and translated. So it should be mentioned how to identify
the Legentds and translate to other subject map.
Rejected. The TMRM does not specify a legend syntax nor how legends can be
identified or associated with particular subject maps.
2.1 Clause 4 The abbreviation of "instance of" relation should be changed
from "isa" to "ins" or something. The "isa" is confusable with "is-a" relation
between types.
Rejected.
2.2 Clause "Normative references" and "Terms and definitions" should be
added.
Accepted to add "Normative References" but Rejected on adding "Terms and
Definitions."
A terms and definitions section would require repetition of the context in
the TMRM that makes the terms meaningful. Reasoning that it is better to define
a term only once in a standard and that such definitions in context are more
useful to a reader of the standard, the editors respectfully decline to add the
requested section.
2.3 Clause B.2.2 " ... at table A.2." should be " ... at Table B.2.".
Accepted.
2.4 Clause B.2.3 "... listed in Table A.1." should be " ... listed in Table
B.1."
Accepted.
2.5 Table B.1 Table B.1 should be updated to the latest version. For
example, "reified" property should be added, the check should be deleted in
the "occurrences" property of "topic map" item, etc.
Accepted.
2.6 Table B.2 A "reified" key and its value should be added to the Table
B.2.
Accepted.
Comments from the Korean National Body
1. However the relation between the Reference Model and the Topic Maps
seems to be open ended, somewhat cyclic, or inconsistent. In other words, the
concepts that are needed to define Topic Maps should be grounded somewhere and
it is a matter of deciding where to stop. It could be stopped at the Topic, at
the Subject, or even at the deeper level. The question is then Topic Maps
itself can be self-contained or closed without further derivation like this
Reference Model.
Accepted. This will be clarified in the redrafting of the mapping of the TMDM
to the TMRM.
2. The notion of "constraints" in the reference model as a filter seems to
be somewhat different from that in the TMCL as an ontological refined
specification of concept. Did we get a consensus on this?
The editors are pursuing this with the Korean National Body offline.
3. The notion of "navigation" also seems to be somewhat superfluous in that
it defines "operations or procedures" while TMDL seems to define only
"declarative" aspects of the affairs of the world. (Am I right on this?)
The editors are pursuing this with the Korean National Body offline.
4. page 10: e) tuple projection tuple projection (p1,
Accepted.
5. page 12: table A.2 --> table B.2
Accepted.
6. Table A.1 --> Table B.1
Accepted.
7. (footnote) Table A.2 --> Table A.2
Accepted as intending Table A.2 -> Table B.2.
8. page 15: (B.5) topic = --> topic item = (??)
Accepted.
9. (last line) “}” --> “)}”
Accepted.
Comments from the Norway National Body
1. The phrase "this Standard" should be changed such that it does not
appear to refer to ISO 13250 as a whole.
Accepted.
2. Foreward: This section should be omitted in further drafts until the
document reaches FDIS stage.
Accepted.
3. This introduction should give a high level overview of what Part 5
brings to the table in the context of the rest of the standard. The order of
exposition might be:
1. The purpose of the Topic Maps standard as a whole. This should be very
short and in line with other parts of the standard. It should emphasize the
subject-centricity and assertion model aspects of Topic Maps.
2. The purpose of Part 2 in defining a data model (TMDM) that provides a
foundation for the syntaxes and notations defined in Parts 3, 4, 6, and 7, and
the query and constraint languages defined in accompanying standards.
3. The fact that the TMDM necessarily makes ontological commitments (for
example, in viewing the world in terms of topics, associations, occurrences,
scope, etc.) that may not always coincide with those in use in the world at
large.
4. The purpose of the TMRM in providing a model with fewer ontological
commitments that can serve as both a mathematical foundation and a method of
disclosure for the TMDM and other subject-centric assertion models.
5. How the TMRM does this by defining the concept of “subject maps”
(without any technical description of what these are).
Other than an informal mention of the term "subject maps," TMRM terminology
should not be used in the Introduction.
Accepted.
4. Subjects: If the concept of "subject" is the same here as in Part 2, the
definition in Part 2 should be referenced instead and no additional
explanatory prose included. If not, a new term should be used.
Accepted.
5. Subject Proxies and Maps: Note 1 should be removed since the definition
and explication of the concept of subject should be left to Part 2.
Accepted.
6. The forward reference to Clause 8 is either unnecessary or else it
indicates a weakness in the order of exposition.
Accepted.
7. Merging:
It is unclear what is meant by "application" in this clause. It is not the
same as in the preceding clause (bullet point a), where it clearly means "the
act of applying". Given the variety of ways in which the term can be used in
information technology, it should be defined and other usages (such as in
Clause 6) should be avoided.
The paragraph beginning "Any merging criteria..." would seem to be rather
central to one of the main concepts of the TMRM, namely that of disclosure. It
should therefore be given more prominence and made less vague. If merging
criteria are required to be disclosed, this should be stated clearly. Anything
else for which disclosure is required should also be stated clearly: a simple
"for example" is not sufficient.
Accepted.
8. Map Legends: This section mixes informal prose and formal definitions in
a way that could make the clause as a whole subject to interpretation.
Accepted. (The prose in question will become a note.)
Topic Maps Data Model (ISO 13250-2) Mapping:
The footnote is unnecessary and should be removed. Other footnotes should
be turned into ISO-style Notes.
It is not clear if this Annex is intended to be (or contain) a Map Legend
as defined in Clause 8. If that is the case, this should be made clear.
Subhead B.1 should read “Topic Maps as Subject Maps” since the purpose of
this section is to demonstrate that a topic map as defined in ISO 13250 can be
regarded as a form of subject map.
The intent of the last paragraph of this section is not clear. Is it to
state that a topic map is a subject map, that every topic map construct is a
subject map, or both?
In the first paragraph of B.2.1, the term “locators” is inappropriate. The
data types mentioned are assigned identifiers in the form of IRIs. The fact
that they are locators is not relevant.
In the model at the end of this subsection, a typographical distinction
should be made between instance and type, on the one hand, and key and
datatype, on the other.
Accepted. (Annex B is to be redrafted.)
Comments from the UK National Body
1. The use of symbols that are not reproducible in emails, HTML or basic
editing tools means that the notation proposed for Part 5 is not suitable for
generalized discussion of the subject.
Rejected.
2. Who does conforming? Is this software or other models?
Rejected (pending next CD draft).
Point d) in the constraints forces topic map applications to implement both
isa and subclass relationships, yet sub classing is not strictly necessary for
topic map applications (you don't have to support the optional variant name
facility)
Deferred to revision of conformance clause.
The use of terms that have no direct correlation with other parts of the
standard make it difficult to ensure that other parts conform to the data
model.
Accepted.
The use of the term isomorphous in the first item of the constraints clause
is obfuscatory. Maybe explain with words of less syllables.
Accepted as needing clarification.
Merging: Defining the merging operator in Clause 6 and the merging process
in Clause 7 could cause someone coming straight to Clause 7 based on the title
to miss the need for a merging operator. (There is no reference to the
operator in Clause 7.)
Rejected.
