There are a bunch of spacing errors (6.4.1 has just one of these) in the document. Word’s grammar checker will find them.

Remove extra spaces

as above

In the XMI file there is a bunch of weird DataType with blank names that are not used.

Fix datatype issues

as above

OWL seems essential, but there is nothing mentioned about OWL until 8.5.3 and no other references.

Add OWL to glossary

Add OWL to glossary

as stated

Add comments to red-line document

as above

as above

Clarify graphics as able

Unable to change some graphics that are too big to fit a standard page legibly.

as above

Make corrections for loading into Cameo

as above but there is no access to Cameo

List of contributors incomplete

Add missing contributor name

Gargi Gajjar contributed to the Finalization Task Force. Her name was added to the list of contributors

The term Admit Data Time used in the example is not correct because Admit Date Time has more syntax than it just in the ADT A01 file.

Add the term "message" to further specify data use

Change " in a HL7 V2.8.2 ADT-A01 there is a field representing Admit Date/Time." to "in a HL7 V2.8.2 ADT-A01 message there is a segment that has is a field representing Admit Date/Time". The change specifies the structure of where a data item of Admit Date/Time would be located for those familiar with HL7 V2.8.2 message model.

The term SNOMED CT is used in the Annex C and it is not included in Annex A

Add the missing definition for SNOMED CT

The definition of the term was added. "The SNOMED CT is a systematically organized computer-processable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting"

The term "MDMI Semantic Element" is incorrect because it represents a proper name and its class name, MDMISemanticElement, should be used.

Change "MDMI Semantic Element" to "MDMISemanticElement" (no spaces)

The term "MDMI Semantic Element" is the proper name of the class MDMISemanticElement in the specification and therefore the term has been changed throughout the document to MDMISemanticElement.

See attached document for specific locations.

The examples provided for the term datum were missing a key concept of time.

Reword sentence to clarify definition

The concept of time as a datum was missing. Change "an atomic datum, such as a name or measurement value" to "an atomic datum, such as a name, measurement, or temporal value"

The file went missing but was recovered. It appears that the recovery munged some of the text.

Reviewer comments:
Lots of elements are strangely duplicated, like Bag, SemanticElementSet, Node, SimpleMessageComposite, ToBusinessElement, MessageSyntaxModel, etc. As I recall, this was one of the files that was lost. I think the recovery was an implosive mix.

Corrected file obtained

File without corruption replaces the one there

The description of the Step 2 process in Annex C for developing the MDMI Healthcare Ontology is incorrect.

Remove ANF reference

ANF was not used as a Reference Model. All sentences after the first sentence in Step 2 were removed.

In the first line:
The goal of the MDMI standard is to provide a declarative, model-driven mechanism to perform message data...

The word "message" is in subscript.

Changed font type of word

"Message" changed from subscript to normal text

No attestation in section 3, Normative References

OWL is mentioned in the document but has no further reference

Added missing reference

Provided link to W3C site for OWL.

Text for the section is missing. It only contains an irrelevant caption.

Added missing diagram

Added diagram for MDMIDatatypes, DataRules - Abstract Syntax

Should this be identified as an RDF/OWL file?
I did find documentation in the RDF file, thank you! However, it might not be aligned with your specification. For example, hasAuthorPersonLegalName is in the RDF, but not in the specification or XMI.
Looking at the RDF itself, I find the following at the beginning that I have questions about:
                <!ENTITY dct "http://purl.org/dc/terms/">
                <!ENTITY mdmi-gsm "https://www.omg.org/spec/MDMI/MDMIGenericStatementModel/">
                <!ENTITY owl "http://www.w3.org/2002/07/owl#">
                <!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#">
                <!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#">
                <!ENTITY skos "http://www.w3.org/2004/02/skos/core#">
                <!ENTITY sm "http://www.omg.org/techprocess/ab/SpecificationMetadata/">
                <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">
 
