ISO/IEC 11179 is a standard for metadata-driven exchange of data in a heterogeneous environment, based on exact definitions of data. Reference material is at:
- Wikipedia overview: http://en.wikipedia.org/wiki/ISO/IEC_11179
ISO/IEC 11179 edition 3 final draft:
historical link: https://wiki.nci.nih.gov/download/attachments/18948131/WG2_N1326_WIP_Post-CD2_11179-3_Editors_Draft.pdf.
The specification includes concept of <<type>> ing metadata items in the metadata registry. Conformance profiles are defined with respect to extent of metadata item <<type>>ing. The specification also defines metamodel constructs used in specifying the registry metamodel, including definitions of class and datatype.
- UML model for 11179ed3: https://wiki.nci.nih.gov/display/CommonProjects/UML+Model+for+11179+ed.+3. Accompanying the 11179 ed3 specification is a uml model. According to the specification, specification text overrides the uml model if there are perceived conflicts. The uml model should be considered a "template", since <<type>>s have not been applied to metamodel constructs.
- caDSR - 11179ed3 gap analysis report: https://wiki.nci.nih.gov/display/caDSR/Domain+Model+Gap+Analysis+Report+--+caDSR+4.0+vs.+ISO+IEC+11179+Ed.+3. This gap analysis report is intended to address gaps between the 11179 ed 2 - based caDSR implementation and the 11179 ed 3 specification.
There are some practical problems, issues, and need for clarification with respect to the reference material cited in above.
11179 ed3 final draft
Key points in the document regarding the application of the specification to particular domains include
- Definition of metamodel constructs.
- Typing of items in the metadata registry
- Dynamic extensions (Slots)
- Conformance
It should be noted that there are inconsistencies and anomolies in the specification which will cause implementation issues.
Section 3.2 Definitions of Metamodel Constructs
defines the metamodel constructs used in specifying the registry metamodel. Of particular note for this review are the following:
- 3.2.4 class metamodel description of a set of objects that share the same attributes, operations, methods, relationships, and semantics
- 3.2.7 datatype set of distinct values, characterized by properties of those values and by operations on those values
These definitions are referenced in subsequent clauses of the specification, for example:
- 5.1.2 Boolean datatype A mathematical datatype associated with two-valued logic
- 5.1.3 Contact class Description of Contact ... Contact is the class of object to whom information item(s), material object(s) and/or person(s) can be sent to or from...
Section 4.5 Types of Items in an ISO/IEC 11179 metadata registry
This section of the specification defines *<<type>>*s which may be applied to any metadata item in the metadata registry, subject to a set of rules. This enables, for example, concepts and data descriptions to also be registered, administered, classifiable, etc., metadata items.
Note that the registry metamodel is specified without application of <<type>>. The relevence of domain-specific application of *<<type>>*s is specified in the Conformance clause.
Section 6.1 Identification
The Identification region of the model specifies how metadata items are identified in the metadata registry. A metadata item that is to be identified shall be assigned the type Identified_Item. Each Identified_Item may be associated with any number of Slots, which is a dynamic way to add arbitrary attributes to instances of Identified_Items.
Section 12 Conformance
This clause provides several views of conformance:
- Conformance by specification clause.
- Degree of conformance. May be "strictly conformant" or just "conformant". A strictly conformant implementation shall not recognize, nor act on, nor allow the production of data element attributes that are dependent on any unspecified, undefined, or implementation-defined behavior
- Profile. There are 4 defined profiles, which provide a range of specification clause conformance and registry/identification support (via <<type>> application to metamodel elements).
The most comprehensive profile (Extended Metadata Registry), requires satisfcation of the following provisions:
- Implementation of all specification clauses 6-10.
- All Data_Elements, Value_Domains, and Derivation_Rules must be Registered_Items.
- All Concepts and Concept_Systems must be Registered_Items.
- All Registered_Items must also be Designatable_Items and Classifiable_Items.
Specification issues
There are some specification inconsistencies.
The following diagram depicts a name conflict:
The class Context has an association with Context_System via a property named "source". The class Relation_Role, which is a subtype of Context, has an association with Relation via a property named "source". The (Property) named "source" can not be redefined.
Another redefinition conflict:
The described_value_domain_meaning association has association ends which have identical names to the association ends of the *valud_domain_meaning" association. Both sides of the association have name redefiniton conflicts. (This is actually referenced in an editorial comment within the specification). The actual intent of one association is to constrain, or <<subset>>, the other association and it should be made clear from the model and text that this is the case.
Although not a specification or model issue, an unfortunate choice of name combinations between classes and association ends is producing code generation errors. This is a tooling problem. The problem is manifested within eclipse EMF generation of model "Package" where generated accessor names for structural features conflict with generated accessor names for classes. For example:
In this model fragment, the "Package" accessor to the (meta model) structural feature named
"example" of class "Data_Element" is named Data_Element_Example, which is the same generated accessor the (meta model) class named Data_Element_Example. A similar problem exists for the "derivation" feature of "Data_Element" vis-a-vis the class "Data_Element_Derivation".
UML Model for ISO11179 ed3
The (Magic Draw) UML Model associated with ISO11179 may be considered an abstract model. It does not include the application of <<type>> inheritance for metadata items. As it stands, the UML model would not satisfy any conformance profile. For any specific domain application of the model, the model needs to include some appropriate level of applied <<type>>s.
Any evaluation of the model should be with respect to a domain-specific conformance profile. Specifically, the model needs to be extended with application of <<type>> inheritance prior to performing a gap analysis.
In addition to work-arounds related to specification issues, the model itself should properly reflect the difference between class and datatype, as defined in the specification. In particular, the metamodel elements denoted as datatype in the specification should be UML Datatype (or PrimitiveKind).
Gap Analysis Report Inconsistencies
The gap analysis report does not take into consideration the domain-specific application of <<type>> to metadata item, the conformance profile considerations, or the use of Slots for dynamic extension of elements. As a consequence, the gap analysis report does not make valid conclusions:
- Classification categories are administered component items in caDSR while in the Standard there is no specification for identifying them as either administered items The specification explicitly provides for any meta model element to be an administered item.
- extensions are deemed required for a number of special cases. This conclusion does not appear to be warrented, based on the ability to utilize the "Slot" mechanism to extend any meta model element.
Although a transformation needs to be implemented from the legacy caDSR to MDR, the new MDR may not appear to require the extensions suggested by the gap analysis report.
Recommended migration strategies
The caDSR implementation of ISO 11179ed2 utilized extensions and modifications of the standard in order to provide some level of traceability to UML models and other forms of data concepts. This approach was taken based on special domain requirements vis-à-vis the existing standards.
With a more flexible ISO 11179ed3 standard, compliance with the "Extended Metadata Registry" profile should be achievable without need for extensions or variance.
The target implementation should be:
- ISO 11179 ed3 compliant at the highest conformance profile and stricted level of conformance.
- Should accomodate arbitrary meta-models, not just UML (there should be no UML-specific extensions in the implementation)
- For UML models, coverage should include any desired model elements and their inter-relationships, not just classes, properties, and associations.
- mapping of models/model elements to ISO 11179ed3 should be model/rules- based, such as via QVT
Implementation
Initial implementation:
- Minor model fixes for name conflicts, primitive types.
- Extend model elements according to 11179ed3 rules to satisfy "Extended Metadata Registry" profile compliance.
- Convert resulting uml model to an M2 level meta-model implementation.
- Upload UML and 11179 model fragments to Knowledge Repository.
- Provide initial implementation for visualization from Knowledge Repository.
Summary
Knowledge Repository MDR will be standards compliant, simplify implementation, extend modeling options, improve semantic access.
