Editor’s 5th Draft Resolution of Comments on SC32 N1851 CD2 11179-3 / Date: 2009-11-05 / Document: JTC 1/SC 32/WG 2/N1327
0 / 1 / 2 / (3) / 4 / 5 / (6) / (7)
Seq / MB1
/ Clause No./
Subclause No./
Annex
(e.g. 3.1) / Paragraph/
Figure/Table/Note
(e.g. Table 1) / Type of com-ment2 / Comment (justification for change) by the MB / Proposed change by the MB / Secretariat observations
on each comment submitted

ISO/IEC JTC1/SC32/WG2 N1327

Title:Editor’s WIP draft disposition of comments on-CD2 11179-3 Edition 3

Supersedes:-

Source:Ray Gates (Editor)

Status:Editor’s draft disposition of comments

Action:For distribution to WG2

Date:05 November 2009

This document is a Work in Progress. It shows the proposed resolution of ballot comment on CD2 11179-3 and records the progress in applying them to the revised text in WG2 N1326.

Another update of this document will be submit to the London WG2 meeting.

/ CA 01 / 00 All / All / Te / All Editor's Notes should be addressed. / Some are addressed by specific comments below. / Accepted in principle. Need specific proposals.
/ CA 02 / 00 All / All / Te / All open issues for this project on the WG2 Issues forum should be reviewed, and a consensus reached as to which need to be addressed in this Edition. / Specific proposals will be submitted to the ballot resolution meeting. / Accepted in principle. Need specific proposals.
/ CA 03 / 00 All / All / Te / A US ballot comment on the CD1 pointed out that CD1 used a mixture of the terms: subtype, sub-type, subclass and sub-class, and called for consistent terminology. The resolution of the comment was to use ‘subtype’ exclusively, and ‘supertype’ as its counterpart. On reviewing the definitions of type and class in 19505, we believe the resolution was incorrect, and we should in fact be using ‘subclass’ and ‘superclass’. Do not make the change blindly. Review each use of the terms to ensure it is appropriate. / Review all uses of the terms ‘subtype’ and ‘supertype’ and change to ‘subclass’, ‘superclass’ where that those terms better reflect the intended meaning. / Accepted. See also JP 07 (#66)
/ CA 04 / 00 Foreword / Ed Note / Ge / Editor’s Note 1 questions the status of 11179-2. / WG2 should determine the future of 11179-2.
Delete Editor’s note 1. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ US 01 / 00 Foreword / te / EDITOR'S NOTE #1.(Action Required by FCD) For the 3rd edition of ISO/IEC 11179, it is expected that part 2 will be withdrawn, since part 3 has subsumed its content. / It is not obvious that Part 2 should be withdrawn. There is likely valid content for Part 2, so take no action at this time. This has not been substantially discussed in WG 2 and should be. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ 20944 editor 01 / 00 general / te / The use of packages and the lack of a combining feature make it impossible to know how the packages features are combined. This was straightforward in Edition 2, but there is no guidance in Edition 3 on how to put all this together. / Provide guidance on how to provide a whole metadata set. / Comments supplied to secretariat from 20944 Project Editor
Accepted.
/ JP 01 / 00 General / 1-Major Technical / Japan NB is strongly be aware of the duplication among the ISO/IEC11179-3 Ed3 and ISO/IEC19763-3 in the term of the ontology registrations.
Japan NB is not able to approve this standard unless some actual activitiesbe initiated and confirmed in the SC32 for the reconciliation of those duplication. / Should be addressed in MDR/MFI Harmonization study period. Do not delay progression of the document in the meantime.
Explicit reference to ontologies to be removed from normative text by resolution of JP 19 (#168)
/ JP 02 / 00 General / 1-Major Technical / Two different frameworks are introduced to 11179-3 Ed3. They should be one.
One is a usual logical framework, where two worlds are:
Real world---Universe of Discourse
Representation (Designation, Symbol, Sign) world ---logical representation.
The other is so-called meaning triangle framework from ISO 1087-1, where three worlds are:
Real world --- object, subject field at 3.1 of ISO 1087-1
Concept world---- concept, concept system at 3.2 of ISO 1087-1
Representation world----definition, designation, terminology at 3.3,3.4., 3.5 of ISO 1087-1.
What 11179-3 Ed3 specifies is a registry for Representation world, simply because we cannot handle Real world nor Concept world without representation, even though Concept and Concept_System are used as class names.
A problem rises if ontologies such as SKOS are with in the scope of 11179-3 Ed3. Because ontologies, including the ones in RDF, OWL and Common Logic etc. are based on the usual logical framework and they do not represent Concept world of ISO 1087-1, but represent Real world. / Proposed changes:
There are two choices.
One is to limit the scope where ISO 1087-1 framework (i.e. a kind of meaning triangle). Then, its underlying framework is of ISO 1087-1 and ontologies that are based on the usual logical framework are out of scope.
The other is to remove ISO 1087-1 from a normative reference and rename the classes such as "Concept" and "Concept_System".
Then, its underlying framework is just of Representation world and is very flexible. / Not Accepted.
We do not agree with the distinction that has been made.
However, the resolution of JP19 (#168) removes all reference to Ontology from the description of Concept System. However, informative annexes will still illustrate that Concept_System can support at least some ontologies.
/ CA 05 / 00 Introduction / Ed Notes / Ed / Editor’s notes 2 and 3 are no longer required. / Delete Editor’s notes 2 and 3. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ US 02 / 00 Introduction / ge / EDITOR'S NOTE #2. (Informational) Throughout this Committee Draft, EDITOR'S NOTEs make reference to 'issues' that are either addressed or not addressed by this document. Details of these issues may be found on the WG2 Issue Management website at: . To locate a specific issue, the generic format of the URL is: where the number at the end is the issue number, without leading zeroes. / OK. Informational, no action required. / Resolved by CA 05 (#9). Editor’s note to be deleted.
/ US 03 / 00 Introduction / ge / EDITOR'S NOTE #3. (Action required) There have been extensive changes from both the second edition of this standard, and from CD1 of the third edition. The whole document needs careful review and comment. / We are providing that in our comments on this ballot. / Resolved by CA 05 (#9). Editor’s note to be deleted.
/ CA 06 / 01.1 / para 2 / Ed / The last sentence of para 2 refers to a subclause that no longer exists because the text was moved to the Introduction. / Delete the last sentence of para 2. / Accepted.
Done
/ CA 07 / 01.2 / para 1 / Ed / `structure of the a metadata registry`is wrong. / Delete `the / Accepted
Done
/ GB 01 / 01.2 / ed / Typo - extra word / Remove “is” in “… conceptual data model is in Clauses …” / Accepted
Done
/ CA 08 / 01.3 / para 1 / Ed / The reference to clause 9 is incorrect. / Change the reference to clause 11. / Accepted
Done
/ CA 09 / 01.4 / List item 1 / Ed / The referenced version of UML is incorrect. / Change UML 2.0 to UML 2.1.2 / Accepted
Done
/ CA 10 / 01.4 / List item 4 / Ed / The clause reference is missing. / Add: (see 8.1) / Accepted
Done
/ CA 11 / 02 / ISO 12620 / Ed / ISO 12620 is listed in the normative references, but does not appear to be referenced anywhere in the document. / Either remove this document from the normative references, or add references to it at appropriate places in the document. / Accepted. Move the reference to the bibliography.
Done
/ CA 12 / 02 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. Also, remove the DIS as soon as the IS is published. / Accepted
Done
/ US 24 / 02 / ed / The Clause 2 reference to UML is incorrect / It should be to ISO/IEC DIS 19505-2 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 — Part 2: Superstructure / Accepted, but include as dated reference.
Done
/ CA 13 / 03.2.01 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. . Also, remove the DIS as soon as the IS is published. / Accepted
Done
/ CA 14 / 03.2.02 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. . Also, remove the DIS as soon as the IS is published. / Accepted
Done
/ CA 15 / 03.2.04 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. . Also, remove the DIS as soon as the IS is published. / Accepted
Done
/ CA 16 / 03.2.05 / Example needed / Te / Add a reference to an example of a composite attribute. / E.g. reference Registration.registration_state in Figure 7-1 / Accepted
/ CA 17 / 03.2.06 / Example needed / Te / Add a reference to an example of a composite datatype. / E.g. reference Registration_Record as used by Registration.registration_state in Figure 7-1 / Accepted
/ CA 18 / 03.2.08 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. . Also, remove the DIS as soon as the IS is published. / Accepted
Done
/ CA 19 / 03.2.11 / ISO/IEC DIS 19501-2 / Ed / The reference to 19501-2 is incorrect. It should be 19505-2. / Change 19501 to 19505. . Also, include DIS in the reference until the IS is published. / Accepted
Done
/ CA 20 / 03.2.12 / New / Te / Add a definition of specialization, as a counterpart to generalization (3.2.8). The term specialization is used in the text. / Editor is requested to locate an appropriate definition from 19505, and adapt it if required. / Accepted. Done with some changes to the definitions of generalization and relationship to better align them.
/ US 25 / 05.1.13.2.6 / te / This paragraph says that reference_provider is mandatory. However, the reference_provider may not be known. / reference_provider should be made optional / Accepted
Done.
/ CA 21 / 03.3, 03.4 / All / Ed / The separation of subclauses 3.3 and 3.4 no longer serves any purpose, now that the 3.4 contains terms and not model elements. / Combine the two subclauses, and order the terms alphabetically within the combined clause. / Accepted. Done
See also US 26 (#33) & US 50 (#34)
/ CA 22 / 03.3.14 / Add Note / Ed / A reference should be added to Clause 3.4.40 designation (of designatable item) / Add a note referencing 3.4.40. / Accepted.
Done.3.3.14 has become 3.3.51, and 3.4.40 has become 3.3.52.
/ GB 02 / 03.3.15 / ed / The definition of the term "entity" is dubious given its usage in the remainder of the document. It makes the reader wonder whether it is intentionally indicating an "entity instance" rather than the common usage of "entity kind" or “entity type”. It also makes the reader wonder whether it intentionally excludes imaginary concepts that could never exist. In fact the term is then used with apparently different meanings.
It is used in the definition of "attribute", where given the current definitions of entity and object it does not seem useful (e.g. "object or entity" could be replaced by "object or set of objects").
It is used in the definition of "organization part", where it appears to have a more specific meaning.
It is used in the definition of "text", where the term "object" could have been used.
It is used in the commentary on the registry metamodel, where it probably means a UML class used to specify the metamodel. / One consistent resolution would be:
- Drop the definition of entity.
- Replace by "set of objects" in "attribute"
- Replace by "object" in "text"
- Replace by "class" in describing registry metamodel.
- Be satisfied with its regular English definition for its one remaining usage in "organization part". / Accepted.
-Done
-Done
-Done
-Done
/ US 26 / 03.4 / ed / It is not clear which model construct names constitute also terms which should be defined in clause 3, and which do not. Many model element names are not defined in clause 3.4. / Concepts should be defined in Clause 3. Clause 3 should not define the model elements--classes, attributes, and associations, which should be defined in the clause where they are specified. Terms and definitions should be included in Clause 3 only if they are necessary for the understanding of those terms as used elsewhere in the document (see ISO/IEC Directives, Part 2, Clause 6.3.1). Clause 3.4 should be reviewed to see that each term conforms to the above.
Prefer resolution according to US 50(#34).
Keep if US 50 not accepted. / The terms included in clause 3.4 are concepts which are represented in the model. The terms included are for all classes in the model, and for selected attributes and associations, where the editor felt the concepts were significant. In general, the concepts represented by attributes have not been included in clause 3.4.
Add text explaining what is included and what is not, for merged clause 3.3/3.4.
List here any terms we decide to remove.
/ US 50 / 03.4 / te / Model constructs are not terms in the TC37 sense. They should be defined where they are presented in clauses 4 – 12. / Remove the sub-clause. Provide definitions of model constructs where they are presented in the clauses 4 – 12.
See also:
US 26 (#33)
US 27 (#39)
US 28 (#40)
US 29 (#42) / The specification of model constructs have already been moved to Clauses 5 through 10. What is left in clause 3.4 are the concepts that the model constructs implement.
These concepts belong in clause 3, but CA 21 (#30) proposes merging clauses 3.3 and 3.4.
Resolved by CA 21 (#30).
/ CA 23 / 03.4.18 / definition / Te / Editor’s note 4 indicates that the definition needs work / TBD / Resolved by US 04 (#36).
/ US 04 / 03.4.18 / te / data element
Data Element
DE
------
EDITOR'S NOTE #4. (Action required) There has been feedback from users of 11179 that this is not a useful definition. It should be reviewed.
------
unit of data for which the definition, identification, representation and value domain are specified by means of a set of attributes / Remove current definition and put in the definition from ISO/IEC 2382:
Part 4 - 04.07.01:
data element (in organization of data)
A unit of data that is considered in context to be indivisible.
Example: The data element “age of a person” with values consisting of all combinations of 3 decimal digits. / AcceptedDone
/ CA 24 / 03.4.19 / definition / Te / The definition of Data Element Concept is too generic. There is nothing that ties it to a data element, or otherwise distinguishes it from a simple Concept.
[This is Issue 456 in Bugzilla.] / TBD / Same as JP 03 (#38).
Revert to definition from Edition 2. Done.
/ JP 03 / 03.4.19 data element concept / 2-Minor Technical / The definition is substantially different from the one in Ed2. This new definition is too broad at least in the following three senses.
1) According to this definition, almost everything, including class definition, is a data element concept, which is not true.
2) A concept in ISO 1087-1 includes an individual concept (almost same as instance or individual). So, according to this definition, any specification of some individual is a data element concept, which is not true.
3) "Specification" usually means that it accompanies with some representation. / Revert to definition from Edition 2. Done.
See also US 40 (#195)
/ US 27 / 03.4.2,
03.4.4, 03.4.72, 03.4.92, 03.4.93, 09.1.2 /
ed / The terms "antisymmetric relation", "asymmetric relation", "reflexive relation", "symmetric relation" and "transitive relation" are defined in clause 3 but not used in the model; while "reflexivity", "symmetry" and "transitivity" are used in the model, but not defined in clause 3. / The definitions should be changed to be definitions for the terms used in clause 9. The meanings are currently all fully specified in clause 9; the definitions should be made in clause 3, and then simply used as defined there, in clause 9.
Prefer resolution according to US 50 (#34). Keep if US 50 not accepted. / Accepted. Done.
/ US 28 / 03.4.28,
05.1.4 / ed / The term "date and time" was not changed everywhere to "date" and "datetime". / The definition for "date and time" should be replaced with definitions for "date" and "datetime". Text in clause 5.1.4 should also be changed.
Prefer resolution according to US 50 (#34). Keep if US 50 not accepted. / Accepted. Done.
/ CA 25 / 03.4.40 / Note / Ed / The clause reference is incomplete. / The referenced clause should be 3.3.14. / Accepted Done, though reference has now changed because clauses 3.3 and 3.4 have been combined.
/ US 29 / 03.4.53, 03.4.73 /
ed / The terms "management" and "register" are defined in clause 3, but not used in the model. / Remove these terms from clause 3.
Prefer resolution according to US 50 (#34). Keep if US 50 not accepted. / Accepted Done.
/ CA 26 / 03.4.71 / Ed Note / Ed / The editor’s note is no longer required. / Delete Editor’s Note 5. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ US 05 / 03.4.71 / te / EDITOR'S NOTE #5. (Action Required) Do we need to be able to distinguish different types of reference_provider? For example, one organization might maintain the document, but another might publish it or make it available. / This would seem to be beyond the scope of 11179. Take no action. / Accepted
Placeholder left to preserve numbering of Ed’s notes.
/ US 30 / 03.4.81 / te / The definition of relation is confusing and it does not meet the requirement of ISO/IEC Directives Part 2: Rules for the structure and drafting of International Standards / Proposed revised definition:
sense in which concepts may be connected, via constituent roles.
Example: causality is a relation with two constituent roles: cause and effect.
Move definition to Clause 3.3. / Accepted change to definition. Done.
Relocation resolved by CA 21 which combines clauses 3.3 & 3.4.
See also US 39 (#176)
/ JP 04 / 03.4.81 relation
08.1.2.4.1 Description of Relation / 2-Minor Technical / "A relation is a subset of the powerset of RxUD" is not true. The powerset of RxUD is not equivalent to Cartesian product UD x ... x UD / Resolved by US 30 (#45)
New definition provided.
/ JP 05 / 03.4.81 relation
08.1.2.4.1 Description of Relation / 2-Minor Technical / To define relation in terms of universe of discourse is inappropriate because relation is about Concept world since Relation is subclass of Concept, but universe of discourse is about Real world. / Resolved by US 30 (#45).
New definition provided.
/ JP 06 / 03.4.81 relation
08.1.2.4.1 Description of Relation / 2-Minor Technical / It needs to be clarified whether this relation is a relations only among general concepts or not.
Posted to Bugzilla as Issue 489. / Add text to clarify that Concepts may be general or individual, and this can depend on perspective. Add example in an Annex e.g. Dog. Reference to general and individual concepts should be restricted to Notes to avoid having to define them.
/ CA 27 / 03.4.84 / definition / Te / The definition uses the plural where singular would be more accurate. / Reword :
‘container for extensions to identified items’
as:
‘container for an extension to an identified item’ / Accepted Done.
/ CA 28 / 03.4.89 / Ed Note / Ed / The editor’s note is no longer required. / Delete Editor’s Note 6. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ US 06 / 03.4.89 / ge / EDITOR'S NOTE #6. (Information) The editor has changed the above definition, because the previous definition was defined as an association with Submission_Record, but that is defined in terms of submission, so the result was circular. / OK. Informational, no action required. / Resolved by CA 28. (#50)
/ CA 29 / 03.4.91 / Ed Note / Ed / The editor’s note is no longer required. / Delete Editor’s Note 7. / Accepted.
Placeholder left to preserve numbering of Ed’s notes.
/ US 07 / 03.4.91 / ge / EDITOR'S NOTE #7. (Information) The editor has changed the above definition, replacing registered item by metadata item for registration, because the item is not yet registered when it is submitted. / OK. Informational, no action required. / Resolved by CA 29 (#52)
/ CA 30 / 03.5 / All / Ed / The list of abbreviations only fills the left side of the page. / Use two columns in this section. / Accepted. Done.
/ CA 31 / 03.5.04 + / New / Te / Insert after 3.5.4 an explanation of ‘mece’ (usage to be added by another ballot comment on clause 4.5) / mece
mutually exclusive and collectively exhaustive / AcceptedDone.
/ CA 32 / 04.1 / para 2 / Te / The first sentence states that the metamodel describes the ‘structure’ of a Metadata Registry. The term structure is too vague. / Replace ‘structure’ by ‘information model’. / Accepted. Done.
/ GB 03 / 04.3.4
05 to 10 / ge / In Clauses 5 to 10 the attributes of each class are defined three times: in the UML diagram; informally in the ‘n.n.1’ part of the text describing the class; and formally in the ‘n.n.2’ part of the text. The associations are also defined three times: in the UML diagram; informally in the ‘n.n.1’ for each class participating in the association; and formally in a separate part of the text. Clause 4.3.4 states that if a conflict exists between what is specified in the UML diagrams and what is specified in the text the text takes precedence. In principle this is supported but there is a potential problem in that it is unclear which text should take precedence in the event of a conflict between the informal description in the ‘n.n.1’ part of the text and the more formal descriptions in the ‘n.n.2’ and association parts of the text. / Restructure clauses 5 to 10 to avoid duplication of information thus eliminating the possibility of inconsistency. / The different representations are present to satisfy different audiences.