Questions:
1. Should these be in normative references in the spec?
2. What is the reason for the choices in these standards (annex?)?
3. Except for the minor reference to OWL, there is no other mention of RDF and these related standards. I’m assuming this is important information that is missing from the specification, given that this is a normative machine-readable file.

No changes necessary

Use of RDF is informative not normative

You are burring the lead in the specification scope. I suggest starting with the Scope section with the remainder of the second paragraph: “The goal of the MDMI standard is to provide a declarative, model-driven mechanism…” The remainder text can then follow as background. A better scope will help with adoption as you will be leading with what the spec is to do.

Clarify scope

Change to:

The goal of the MDMI standard is to provide a declarative, model-driven mechanism…

6.4.2 “360  View of diverse IT eco-system” seems like an odd choice for a paragraph title. There is no mention of 360 in the body. Perhaps this is better discussed as enterprise-level definitions and reuse.

Change title of the paragraph

as above

as above

Add normative references

for OWL and RDF

6.2.1.1 Please define ‘conceptsentities’ or fix the typo (missing comma).

Put a space between the words

as above

No references are made to the normative machine-readable,  no RDF/OWL hook to hang your propeller cap. OWL is not defined or discussed.

No changes necessary

Files are informative not normative

as above

No changes necessary

File is required by OMG process

The name, VitalSignObservationActionFocus, in Annex C is inaccurate and the graph description of the correct term is inaccurate.

Remove "Action" from "VitalSignObservationActionFocus" and "ActionFocus"

In the example in Annex C, change the term VitalSignObservationActionFocus to VitalSignObservationFocus. In addition, change the graph description of the DataElementConcept to Focus.

The expression "are synonyms" is incorrect. There are other possible conditions that may cause the condition besides the MDMIBusienssElements being synonyms.

Change statement from definitive to possible

An example of a different condition is that one MDMIBusinessElement has an incorrect specification of its StatementContext or DataElementContext. Proposed change is to change "are synonyms" to "could be synonyms".

In the standard, each MDMISemanticElement must be unique. Having "near-synonyms" with the same MDMISemantic Element violates this principle.

Remove the sentence

Deleting the sentence "In effect, they define the domain of “near-synonyms” that are allowed in a mapping." addresses this issues

There has already been introduced a term in the document for "semantic unit" and it should be used.

Clarify use of "semantic unit"

The term data item has been used previously. Change "to expedite the insertion or extraction of as little as one semantic unit data item of a message" to "to expedite the insertion or extraction of as little as one data item of a message"

With the additional functionality of providing a StatementContext and DataElementConcept to the MDMI Business Element Reference Class, the term registry does not sufficiently express the nature of the SEER.

Change "Registry" to "Repository

same

Issue: The term of smallest semantic enitities is ambiguous.

Proposed Resolution: The term is replaced with the term business concept which is defined.

The principle that the mapping between the MDMI Semantic Element and the MDMI Business Element is not as clear as it should be.

The use of AdmitDateTime is not valid as it is ambiguous. It is not a business concept because the context is missing.

smallest semantic entities is undefined and in the same paragraph the condition of losing semantic meaning results in having only generic data-type values which is incorrect.

Issue: The example of Admit Date/Time is ambiguous. It does not provide the context; Admin DateTime to what?

Proposed Solution; Provide the content in the example which is Encounter. There the example is EncounterDateTime

Issue: extra space between "Element" and "to".

Proposed Resolution: removed extra space

Issue: The term "ToMDMISemanticElement Semantic class" is not correct.

Proposed Resolution: Removed the word semantic in front of class.

Issue: the term semantic elements is ambiguous and could be interpreted by different individuals based on their perspective.

Issue: The term Semantic Element is ambiguous as it could be interpreted as a formal term.

Proposed Resolution: The term Semantic Element has been change to MDMI Semantic Element which has a specific meaning in the context of the standard and it refers to the name of the class in the MDMI meta-model.

Issue: There is a missing closing parenthesis after LOCAL

Proposed resolution: Paren added

There is an extra space after "NORMAL"

changed two to three and shouldn't have

see issue 21.

There is an extraneous "are" in front of synonyms.

