ISO/IEC JTC 1/SC 34N0739
ISO/IEC JTC 1/SC 34
Information Technology --
Document Description and Processing Languages
|TITLE:||Summary of Voting on JTC 1/SC 34 N 710 - Text for CD Ballot - ISO/IEC CD 13250-5 - Topic Maps - Reference Model|
|PROJECT:||CD 13250-5: Information technology - Topic Maps - Reference model|
|PROJECT EDITOR:||Mr. Patrick Durusau; Dr. Steven R. Newcomb|
|STATUS:||Summary of voting|
|ACTION:||Based on the ballot responses, this CD is APPROVED and the project status changes to 30.60. Project Editors are requested to review comments and advise the Secretariat regarding (1) the change to status 30.92 or 30.99, and (2) the next project status and anticipated date that project status will change.|
|DISTRIBUTION:||SC34 and Liaisons|
|REFER TO:||N0710b - 2006-02-26 - Ballot due 2006-05-26 - ISO/IEC CD 13250-5 - Topic Maps - Reference Model
N0710 - 2006-02-26 - Text for CD Ballot - ISO/IEC CD 13250-5 - Topic Maps - Reference Model
Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Kars, ON K0A-2E0 CANADA
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: [email protected]
|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|
|Korea, Republic of||X|
- 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.
- 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.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.
- 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.
Korea, Republic of
* 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?)
- 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) “}” --> “)}”
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.
This section should be omitted in further drafts until the document reaches FDIS stage.
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.
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?]
The forward reference to Clause 8 is either unnecessary or else it indicates a weakness in the order of exposition.
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.
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.
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).
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.
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.)