| P-Member |
APPROVAL OF THE DRAFT AS PRESENTED |
APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED |
DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED |
DISAPPROVAL (appropriate changes in the text will change vote to APPROVAL) |
ABSTENTION (For Reasons Below) |
NO RESPONSE |
| Canada |
|
X
|
|
|
|
|
| China |
|
|
|
|
|
X
|
| Italy |
X
|
|
|
|
|
|
| Japan |
|
|
|
X
|
|
|
| Korea, Republic of |
|
X
|
|
|
|
|
| Netherlands |
X
|
|
|
|
|
|
| Norway |
|
X
|
|
|
|
|
| Thailand |
|
|
|
|
|
X
|
| United Kingdom |
|
X
|
|
|
|
|
| USA |
X
|
|
|
|
|
|
editorial:
- Numbered page 4, first paragraph, last sentence, suggest it read "This primitive path is denoted by PM".
- Numbered page 4, first Note, "...only serves as *a* minimal baseline...", and "It can also be used as *the* basis for a...".
- 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.
1. Technical
- (1.1)
-
In order to identify the properties, proxies, subjects, etc., Published Subjects
should be used.
- (1.2) Clause 3
-
There are possibilities of polysemy problem in the keys.
It should be mentioned how to handle it in the keys.
- (1.3) Clause 8
-
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.
2. Editorial
- (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.
- (2.2)
-
Clause "Normative references" and "Terms and definitions" should be added.
- (2.3) Clause B.2.2
-
" ... at table A.2."
should be
" ... at Table B.2.".
- (2.4) Clause B.2.3
-
" ... listed in Table A.1."
should be
" ... listed in Table B.1."
- (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.
- (2.6) Table B.2
-
A "reified" key and its value should be added to the Table B.2.
*
KATS comments on N0710
* The document has improved
much from the previous version and provides philosophical background
for the Topic Maps.
* 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.
* 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 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?)
* Typos:
- page 10:
e) … tuple projection
<p1, … --> tuple projection (p1, …
i) … Iff --> If and
only if
- page 12:
table A.2
--> table B.2
Table A.1 --> Table B.1
(footnote) Table A.2 -->
Table A.2
- page 15:
(B.5) “topic =”
--> “topic item = ” (??)
(last line) “}”
--> “)}”
General
In general the document seems to be developing in a useful
direction. However, it is also becoming significantly more complex
technically. For this reason, we reserve comments on the more
technical parts until after the presentation of this document that is
due to be given at WG3's meeting in Seoul in May 2006. Because of
this, a new CD ballot round should be held after that meeting.
The phrase “this Standard” should be changed such that
it does not appear to refer to ISO 13250 as a whole.
Foreword
This section should be omitted in further drafts until the
document reaches FDIS stage.
Introduction
Most of the problem statement in the current draft applies to the
whole of 13250 and is therefore not appropriate for this Part.
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:
-
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.
-
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.
-
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.
-
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.
-
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.
1. Scope
No comments.
2. 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.
3. 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.
[Additional comments on the definitions,
examples, and notes in Clause 3?]
6 Constraints
The forward reference to Clause 8 is either unnecessary or else it
indicates a weakness in the order of exposition.
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.
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.
9 Conformance
We reserve judgment on the need for such a clause, and the form it
should take, until after the presentation of this draft (ensuing
discussion) that will take place at the Seoul meeting of WG3.
Annex A τ Path
Language
We reserve judgment on the need for this annex until after the
Seoul presentation and discussion.
Annex B 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.
1. General
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.
2. Constraints & Conformance:
Who does conforming? Is this software or other models?
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).
3. Terminology
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.
The use of the term isomorphous in the first item of the constraints clause is obfuscatory. Maybe explain with words of less
syllables.
4. 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.)
