ISO/IEC JTC 1/SC 32 WG2-EM0112-003
Date: 2001-12-11
REPLACES:
WG2-VIC-017R6
ISO/IEC
JTC 1/SC 32
Data
Management and Interchange
Secretariat: United States of America (ANSI)
Administered by Pacific Northwest National Laboratory
on behalf of ANSI
|
DOCUMENT TYPE |
Resolution of Ballot
Comments |
|
TITLE |
Draft Resolution of Ballot Comments in 32N0691 on
32N0643 ISO/IEC FCD 11179-3:200x Information technology - Data management and
interchange - Metadata registries (MdR) - Part 3: Registry metamodel (MdR3) |
|
SOURCE |
Ray Gates, Project Editor |
|
PROJECT NUMBER |
1.32.15.02.03.00 |
|
STATUS |
For information |
|
REFERENCES |
32N0643, 32N0691 |
|
ACTION ID. |
ACT |
|
REQUESTED ACTION |
|
|
DUE DATE |
|
|
Number of Pages |
100 |
|
LANGUAGE USED |
English |
|
DISTRIBUTION |
FCD11179-3 Continutation
Editing Meeting |
Douglas Mann, Secretariat, ISO/IEC JTC 1/SC 32
Pacific Northwest National Laboratory *, 901 D
Street, SW., Suite 900, Washington, DC, 20024-2115,
United States of America
Telephone: +1 703 379 6915 x 111; Facsimile; +1 703
379 8934; E-mail: MannD@battelle.org
available from the JTC 1/SC 32 WebSite http://www.jtc1sc32.org/
*Pacific Northwest National Laboratory (PNL)
administers the ISO/IEC JTC 1/SC 32 Secretariat on behalf of ANSI
Note that 32N0691 mistakenly included comments from the Netherlands that were intended for the ballot on the Data Mining document. The Netherlands comments have been omitted from the list below.
Note: CEM = Continuation Editing Meeting.
|
SEQ# |
Cmnt ID |
See Also |
Severity |
Reference |
Description |
Addressed By |
|
AU00 |
AU44 (#210) |
0-General |
P03 |
Australia
votes in favour of approval of the FCD and its rapid progression to IS in
tandem with revisions of other Parts of ISO 11179 Proposed Solution
Conditional
on deletion of Figure 1 in Clause
4.4. but not conditional on
acceptance of other comments |
Resolved by #210 (AU44). No action here. |
|
|
CAN-P03-001 |
CAN-P03-004 (#007) CAN-P03-105 (#010) CAN-P03-108 (#004) CAN-P03-142 (#303) |
1-Major Technical |
P03 |
An Editor's
Note on the cover page proposes reviewing the name of the overall standard
and of each part. Canada reiterates
its comment on CD 11179-3, with some elaboration. Background: a) The overall
title of the IS 11179 family of standards is: “Information technology --
Specification and standardization of data elements”. b) The title
of the original Part 3 is: “Part 3:
Basic attributes of data elements”. c) Part 1:
Framework for the specification and standardization of data elements was
published as recently as 1999. d) 11179 is a
well-recognized standard that is used for more than just registries. It is
referenced from documents as diverse as:
e) The title
on the new FCD 11179-3 is:
“Information technology - Data Management and Interchange - Metadata
Registries (MdR) - Part 3: Registry Metamodel (MdR3)”. There are
several problems with the new title: Problem 1:
The proposed title of the overall family of standards “Metadata
Registries (MdR)” drops all reference to Data Elements which is the primary
purpose of the current 11179. We need
to provide continuity with the current 11179 in both name and content. New areas of standardization should be
addressed in new standards or new parts, and should not be allowed to
subvert existing standards. We need
to maintain the capability to use 11179 for more than just registries. Problem 2:
The use of the term “metadata registry” without qualification suggests
that the registry can handle more than it actually can. Even with the expanded scope of the
metamodel, 11179 covers only a small subset of all metadata. The registry is still very much focused on
data elements and associated metadata, especially: data element concepts,
conceptual domains and value domains.
It in no way attempts to address other types of metadata such as
document metadata or database schemas. Problem 3:
The proposed title of the revised part 3 “Registry Metamodel (MdR3)”
drops all reference to the basic attributes, which is what the published part
3 is all about. Again, we need
continuity from the existing standard. Problem 4: While the acronym “MdR” is potentially
useful, we see no value in the acronym “MdR3”. Problem 5: The insertion in the title of the SC32
name “Data Management and Interchange” makes the title unnecessarily
long. It is not required by
ITTF. The Foreword will state that
the standard is the work of SC32, so this does not need to be part of the
title. Proposed Solution
Proposal 1: Remove the text “- Data Management and
Interchange” from the title. Proposal 2: For the 11179 family use the name: “Specification
and standardization of data elements and metadata registries”. Proposal 3: For part 3, use the name: "Basic
attributes of data elements and registry metamodel”. Note: This covers the major topics in the Scope
statement. The scope statement can
explain that the reference to "data elements" in the title covers
the associated administered items. Proposal 4: "MdR" is a reasonable
abbreviation for "Metadata registry" (or "Metadata
register)". Proposal 5: Eliminate the use of the abbreviation
MdR3. Proposal 6: Remove the Editor's note from the
cover page and the Foreword. |
Proposal 1 accepted. Done. Review scope statement to ensure that the Data Management and
Interchange aspects are covered there.
Done. Editor's response: The Foreword lists the SC name. Clause 1.4 Areas of
Applicability covers these aspects. Proposal 2 amended to: “Specification for Standardization and Registration of Data Elements
and Associated Metadata.” Done. Proposal 3 accepted with amendment.
Insert “, associated metadata” after “data elements”. The note is not required. Done, but see Editor's Note on Title page. Proposal 4 keep acronym in the title in uppercase (MDR) to mean
Metadata Registry. Also add the
acronym within clause 3. Because Proposal 2 was amended, the term
"Metadata Registry" is no longer in the title, so neither is its
abbreviation. Proposal 5 accepted. Done in the title. Needs to be done in the replacement for clause 6. Proposal 6 accepted. Done. |
|
|
CAN-P03-108 |
CAN-P03-001 (#002) |
3-Major Editorial |
P03-00a-Cover |
Provide an equivalent French title: Proposed Solution
If the existing FCD title is retained,
then: “Technologies de l’information –
Gestion et échange de données - Registre de métadonnées (RM) - Partie 3
Métamodèle de registre” If CAN-P03-001 (#002) is accepted,
then: For the 11179 family as a whole: Spécifications et normalisation des éléments de données
et des registres de métadonnées For part
3: Partie 3:
Attributs de base pour les éléments de données et le métamodèle de registre |
Accepted. Canada to provide
changes to the French title corresponding to those made to English title. Done – see Title page. |
|
|
CAN-P03-002 |
|
4-Minor Editorial |
P03-00b-Contents |
Ensure the
Table of Contents is refreshed once all text changes have been made. |
Accepted. Do at end. |
|
|
CAN-P03-003 |
|
4-Minor Editorial |
P03-00c-Table of Figures |
Ensure the
Table of Figures is refreshed once all text changes have been made. |
Accepted. Do at end. |
|
|
CAN-P03-004 |
CAN-P03-001 (#002) |
4-Minor Editorial |
P03-00d-Foreword |
An Editor’s
Note in the Foreword proposes reviewing the name of the overall standard and
of each part. Proposed Solution See CAN-P03-001
(#002) above. Delete the
abbreviation “(MdR3)” from the title of Part 3 in the Foreword. Delete the
Editor’s Note from the Foreword. |
Resolved by CAN-P03-001 (#002). Proposed deletions accepted. Done. |
|
|
CAN-P03-110 |
AU01 (#009) |
2-Minor Technical |
P03-00e-Introduction |
The terms “data”, “data elements” and “metadata” are used in the
Introduction with no explanation of the differences between them, or the
relationships among them. An
understanding of 11179-3 will benefit by a brief non-technical introductory
explanation of the inter-relationships among these three terms. Proposed Solution
To be
provided. |
Accepted in principle. Revised text developed at the editing meeting
as recorded in WG2-VIC-025R1. Done. |
|
|
AU01 |
CAN-P03-110 (#008) S22-W11-038 (#207) |
3-Major Editorial |
P03-00-Introduction |
The
introduction is heavily focussed on computer databased operations of metadata
registries for statistical and/or administrative data. However, the Standard
can be, and are, also applied to other information management activities such
as document management, corporately, in libraries and on the Internet, as
well as more generally to software management. It
is suggested that the FCD should make reference to the applicability of this
Standard to these additional forms and applications of metadata. Proposed Solution
Consideration
be given to modifying the second para. of the introduction to explain that
its application can be broader than metadata registries for statistical
and/or administrative data. Suggest
that the following additional paragraph be included in Clause 4.3
Extensibility: “While the metamodel is suitable
for specialised purposes such as document management and scientific data,
these may require metadata attributes not specified in this (Part of the)
Standard. For example, the Dublin Core standard (refer http://dublincore.org
) has been mandated for webpage metadata in a number of countries. Each
Dublin Core element is defined using a set of attributes from this Standard.” |
Accepted in principle to amend the
Introduction. Resolved by #008. Accepted in principle that clause 4.3 needs
revision, but the proposed text not supported. Resolved by #207. No action here. |
|
|
CAN-P03-105 |
CAN-P03-001 (#002) CAN-P03-005 (#011) |
3-Major Editorial |
P03-01 |
Reflect CAN-P03-001 (#002) proposal 3
in the Scope statement. Reconcile
with CAN-P03-005. Proposed Solution
To be provided. |
Resolved by CAN-P03-005 (#011). No
action here. |
|
|
CAN-P03-005 |
CAN-P03-105 (#010) |
4-Minor Editorial |
P03-01 |
Some readers
of this document have interpreted the first part of the Scope statement to
mean that this document is intended to standardize the activities listed,
whereas all that is intended is that the standard has applicability in these
areas. Review in
light of CAN-P03-105 (#010). Proposed Solution Move the text
following heading "1 Scope" and before heading "1.1 Structure
of a metadata registry" to a new clause "1.3 Areas of
Applicability". In its place
insert the following text: "The
scope of this standard is outlined in sub-clauses 1.1 and 1.2. Sub-clause 1.3 provides examples of
activities where the standard may be applied." |
Accepted, but also add an Exclusions sub-clause to list features that
have been deferred to a future version. Resolved by WG2-VIC-026R3. Done. |
|
|
AU11 |
|
3-Major Editorial |
P03-01-01 |
Cl. 1.1 is poorly named.
It gives more the purpose, structure and context of this part of the
standard. The section is very important in that it should identify this part
in the context of the other parts. The name should also differ to that of
Cl. 4. The qualification: “ This
standard does not ….” Does not fully reflect the fact that later sections
tend to set out diagrams in the UML format, as noted at Cl. 4.1. That
statement about the notation and format used should be stated here so that
the readers know what they need to know before they wade into the part
itself. Furthermore, the statement
that “basic attributes …are required to describe metadata items in situations
where a complete metadata registry is not appropriate” is obtuse and
confusing, particularly as it is not explained. It could easily be read as meaning that only strictly
conformant applications are “complete”, and so It needs to be less
prescriptive, and more encouraging of partially conforming applications.
Australia has a real live example of a complete metadata registry, and while
this does not literally conform with every aspect of the metamodel, an essential component of
its completeness is the use of a set of basic attributes based on Part 5 this
Standard. The
reason for separating out this Cl. 1.2 is questioned. Surely it would be
better placed in 1.1 as a part of a more expanded form of note. Proposed Solution
Rename clause 1.1 to
“Structure“, and amend this Clause to comprise: ·
the existing first para.; ·
points a) and b) ·
a new point c) based on the text
of 1.2 viz. “ ·
points c) to f) – renumbered
accordingly; and ·
the last para of 1.1 amended to be
prefaced by “While the model diagrams are presented in UML format, …” An alternate option would be
for Cl. 1.1 to describe the parts of the standard, and 1.2 to discuss
the clauses of Part 3. |
Resolved by WG2-VIC-026R3. Reorganize the text to separate the description of
clauses in this part from the description of other parts. The structure and naming of sub-clauses 1.1 and 1.2
is intended to mirror clauses 4 and 5. The titles of clauses 1.1 and 1.2 have been made
different from clause 4 and 5 by inserting the prefix “Scope – ”. Done. |
|
|
CAN-P03-006 |
|
4-Minor Editorial |
P03-02 |
The following
documents are listed in clause 2, but are not referenced from the text. ·
ISO 704:2000, Principles and methods of terminology ·
ISO 10241:1992, International terminology standards
- preparation and layout
Proposed Solution
These entries
should be either deleted, moved to the Bibliography, or appropriate
references should be added elsewhere in the text. Recommend deletion of the first two, and moving the third to
the Bibliography. |
Recommendation accepted. Done. |
|
|
CAN-P03-007 |
|
4-Minor Editorial |
P03-02 |
The following
document is listed in both clause 2 and the Bibliography., but is not
referenced from the text.
Proposed Solution
Delete the entry from clause 2. |
Accepted. Done. |
|
|
CAN-P03-008 |
|
4-Minor Editorial |
P03-02 |
Because of the
restructuring of the text, the following documents are now referenced only
from Informative Annexes.
·
ISO 6093:1985, Information processing - Representation
of numerical values in character strings for information interchange Proposed Solution
Move these
document references to the Bibliography, and in so doing, replace ISO
646:1983 by the more recent ISO/IEC 646:1991. (The reference in clause F.2.6.1 is to ISO/IEC 646.) |
Accepted. Done. |
|
|
CAN-P03-009 |
CAN-P03-206 (#158) CAN-P03-207 (#159) CAN-P03-208 (#160) CAN-P03-209 (#162) CAN-P03-210 (#164) |
4-Minor Editorial |
P03-02 |
ISO/IEC 6523 is referenced in Figure 2
on p.31, but is not currently listed in clause 2. Proposed Solution
Add the following document references
to clause 2:
Terms and
definitions in clause 3 that are taken from these standards should reference
these standards instead of 11179-6. |
Accepted. Done. |
|
|
CAN-P03-010 |
CAN-P03-014 (#039) |
4-Minor Editorial |
P03-02 |
CD 11179-3
included a reference to ISO 15046-3 as a source for a description of the UML
modelling conventions used in the metamodel.
A UK comment on the CD changed this to ISO 19103, which superseded ISO
15046-3. However, a Canadian comment
added a direct reference to ISO/IEC DIS 19501-1 which is a PAS submission of
the OMG UML standard. Therefore, the
reference to ISO 19103 is no longer required. Proposed Solution
1) Delete the
reference to ISO 19103 in clause 2. 2) Remove the
DIS designation in reference to ISO/IEC 19501-1, which was approved. |
Accepted. Done. |
|
|
CAN-P03-102 |
CAN-P03-101 (#152) |
4-Minor Editorial |
P03-02 |
CAN-P03-101 (#152) adds a reference to
ISO 639-2/Terminology in clause 3. Proposed Solution
Add ISO 639-2/Terminology to clause 2
Normative references. |
Accepted. CAN-P03-101 (#152)
also accepted. Done. |
|
|
GBR-P03-002 |
|
4-Minor Editorial |
P03-02 |
The following
standards listed as normative references do not appear to be referenced in
Part 3. ISO 646:1983, Information Interchange - ISO 7-bit
coded character set for information interchange ISO 704:2000, Principles and methods of terminology ISO 1087-1:2000 Terminology work - Vocabulary - Part
1: Theory and Application ISO/IEC 2382-4:1999, Information technology -
Vocabulary - Part 4 Organization of Data ISO/IEC 2382-17:1993, Information technology -
Vocabulary Part 17: Databases ISO 3166-1:1997, Codes for the representation of names
of countries and their subdivisions -- Part 1: Country codes ISO 5127-1: Documentation and Information - Vocabulary
Part 1: Basic concepts ISO 6093:1985, Information processing - Representation
of numerical values in character strings for information interchange ISO TR 9007:1987 Information processing systems -
Concepts and terminology for the conceptual schema and the information ISO 10241:1992, International terminology standards -
preparation and layout ISO/IEC TR 15452:2000, Information technology –
Specification of data value domains ISO CD 19103 Geographic information - Conceptual Schema language Proposed Solution
Remove these
standards from clause 2, or provide references to them. |
Resolved by
#013 through #017b. Those standards
referenced from definitions should be retained. No
action here. |
|
|
MN-002 |
CAN-P03-118 (#116) S22-W11-033 (#171) |
4-Minor Editorial |
P03-02 |
Normative
references should include ISO 8601 for Date and Time, at least for
Input/Output and in XML, and where date/time values are stored as character
strings. Proposed Solution
Add ISO 8601
to the list of normative references. |
Accepted. Note
that the publication date is 2000. Done. Note the
resolution of #116 adds a reference to ISO 19108:2000 Geographic Information
– Temporal Schema. |
|
|
AU31 |
GBR-P03-001 (#412) |
1-Major Technical |
P03-03 |
Each of the Editor’s Notes in Cl. 3. are
supported by Australian stakeholders (ie. this is not just the former
Editor’s opinion). For each component there must be a valid function that the
component serves. An attribute (or attribute value etc. must have a function
(serve a purpose) that its definition identifies. That definition must be
immediately relevant to the reader as supporting the “area of interest” under
discussion. While some of this can be deduced from the subsequent metamodel
diagrams and explanation, it might be useful to compare the definitions and
diagrams to identify instances where further explanation needs to be provided
in the definition Proposed Solution
Suggest the
Editor’s Notes in Cl. 3 be implemented. |
Deferred for review after specific comments have
been addressed. Editor's
Notes have been removed where there was a comment addressing them. All
remaining Editor's Notes need discussion at the continuation editing meeting. |
|
|
CAN-P03-111 |
CAN-P03-114 (#050) CAN-P03-119 (#022) CAN-P03-120 (#027) CAN-P03-121 (#067) CAN-P03-123 (#060) CAN-P03-124 (#079) CAN-P03-125 (#089) CAN-P03-153 CAN-P03-180 |
1-Major Technical |
P03-03 |
As a general
principle, terms used in ISO and ISO/IEC standards should have unique
definitions. Where we wish to use a
term that has been previously defined in another standard, we should try to
live with the existing definition. If
the existing definition is not suitable, then we should either use a
different term, or qualify the term in some way to make it unique. In addition, we should try not to narrowly
define terms for which different definitions are likely to be required by
other standards. As an example
of where terms have been defined appropriately see: - 3.1.7
“definition” - a general term
included from ISO 1087. - 3.3.56
“Definition (of Administered Item) - qualified in both the term and the
definition. Other terms,
particularly in clause 3.2 (e.g. 3.2.11 extension, 3.2.16 mandatory) use
general terms with narrow meanings, and must be amended accordingly. Proposed Solution
Carefully
review each term to ensure that terms which are potentially useful in other
contexts have definitions that are equally applicable. Make changes as necessary along the lines
of the example above. Other comments
address specific terms, but our review, while exhausting, has not been
exhaustive. |
Principle
accepted. Specific proposals are
addressed by other comments. No
action here. |
|
|
CAN-P03-119 |
CAN-P03-111 (#021) |
1-Major Technical |
P03-03 |
Any term or definition based on another ISO standard should reference
that standard. Where they have been modified, the reference should include the note
(with modifications). However, preferably both the term and the definition should be
qualified (see CAN-P03-111 (#021)). Proposed Solution
Identify terms
which are drawn from other standards, and add the necessary notes. According to
the ISO/IEC Directives, the form of reference should be as follows: a) for an
exact reference, as: [ISO 1382:1982] b) for a
modified reference, as:
NOTE Adapted from ISO/IEC 2382-7:1989. |
Principle
accepted. No
action here. |
|
|
CAN-P03-109 |
CAN-P03-171 (#108) CAN-P03-173 (#117) CAN-P03-174 (#171) CAN-P03-175 (#155) CAN-P03-176 (#111) CAN-P03-177 (#118) CAN-P03-178 (#163) CAN-P03-179 (#112) CAN-P03-202 (#255) AU35 (#049) |
2-Minor Technical |
P03-03 P03-03-03-006 P03-03-03-032 P03-03-03-033 P03-03-03-034 P03-03-03-055 P03-03-03-088 |
Proposal to use not use abbreviations
in terms in clause 3, but to provide short names as aliases where they are
needed (e.g. to fit in a diagram). See detailed comments on clauses 3.3.6,
3.3.32, 3.3.33, 3.3.34, 3.3.55, 3.3.88 and perhaps more. Where we do need to
use abbreviations, we need to decide whether they should always be
capitalized, or whether the capitalization should vary depending on the
metamodel construct being named – i.e. capitalize only classes. Proposed Solution
Spell out the terms in full in clause
3. Add a clause 3.4 Abbreviations to list the abbreviations that are used
elsewhere in the document. Check
usage throughout the document. To be
discussed at editing meeting. |
Accepted. Done in clause 3 and in the
Figures. List of
Abbreviations still to be added. |
|
|
CAN-P03-112 |
|
3-Major Editorial |
P03-03 |
Clause three is organized into three sub-clauses by type of
term. While there is some merit in
this organization, the result is that there is no alphabetical list of terms. Proposed Solution
Add an
alphabetical list of terms as an informative Annexe, with references to the
precise sub-clauses where the definitions can be found. See Annex C to these comments for an
example. The example will need to be
updated to reflect any changes made as a result of other comments. |
Accepted. Editor to supply. Do after other changes to clause 3. |
|
|
S22-W11-002 |
|
3-Major Editorial |
P03-03 |
Clause 3, page 3: The terms in subclause 3.3 should be a
separate clause because they are assertions, not definitions. The terms in subclauses 3.1 and 3.2
should be merged. |
Not accepted.
For proposal 1, it is believed more useful to have
the entries in clause 3. For proposal 2, it is felt more useful to keep these
separate. The existing structure is to be retained No action here. |
|
|
DDM-000.5 |
|
4-Minor Editorial |
P03-03 |
Some terminology
folks say defs are bad because terms are in defs Most of
wording in first sentence is almost verbatim out of ISO 1087. Insert the
following after the first sentence:
“Each definition in this clause is a statement which describes a
concept and permits its differentiation from other concepts within this
standard. The term that is associated
with the definition was selected to represent the definition that describes
the concept.” |
Individual
instances are addressed by other comments. Addition of
text not accepted. No
changes here. |
|
|
CAN-P03-120 |
CAN-P03-111 (#021) CAN-P03-119 (#022) CAN-P03-121 (#067) |
2-Minor Technical |
P03-03-01-01 |
“attribute” is defined in terms of
“characteristic”, “object” and “entity”, all of which are defined ISO and/or
ISO/IEC terms and should be included as terms/definitions in 11179-3. Proposed Solution
Add the
following definitions in clause 3.2. “characteristics:
abstraction of a property of an object or of a set of objects NOTE –
Characteristics are used for describing concepts. [ISO
1087-1:2000 (3.2.4)] Object:
Anything perceivable or conceivable NOTE – Objects
may also be material (e.g. engine, a sheet of paper, a diamond), immaterial
(e.g. conversion ratio, a project plan) or imagined (e.g. a unicorn) [ISO
1087-1:2000(3.1.1)] CAN-P03-121
(#067) revises the definition of entity (see 3.2.10). Highlight the
words “characteristic”, “object” and “entity” in the definition of
“attribute”, to show that they are defined terms. |
Accepted. Done. |
|
|
CAN-P03-117 |
CAN-P03-185 (#130) |
1-Major Technical |
P03-03-01-02 |
Canada has
previously stated its position that the metamodel should be powerful enough
to model itself. One of the
impediments to doing this is the use of attribute capsules as datatypes,
which seem to have no correspondence in the model. Proposed Solution
A recent
change added a “datatype scheme”, allowing references to arbitrary
collections of datatypes. We could
define a 11179-3 datatype scheme, and simply name the attribute capsules as
datatypes within the scheme. It still
would not be possible to represent the structure of these datatypes within
the registry. |
Defer to the
next version. Note in the Scope
clause that Encapsulation, Stereotyping and Inheritance are out of scope. Scope
exclusions done. |
|
|
CAN-P03-011 |
DDM-001 (#030) |
2-Minor Technical |
P03-03-01-02 |
The Editor's
Note on the definition of Attribute Capsule needs to be addressed. Note that UML 1.3 does not use the term Attribute
Capsule. Proposed Solution None provided. |
Resolved by DDM-001. (#030) No
action here. |
|
|
DDM-001 |
CAN-P03-011 (#029) S22-W11-003 (#031) |
4-Minor Editorial |
P03-03-01-02 |
The definition
should note the encapsulation of classes and relationships not attributes. Proposed Solution
Change the
definition to "An attribute that encapsulates other classes and
associated relationships." |
Accepted. Append the note: “Note: In this standard,
it is used for presentation purposes.” Done. |
|
|
S22-W11-003 |
DDM-001 (#030) |
4-Minor Editorial |
P03-03-01-02 |
Subclause 3.1.2, page 3: "attribute capsule" and its
definition aren't exactly right.
Either "composite attribute" or "nested attribute"
are the right terms. Within the
definition "encapsulates" is the wrong verb because it has the
connotation of "hiding".
Presumably, one would care about an "attribute capsule"
because one would want to know there are attributes inside the
"attribute capsule" ... if "knowing" that there are are
subattributes is important, then "encapsulation" is the wrong term
... if not "knowing" is important, then there is no need to
distinguish between an "attribute" and an "attribute
capsule". Thus, "composite
attribute" or "nested attribute" is the right term. |
Resolved by DDM-001. (#030) No
action here. |
|
|
CAN-P03-012 |
S22-W11-004 (#033) |
2-Minor Technical |
P03-03-01-03 |
This term
"attribute value" is not used in the document. However, it would be useful to make a
distinction between an attribute and its value. Proposed Solution Either add
text that explains the distinction between an attribute and its value, or
delete clause 3.1.3, thus removing the term, preferably the former. |
Change the
definition as proposed in the Editor’s note.
Added note that the definition is amended from that in 2382-17. Done. |
|
|
S22-W11-004 |
CAN-P03-012 (#032) |
2-Minor Technical |
P03-03-01-03 |
Subclause 3.1.3, page 3: I don't see any problem with the term
"attribute value" because we need to have the term to discuss,
specify, and constrain the values of attributes. A better definition is "the value of an attribute". This definition is not redundant because
it makes it clear that "attribute value" is a term with a
definition, i.e., it is improper to interpret the standards wording by the
construction "attribute" + "value". Also, "a value" (in the
context of 11404) may actually have subcomponents (e.g., multiple values), so
there is no need to refer to a "value set". |
Resolved by CAN-P03-012 (#032). No
action here. |
|
|
DDM-002 |
CAN-P03-012 (#032) |
4-Minor Editorial |
P03-03-01-03 |
This term
"attribute value" is not in the document Proposed Solution
Remove the
term |
Resolved by CAN-P03-012 (#032). No
action here. |
|
|
CAN-P03-013 |
|
2-Minor Technical |
P03-03-01-04 |
The Editor's
Note on the definition of "attributed relationship" needs to be
addressed. Proposed Solution None provided. |
Defer to next
version of the standards. Delete the
editor’s note. Done. |
|
|
CAN-P03-118 |
|
2-Minor Technical |
P03-03-01-04 |
The term
“attributed relationship” is not used in UML. Since we are using UML as our modelling approach, why are we
using different terminology. The term used in UML is “association class”,
which is defined as: “An
association class is an association that is also a class. It not only
connects a set of classifiers but also defines a set of features that belong
to the relationship itself and not any of the classifiers.” Proposed Solution
None provided. |
Not
accepted. Keep the existing
definition. No
action here. |
|
|
DDM-003 |
|
4-Minor Editorial |
P03-03-01-04 |
Revise the
definition to be more like the UML standard definition Proposed Solution
Revise to
" A relationship that has class like attributes." |
Not
accepted. Keep the existing
definition. No
action here. |
|
|
S22-W11-005 |
|
2-Minor Technical |
P03-03-01-05 |
Subclause 3.1.5, page 4: Change "semantics" ==>
"meanings". With this
change, we can talk about (interpret) the standard and the semantics of the
standard without confusing it with the meanings of particular features of the
standard. |
Not accepted.
Leave as is. No
action here. |
|
|
CAN-P03-014 |
CAN-P03-010 (#017) CAN-P03-119 (#022) |
4-Minor Editorial |
P03-03-01-05 |
The definition of "class" is taken from ISO/IEC DIS 19501-1,
but this reference is not shown. Proposed Solution
At the end of the definition add the text : (Note: See ISO/IEC
19501-1.) |
Accepted, but check format of the note specified by ISO/IEC directives.
(See #022.) Done. |
|
|
CAN-P03-015 |
DDM-004 (#041) |
4-Minor Editorial |
P03-03-01-06 |
The Editor's
Note on term "data element attribute" needs to be addressed. The term is
used only in another Editor's note.
It is not used in the text.
(The phrase "attributes of data elements" is used
however.) Note that other standards
may reference this definition in 11179-3:1994, so it is probably useful to
keep it. Proposed Solution Either delete
clause 3.1.6, thus removing the term, or add text that uses it, preferably
the latter. |
Resolved by
DDM-004 (041). No
action here. |
|
|
DDM-004 |
CAN-P03-015 (#040) S22-W11-006 (#042) |
4-Minor Editorial |
P03-03-01-06 |
This term
"data element attribute" is not in the document Proposed Solution
Remove the
term |
Accepted. Done. |
|
|
S22-W11-006 |
DDM-004 (#041) |
4-Minor Editorial |
P03-03-01-06 |
Subclause 3.1.6, page 4: Change "Data Element" ==>
"data element". In response
to the editor's note, yet this definition makes sense because it prevents
"data element attribute" from being deconstructed. |
Resolved by
DDM-004 (041). No
action here. |
|
|
S22-W11-007 |
|
2-Minor Technical |
P03-03-01-07 |
Subclause 3.1.7, page 4: Is the definition of
"definition" necessary? |
Delete clause 3.1.7, and remove the highlighting of
“definition” in 3.3.56. Done. |
|
|
CAN-P03-104 |
|
2-Minor Technical |
P03-03-01-09 |
We would like to emphasise some
particular aspects of identifiers. Proposed Solution
Add the following Notes after the
definition of Identifier. Notes: 1. A Name shall not be used as an identifier
because it is not linguistically neutral. 2. Once assigned, an identifier shall not be
reassigned, to avoid possible later confusion over what is being identified. These
statements should also be incorporated into the revision of 11179-5. |
Accepted, but remove capital from “name”, and replace “shall” by
“should”. Done. |
|
|
CAN-P03-113 |
|
2-Minor Technical |
P03-03-01-09 |
There are
existing ISO and ISO/IEC standards with differing definitions of
“identifier”. To avoid
confusion 15944-1 used the unique term “identifier (business transaction)”. Proposed Solution
It is
suggested that 11179-3 use a similar approach, i.e. identifier (metadata registry) |
Accepted. Done. |
|
|
S22-W11-008 |
|
2-Minor Technical |
P03-03-01-09 |
Subclause 3.1.9, page 4: The definition of
"identifier" appears to be circular. The definition from the ITV (2382-04) appears to be more useful
as a basis for a new definition:
04.09.02 identifier (in organization of data): One or more characters
used to identify or name a data element and possibly to indicate certain
properties of that data element. With some slight improvements, it would
be:
identifier: A moniker associated with an object. Example: An identifier for a metadata
item. Note 1: Typically, a moniker is
a sequence of symbols, such as characters or octets. Note 2: Typically, an identifier is
linguistically neutral. The above definition is more consistent
with the definition of "name". |
Not accepted.
The existing definition has been carefully chosen. No
action here. |
|
|
AU33 |
CAN-P03-114 (#050) |
1-Major Technical |
P03-03-01-11 |
Clauses 3.1.1
to 3.1.4, 3.1.6, 3.1.10, 3.1.11 and 3.1.11 should be located in Clause 3.2
since they are broader terms, not solely
metamodel constructs. If they are retained in Clause 3.1 their meaning
will be constrained eg the term “metadata item” will have to be limited to
instances of metadata included in the model in Cl. 4. This would then
not allow the labelling of items that relate to extensions beyond the
metamodel. This
leaves too few definitions in Cl. 3.1, and amalgamation of 3.1 and 3.2
is proposed accordingly. Proposed Solution
Amalgamate
Clauses. 3.1 and 3.2 Remove
the restriction from 3.1.11. |
Proposal 1 not accepted. We believe it is clearer the way it is. Proposal 2 addressed by #050 (CAN-P03-114). No
action here. |
|
|
AU34 |
CAN-P03-114 (#050) |
2-Minor Technical |
P03-03-01-11 |
Cl. 3.1.11 is not clear.
The examples indicate that “metadata item“ relates to such things as a “Data
element”, ”Data element concept” or ”Permissible value”, each of which is a
whole “administration record”. However, both the name “metadata item”, and
the definition, implies that it would also apply to individual fields
(attributes) within an administration record, such as
“classification_scheme_type_name” in Figure 4 above Cl. 4.7.1. Furthermore, since the word
“item” has no specific definition, the term “metadata item“ has an inherent
meaning that is far broader, and likely to cause confusion among readers who
don’t realise it has a specific definition. It is suggested the draft would benefit from
explicitly defining, and differentiating between, the two different types of
items specified in the current definition. It is also queried whether there is
a need for the term “metadata item“, ie. Generally applying to both
administration records, and fields within administration record. Proposed Solution
1
Add additional defined term,
“Administration record field (ARF)”. Review whether
there is a need for a separate general term “metadata item“. |
Resolved by #050 (CAN-P03-114). “metadata item” refers to instances of metadata
represented as classes in the model.
Those classes which have associated “Administration Records” are also
known as administered items. The properties of the classes are known as
“attributes of metadata items”. No
action here. |
|
|
AU35 |
CAN-P03-109 (#023) |
4-Minor Editorial |
P03-03-01-11 P03-03-02-01 |
There
have been objections raised to the use of the acronym “AI“, for “Administered
item“, because of that term’s normal use for “Artificial Intelligence“. Combination
with “metadata registry“ (MR) simply overcomes the problem. Proposed Solution
Adopt
the acronym MRAI (meaning Metadata Registry Administered Item) be adopted for
“Administered item“ . |
The acronym AI is not used in the standard. (This was a problem in the CD, but was
fixed in the FCD.) The new acronym is not needed. No
action here. |
|
|
CAN-P03-114 |
CAN-P03-111 (#021) AU33 (#047) AU34 (#048) |
4-Minor Editorial |
P03-03-01-11 |
The definition
of metadata item does not meet the demands of reusability as proposed in
CAN-P03-111 (#021). The definition
has to stand alone without references to other clauses. The second
sentence lists examples, and should be separated out from the definition. Proposed Solution
Replace the
definition by: “An instance
of metadata. Note: In all parts of ISO/IEC 11179 the term is
applied only to metadata described by the metamodel in this standard. Examples
include instances of Data Elements, Data Element Concepts, Permissible
Values etc.” |
Accepted. Amend the note
to refer to classes in the metamodel, to resolve AU34 (#48). Done. |
|
|
CAN-P03-016 |
CAN-P03-049 (#216) CAN-P03-085 (#293) CAN-P03-086 (#406) |
4-Minor Editorial |
P03-03-01-13 |
The Editor's
Note on term "related metadata reference" needs to be addressed. The term uses
the word “reference”, while the definition uses the word “relationship”. We should be more consistent. CAN-P03-049 (#216) proposes adding an
“administered item relationship” to the model. This would seem to be a form of “related metadata
reference”. However, in 11179-3:1994
“related data reference” supports references both within a single dictionary,
and externally. How can we support
external references? If we add an
attribute to the model to explicitly support such references, the term and
definition will need to be moved from 3.1 to 3.3. Proposed Solution
For discussion at the editing meeting. At least make the term and definition consistent. [I.e. use either "reference" or
"relationship" in both places.] The resolution of #216 (CAN-P03-049) has
introduced a recursive relationship between administered items. This supports references within a
registry. Possibly add an external metadata reference as an attribute. Delete the Editor's Note from clause 3.1.13 once it has been resolved. See also comments CAN-P03-085
(#293) and CAN-P03-086 (#406). |
For
discussion at the CEM in conjunction with CAN-P03-049
(#216), CAN-P03-085 (#293), CAN-P03-086 (#406). |
|
|
CAN-P03-115 |
S22-W11-009 (#053) |
2-Minor Technical |
P03-03-01-14 |
The existing
definition is adapted from ISO 704:1997 which uses: “Mental link between two
or more concepts.” For relating
concepts specifically, we have “Concept Relationship” in clause 3.3.16. In
clause 3.1, the term “relationship” refers to a metamodel construct. Such a relationship is more than just a
link between concepts. The definition from IS 15901-1 UML (which is the
modelling convention we use) is: “A
relationship is a connection among model elements. In the
metamodel, Relationship is a term of convenience without any specific
semantics. It is abstract. Children of
Relationship are Association, Dependency, Flow, and Generalization.” In the 11179-3
metamodel it is only ever an association or a generalization. Proposed Solution
Adapt the UML
definition: “A
relationship is a connection among model elements.” Note: In the 11179-3 metamodel it is either an
association or a generalization”. If the
proposed solution is rejected, and the existing definition is retained, then
add : Note: Adapted from ISO 704:1987. |
Proposed
solution accepted. Done. Also.
the Editor has added the qualification "(in registry metamodel)" to
the term to make the term as specific as the definition. |
|
|
S22-W11-009 |
CAN-P03-115 (#052) |
2-Minor Technical |
P03-03-01-14 |
Subclause 3.1.14, page 4: The definition of relationship should
be reworked towards the following ITV (2382-17) definitions:
17.02.17 (entity) relationship: A perceived association among entities
or among attributes of the same entity class. NOTE - In certain contexts, an
entity relationship may be considered to be an entity.
17.02.18 (attribute) relationship: A perceived association among
attributes. |
Resolved by #052. (CAN-P03-115). No
action here. |
|
|
S22-W11-010 |
|
4-Minor Editorial |
P03-03-02-01 |
Subclause 3.2.1, page 5: Change "Administration
Record" ==> "administration record". |
Not accepted.
The capitalization follows the standard of the model. No
action here. |
|
|
CAN-P03-116 |
|
2-Minor Technical |
P03-03-02-03 |
The definition
of “binding” is unsatisfactory. A mapping is not necessarily a binding, so
what distinguishes a binding. A “Framework”
is at one end of a range while “specification” is on the other. Can a binding
really apply to both (and everything in between)? Further
neither “framework” nor “specification” is defined in this standard, so it is
difficult to know what is being bound. The definition
of “binding” in IS 10032 (Data Management Reference Model) is: “A process
which involves relating a process to specific data definitions”. This does not
seem very satisfactory either. TR 14369:1999
defines “language binding” as: “A specification of the standard
interface to a service, or set of services, for applications written in a
particular programming language.” Proposed Solution
Discussion at
the editing meeting in Victoria led to the following proposal: Insert "An instantiation of" at
the beginning of the definition, to give: "An instantiation of a
mapping from one framework or specification to another." |
To be discussed at the CEM in context of clause
6. Check resolution of WG2-VIC-019D. We may not
need the definition if all bindings are moved to ISO/IEC 20944. |
|
|
CAN-P03-017 |
DDM-005 (#057) |
4-Minor Editorial |
P03-03-02-04 |
The Editor’s note needs to be addressed. Since the term “component” is really used only in its normal English
sense when describing the partitioning of the model for explanatory purposes
in clause 4. Do we really need to
define it. Proposed Solution
Delete the term, definition and Editor’s note. |
Accepted. Done. |
|
|
DDM-005 |
CAN-P03-017 (#056) |
4-Minor Editorial |
P03-03-02-04 |
The definition
refers to "object classes" which may cause confusion since this is
not the metamodel "Object Class" Proposed Solution
Revise the
definition to: “A collective term used to refer to one or more metadata items
in this model." |
Resolved by
056 (CAN-P03-017). No action here. |
|
|
CAN-P03-122 |
S22-W11-011 (#059) |
2-Minor Technical |
P03-03-02-05 |
The intent of current the definition of
“conceptual data model” has been to distinguish it from a logical or physical
model of an information system.
However, in focusing on that aspect, we have lost the notion that a
conceptual model is an abstract view of the real world. Also, “data model” is itself a defined
term, and should be highlighted as such, and its definition already includes
the concept of information structure. Proposed Solution
Replace the definition by: “A data model that represents an
abstract view of the real world.” |
Accepted. Done. |
|
|
S22-W11-011 |
CAN-P03-122 (#058) |
2-Minor Technical |
P03-03-02-05 |
Subclause 3.2.5, page 5: This definition could be improved. It should use a combination of the
following from ITV (2382-17):
17.02.02 conceptual model: A representation of the characteristics of
a universe of discourse by means of entities and entity relationships.
17.01.07 data model (1) A pattern of structuring data in a database
according to the formal descriptions in its information system and according
to the requirements of the database management system to be applied.
17.01.08 data model (2) A description of the organization of data in
the management information system of an enterprise. |
Agree the definition needs to be improved. Resolved by 058. (CAN-P03-122) No
action here. |
|
|
CAN-P03-123 |
CAN-P03-111 (#021) CAN-P03-124 (#079) CAN-P03-125 (#089) |
2-Minor Technical |
P03-03-02-06 P03-03-02-16 P03-03-02-22 |
Current
definitions of the terms “conditional”, “mandatory” and “optional” are not
true definitions. The definitions do
not meet the demands of reusability as proposed in CAN-P03-111 (#021). Conditional is
first and foremost a state of dependency. which is specified through a rule
base. Conditional is but one of several “Presence-Types”. The others are
“Mandatory”, “Mandatory subject to a conditional”, “Optional” and “Not
Applicable”. Note that ISO/IEC
FDIS 15944-1 Annex B(normative)
“Codes Representing Presence-Type Attributes" specifies these as a codeset (though without definitions) We note that better definitions are
contained in the text of clause 5: Proposed Solution
Use the
definition from clause 5, with
modifications: conditional:
required See also CAN-P03-124 (#079) and
CAN-P03-125 (#089). |
Proposal
accepted. Done. The next
version of this standard should look at whether additional prescence types
are required. |
|
|
S22-W11-012 |
|
4-Minor Editorial |
P03-03-02-06 |
Subclause 3.2.6, page 5: Change the title of the definition
"conditional" ==> "conditional (data obligation)". Change the definition to:
Adjective applied to any feature, in context, that is required if
certain criteria are satisfied. |
Resolved by 060. (CAN-P03-123). No action here. |
|
|
CAN-P03-126 |
CAN-P03-133 (#299) S22-W11-013 (#063) |
2-Minor Technical |
P03-03-02-07 |
“Consume”
implies “to use up” which is not applicable to information processing. The definition seems to better fit the
term “parse”. However,
CAN-P03-133 (#299) proposes replacing “consume and interpret” by “input”. Proposed Solution
Delete clause
3.2.7. |
To be resolved by WG2-VIC-019D. |
|
|
S22-W11-013 |
CAN-P03-126 (#062) |
4-Minor Editorial |
P03-03-02-07 |
Subclause 3.2.7, page 5: Change the title of the definition
"consume" ==> "consume (input data processing)". |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-151 |
|
2-Minor Technical |
P03-03-02-08 |
The definition is quoted as coming from ISO 2382,
Part 4 (undated). ISO FCD 2382-4:1998 did not contain this term. Is it in the latest IS? ISO/IEC
15944-1 uses the 2382-1 definition which is: “A
reinterpretable representation of information
in a formalized manner suitable for communication, interpretation or
processing. NOTE: Data can
be processed by human or automatic means [ISO/IEC
2382-1:1993 (01.01.02)]” Proposed Solution
Review the
definition as specified in the latest version of ISO 2382, and use that if it
makes sense in the context of this standard.
Otherwise, use it with appropriate modification. ISO 2382-1 was last revised in 1998. ISO
2382-4 was last revised in 1999. |
Use definition
from ISO/IEC 2382-1:1998. (not 1993). Check clause
2. Done. |
|
|
CAN-P03-152 |
S22-W11-014 (#066) |
2-Minor Technical |
P03-03-02-09 |
The definition
of “data model” seems imprecise, ambiguous and possibly incomplete. Is this a standard term/definition taken
from another IS? If not, is there
such a definition? Is a data model
just a “description” or is it a “specification”? The 11179-3 metamodel is surely a specification. “information”
and “information structure” are not defined.
Do we need to introduce these terms? Proposed Solution
Consider alternative definitions. Alternative 1: “A graphical and textual
representation of data.” Alternative 2: “A graphical and textual
representation of data, specifying their properties, structure and
inter-relationships.” For discussion at the editing meeting. |
Accept
Alternative 2, but change the first “and” to “and/or” and change “textual” to
“lexical”. Done. |
|
|
S22-W11-014 |
CAN-P03-152 (#065) |
2-Minor Technical |
P03-03-02-09 |
Subclause 3.2.9, page 5: Change this definition to one that is
compatible with ITV (2382-17):
17.01.07 data model (1) A pattern of structuring data in a database
according to the formal descriptions in its information system and according
to the requirements of the database management system to be applied.
17.01.08 data model (2) A description of the organization of data in
the management information system of an enterprise. |
Resolved by 065 (CAN-P03-152). No action here. |
|
|
CAN-P03-121 |
CAN-P03-111 (#021) CAN-P03-119 (#022) CAN-P03-120 (#027) S22-W11-015 (#068) |
2-Minor Technical |
P03-03-02-10 |
Further to CAN-P03-119 (#022) and CAN-P03-120 (#027),
replace the definition of entity with that from ISO/IEC
2382-17:1999(17.02.05) Proposed Solution
“entity: Any
concrete or abstract thing that exists, did exist, or might exist, including
associations among these things. Example: A
person, object, event, idea, process, etc… NOTE – Please observe
that an entity exists whether data available about it are available or not. [ISO/IEC 2382-17:1999 (17.02.05)] |
Accepted, but
check format of reference (see #022). Done. |
|
|
S22-W11-015 |
CAN-P03-121 (#067) |
2-Minor Technical |
P03-03-02-10 |
Subclause 3.2.10, page 5: Just use the ITV (2382-17) definition:
17.02.05 entity: Any concrete or abstract thing that exists, did
exist, or might exist, including associations among these things. Example: A person, an object, an event, an
idea, a process, etc.. NOTE - An
entity exists whether data about it are available or not. |
Accepted, but add reference to source as per 067
(CAN-P03-121). Done. |
|
|
DDM-006 |
|
4-Minor Editorial |
P03-03-02-10 |
This term
"entity" is not in the document except in annex A where the correct
term is "class" Proposed Solution
Remove the
term |
Not
accepted. The term is used in the
definition of “attribute”. No action here. |
|
|
CAN-P03-153 |
CAN-P03-111 (#021) S22-W11-016 (#071) |
2-Minor Technical |
P03-03-02-11 |
A generic term
is being used with a specific definition, contrary to CAN-P03-111 (#021). Proposed Solution
Revise the
definition for the generic term to be generic, and add a more specific term
for use with the specific definition.
For example: extension:
a feature not defined by this Standard that is added by an
implementation. extension (of registry metamodel): A class, an attribute or a relationship
that an implementation of
a metadata
registry provides that
is not defined by this Standard. |
Accept the
example as the solution. Done. |
|
|
S22-W11-016 |
CAN-P03-153 (#070) |
4-Minor Editorial |
P03-03-02-11 |
Subclause 3.2.11, page 6: Change the title of the definition
"extension" ==> "extension (conformance; data
obligation)". |
Resolved by 070 (CAN-P03-153). No action here. |
|
|
CAN-P03-134 |
CAN-P03-133 (#299) S22-W11-017 (#073) |
2-Minor Technical |
P03-03-02-12 |
Delete use of
the term “generate”, as proposed by CAN-P03-133 (#299). Proposed Solution
Delete clause
3.2.12. |
To be resolved by WG2-VIC-019D. |
|
|
S22-W11-017 |
CAN-P03-134 (#072) |
4-Minor Editorial |
P03-03-02-12 |
Subclause 3.2.12, page 6: Change the title of the definition
"generate" ==> "generate (output data processing)". |
To be resolved by WG2-VIC-019D. |
|
|
AU36 |
|
2-Minor Technical |
P03-03-02-13 |
There
is a trend to refer to information models, as defined here, as “frameworks”.
Examples are the “Zachman Framework” (refer http://members.ozemail.com.au/~ieinfo/zachman.htm ). and the
Canadian Institute for Health Information’s “Health Information Framework”
(refer http://health.hnet.bc.ca/hds/data_archetecture/framework/
). Proposed Solution
Suggest the definition be
amended to “Information Model (Framework)” |
Not accepted.
A “Framework” is usually at a higher level than a “model”. No action here. |
|
|
CAN-P03-154 |
S22-W11-018 (#076) |
2-Minor Technical |
P03-03-02-13 |
The approach
to and definitions of data model and information model are not
harmonized. There is no clear
relationship between the two. However, the
term Information Model is used only in Informative Annexes, so probably does
not need to be defined. Proposed Solution
Delete clause
3.2.13. |
Accepted. Done. |
|
|
S22-W11-018 |
CAN-P03-154 (#075) |
4-Minor Editorial |
P03-03-02-13 |
Subclause 3.2.13, page 6: I wonder why we need this
definition? It should be harmonized
with the definition of "data model". |
Resolved by 075 (CAN-P03-154). No action here. |
|
|
CAN-P03-132 |
CAN-P03-133 (#299) S22-W11-019 (#078) |
2-Minor Technical |
P03-03-02-14 |
Delete use of
the term “interpret”, as proposed by CAN-P03-133 (#299). Proposed Solution
Delete clause
3.2.14. |
To be resolved by WG2-VIC-019D. |
|
|
S22-W11-019 |
CAN-P03-132 (#077) |
4-Minor Editorial |
P03-03-02-14 |
Subclause 3.2.14, page 6: Change the title of the definition
"interpret" ==> "interpret (input data processing)". |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-124 |
CAN-P03-111 (#021) CAN-P03-123 (#060) CAN-P03-125 (#089) S22-W11-020 (#080) |
2-Minor Technical |
P03-03-02-16 P03-03-02-06 P03-03-02-22 |
See CAN-P03-123
(#060). Proposed Solution
Alternative
1: Use the definition from clause 5. mandatory:
always required; Alternative
2: mandatory:
presence always required; [Note: Are there ever situations where what is
mandatory is the “absence” of something? E.g. extensions] |
Accept
Alternative 1. Done. |
|
|
S22-W11-020 |
CAN-P03-124 (#079) |
2-Minor Technical |
P03-03-02-16 |
Subclause 3.2.16, page 6: Change the title of the definition
"mandatory" ==> "mandatory (data obligation)". Remove the assertion in the definition
("... is required when ..."). The revised definition should be:
“Adjective applied to any feature, in context, that is required.” |
Resolved by 079 (CAN-P03-124). No action here. |
|
|
CAN-P03-155 |
|
2-Minor Technical |
P03-03-02-17 |
“Metadata entry
application” is defined, but clause 6 uses the term "metadata
writer". Also, the current
definition is incomplete because it does not allow for entry via electronic
data interchange (EDI). Proposed Solution
Pick one term
and use it consistently. If text is
added that uses the text, amend the definition to include reference to entry
via data interchange. [Note: is it
better to use the generic “data interchange” or should we restrict this to
“electronic data interchange (EDI)” – in which case include the definition
from ISO/IEC 14662.] |
To discussed at CEM in the context of clause
6. See WG2-VIC-019D. |
|
|
CAN-P03-138 |
CAN-P03-133 (#299) |
2-Minor Technical |
P03-03-02-18 |
Remove
references to “consumption and interpretation” in accordance with CAN-P03-133
(#299). Proposed Solution
Replace the
definition by. “An
application that inputs metadata.” |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-139 |
CAN-P03-133 (#299) |
2-Minor Technical |
P03-03-02-18 |
Add a
definition for “metadata writer application”. Proposed Solution
metadata
writer application “An
application that outputs metadata.” |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-156 |
CAN-P03-157 (#086) S22-W11-021 (#085) |
2-Minor Technical |
P03-03-02-19 |
This
definition lacks a linkage to/inclusion of “registration”, i.e. the
definition is more appropriate to a “metadata system” than a “registry”. A
“registry” involves a process of
registration, i.e. an entry in a register. See further
3.2.24 registry item definition which assumes that a recording/registration
process has been completed. Proposed Solution
Revise the
definition. E.g. “An
information system for registering metadata.” Note: The
associated information store or database is referred to as a “metadata
register”. |
Accepted. Done. |
|
|
S22-W11-021 |
CAN-P03-156 (#084) |
2-Minor Technical |
P03-03-02-19 |
Subclause 3.2.19, page 6: Change definition to:
An information system for metadata. See the ITV (2382-17) definition of
"information system":
17.01.04 information system (in databases), IS (abbreviation): A system
consisting of a conceptual schema, information base, and information
processor, forming together a system for keeping and manipulating
information. |
Resolved by 084 (CAN-P03-156). No action here. |
|
|
CAN-P03-157 |
CAN-P03-156 (#084) |
2-Minor Technical |
P03-03-02-19+ |
Add a
definition of “metadata register”. Proposed Solution
metadata
register: The
information store or database maintained by a metadata registry.” |
Accepted. Done. |
|
|
CAN-P03-161 |
CAN-P03-162 (#317) CAN-P03-163 (#320) S22-W11-022 (#088) |
2-Minor Technical |
P03-03-02-21 |
The term and
definition are unclear. Also, the
term actually used elsewhere in the document (6.1.3 and 6.1.4) is “smallest
permitted maximum” Proposed Solution
permitted
maximum lower bound: A
lower limit (specified by this Standard) on a maximum value that is to be
specified by an implementation. |
To be resolved by WG2-VIC-019D. |
|
|
S22-W11-022 |
CAN-P03-161 (#087) |
2-Minor Technical |
P03-03-02-21 |
Subclause 3.2.21, page 6: Change the title of the definition
"minimum-permitted maximum" ==> "smallest permitted
maximum". Change the definition to:
For implementation-defined values, the smallest permitted maximum
value. Example: "The smallest
permitted maximum string length of data element X shall be 17." |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-125 |
CAN-P03-111 (#021) CAN-P03-123 (#060) CAN-P03-124 (#079) S22-W11-023 (#090) |
2-Minor Technical |
P03-03-02-22 P03-03-02-06 P03-03-02-16 |
See
CAN-P03-123 (#060). Proposed Solution
Use the
definition from clause 5. optional:
allowed but not required. |
Accepted. Done. |
|
|
S22-W11-023 |
CAN-P03-125 (#089) |
2-Minor Technical |
P03-03-02-22 |
Subclause 3.2.22, page 7: Change the title of the definition
"optional" ==> "optional (data obligation)". Change the definition to:
Adjective applied to any feature, in context, that is permitted but
not required. |
Resolved by 089 (CAN-P03-125). No action here. |
|
|
CAN-P03-135 |
CAN-P03-133 (#299) S22-W11-024 (#092) |
2-Minor Technical |
P03-03-02-23 |
Delete use of
the term “produce”, as proposed by CAN-P03-133 (#299). Proposed Solution
Delete clause
3.2.23. |
To be resolved by WG2-VIC-019D. |
|
|
S22-W11-024 |
CAN-P03-135 (#091) |
4-Minor Editorial |
P03-03-02-23 |
Subclause 3.2.23, page 7: Change the title of the definition
"produce" ==> "produce (output data processing)". |
To be resolved by WG2-VIC-019D. |
|
|
CAN-P03-165 |
|
2-Minor Technical |
P03-03-02-25 |
One assumes
that a formalism involves/requires a
“specification” and not a “representation”. Proposed Solution Replace
“representing” with “specifying” |
Delete the
term and its definition. Its only
used in clause 4.2 does not really require the term to be defined. Done. |
|
|
S22-W11-025 |
|
2-Minor Technical |
P03-03-02-25 |
Subclause 3.2.25, page 7: This definition is very close to the
definition of a "datatype": a formalism ... [defined] by means of
its possible values. This definition
should be revised. Possibly
"datatype" should be the correct term. |
Delete the
term and its definition. Done. |
|
|
CAN-P03-166 |
|
2-Minor Technical |
P03-03-02-26 |
We assume that
“shareable data” involves the sharing of data among two or more autonomous
parties. If this is the requirement, then the current definition does not capture/support such
concept/term. Proposed solution Add following
text to the end of the current definition: “as mutually agreed to among the
parties sharing such data.” |
Delete the
term and its definition. Done. Consider addition of text to explain the
concepts and implications of shareable data. The current
definition is a list of constraints that shareable data must conform to. It is not a definition. |
|
|
S22-W11-026 |
|
2-Minor Technical |
P03-03-02-26 |
Subclause 3.2.26, page 7: The term "shareable data" is
the wrong term. Maybe
"structured data" or "aggregate data". In ISO/IEC 11404, the term "aggregate
datatype" is very close to this definition. |
Delete the
term and its definition. Done. |
|
|
CAN-P03-167 |
CAN-P03-168 (#177) CAN-P03-169 (#098) |
2-Minor Technical |
P03-03-02-27 |
A definition
usually consists of only one sentence. The second and third sentences here,
should be cast as NOTES to the definition. |
Resolved by
098 (CAN-P03-169). No action here. |
|
|
CAN-P03-169 |
CAN-P03-167 (#097) |
2-Minor Technical |
P03-03-02-27 |
A “steward” is
a role of a Person which involves commitment(s), right(s), obligation(s
(possible liabilities), etc.. This is imbedded in the current use of of
“responsible several times in the proposed definition. If so, then 15944-1
terms/definitions which deal with commitment must be used in 11179-3 , i.e.
the definition for commitment, those for Person(and its three sub-types
“individual, “organization” and “public administration”, and then within the
latter two “organization person”. Further, a
“steward” is someone who maintains. On the whole a steward acts and
implements on behalf of someone else, i.e has a master. Thus a steward rarely
“determines”. Is not the
real need/purpose here for a term/definition for “metadata steward”? If so,
why not just say so. Is the
application here not an “item” but a “metadata item” Why bring in “system”? an undefined
concept?. Proposed Solution Use the
following term/definition “metadata
steward: a Person who is charged with the responsibility for the
implementation and maintenance of
a metadata registry including the associated administration
record(s) NOTES: In the
management of metadata , a metadata steward is the Person responsible for the
determination of the content of administration records. For a metadata
registry, maintained by a registrar for a Registration Authority, as such a registrar may not necessarily be
the metadata steward of all or any items in that metadata registry. |
Replace the
term “steward” by “stewardship (metadata)” and revise the definition as
follows: “The
responsibility for the determination of the content of administration records
applicable to one or more administered items. Note: The
responsibility for the registration of metadata may be different from the
responsibility for stewardship of metadata.” Done. The
introduction of the concepts of Person and Role need to be addressed in a
future version of this standard. |
|
|
GBR-P03-004 |
|
1-Major Technical |
P03-03-03 |
The Editor's
Notes concerning datatype and related terms suggest that the reconciliation
of the 11179-3 data model with that of 11404 needs further work. Proposed
Solution UK is
sympathetic to the quest for consistency with 11404, but does not have the
technical knowledge of 11404 to be able to propose a solution. |
Reconciliation
with 11404 is deferred to a future version of this standard. Remove the
editor’s notes. Return when other comments on this
clause addressed. |
|
|
CAN-P03-062 |
CAN-P03-058 (#228) CAN-P03-076 (#248) |
2-Minor Technical |
P03-03-03 |
Revise clause 3 to reflect the changes proposed in CAN-P03-058 (#228). Proposed Solution
Insert in clause 3.3 the following terms and definitions. 3.3.x administered item context The relationship that provides a Context for an
administered item. Object type: Relationship The
part of a terminological entry containing information related to one
language. [ISO CD 16642:2000] Object type: Class [Note:
add a reference to [ISO CD 16642:2000] in clause 2.] 3.3.x language section
language identifier The
identifier of the language used to group a set of designations and
definitions. Object type: Attribute of
Language
Section [Note:
This assumes the acceptance of CAN-P03-076 (#248) adding “identifier”.] |