Language missing that the development he MDMI Healthcare Concept Model was an iterative process.

Issue have been entered in Issue 21

Scope described was not appropriate for the FTF.

Issue: ANF was not used as a reference Model. It was inappropriate as a reference model for the SEER content.

Proposed Resolution: Remove all references to ANF. Section 0.6.1

Issue: The concept of a datum having a temporal concept (start time and end time) was missing.

Proposed Resolution: Added the term temporal

The concept of "near-synonym" mappings can lead to ambiguities and, in healthcare, possible patient safety issue.

The reference to SNOMED CT was missing in Annex A

Issue: the term semantic element is not defined and could be interpreted incorrectly.

Proposed Resolution: This reference is to the MDMISemanticElement and the word MDMI has been added.

The FTF did not use Step 2 in developing the MDMI Healthcare Concept Model.

Present language is misleading as it is not accurate.

As this term in used in Annex B which is informative about a healthcare example, the term MDCM should be move specific.

The term semantic element can be interpreted by differently by different readers of the standard. In the MDMI standard the term semantic elements is the MDMISemanticElement in the MDMI meta-model.

Issue: extra space between Element and to

In MDMI 2.0, we added two properties in the MDMI Business Element Reference Class; the StatementContext property and the DataElementConcept property. The name StatementContext is too limiting as there are concepts in the SEER the not only as defined in a "speech act" but can also be used to define a semantic of a more broader concept of Situation.

Because of prior changes, change all references to Step 4 to Step 3. This includes sub-steps.

Needed to occur because of deleting Step 2

In Annex B which is informative.

Present Step 2 has been deleted

O

The acronym SEER is not defined in the document and the term repository was used instead of registry.

The resolution of this issue is correlated to issue # 41 because the issue and the resolution of both issues have dependencies.

Issue: The name of the Business Element in the example beginning on the bottom of page 52 was VitalSignObservationActionFocus. Based on the work of the FTF, this name is not appropriate and should not be used. The name is inappropriate because Vital Sign Observation term as the ContentConcept property (formerly the StatementConcept Property) should be ObservationActivity. The name is also not appropriate because the term for the DataElementConcept Property, formerly ActionFocus, should be ContextFocus based on advice of the SMEs in the FTF.

he resolution of this issue is correlated to issue # 42 because the issue and the resolution of both issues have dependencies.

Issue: The name of the Business Element in the example beginning on the bottom of page 52 was VitalSignObservationActionFocus. Based on the work of the FTF, this name is not appropriate and should not be used.

Proposed Resolution: The name is inappropriate because Vital Sign Observation term as the ContextConcept property (formerly the StatementConcept Property) should be ObservationActivity. The name is also not appropriate because the term for the DataElementConcept Property, formerly ActionFocus, should be ContextFocus based on advice of the SMEs in the FTF.

Presently the wording of "MDMI Business Elements are synonyms" is not correct.

having the word "are" in first sentence leading off this section could be misleading and is not proper English.

Related to Issues 41 and 42

Issue: Graph description is incorrect as the ContextConcept is not VitalSignObservation.

Proposed Resolution: Removed words vital sign.

The term "a semantic unit" is ambiguous and does not convey the concept appropriately.

The word "The" is missing before "KBS Team"

Issue: The term smallest semantic unit is undefined in the document and it is ambiguous.

Proposed Resolution: Replace the phase with the phase "business concept" which is used in the description of the term MDMI Business Element and is appropriate in this context.

the term SEER was not defined in Annex A.

The term MHDM is not defined and inaccurate.

Relationship is missing in MagicDraw diagram. It appears to have been the result of an editing error as is has shown up in all versions of 8.2 I see in document.

Issue: the present name of the association is repository.

Proposed Resolution: The name of the association should be changed to registry based on other proposed resolutions

the SemanticElement is used in the UML model

Not an issue .... original language acceptable

In the Annex B, based on the work in the FTF the term VitalSignObservationActionFocus is not valid.

The term smallest semantic unit is undefined in the document and it is ambiguous.

