Many thanks – this really does help. On last item first, will follow up on OMG Versioning, and definitely agree that it’s so fundamental that it needs to be right at the root (metametamodel), which is probably the level of what I’m describing here anyway.

I’m probably not being clear enough on subtyping versus instantiation. To give a concrete example, using Zachman-style layering, imagine I have a type ‘database application’. I might then either instantiate or subtype it, Protege-style, to give an entity ‘Oracle database application’. I take that to full instantiation as ‘Oracle 9i database application’. That all sits at the layer-4 ‘Physical’ or ‘Develop’ in Zachman-style layering. When I take it down one Zachman-layer, to the real-world ‘Deploy’ level. I need to re-convert that instance to an instantiable subtype as a composite with the subtype ‘server’, as ‘Oracle 9i server’; I can then instantiate that as ‘Oracle 9i develop server’, ‘..test server’, ‘..production server’, ‘..fallback server’ and so on (each of which might again need to be re-instantiable as ‘..server #1′, ‘..server #2′ and so on).

On inheritable display-method, what I’m thinking of here is that some model-types would want to list everything that is, for example, a physical-asset either in whole or in part (such as a paper form, which is both a physical-asset [paper] and virtual-asset [data]). If the display-method is an attribute of the attached inherited-entity – which I’ve rather loosely described as the ‘parent’ – then it would / could be available to the subtype. I’m currently working on how that sort-of-inheritance would work in practice, but it seems doable. It’s certainly close in concept to your notion of Diagram Definition as yo describe above, though perhaps not quite the same.

I’ll admit I’ve been working almost entirely on my own at a ‘thought experiment’ level; as yet haven’t really mined from or aligned with the available information from other important sources such as OMG, and it’s clear I need to do so. Any suggestions as to where I ought to start on that, or who else to work with?

Many thanks again, anyway.

Your ideas strongly relates to work I’m involved in at OMG in the areas of:
a) ‘MOF for Semantic Structures’ which allows the entities to evolve over time to adopt different entity types
b) Diagram Definition which allows the definition of what diagrams can contain and which are valid.
Thus, to take your example, an instance of entity type RelationalTable could be given the additional Entity Type BPMN Data Object to allow it to participate in BPMN models/diagrams.

However I think you do need to distinguish subtyping (a relationship between 2 types) from instantiation (a relationship between a type and an instance): to talk of an instance being subtyped does not really make sense IMHO.
And I don’t quite get “a composite inherits not only the attributes and display-methods of its included ‘parents’ ” – what do you mean by ‘parent’ (seems unintuitive for the entities included in the composite)? And I think any ‘display meatods’ would be associated with the composte itself not to the entities included in it: as you say elsewhere this needs to be context-driven.

Finally, I agree versioning is important, but it should be metamodel-independent. The OMG Versioning standard is defined at the metametamodel level (MOF) so automatically and implicitly applies to models in any MOF-based metamodel (UML, CWM, BPMN etc). This gives a clean separation of concerns, does not muddy individual metamodels with versioning details, and most importantly, provides a capability for versioning composites of entities from many different metamodels.

No, I hadn’t properly thought in terms of Architecture Description Languages (I presume that’s what you mean by ‘ADLs’?), other than a discussion with one of the Open Group crew who said that an ADL for TOGAF has been ‘coming Real Soon Now’ for about a dozen years.

The catch is that all of the ADLs I’ve seen to date are designed for software, which is great for explicit rule-based relationships, but can’t handle the complexity of real-world ‘ifs and buts and perhapses’ relationships between entities.

That’s the point about ‘legal’ versus ‘non-legal’ relationships in your comment above. It’s not so much about whether it appears in a specific view or model, as whether and how it should be used within the whole architecture. From a requirements perspective, a ‘legal’ relationship is a “shall”; but we also need a whole slew of levels of bindedness, such as the MoSCoW set ‘must’, ‘should’, ‘could’, ‘would be possible’ – which is the kind of range that we get in reference-frameworks and in architecture dispensations.

Ultimately, yes, we _must_ be able to express all of this in an XMI-like ADL, but that’s going to take, again, a whole slew of separate work. What I’m trying to do right now is get my thinking straight on what a metamodel should look like and what attributes and methods would be needed to make it work. Any suggestions on that would be much appreciated!

As for legal relationships, my initial response is a relationship between two entities is either always legal or always illegal. Now, whether it is displayed in a view or not is a different concern based on the stakeholder who is viewing the view. My thoughts here would be counter what you say above so I must ask: am I way off or do we have a mismatch on terms?

Cheers!