ISO/IEC JTC 1/SC 34N0496
ISO/IEC JTC 1/SC 34
Information Technology --
Document Description and Processing Languages
| TITLE: | Editors' disposition of comments on N0483 |
| SOURCE: | Mr. Graham Moore; Mr. Lars Marius Garshol |
| PROJECT: | CD 13250-2: Information Technology - Document Description and Processing Languages, Topic Maps - Data Model |
| PROJECT EDITOR: | Mr. Lars Marius Garshol; Mr. Graham Moore |
| STATUS: | Disposition of comments |
| ACTION: | For information |
| DATE: | 2004-04-01 |
| DISTRIBUTION: | SC34 and Liaisons |
| REFER TO: | N0483 - 2004-02-06 - Summary of Voting on JTC 1/SC 34 N459 CD of ISO 13250-2: Topic Maps -- Data Model |
| REPLY TO: |
Dr. James David Mason (ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada) Crane Softwrights Ltd. Box 266, Kars, ON K0A-2E0 CANADA Telephone: +1 613 489-0999 Facsimile: +1 613 489-0995 Network: [email protected] http://www.jtc1sc34.org |
Editors' disposition of comments on N0483
The editors thanks the Japanese and US national bodies for their input. We hope this constitutes sufficient response, but would be happy to discuss the issues further at the Amsterdam meeting.
Japan comments
The descriptions on HyTime should be deleted, in accordance with the WG3 Recommendation 6 approved in the Philadelphia meeting.
The references to HyTime have been removed.
"The Unicode Standard, Version 3.0" should be replaced with "The Unicode Standard, Version 4.0", which is the latest version.
The reference has been updated.
ISO/IEC 10646 should be added as a Normative reference.
We are uncertain about this. It seems redundant to reference ISO/IEC 10646, and it also seems unclear what such a reference should mean. Input is wanted on this issue, which will be brought up at the Amsterdam meeting.
Only the data-model specific terms should be defined in this clause. Generic terms of ISO/IEC 13250 should be defined in "3 Terms and definitions" of Part 1.
The committee has discussed this, and decided that Part 1 should have no normative text. This means that the definitions must be in part 2.
In 3.7, "fundamental types" should be "fundamental type", since a term should be defined as singular.
This term is not needed, and so has been removed entirely.
In 3.26, the sentence "The topic thus ... of the topic." should be described as a NOTE of 3.26.
The editors feel that this is an intrinsic part of the definition, and would prefer to leave it as it is, but welcomes input from other parties familiar with ISO guidelines.
All the figures should be accompanied with their numbers and captions.
We will add numbers and captions to the figures.
6.7 Merging association role items
Clarify the procedure more comprehensibly
This seems quite comprehensive to us. Please explain what it is about this section that is difficult to comprehend. We would prefer not to try to change this clause without a better understanding of what the problem is.
The clause "7 Published subjects" should be moved to Part 1 of ISO/IEC 13250, since the clause specifies generic issues of ISO/IEC 13250.
Again, given the committee decision on the status of Part 1, this cannot be done.
US comments
The US National Body has previously stated that no part of the current restatement of ISO 13250 should progress beyond CD until the Topic Maps Reference Model is also at CD status (see N477). The motivation for this position is to ensure that the different parts of this multi-model standard are coordinated. In furtherance of the goal of consistency, we feel that the data model should not progress to CD before the other parts. The US National Body therefore votes against progressing the current draft of ISO 13250-2 to CD.
We note the US position, but since progress on ISO 13250-3, ISO 13250-4, ISO 19756, and ISO 18048 all depend crucially on ISO 13250-2, we feel that it is imperative that ISO 13250-2 move forward. Also, given that the committee has not yet decided whether to continue the work on the Reference Model, and there is no CD-ready draft of it yet, it does not seem appropriate for the RM to move to CD, or for ISO 13250-2 to wait for it.
Note that there are two other rather severe defects in the proposal:
1. The most telling is the lack of any means of documenting an extension to the data model for additional merging rules. While the data model allows additional merging rules, the proposal provides no means for documenting such extensions. As a result, different implementations may treat the same data completely differently. Even more pernicious is that this unpredictability locks users into a particular vendor's software after a merger since in general the merging rules cannot be deduced after the fact.
There is no need to extend the data model in order to define application-specific merging rules. Applications are free to define any additional merging rules they want; this falls under what is termed "authoring," and so there are no constraints on what additional merging is allowed. Those creating applications can define merging rules in whatever way they wish, and provide documentation as part of the topic map or externally, as they please.
As regards "vendor lock-in" from undefined merging rules this is an issue between the vendor and its customers. It is difficult to see to what extent this can be considered an issue with the current draft. If the US wishes to see this addressed, it would be welcome if the US could suggest some means of doing so.
We do recognize that support for and documentation of merging based on complex criteria is a real and useful requirement, but there are several reasons why we feel support for this requirement does not belong in ISO 13250 itself:
- The restatement of ISO 13250 was intended to correct flaws in the original standard by introducing a data model, but not to introduce major new features like these.
- ISO 13250 as envisioned is meant to just be the model, the interchange syntax, and a canonical syntax for test purposes. This provides the foundation for capabilities such as complex merging rules, but we feel that such rules do not belong in the data model itself. Like other constraints and operations they belong as part of TMCL and TMQL.
2. The other defect is a limitation of subject identity to potentially network-accessible resources. This limitation does not exist in the current ISO 13250 standard and should not be introduced now.
It is not clear to us how to interpret this comment, but we see two possible interpretations:
"Only subjects which are network-accessible resources can be identified using this model."
This is incorrect, as paragraphs 2 and 3 of clause 5.4.2 clearly describe how subjects which are not network-accessible can be identified.
"Subjects can only be identified via potentially network-accessible resources, but it should be possible to use other forms of identification."
The note at the end of 5.4.6 shows how subjects can be identified using ISBN numbers, which are not network-accessible resources. It could be argued that this is in contradiction with the definitions in 5.4.2, about which, more below.
We do feel that 5.4.2 is less clear than it could be, and at the same time that the wording implies an unintentional restriction. We suggest amending 5.4.2 to read as follows, with additions marked thus:
Formal identification of subjects with locators allows topic maps to be merged safely and precisely, and also allows the definition of subjects with semantics that can be implemented in topic map systems. Examples of such subjects can be found in Clause 7.
A subject locator is a locator that refers to the information resource that is the subject of a topic. The topic thus represents that particular information resource; i.e. the information resource is the subject of the topic. Different locators are assumed to identify different information resources.
However, not all subjects are information resources, addressable with locators, and so a similar mechanism—subject indicators— is provided, by means of which any subject may be identified.
A subject indicator is an information resource that is referred to from a topic map in an attempt to unambiguously identify the subject of a topic to a human being. Any information resource can become a subject indicator by being referred to as such from within some topic map, whether or not it was intended by its publisher to be a subject indicator.
A subject identifier is a locator that refers to a subject indicator. Topic maps contain only subject identifiers, and consequently it is the subject identifier that is the basis for merging; the subject indicator is ignored during merging. The subject indicator referred to is not required to actually exist, though this is considered good practice.
(The example following would be retained unchanged.) Feedback on this proposed change would be welcome.