Issue: the term Referent Index appeared in the document. It was deprecated in the 2.0 submission.

Proposed Resolution: Changed the term Referent Index to SEER.

During the FTF process, there was one change made to the name of a property in a class and there were one or two changes made to class names to remove possible ambiguities. In addition, as different modeling tools used to develop the diagrams throughout the 2.0 process, new diagrams were generated for Section 8. At some point during the review process, it was discovered that an important relationship was missing.

Currently there are (usually) subtle differences in the XMI files created by different design tools. If runtime engines are going to successfully read MDMI maps, then the standard has to specify a standard format for the XMI for a map
Discussion:
It is agreed that the XMI format of an MDMI map must be consistent. However there are ongoing activities both within OMG and ISO 20022 to more generally define a consistent XMI standard. The MDMI FTF would like to assess the potential of these other formats before defining an XMI format standard just for MDMI.

The MDMI specification identifies the semantic unit in a message to be a Message MessageElement and MessageElementSet. The term Message Element and associated class names may be confused with the term Message Element in The ISO 20022 specification for those using the specification for financial service mapping. Since the central hub dictionary used in these mappings will most likely be the ISO 20022 data dictionary.

For better documentation, there is no reason why there should not be a description attribute for each class but this must be integrated into any table or spreadsheet UI.

we beleive the MDMI 1.0 spec has only limited ability to support data translation in the presence of structure clashes bewtween source and target data structures. We suggest ways in which this could be tackled.

These are important for impact analysis and management purposes. The following should be drawn as associations and have opposite properties:

• SemanticElement::datatype

• DataRule::datatype

• MDMIBusinessElementReference::referenceDatatype

A key concept of MDMI is that it requires a domain dictionary as a hub in its "hub and spoke design". The current specification does not associate a Message Model with a domain dictionary. If the specification is to work, such a reference will be important. Otherwise, the specification will not be clear and maps may be ambiguous.

Current text
In particular, an implementation needs to support a design-time activity with all of the steps involved in generating the conversion maps, and the runtime application of the generated maps to a source physical message in order to create a target physical message.
New text
SEE QUESTIONS & COMMENTS IN NEXT COLUMN
Rationale
Must all implementations have a design-time activity? Don't we expect to have more implementations that use the conversion maps than implementations that can create the maps?

The property SemanticElement::datatype has no type itself in the metamodel or UML diagram. According to 8.3.4 (property 4) it should be MDMIDatatype so this is arguably an editorial change.

Likewise MDMIBusinessElementReference::referenceDatatype has the same problem (missing from the model but documented as Property 5 of 8.5.3.)

However it is a fundamental problem with use of the normative metamodel and should be fixed as an urgent issue.

Figures 8.1, 8.2, 8.4, 8.8 also need updating.

Oddly Figure 8.5 is OK (indicating that it is out of date with the metamodel so may be missing other changes. E.g. the property ToBusinessElement::description is missing its datatype of String).

Likewise 8.6 is OK in that respect but is out of date with respect to the metamodel: datatypes of int and bool are shown instead of Integer and Boolean correctly used in the metamodel

Since it is derived from fieldName presumably this means that on creation fieldName is always set to null! I don’t think this effect was intended, so /isSyntacticField should have isReadOnly=true and not have a default.

In the metamodel Choice::contraint is mis-spelled. It is correct in 8.2.6 but not Figures 8.1 and 8.8.

The description and use of MDMIBusinessElementRule is completely unclear. All we have, in 8.5.7 is “some business rules may have to be specified within a map to make sure that the mapping is correct”.

Section 8.5.3 states that a Dictionary is required to have a function that returns a unique id for any use of the ‘same’ business element. However it’s not clear what ‘same’ means here – and this is key to the whole MDMI process. It would help if the operation signature and semantics were to be specified in MOF as part of the metamodel.

