[BUG] - mapping of concrete metaclasses can violate MOF constraints

[NicolasRouquette]

Description

A clear and concise description of what the bug is.

The generated oml vocabulary from an ecore M2 metamodel should preserve the intended semantics of a MOF M2 metamodel. In particular, in an M1 model that is an instance of an M2 metamodel, every M1 element must be an instance of a single metaclass in the M2 metamodel. This is described in section 9.1 Reflection of the MOF 2.5 specification:
https://www.omg.org/spec/MOF/2.5.1/PDF

In oml terms, this means that the statement: ci X : Y should mean:

• X is an M1-level instance
• Y is an M2-level metaclass

The reasoner should produce an inconsistency whenever X is multi-classified by different M2 metaclasses. This means that the oml concepts corresponding to M2 metaclasses must be mutually disjoint. This requires making a distinction between:

• the vocabulary of the specification of metamodel where a concrete "metaclass" can specialize others
• the vocabulary of the M2-level metaclasses of that metamodel where all metaclasses are disjoint because of the single metaclass instantiation requirement of the MOF architecture.

With the current ecore2oml mapping, a concrete M2 metaclass maps to an oml concept.
Consider for example the UML 2.5 metamodel where several concrete metaclasses (e.g., AssociationClass, Component) specialize a concrete metaclass (e.g., Class).

This mapping yields something like this:

vocabulary <...> with # as uml {

  concept Class
  concept AssociationClass :> Class
  concept Component :> Class

}

At M1, this allows someone to construct an oml description like this:

ci x : uml:Class
ref ci x : uml:Component

This example violates the principle in MOF that every M1 element is an instance of exactly 1 metaclass.

One could argue perhaps that x above is effectively classified by the most specific metaclass, i.e., uml:Component.
However, this would ignore the fact that whoever or whatever produced that example may have made a mistake:
x should be declared as an instance of a single metaclass; that is, either:

ci x : uml:Class

or

ci x : uml:Component

but not both.

While it is true that if x is asserted to be a uml:Component, it is also a uml:Class; the problem here is that the oml metamodel fails to capture the subtle distinction between:

• for constructing M1-level instances of M2 metaclasses, an element must have a single M2 metaclass classifier.
• for the purposes of reasoning, an element constructed as an instance of a single M2 metaclass is also classified by all specialization parents of that metaclsss.

It is possible to capture this subtle distinction with a different mapping strategy:

An ecore metamodel maps to two oml vocabularies:

• a vocabulary for the metamodel where all M2 metaclasses (abstract and concrete) map to an oml Aspect.
• a metamodel that extends the above vocabulary where every concrete M2 metaclass has a corresponding oml Concept that specializes the corresponding oml Aspect of the vocabulary.

For example, this would yield something like this for a subset of UML:

vocabulary <.....> with # as uml-vocabulary {
 
  aspect Classifier
  aspect Class :> Classifier
  aspect AssociationClasss :> Class
  aspect Component :> Class

}

vocabulary <....> with # as uml-metamodel {

  extends <....> // the iri of the uml-vocabulary above.

  concept Class :> uml-vocabulary:Class
  concept AssociationClass :> uml-vocabulary:AssociationClass
  concept Component :> uml-vocabulary:Component

}

With oml bundle closure, the following examples will work:

ci x : uml-metamodel:Class

or

ci x : uml-metamodel:Component

or

ci x : uml-metamodel:AssociationClass

The reasoner would reject the following examples:

ci x : uml-metamodel:Class, uml-metamodel:AssociationClass

or

ci x : uml-metamodel:Class
ref ci x : uml-metamodel:AssociationClass

Steps to Reproduce

Steps to reproduce the behavior:

• Step 1
• Step 2
• Step 3

Expected Behavior

A clear and concise description of what should be the expected behavior.

Additional Context

Enter any other details such as dependencies, environment, examples, etc.

Relevant screenshots

If applicable, add screenshots to help illustrate the issue.