What would this ‘generic modelling metamodel’ look like? And how could we implement it?
This continues the work from previous posts on this theme, such as ‘More detail on EA metamodel‘ and ‘EA metamodel and method‘.
The legal bit: The aim is that this should contribute towards an open standard, and should not be used in proprietary fashion. For now, a Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) license applies to this text.
This will be, again, long, very technical, and probably with no illustrations (you’ll see later why there’s little point in trying to describe this visually – it just gets too messy). Sorry. 
But if this is of no interest to you, you can always skip it, can’t you? 
A reminder that this is all at the M3/M4 metametametamodel layer: the layer at which we describe very simple structures that can define metamodel-families that can define metamodels that can define the structures for models. What we’re after here is something with which we can describe any metamodel or metamodel-family – UML, BPMN, Archimate, Southbeach, Cohere, mindmap, Porter supply-chain, Business Model Canvas, whatever – in the same consistent way, such that we can move entities and relations between each of them, as using each model-type as views into the same overall ‘holograph’.
The other aim is that we should end up with a single file-structure that can move this information – selected subsets of the ‘holograph’ – between toolsets across the whole of the toolset-ecosystem.
What follows here is a first attempt towards a workable way to do this.
At the moment this description is just in pseudocode. It should be implementable as-is – I’ve roughed out some ideas for a preliminary PHP/MySQL implementation, anyway – but judging from the recursive database searches that that first design implies, it would be horribly inefficient and slow. It would be valid for a text-based file-format, though (such as JSON or XML), it does maintain separation between data and presentation (hence should work with a Model-View-Controller implementation-pattern) and so far I think it should work okay with a RESTful interface-protocol – so I think it should be implementable in line with current standards. Over to you on that, anyway.
Core concepts
The ‘holograph’ consists of a cloud of information-objects – call them ‘atoms’, or ‘motes’, or ‘molecules’, or some such term. (I’ll describe them as ‘motes’ from now on.)
For security reasons, encryption could be applied to all or any part of this mote-cloud.
All motes have the same structure, as follows:
- globally-unique identifier
- mote-role (including namespace of role)
- parameter-value for this mote
- list of (pointers to) other related motes
Each mote has an identifiable role – how it should be interpreted, the purpose that it represents within the overall holograph. A namespace typically relates to a specific metamodel or metamodel-family: UML has its own namespace, as does BPMN, BMCanvas, mindmap and so on. At the file-format level, a namespace represents the equivalent of a CSS file for XHTML: in effect, loading a namespace makes the respective metamodel and notation available to the toolset.
Each mote carries one parameter, as indicated by the role. (The value may be null or NaN or some other ‘non-value’, hence in effect the mote carries 0..1 parameters.) The parameter-value is raw data: the rules for interpretation and validation of that data are specified by other motes referenced in the related-mote list for this mote.
There’s an important design-decision as to whether parameter-values for motes can ever be changed. Some cases suggest that we should allow it; others suggest that we should never delete or change anything, but simply create a new mote for each update. I suspect that we’ll end up with a mixture of both, determined by mote-role, but that’s a decision that can be put off until later.
The related-mote list represents the usage and change-history for this mote. It is unidirectional: it lists other motes that are used by this mote – not those that use this mote. It is a list of pointers to other motes – not a container for other motes, because there may often be a many-to-one relationship between motes. In effect, this mechanism allows motes to have the equivalent of any number of parameters, complete with a full version-history for each of those parameters, without actually containing those parameters.
The sequence of the related-mote list is time-linear, and accumulative: nothing is ever deleted as such. The equivalent of deletion is that an entry in the list may be marked as ‘superseded’, indicating that another item in the list has now superseded that item in its role.
Access-control for motes is defined by references to other motes that have access-control roles.
Version-management for motes is defined via references within the related-mote list to version-identifier motes. The version-identifier references and ‘superseded’ markers in the related-mote list would be read in time-order – hence the process of recreating a version would consist of reading the related-mote list up to the respective version-ID marker.
Although nothing is ever deleted, it should be possible to create ‘export’-variants of motes in which version-IDs and ‘superseded’-references are stripped out – in other words, all the information for the current version only for each mote. Likewise, we could create an archive in which appropriate subsets of known-superseded motes are moved to a permanent-archive, with all references to those motes superseded by a pointer to the archive.
In general, toolsets should be able to ignore the absence of any mote that cannot be found. (There may be a small subset of core-level mote-types to which this general rule may not apply – particularly those relating to security and access-control.) Among other things, this enables information-hiding likely to be required by access-control rules.
Some key mote-types
In the bullet-lists that follow, the mote-name or ‘role’ is shown first; then, in brackets, the meaning of the mote-parameter; followed by a brief summary of how the mote is used.
Before we get on to the mote-types that are of most obvious interest – such as entity, relation and model – we need to summarise a whole range of base-level or ‘housekeeping’ motes. These include:
- parameter-type (type-ID): how a mote-parameter should be interpreted and validated (e.g. boolean, string, integer, floating-point number, etc) – in effect, part of an API for the toolset
- parameter-name (text-string): the display-name for a mote-parameter – language is indicated by a language-mote in the related-mote list
- language-name (text-string): identifies the language to which a mote or mote-parameter applies – usually some form of language-ID
- based-on (mote-ID): the ‘type’ on which a mote (entity, relation, model, etc) is based
- tag (text-string): general-purpose tag – used as ‘hooks’ for relations, to mark namespace-affiliation, and for many other ‘tagging’ purposes
- source-tag (mote-ID for tag-mote): reference to a tag-type that may be used as a ‘hook’ within a mote for the ‘source’-end of a relation
- destination-tag (mote-ID for tag-mote): reference to a tag-type that may be used as a ‘hook’ within a mote for the ‘destination’-end of a relation
- source (mote-ID): reference to a mote used as the ‘source’-end of a relation
- destination (mote-ID): reference to a mote used as the ‘destination’-end of a relation
- presentation (presentation-info): content on how to display or represent something – related-mote list will include an identifier from the ‘presentation’ namespace, to indicate how to interpret the mote’s parameter
- media (media-info): content for associated media – related-mote list will include an identifier from the ‘media’ namespace, to indicate how to interpret the mote’s parameter
- responsibility (responsibility/access role): identifies a responsibility/access set, as per the ‘responsibility’ namespace – related-mote list for each of the instances would include any number of pointers to person and/or role motes
- role (role-name within the business): identifies a business role, as a proxy for one or more individual persons – related-mote list may include pointers to actual ‘person’-identifiers
- person (person-ID): identifies an actual person, for responsibility-mapping purposes
- version (version-ID): identifies an edit-version(or, for security-purposes, an access-version) that applies to one or more motes – related-mote list would include a date-time stamp and user-ID, and probably other parameters as required
The ‘presentation’ namespace applies to the primary presentation of the mote itself, and could include the following identifier-motes:
- mime-type (MIME-type identifier): interpret the mote-parameter in terms of the respective standard MIME-type
- draw (schema-ID): interpret the mote-parameter in terms of a non-MIME schema – for example, some toolset-specific equivalent of the Visio draw-spreadsheet
The ‘media’ namespace applies to secondary information related to the mote, but would otherwise essentially be the same as for the ‘presentation’ namespace – i.e. mime-type and suchlike.
The ‘responsibility’ namespace could include the following identifier-motes:
- mote-owner (role or person): role or person responsible for the mote itself
- mote-creator (person): person who created the mote itself
- mote-editor (person): person who last edited the mote itself
- owner (role): role and, ultimately, person who in RACI terms is responsible for (‘accountable for’) the item referenced by the mote
- actor (role or person): role or person who in RACI terms assists in (usually is a user of) the item referenced by the mote
- consulted (role or person): role or person who in RACI terms needs to be consulted about any usage or changes to the item referenced by the mote
- informed (role or person): role or person who in RACI terms needs to be informed about any changes to the item referenced by the mote
- access (role or person): role or person that may access the referencing mote
- exclude (role or person): role or person that may not access the referencing mote
(Any other suggestions for generic ‘housekeeping’ motes?)
Entity
An entity is a mote that describes a ‘thing of interest’ in modelling.
Structurally, it is just another mote – exactly as for all other motes. Its parameter will usually be a text-name for the mote. However, its related-mote list would usually include references to the following types of motes:
- description: a mote with a text-parameter and a label of ‘description’ – used as the content for a derived glossary
- discussion: a mote with a text-parameter – used as the container for a wiki-type discussion
- parameter: any number of motes that represent additional parameters for this mote
- relation-type: tag-mote that acts as the ‘hook’ for a source-tag or destination-tag mote attached to a relation
- presentation: a set of one or more presentation motes that indicate how the mote should be presented – one of these should probably be marked as the default-presentation (perhaps the first, perhaps indicated by a tag?)
- responsibility: a set of responsibility motes that identify the RACI and access-controls for this mote
- model: a set of tag-motes or other parameter-motes that identify the model(s) or notation(s) in which this mote was first created and subsequently used or changed
- based-on: a reference to another entity-mote that was used as the ‘type’ or template on which this entity was based or from which it was derived
(Any suggestions for other items needed in the ‘entity’ related-mote list?)
Note that an entity is ‘model-agnostic’: it can be used with any model or notation, subject to filtering within the toolset (usually via reference to namespaces and/or attached tag-motes).
To display an entity, a referenced presentation mote is called by the toolset.
To edit or update an entity, new references are added to the mote-list, with ‘superseded’ flags attached to the previous mote-references as required. A reference to a version-identifier mote would usually be added to the mote-list once edits are complete, preceding any updates and ‘superseded’-references so as to support the versioning-method described above.
An ‘entity-type’ is simply an entity pointed to as ‘based-on’ by some other entity-mote: every entity is an ‘instance’ of some other entity (ultimately, of the root-definition of mote), but may also be used as a ‘type’.
Relation
A relation is an entity that is used to denote a link between two other entities.
Structurally, it is just another mote. Ultimately it’s based on the ‘entity’ type of mote, and its related-mote list would be likely to include the same types of motes as for ‘entity’. However, the mote-list would also include:
- source-tag: one or more tag-motes that, when embedded in an entity (or relation, or model, since these are structurally derived from ‘entity’), identify that that entity may be used as the ‘source’-end of the relation
- destination-tag: as for source-tag, but for the ‘destination’-end of the relation
- source: mote-ID of the single mote that is linked as the ‘source’-end of the relation
- destination: mote-ID of the single mote that is linked as the ‘destination’-end of the relation
(Any suggestions for other items needed in the ‘relation’ related-mote list?)
There is no built-in constraint on source-tag or destination-tag: for example, the same tag may be used for both, indicating a non-directional relation.
Since relations link to tags rather than to entity-types, the number of relation-types and required relation-linkage definitions increases much more slowly than in a conventional entity-oriented structure (i.e. increase is almost linear, rather than near-exponential or near-factorial).
Dependent on the notation, other parameters may be needed in the related-mote list to define line-type, arrow-type, and so on.
To model flows and exchanges, it may be useful – again, notation-dependent – to attach an entity to the relation itself, to identify the content and conditions for the flow.
Some types of relations will be needed that can attach to any entity – or relation, or model – such as the ‘thesaurus’-type relations (broader-term, narrower-term, synonym, antonym, conflict etc). Another is the ‘annotation’ pattern, which would consist of a text-entity and attached relation that could be linked to anything else. For these cases, we might design this such that the absence of any source-tag or destination-tag mote (or one end only, for the ‘annotation’ pattern) would indicate that the respective relation can be attached to anything.
Display, edit and ‘based-on’ are the same as for entity-motes.
Model
A model is an entity that acts as a container for entities and relations between those entities.
Structurally, it is just another mote. As for ‘relation’, it’s ultimately based on the ‘entity’ type of mote, and its related-mote list would be likely to contain most of the same types of motes. However, the mote-list would also include:
- model-tag (tag-ID): one or more tag-motes that identify the model, and will be attached to any entity or relation created (or edited?) whilst the model is in use in the toolset
- allowed-tag (tag-ID): any number of tag-motes that can be used as filters to select entities and relations that are allowable for use within the model (also possibly excluded-tag, for items that explicitly may not be used within the model?)
- allowed-relation (relation-ID): one or more relation-types that can be used within the model, which via their embedded tag-lists in turn identifies the entity-types that can be included (possibly use allowed-tag instead for this purpose – i.e. tags attached to relation-types?)
- mapping (mapping-ID): a mote that contains a set of parameters that identify the relative positions of entities and relations in terms of some (usually graphical) modelling-schema
(Any suggestions for other items needed in the ‘model’ related-mote list?)
A model and notation will need validation-rules, modelling-constraints and many other parameters and functions. Although some of these can be embedded as parameters within the related-mote list for the ‘model’-entity, or act as triggers via a toolset API, it’s probable that not everything could be managed via configuration alone. For items that cannot be embedded directly into the ‘mote’-structure, there would need to be a separate ‘plug-in’ for the toolset, referenced by an appropriate tag or other mote within the ‘model’-entity definition.
Note that models will often need their own displayable or non-displayable parameters, such as those used in a description-box placed in one corner of the displayed model.
Display, edit and ‘based-on’ are much the same as for entity- and relation-motes. To display itself, the model ‘calls’ the presentation-functions (or rather, presentation-configuration parameters) within the respective motes. In editing, the model would also update its mapping schema, to keep track of the relative positions of its entities and relations. Every model-instance would be based on another model-instance that is used as its model-type.
Other comments
Because all motes have the same underlying structure, it should be relatively simple to implement this even within SQL, or preferably with a more polymorphic object-type database. The recursive database-calls would imply a significant impact on performance, hence at run-time – especially for a large repository – it would probably be wise to convert these to fully-encapsulated objects, but it actually is not essential other than for performance-reasons.
The simplest file-format would be a JSON- or XML-representation of the full set of motes (or selected subset of motes).
A model-definition file (in other words, a means to add a model-type or notation to a toolset) consists simply of the subset of motes that describe that model-type and its associated relations and entity- and relation-presentations, optionally including one or more tags to identify and denote a namespace.
A taxonomy-type framework such as Zachman or TOGAF/Archimate-style layering can in effect be represented very simply by a set of related tags. Graphic frameworks such as Business Model Canvas or Porter Value-Chain can be represented by a backplane image stored within a ‘presentation’ or ‘media’ mote.
— —
Okay, that’s it for now: over to you for comments, suggestions brickbats, whatever?