Section 8.6.3 makes several references to ‘source’ and ‘target’ SemanticElements. However the metamodel does not use these terms – but ‘context’ (which I presume is ‘source’) and ‘relatedSemanticElement’ (which I presume is ‘target’). The descriptions of the properties sourceIsInstance and targetIsInstance are confusing, do not make sense, and in some cases are outright wrong (e.g. “the relatedSemanticElement owns the relationship by composition”). The scope when sourceInstance=’false’ is unclear – is it all instances of the semanticElement class in the message? The known universe?

It would make sense for the ‘defaultX’ properties of MessageGroup to be optional

Property SemanticElementSet::/mesageModelname should have isReadOnly= true

Current text: their
New text: its
Rationale: grammatical error

Resolution:
Fixed text
Revised Text:
Please see the annotated Beta 2 with markup.
Disposition: Resolved

Current text
Conversion Models for Payment Messages
New text
Model Driven Interoperability (in the Financial Industry)
Rationale
There should be a new name for this specification

Should changed text as above. Should change all instances of CM4PM to MDMI

Why would the parts of the address be considered as separate semantic elements? Can't we consider address as a data type?

Disposition: See issue 12734 for disposition

The attributes, propertyQualifier and dataTypeQualifier, refer specifically to dictionary terms in a UN/CEFACT dictionary and are meant to say these terms are all that are legal in a conversion. The specificity and use of these attributes is muddled. They should be removed.

The attributes propertyQualifier and datatypeQualifier will be removed from the ConversionRule abstract class

Simplifying the name of the MessageElementoUnqualifiedBusinessElement class and the name of the UnqualifiedBusinessElementtoMessageElement classes

The actual proper name of a dictionary BusinessElement is not likely to be an "UnqualifiedBusinessElement" so the name should be simplified.

These classes will be renamed "To Business element" and "To SemanticElement"

The MessageElementInstance class contains the value of a MessageElement. However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The class MessageElementInstance will be removed from the specification.

The current specification is in adequate in indicating the hub Business Element to which a MessageElement is to be mapped. The actual Business Element cannot be in an MDMI map since the structure of those Business Elements are already defined, given that the MDMI map is tied to an existing hub dictionary.

The UnqualifiedBusinessElement class is replaced with a class that references a Business Element in a dictionary. No assumption is made about the format of the Business Element in the central dictionary.

The UnqualifiedBusinessElementInstance class contains a place where a value in the central dictionary could be placed. However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The UnqualifiedBusinessElementInstance class will be removed from the specification

While a definition of datatypes is not in the specification directly, the structure of a datatype must be known to a runtime implementation so that it can execute the proper transformation. This is especially true since MessageElements can have very complex datatypes. Therefore, the specification has at least to have an explicit reference to a declarative structure that describes the MessageElement's datatype.

While the specification does not deal with datatypes directly, some restrictions on complex datatype definition are necessary for syntactic modeling. In addition, there has to be some restrictions on complex datatypes to ensure that a runtime engine will do proper transformation utilizing the maps that are linked through a business element in the central dictionary. These restrictions include: 1) that the simple datatypes be from a known standard, such as the XML simple datatypes or the Java simple datatypes; 2) that every element in a complex has a named field for the simple datatypes it contains. Therefore, the datatype for the attribute "datatype" will be changed to a datatype of "MDMIDatatype".

Given that the MDMI standard does not provide a specification for a the hub dictionary and in effect allows mapping to any appropriate dictionary, such as the ISO 20022 Data Dictionary, then some business rules may have to be specified to make sure that the mapping is correct.

An MDMIBusinessElementRule class will be added that has a many-to-one association with the MDMIBusinessElementReference class

The current MessageElementRelationship class does not seem to handle message relationships properly, especially given the potential for a MessageElement to have multiple instances, i.e., how does one distinguish between relationships to an instance and relationships to a class.

