I’m losing the thread slightly between what’s in the metamodel and what’s in the model here. My understanding (in protégé / RDF terminology) would be:

- Metamodel has abstract classes, which cannot be instantiated in models
- Metamodel has concrete classes, which can be instantiated in models
- Models have abstract (logical??) instances, which represent grouping or abstract constructs
- Models have concrete (physical??) instances, which represent actual enterprise assets

for MikeT?:

My apologies, it isn't easy to follow first-off, because I am tackling it in a somewhat different way from the usual, as described in my note to your comment on the previous page (Model-objects?).

Remember that much of this is more like a metametamodel layer, except that it can also be used as a metamodel for instantiation within displayable models.

- The nearest we have to conventional abstract metamodel classes are Categories, but even they can be instantiated as 'dummy' placeholders in models (see the Models? page for more about placehlders).
- Entities and Relations are concrete classes which can be instantiated in models, and used as metametamodel classes which can be extended to create new concrete classes which can be instantiated in models.
- At the metametamodel level, there is no real difference between classes to represent abstract groupings, and those which represent concrete 'things': they're all 'classess' to be instantiated in some way. The semantics of 'abstract' versus 'concrete' at the model level is determined by the language in use, not by the metalanguage (i.e. the metametamodel layer).

It's obvious I need to explain this in a much better way! :-( But note that Protege is one example that already works in much this way: there's no real difference in Protege between a class and an instance - an instance is simply an end-point in the current trails of subclassing, and may itself become an instantiable class if we need it to be so.

I am not feeling very comfortable with the way subclassing (inheritance) is used in the above description. I am not experienced in meta modeling so perhaps I misunderstood some parts.

It looks to me like the notion of subclassing used here, is over-loaded.

From the brief description above it seems that subclassing is used to inherit or add properties and display-methods. I am not sure if inheritance is always the best way to deal with this. Take the example where you want to link an entity-type to a BPMN model. If I understood your description correctly, that would be done by introducing a subclass that holds the necessary properties and display-methods. Any extension of the entity-type that requires this notion of linkage to BPMN, will have to inherit from that subclass. Modeling a relationship between an entity-type and, in this example, a BPMN model, as a subclass of the entity-type limits the flexibility you have in creating these types of relationships. What would happen if you introduce a new relationship, with different semantics, between an entity-type and BPMN models? Multiple-inheritance might look like a solution, but it is not: it is not scalable and requires you to know all classes to subclass (inherit from). Any subclass introduced in the future, will not take part in that particular multiple inheritance relation.

Perhaps introducing the notion of "aspects" (as a special type of relationship perhaps, maybe even a first-class citizen of the model) of entity types (or their subclasses) might open up some opportunities to more cleanly model these concepts.

If you give a definition of "An entity-type is a stack of subclasses of the root entity-type.", can those subclasses themselves be entity-types in another inheritance lattice?

I am not sure if my above comments make any sense, typing them from the top of my head. I will spend some more time thinking about what this page is about. Have you thought about using some UML (class model?) to graphically describe the above meta-model? That would make it easier to follow I think.

Tom,

Please do try to explain this in a better way...

My view is this:
- Your metamodel will contain a class hierarchy of entities
- Some metamodel entities will be permitted to exist in models - they are concrete
- Some metamodel entities will not be permitted to exist in models, but will be needed to provide structure to the metamodel - these are abstract

Bavo, Mike - I fear I've messed this one up badly, and as Bavo suggests, it would probably be best described in a graphic, which can be tricky on this rather ancient homebrew wiki :-( All I can say is that it does work at the thought-experiment level, but I'm struggling to find an accessible toolset that will allow me to build something to test it with.

On the multiple-inheritance bit... damn, it really does need a full detailed example of how the 'sub-class stack' works. I'll have to hack it out of Archimate or something, which I won't be able to do for a couple of days. Agreed, it wouldn't be possible for a 'child' to inherit from other subsequent 'children' of one of its 'parents', but I don't see that as a problem. Yes, there is a scalability issue, but it's nothing like as severe as with the atomic-level links: Archimate 1.0 has just 32 entities (Concepts) and 10 possible relation-types, but that still leads to something like 1000 distinct relationship-pairs (at a quick guesstimate from the book) because they're defined individually at the atomic level. At a similar guesstimate, that should slice down to just 10 relationship-pairs, because the the pairing would be done in the relation-type, not from the atomic Concept-type.

(As I said in the comment to Relation, which I wrote just before this, I really need to clarify about 'entity' - it's best to use, say, the Archimate term 'Concept' for an architectural 'thing', and reserve the term 'entity' to mean the common base-type shared by Concept, Relation, Model and Category.)

Yes, any entity-type can itself be an entity-type in another inheritance lattice: the only restrictions are that it can't be re-used within the same stack, and (with the exception of Category, which can be sub-classed into any of the others), each type - Concept, Relation or Model - can only by stacked with the same type.

Mike, yes, that's exactly correct: the hierarchy, and the distinctions between abstract and concrete. There a few subtle complications such as the role of placeholders, which are kind of halfway between abstract and concrete (modal-logic again), but the main probable source of confusion is that we're dealing two different layers here - the metametamodel (like MOF), and the metamodel (sort-of like UML). The metametamodel consists of a very small set of entities such as Concept, Relation, Model and Category, and these are abstract within the metametamodel. Within the metamodel (next layer up) each item-type - a concrete class - is built up from a stack of instantiations(??) of those abstractions, each in themselves abstract, but collectively concrete. The reason I say 'sort-of' like UML is because it's actually an intermediate layer, kind of halfway between MOF and UML: it isn't a language like UML, it's a language to build languages. (You can't do that kind of stack in UML, or Archimate, for example, because they're at the next level up, where the language is already fixed. In this type of metamodeling we build a custom UML-like language for each client: the point of all this fuffling around is to design a way in which that kind of information can be interchanged between systems that are using different languages at the UML/Archimate-equivalent layer. Hence why I said it's a core-metamodel, not a straight EA metamodel like TOGAF or Archimate: it has to be able to handle any EA metamodel we need to throw at it.)