Editor's disposition of comments on CD 19763-12
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
001
CA00
0-Ballot
-
Ge
Canada has voted ‘Disapprove with Comments’ on
this ballot, for the reasons stated below. Canada
supports the project and will change its vote to
Approval on satisfactory resolution of these
comments.
002
CA01
0-All
Page
headers
Ed
Most odd numbered pages show the document
number incorrectly in the page header: 17963
instead of 19763
Correct the document number.
Accepted – page numbering
corrected
003
CA10
All
Te/Ed
Any other errors found before or during the
Comment Resolution meeting should be corrected
if consensus can be reached on a resolution.
To be addressed at the CRM as required.
No further action at this time
part 2: Core model and modeling mapping
Accepted – title corrected to
"Part 10: Core model and
basic mapping"
004
KR1
ed
page 3 line 8 - missing title
005
KR2
ge
This part of 19763 forcuses on the registration of
modeling notations
No further action at this time
Rejected – the metamodel
already handles inheritance,
aggregation and composition.
(escpecially on relational database modeling).
But I am confusing whether this metamodel can
support Object-orient Concept including
inheritance, aggregation, composition..
Thus, it is needed to make up some examples or
explanations on OO model.
006
GB 01
General
007
US 001
Introduction
ge
2nd
paragraph
ed
It is noted that there are some notational
differences between this CD and CD 19763-10.
The first sentence seems incomplete:
Business information requirements, including the
semantic meaning of the information, are often
represented by information models before the
databases that are an integral part of the systems.
008
CA02
1-Scope
1st para
4th line
Te
The scope statement refers to ‘industry standard
diagramming techniques and notations, but not all
the techniques listed are standardized.
These notational differences must be
resolved to ensure consistency across
19763.
Business information requirements,
including the semantic meaning of the
information, are often represented by
information models before the databases
that are an integral part of the systems are
designed.
Rephrase as ‘common industry
diagramming …’
Accepted – notations aligned.
Accepted – amendment made
Accepted – amendment made
page 1 of 8
Serial
009
MB
CA03
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
1-Scope
Editor’s
Note 1
Te
010
GB 02
1
011
US 002
1 Scope
012
CA04
2
Conformanc
e
013
US 003
2General
Conformance
ed
014
CA05
3-Normative
References
Ed
015
JP 01
3 Normative
reference
016
US 004
3-Normative
References
ge
Editor’s Note
1
te
2.2.2, 2.2.3
Te
19763-2
ed
Editor’s Note
2
te
Comment (justification for change) by the MB
Proposed change by the MB
The editor’s note suggests that Fact Based Models
could be supported by making Fact a synonym for
Entity Type. Canada does not believe this
approach is appropriate. (See WG2 N1641 for a
more detailed explanation.) A similar approach is
proposed for database schemas, which needs
further discussion.
Revise the scope statement to more
accurately reflect the type of models that
are supported by this standard.
The scope issues highlighted in Editors Note 1
need to be resolved.
None proposed.
The text specified ‘conformance’ as supporting
metamodel specified in 5.3, but the later text
specified 5.1
Fact Based Models are the
subject of a separate study
group and are not in scope for
the current version of this
Part.
Database schemas are in
scope and are included in
CD2.
Editor’s Note 1
The proposed technique for covering fact
There were two areas that were not fully addressed based models and database schemas
should be incorporated into the next draft.
in the study period. The first of these was 'fact
based' models using techniques such as ORM. The
second was database schemas and structures. The
first could, I believe, be accommodated in the
metamodel by making 'fact' a synonym of 'entity type'
and allowing a 'fact' to be directly related to 'domain'
or 'datatype'. The second could also be
accommodated at a rudimentary level by making
'record' and 'table' synonyms of 'entity type' and 'field'
and 'column' synonyms of 'attribute'.
The Metamodel is referenced as clause 5.1, but
that is just the diagram. The whole of clause 5
constitutes the Metamodel and should be
referenced.
Draft disposition
Change all references to 5.1 to reference
5 instead.
It seems the model is in Figure 1, section
5.1 and should be changed in the General
section text to 5.1
See response to 009 (CA03)
See response to 009 (CA03)
Accepted – reference
changed to Clause 5.
See response to 012 (CA04)
The title of the referenced document is incomplete.
It should be ‘Core model and basic mapping’
Make the change.
Accepted – title corrected to
"Part 10: Core model and
basic mapping"
“ISO/IEC 19763-2, Information technology –
Metamodel framework for interoperability (MFI) –
Part 2:Core model and”
should be “ISO/IEC 19763-2, Information
technology – Metamodel framework for
interoperability (MFI) – Part 10:Core
model and basic mapping”
See response to 014 (CA05)
I would include 19763-3 and add annotations to the
classes that carry the semantics of the model.
See specific recommendations in comments See response to 014 (CA05)
by metaclass
page 2 of 8
Serial
MB
017
US 020
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
4
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Terms,
definitions
and
abbreviated
terms
Type
of
comment
te
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
many of the term sin this section have standard
Please use existing standard definitions
definitions in the Software Engineering Vocabulary
where possible.
http://pascal.computer.org/sev_display/search.action
E.g. attribute:
All definitions have been
reviewed and where
appropriate have been
revised. Where there is an
appropriate definition in an
existing ISO or ISO/IEC
standard this has been used
property associated with a set of real or
abstract things that is some characteristic of or adapted to fit this part.
interest (IEEE 1320.2-1998 (R2004) IEEE
Standard for Conceptual Modelling
Language Syntax and Semantics for
IDEF1X97 (IDEFobject), 3.1.9)
unique item of information about an entity
(ISO/IEC 20968:2002 Software engineering
-- Mk II Function Point Analysis -- Counting
Practices Manual,
Cardinality:
(1) the constraint on the number of entity
instances that are related to the subject
entity through a relationship (ISO/IEC
15474-1:2002 Information technology -CDIF framework -- Part 1: Overview, 4.2)
domain.
(1) set of objects, each of which is related
by a characterizing relationship to a
controlling object (ISO/IEC 10746-2:2009
Information technology -- Open Distributed
Processing
-Reference
Model:
Foundations, 10.3)
The link to the vocabulary is provided so
that the terms can be researched.
018
GB 03
4
te
Although this clause says that the terms and
definitions in 19763-1 and 11179-3 apply, some of
the definitions in 4.2 redefine terms without
explaining whether, or why, they are different.
Review all terms and definitions to ensure
consistency.
See response to 017 (US020)
page 3 of 8
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
019
GB 04
4.2.1, 5.4.10
te
This definition of attribute confuses type and
instance.
Replace definition in 4.2.1 with:
"characteristic of an entity type whose
values serve to qualify, identify, classify,
quantify or express the state of instances
of the entity type"
Replace definition in 5.4.10 with:
"Attribute is an abstract metaclass each
instance of which represents a
characteristic of an entity type whose
values serve to qualify, identify, classify,
quantify or express the state of instances
of the entity type."
See response to 017 (US020)
020
GB 05
4.2.7,
5.4.17
te
Casual language used
Replace definition in 4.2.7 with:
"collection of values from which an
instance of an attribute must take its
value"
Replace definition in 5.4.17 with:
"Domain is an abstract metaclass each
instance of which represents a collection
of values from which an instance of an
attribute must take its value."
See response to 017 (US020)
021
GB 06
4.2.11
ed
There are two clauses numbered 4.2.11
Renumber clauses 4.2.11 (second) to
4.2.29 as 4.2.12 to 4.2.30.
See response to 017 (US020)
022
GB 07
4.2.11
(second),
5.4.3
te
Casual language used
Replace definition in 4.2.11 with:
"set of characteristics common to a
collection of entities that are instances of
that type"
Replace definition in 5.4.3 with:
"Entity_Type is a metaclass each instance
of which represents a set of characteristics
common to a collection of entities that are
instances of that type."
See response to 017 (US020)
page 4 of 8
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
023
GB 08
4.2.20, 5.4.7
te
024
GB 09
4.2.20
025
JP 02
026
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
"Association", used in the definition is not defined
and the definition could, as it stands could include
super-subtype relationships.
Replace definition in 4.2.20 with:
"set of characteristics common to a
collection of connections between
instances of two or more entity types, or
between instances of one entity type and
other instances of the same entity type"
Replace definition in 5.4.7 with:
"Relationship is a metaclass each
instance of which represents a set of
characteristics common to a collection of
connections between instances of two or
more entity types, or between instances of
one entity type and other instances of the
same entity type."
See response to 017 (US020)
ed
The definition includes superfluous information.
Remove "Each relationship may have a
name and may have an identifying
indicator"
See response to 017 (US020)
4.3
Abbreviated
terms
ed
“MFI Core and Model Mapping”
should be “MFI Core and mapping”.
Changed to "MFI Core model
and basic mapping"
throughout
JP 03
4.3
Abbreviated
terms
ed
“ISO/IEC 19763-2, Information technology –
Metamodel Framework for Interoperability – Part-2:
Core model and model mapping”
should be “ISO/IEC 19763-2, Information
technology – Metamodel Framework for
Interoperability – Part-10: Core model and
basic mapping”
Amended to “ISO/IEC 1976310, Information technology –
Metamodel Framework for
Interoperability – Part-10:
Core model and basic
mapping” throughout.
027
US 005
5.1
Overview
ed
028
CA06
5.1
Figure 1
Te
5.4.2
References
It is hard to find entities in the list of metaclasses
found under figure 1
In UML, a model may have a class with no
associations. The Metamodel does not support a
model that consists of a single class.
consider alphabetizing the list
Change the multiplicity of
relationship_model_element to be 0..*
Accepted – the list has been
alphabetised.
Accepted – multiplicity relaxed
to 0..* in the metamodel for
CD2.
page 5 of 8
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
029
CA07
5.1
Figure 1
Te
It is frequently the case that an Information Model
is divided is multiple diagrams or figures because
the whole model is too large or complex to
represent all at once. (E.g. The 11179-3
metamodel is divided into multiple figures.) When
this occurs, one entity may appear in more than
one of the figures. The current model has no way
of representing this partitioning.
Either include ‘diagram’ as a model
element, or allow a hierarchy of
Information Models, where the top level
model represent the whole model, and
lower levels represent a partitioning. If the
latter approach is used, then in becomes
necessary to allow an Entity_Type to be
shared across models, which in turn
requires the Entity_Types to be
Administered_Items, not Attached_Items.
Accepted – "Diagram"
metaclass added to the in the
metamodel for CD2.
030
CA08
5.2
All
Te
This clause appears to restrict the 11179-3 types
that may be applied to the model elements by
listing types which ‘may’ be used. The choice
should be up to the registration authority. In
particular, it may be desired to make some
Entity_Types Administered Items (see CA07).
Change the wording ‘may be extended as”
to ‘may be extended by types such as’, so
as not to include types not listed.
Accepted – change made
031
US 011
5.3
Second set
of bullets
ed
It is important that readers easily understand where
the links are to the other ISO standards…
•The name of the attribute; where the attribute is one
that is provided by the type defined in the MDR
metamodel by which the instances of the metaclass
are extended the name is italicised.
032
US 006
5.4
Metaclasses
in MFI
Information
Model
Registration
ed
It is hard to find the entities in the list of metaclasses consider alphabetizing the list
in this section without referring to the index
Accepted – the ordering of the
metaclasses has been
alphabetised.
033
US 012
5.4
Superclass
ed
Same as above, generally change:
Model_Element (defined in MFI Core and Model
Mapping)
Not accepted – see Clause
4.3 Abbreviated Terms
034
JP 04
5.4.3
Entity_Type
Reference
te
Containing_
model
Its Precedence should be “No”, instead of “Yes”.
Change to:
The name of the attribute; where the
attribute is one that is provided by the type
defined in the ISO/IEC 11179 MDR
metamodel by which the instances of the
metaclass are extended, the name is
italicised.
To:
Model_Element (defined in ISO/IEC 197632 MFI Core and Model Mapping)
Accepted – change made
Accepted – change made in
the restructuring of this clause
page 6 of 8
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Type
of
comment
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
035
US 007
5.4.3
Entity_Type
ed
Since Entity_Type has name and
significance_statement, do those two attribute need
to be repeated in all the sub-classes?
Also, if this class is a subclass of Model_Element,
which also have Name and probably a definition, do
those need to be repeated here in part 12?
Add text to clarify the presence of ‘name’
and ‘significance_statement’ in this part of
MFI.
Not accepted – the
significance of the italicised
attributes is included in the
text. Also Entity_Type does
not have any subtypes.
036
US 013
5.4.3
Entity_Type
attribute
ge
significance_statement is in italics which implies it
comes from MDR 11179
Can’t find ‘significance_statement’ in ISO
11179 Ed 3 – do not italicize
Accepted –
"significance_statement" has
been renamed throughout to
"description" in the metamodel
for CD2.
037
US 014
5.4.4
class
Entity_Type_
Alias
te
since 11179 items can have alternate designations,
the class may be redundant with ISO/IEC 11179
7.3.2.3 Designation Class
Reuse designation Class if possible
Accepted –
"Entity_Type_Alias" has been
removed in the metamodel for
CD2.
038
US 015
5.4.5
Attribute
Entity_Specia
lisation_Hiera
rchy
ge
The attribute “description” is italicized which implies consistency in attribute naming unless
is comes from MDR 11179 – why in some classes is justified
this called “description” and in other classes is called
“significance_statement”?
Accepted –
"significance_statement" has
been renamed throughout to
"description" in the metamodel
for CD2.
039
US 016
5.4.6
class
Entity_Subty
pe
te
This class has no attributes, how does one tell an
instance of this class from the superclass? What
makes it a subtype?
Accepted – the
"Entity_Subtype" metaclass
and its associations has been
replaced by a many-to-many
association in the metamodel
for CD2.
040
US 009
5.4.7
Relationship
te
same as above (A text name is good for human
consumption, but not necessarily comparable – it
would be better if the names were associated with
controlled terminology or ontology registered using
19763-3)
041
US 008
5.4.10
Attribute
te
A text name is good for human consumption, but not Add an “annotation” attribute, 0..1
Accepted – annotation
necessarily comparable – it would be better if the
attribute added with
Concept_URI
names were associated with controlled terminology
A link to a concept in a domain ontology that multiplicity [0..1]
or ontology registered using 19763-3
expresses the meaning of the class.
Add an “annotation” attribute, 0..1
Accepted – annotation
attribute added with
Concept_URI
A link to a concept in a domain ontology that multiplicity [0..1]
expresses the meaning of the class
page 7 of 8
Serial
MB
Clause No./
Subclause
No./ Annex
(e.g. 3.1)
042
US 019
5.4.18 and
5.4.19
043
US 010
5.4.20
044
US 018
Annex
045
CA09
Annex B
Paragraph/
Figure/
Table/Note
(e.g. Table
1)
Valid_Value
Table 1
Type
of
comment
Comment (justification for change) by the MB
Proposed change by the MB
Draft disposition
Accepted – the names of
these metaclasses has been
changed in the metamodel for
CD2.
te
Continuous and Discrete Domains
Use Enumerated and Described from
11179-Ed3 instead
te
same as above (A text name is good for human
consumption, but not necessarily comparable – it
would be better if the names were associated with
controlled terminology or ontology registered using
19763-3)
Add an “annotation” attribute, 0..1
Accepted – annotation
attribute added with
Concept_URI
A link to a concept in a domain ontology that multiplicity [0..1]
expresses the meaning of the class
te
Informative Annex
rationale that explains how this ties in with
MOF – why is the data model different?
Te
UML supports n-ary associations.
In the UML Class Diagram column,
change the answer for:
“All relationships are binary” to “No”
Not accepted – the comment is
not understood.
Not accepted, but the UML
Association Class concept has
been accommodated in the
metamodel for CD2.
“n-ary relationships are allowed” to “Yes”.
page 8 of 8