To handle correctly SemanticElementRelationships, two changes will be introduced.
1. In the SemanticElement class, an association will be added to declare explicitly a parent/child relationship, as defined in a message format.
2. Second, in the SemanticElementRelationship class the Boolean attributes sourceIsInstance and targetIsInstance will be added. If the source SemanticElement has multiple instances then:
· when the sourceIsInstance is true, the defined relationship is for each Instance of the source SemanticElement
· when the sourceIsInstance is false, the defined relationship is for the SemanticElement class as a whole
· when the targetIsInstance is true, the defined relationship is for each Instance of the target SemanticElement
· when the targetIsInstance is false, the defined relationship is for the SemanticElement class as a whole
There are also two additional attributes that are there to help a runtime parse a message. These are minOccurs, which says how many instances of the target at a minimum must be involved in the relationship; and maxOccurs\, which says how many instances at most can be involved in the relationship.

The attribute "position" was meant to describe the cardinal position of a repeated MessageElement class (i.e., the "multipleInstance" attribute has a value of "True"). Obtaining such a value may be difficult. It would be better if the attribute simply described a more general ordering description in which a cardinal position could be an option.

The attributes "position" and "positionLanguage" will be changed to "ordering" and "orderingLanguage" respectively. The description of the "ordering" attribute will be that it specifies the method of ordering for SemanticElements that have multiple instances.

It would be useful an attribute of the MessageElement contained information that explicitly identified the MessageElement with the message format in which it resides.

An attribute "propertyQualifier will be added that will allow modifiers to be enumerated for the SemanticElement, such as a tag associated with the value in the original message format.

The current specification can require very complex incoming and outgoing conversions between a MessageElement and a dictionary's Business Element. The ConversionRule rule language will have to be complex and non-standard. In addition, important information for an implementation would be buried in those rules as opposed to that information being declarative and accessible.

MDMI will provide a clearer map if the association between a SemanticElement and a central dictionary's BusinessElements is isomorphic or represents well defined "near synonyms". This requires that transformations that are more complex are needed to prepare for that isomorphism be more explicitly included in the map. Towards that end, the new attribute "elementType" will be added to the SemanticElement class.
This attribute is defined by an enumeration that currently has three values each of which defines the type of Semantic Element.
· NORMAL - a "NORMAL" semantic element is equivalent to the current definition of a SemanticElement, i.e., a semantic element, contained in a message format, which is to be mapped to a central dictionary.
· LOCAL - a "LOCAL semantic element contains some technical information need that is needed to correctly map NORMAL semantic element, e.g., it may contain an index that is used to provide the ordering for a semantic element that has multiple instances.
· COMPUTED - a "COMPUTED" semantic element that is to be mapped to the central dictionary but contains a value that is not extracted from a message Instead, a "COMPUTED" semantic element's value is computed from the value of other SemanticElements in the message.
Three additional attributes are added to provide rules for computed values:
1. computedValue - An MDMIExpression that computes the value of the SemanticElement, which can refer to the value of other SemanticElements This attribute is most often used for SemanticElements of the type LOCAL.
2. computedInValue - an MDMIExpression that computes a value for a SemanticElement, when it is a target, based on the values of one or more BusinessElements and SemanticElements. The value when it is a source is directly mapped.
3. computedOutValue – an MDMIExpression that computes a value for a SemanticElement, when it is a source, based on the values of one or more SemanticElements. The value when it is a target is directly mapped.

Message Composites form a tree structure. The MDMI specification would make that structure clearer to discern if the parent of a MessageComposite was included as an attribute.

An "owner" association will be added to the MessageComposite class.

Having a Choice class inherit from a Set class seems unnecessarily complex. In addition, a Choice class should involve at least two Nodes whereas a Set could degenerate into having just one Node.

The Choice and Set class separately inherit from the Node class.

There need to be an allowance for the degenerate case where as Bag may only have one Node. In addition, the default value for the attribute "isUnique" should be True, as a Bag will most commonly be a set, i.e., contain no duplicates.

The multiplicity for the association will be changed from 2...* to 1...* and the default for the isUnique attribute will be changed to "True"

The current specification does not adequately deal with Semantic Elements that are represented by a multi-field, complex datatype. While the current specification, in theory, could be used to provide a complete MessageSyntaxModel, the location and format languages would have to be unduly complex and non-standard. The MDMI specification should be enriched so that the components of a complex datatype, which are, by definition, purely syntactic, can be mapped.

