---

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.