A modeled MDMI complex datatype is composed of classes, where the classes themselves can be complex datatypes or a class with a single valued simple datatype. Ultimately, all complex datatypes resolve to a set of simple datatypes that correspond to fields (or subfields) in a message format. Therefore, to accommodate Semantic Elements that are complex datatypes, a "fieldname" attribute will be added to the Node abstract class, which holds the name of the simple datatype class. For computational efficiency, a derived Boolean attribute is also added that says this node contains a syntactic element that is part of a complex datatype.

The Node class is the core abstract class of a Message Syntax Model. The current specification only allows a multiplicity of one for these classes. Given the fact that syntactic groups, especially complex datatypes can be repeated, mapping will be simplified if the Node class is redefined to take care of a multiplicity greater then one.

Two attributes are added to the abstract class Node, minOccurs and maxOccurs. If MinOccurs is zero, it indicates that this node is optional. If maxOccurs is greater than one, it indicates that the message format allows up to maxOccurs instances of this Node. The attribute "isOptional" is deleted, as it is now redundant.

The MessageInstance class is contains a URI to a physical address of an actual instance of a message for which maps are to be applied. However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent runtime characteristic so it should not be included in the specification.

The MessageInstance class is removed from the specification.

The MessagePackage class is an aggregation of messages that are physically stored in a single Package. These packages may be different then the MessageGroup. However, the MDMI specification is a Platform Independent Model (PIM) and this class really relates to a platform dependent characteristic so it should not be included in the specification.

The MessagePackage class will be removed from the specification.

The name of the Set class is formally incorrect. It contains an attribute that implies that the elements in the "set" may not be unique. Elements in a set must be unique. The proper term would be Bag.

The class name "Set" will be changed to "Bag". In addition, the default value for the attribute "isUnique" will be True, as a Bag most commonly will be a set, i.e., contain no duplicates.

The MDMI specification identifies the semantic unit in a message to be a Message MessageElement and MessageElementSet. The term Message Element and associated class names may be confused with the term Message Element in The ISO 20022 specification for those using the specification for financial service mapping. Since the central hub dictionary used in these mappings will most likely be the ISO 20022 data dictionary.

A global change in the MDMI metamodel and the specification document of the term MessageElement to SemanticElement has been made and the phrase or sub-phrase "Message Element" to "Semantic Element" has been made.

For better documentation, there is no reason why there should not be a description attribute for each class but this must be integrated into any table or spreadsheet UI.

For class definitions that did not have a "description" attribute, a "description" attribute was added. These include the following classes: MessageGroup, MessageSyntaxModel, MessageElementSet, Keyword, SimpleMessageComposite, MessageComosite, ConversionRule, MessageElementRelationship, SemanticElementIBusinessRule, and MDMIBusinessElementRule,

The DataRule rules are dealing with datatypes. It will be difficult to find a rule language and complex to write rules unless the structures of the datatypes (especially complex datatypes) in the rule are explicit and discoverable.

Even though datatypes are not part of the standard, there are restrictions required for the form of datatypes, especially complex datatypes. Section 8.4 of the document will be revised to take into account these requirements. The specific change to the model will be to include a "datatype" attribute in the "DataRule" class with a multiplicity of [1...*] to provide explicit references to the datatypes used in the rule expression. This is necessary so that DataRules expressions can be properly parsed.
While the class specification for DataRule does not change much, a large amount of explanatory text is included in the Beta 2 document to properly resolve this issue. First, there is the addition of a URI "reference" property in the MDMIDatatype class. In addition, associations are removed from the MDMIDatatype class and the MDMIDatatype class is simply used to define the type of any "datatype" property in the model. This was necessary in order to define the type for DataRule's new property, "datatype".
Then a section is added that presents an example of a metamodel for a "complex datatype" so the need for the explicit "datatype" property is clearer, as it exposes the type of structure that a DataRule language would have to access.