EA metamodel – a possible structure
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?
Hi Tom,
“you’ll see later why there’s little point in trying to describe this visually – it just gets too messy”
I still gonna try to visualize some of it because I with my limited programming capabilities/experience (last real program that I made was in Turbo Pascal 🙂 ) I need to have some visual anchors to understand you story.
I do have one question at this point: why does every mote has a “list of (pointers to) other related motes”. I would think that linking motes is the role of the “Relation” mote. I see that the list is there for some sort of lifecycle management but does that mean that this list only point to iterations/evolutions of the same mote?
I’m also thinking to make some kind of simple paper prototype for myself as a learning device. Not only for learning by doing about your ideas but also to see if paper prototyping can be useful for trying out complex ideas. If I manage to create something useful I will show it on my weblog, but don’t hold your breath 🙂
@Peter Bakker – Thanks for the reply, Peter. 🙂
The reason why I didn’t do any diagrams is because at this level it soon becomes an impenetrable mass of cross-connections. I’ve found it quite easy to hold it in my head, but surprisingly difficult to draw; okay, quite easy to draw on a whiteboard where the connections can be shown and erased, but difficult to show on a static diagram. But that’s just me, I guess. 😐
On “list of pointers to related motes”, and the role of the Relation mote: okay, there’s a fairly straightforward level-problem, but I can see how this would be confusing. The simplest way to put it is that motes are atoms, and the bindings that link them together are the normal atomic-level bonds. You can think of the mote plus its list of related-motes as being like a molecule. So each Entity (and Relation, and Model) is a molecule, made up of smaller motes, which are actually sort-of independent of each other in the same way that atoms are sort-of independent of each other. If we then jump up a level, each Entity ‘molecule’ is distinct from every other, and we then use Relation ‘molecules’ to link them together. So at the deeper level, the links between motes are like atomic bonds, and the Relation links between Entity ‘molecules’ are like chemical bonds. Still ultimate the same thing, but at a different level.
By the time we get to a conventional metamodel and model, all we’ll see (or usually see, rather) is Entity and Relation – we don’t see the underlying motes, and we don’t see the underlying ‘atomic forces’ that bind the motes together, all we see are the ‘chemical bonds’ that bind Entity items together via Relations. The toolset does all the ‘atomic’ level manipulation for us – we don’t need to see it. (Unless we want to, of course. But that’s usually something that’s hidden from us in a conventional-layer metamodel.)
Remember what I said earlier, that most of this description is about what happens at the M3/M4 metamodel layer. An Entity and Relation are at the M2/M3 layer, whilst an explicit version of an Entity – such as an Archimate ‘Business Interface’, or a ‘StickyNote’ in Business Model Canvas – would be defined right up at the surface, at the M1 metamodel layer. The point is that we’re doing a rather interesting trick here: in a conventional layered-metamodel such as the relationship between MOF (M3/M4) and UML (M1/M2), there’s a strong separation between the layers; but in this structure they’re all actually the same. In a conventional metamodel-structure, we can’t move entities between metamodels; but here, courtesy of the underlying ‘mote’ structure (and especially the ‘tag’ motes), we can move entities between metamodels. That’s the big change that this approach enables.
Hope that makes somewhat more sense now? 😐
@Tom G
Thanks Tom,
I understand your motives but putting the related motes list on the mote itself feels like breaking the simplicity to me. I still feel it would be more “natural” to put that list on a mote which is specialized in dealing with such a list. But that is just my feeling based on probably not having a clear picture of the whole idea 🙂
The parameter-value is also not quite clear to me. What is its exact purpose, how would you use it in practice?
@Tom G – Peter, I’ve just realised on re-reading that that ‘explanation’ is almost worse than the main text… sorry… 🙁
Start again.
The motes really are like little atoms: each of them only has one parameter, and even that is just raw-data. Each mote has a role, typically defined within a namespace. And each mote also has a list of other motes that it uses – and the main use of those other motes is to help make sense of itself. The other motes are never actually attached as such – it’s just a list of references – but the effect is that some motes kind of accrete other motes, to build up a what is in effect a larger molecule (‘in effect’ because the linkage is by reference rather than by explicit attachment).
So a mote references another mote with a ‘parameter-name’ role that tells it that its parameter has a specific label; that mote in turn references another mote with a ‘language-name’ role that tells the label-mote that the label is in French. Another mote with a ‘parameter-type’ role tells the first mote that its parameter should be interpreted as an integer. Another mote with an ‘owner’ role tells it that its owner is ‘Fred Smith’; and so on.
At the root level, in most cases, each mote is a tiny little thing with only a tiny little function, determined by the role and parameter. But because the related-motes list means that we can sort-of link mote-references together, we can sort-of create something that looks like a larger or even much-larger ‘molecule’, even though in reality it’s just another mote. And some of these larger ‘molecules’ – such as Entity and Relation and Model – start to be large enough that we can see them with the naked-eye (so to speak), at the metametamodel level, where we can start to be more explicit and give distinct names to their instances at the metamodel level. And it’s at those layers that the ‘chemical bonds’ represented by Relation start to make sense.
Another way to explain it: a Relation can ‘connect’ one Entity to another Entity because the respective Entity motes have tags that match up with the permitted-tag list for the Relation. That’s what it looks like at the surface, within a model that’s being developed in the toolset. If you like, that’s the ‘chemical bond’. But as you’ll know, a chemical-bond is actually the outcome of atomic-level forces. So here, down at the ‘atomic’ level – the level of individual motes, what actually happens at one or other end of the relation (the ‘source’ end, let’s say) is as follows:
– When we create the Relation instance, we copy it from another Relation mote (typically defined as part of the namespace for the respective notation) that acts as a template. This original template is referenced in the new Relation via a mote in its related-mote list that has a role of ‘based-on’, and whose parameter points to the mote-ID of the original template.
– One of the motes referenced in the Relation related-mote list has a role of ‘source-tag’ and a parameter-vale of ‘isParent’.
– In much the same way, the Entity inherited from its template a reference to a mote that has a role of ‘tag’ and a parameter-value of ‘isParent’ – which means that in this notation this type of Entity is allowed to be used as the source of a relationship in which it is described as the ‘parent’ of another entity.
– To make the connection (the ‘chemical bond’) between the Entity and the Relation, the toolset confirms that the Entity’s ‘tag’ and the Relation’s ‘source-tag’ match – which means that the connection is permissible. The toolset then creates a new mote, with a role of ‘source’, and with the parameter-value set to the same as the Entity’s mote-ID. Finally, the toolset adds a reference to that new ‘source’-mote in the related-motes list of the Relation.
In other words, most of this stuff about motes happens at a very low level – the kind of activity that happens deep within the toolset. What we see on the surface, as a result of all that activity, is that an Entity is now connected to a Relation. At that surface-level, the fact that those Entity and Relation are actually also motes doesn’t really matter – other than the fact that they are motes means that we can move them between all the different notations. (Or, more usually, just the Entity motes, because Relations tend to to be associated only with a single notation.)
Again, hope this makes a bit more sense now?
@Tom G
Thanks again Tom,
To me it looks a bit similar to neuroplasticity where neurons that fire together wire together http://www.neurosciencemarketing.com/blog/articles/neurons-fire-together.htm but where at the same time everything can adapt itself to new circumstances.
“I have a cunning plan” for a paper prototype. (Blackadder fans will know how cunning plans usually end) So I will wait with the answer to your last question if it makes more sense until I played a bit with this cunning plan 🙂
@Peter Bakker – Peter – will look forward to seeing the end-results of your ‘cunning plan’! 🙂
For your paper-model, remember that for this putative design (which I admit is still little more than a thought-experiment at present), each of the motes is tiny. Each is made up of only four items:
– globally-unique mote-ID
– role-identifier (probably a text-string, that could also include a namespace-ID)
– parameter (raw-data only; may be null)
– list of ‘related-motes’
In the classic metamodel, an Entity or Relation is huge, with probably dozens of parameters and link-identifiers and so on.
In this approach, the core of Entity or Relation is tiny: it’s just a mote. The only thing that’s large is the list of related-motes, that in effect emulate the complicated structure of the classic Entity or Relation, but without actually embedding anything. Instead, everything’s done by pointers (references) to other motes.
So when you make your paper-model, what you’d start with is a whole bunch of almost-identical stickynotes or index-cards or whatever, each with their ID and role and parameter, and that variable-length list of pointers. Use the role-names I’ve suggested in the post above. Draw lines between the ‘related-mote’ list of, say, an Entity, and the smaller motes that define its nominal ‘content’. Motes point to other motes to fill in all the missing detail, and so on.
It looks a bit messy at first, but the point is that it supports a very high degree of versatility. There’s almost no predefined structure, which means that almost anything is possible. A quite small set of roles – not much more than I’ve summarised above – would actually cover almost all of the needs for most existing metamodels.
It’s decidedly difficult to describe in writing (as you’ll have seen above… 🙁 ), but actually quite easy with a bunch of stickynotes and lines drawn on (and erased from) a whiteboard.
Will be very interested to see what you make of it, anyway.
And thanks, of course. 🙂
@Tom G
My cunning plan is simple:
I pretend that I want to start my own Tubemapping Promotion Enterprise 🙂
Therefore I will sketch three models:
1. a mindmap for the brainstorm part
2. a business model canvas for the business model derived/extrapolated from the mindmap
3. a tubemap to visualize the routes from here (the idea) to there (a running business)
I keep them as simple as possible of course.
Next step is to see if I can metamodel/model all three models together with motes following my perception of your guidelines above. This can take some time but I promise that I will document how this plan will unfold…
@Peter Bakker – Peter – One point that came up in a previous comment somewhere (someone else’s, not yours, I think):
They said that this was like “going back to assembly language”. Which it is.
They didn’t mean it politely – they evidently thought this was a fatal design flaw – but they’d actually missed the point: down at the root, everything is assembly-language. (Or machine-code, to be pedantic, but that’s described here too, of course.)
For this layer, it is the equivalent of assembly-language. It has to be. If we don’t get the thinking right at this level, we’re not going to get the interoperability and versatility that we need at the surface-level. But the M3/M4 layer really is the equivalent of assembly-language; M2/M3 is the compiler, M1/M2 (the surface-ish metamodel) is the high-level language, and M0/M1 (the modelling that we actually work with) is the application.
So when you’re developing your tubemapping ‘app’, consider all those four inter-layers at once:
– at the surface layer (M0/M1) you need a notation for each of the three distinct models (mind-map, BMCanvas, tubemap)
– at the metamodel (M1/M2) you need a metamodel that would describe the components and interactions (entities and relations, plus the rules and parameters that define them) that make up each of those notations
– at the metametamodel layer (M2/M3) you need to identify how to move entities (and, in a few cases, relations) between each of the metamodels, without losing or damaging anything from what’s already been done at the individual (meta)model layers
– at the ‘atomic’ layer (M3/M4, the focus of this post) you need to identify the ‘assembly-language’ fine-detail of exactly what happens at each stage and with each change to each of the underlying motes, so as to verify that everything actually works and nothing is missed.
Note that for most work we shouldn’t ever need to look at the ‘atomic’ layer. We’re only doing it now because we’re roadtesting the ideas for this ‘mote’ concept, deliberately running everything backwards from the surface layer to check out the interoperability and the rest.
(In other words, yes, we’re doing a deep-dive into the ‘assembly-language’ layer, and it isn’t what we’d normally do. But if you’re a CompSci student, you’d usually expect to have to build a compiler at some stage, to prove that you know what’s going on ‘under the hood’. You’d typically start from hand-sketches that become UML diagrams that become language-specifications for the compiler that works with assembly-language. Most everyday users aren’t CompSci students mucking around with compilers – but someone has to do it if we’re to get usable surface-layer applications. Same here, really. 🙂 )
By the way, there is one context in which we do work directly at the mote-level. It’s when we ask those two questions: “tell me about yourself?” and “tell me what you’re associated with, and why?”. The information to answer those questions is carried directly within the mote, in its embedded role and parameter and via its related-mote list. The ‘yourself’-mote in this case would only be an Entity, a Relation or a Model.
@Tom G
I still have problems understanding the parameter-bit but that is because we are talking different languages I guess (you are explaining things by comparing it to computer languages but I think more in modeling concepts from systems thinking and petri nets or from the working of the nervous system).
But I’m pretty sure I understand your intentions fully and the needed dynamics good enough to build a usable paper prototype. And then we can hopefully discuss things more “directly” (=related to something tangible).
Anyway it will be a fun exercise 🙂
BTW zAgile responded by tweet that they are willing to help, they find it a very interesting idea.
@Peter Bakker – Re the parameter, if the mote didn’t carry a parameter, it would literally have no value. 🙂
(Not in all cases, actually – in a few examples, the real value is carried just by the role, and in several cases the value is mainly in the related-motes list. But you’ll see the point, I think?)
In a ‘language-ID’ mote, the parameter-value is the language-name.
In a ‘description’ mote, the parameter-value is a chunk of text used somewhere as a description.
In a ‘media’ mote, the parameter-value is the raw MIME data of the media. (Another related-mote will say what type of media this is.)
Some of the question “Tell me about yourself” is carried via the related-mote list. But ultimately that question is answered by the set of parameter-values carried by the mote itself and its related-motes.
Remember again that this is very low-level – right down at the ‘atomic’ layer. It’s a bit tricky to get the head round it at first, because it’s at such a low level: but ultimately, just as in the real-world, everything builds upward from these tiny building-blocks. And also, just as in the real-world, we usually work at a much coarser level of granularity – in other words, metamodel and models. For this specific purpose, though, it’s very useful indeed to have some understanding of what happens right down at the ‘atomic’ level. Hence these way-too-technical posts and notes! 🙂
Tom,
The coin has finally dropped 🙂 (translation of the Dutch expression: ‘het muntje is eindelijk gevallen’ which we use when arrive at the eureka moment at last…
Thanks for your patience…
@Peter Bakker – Peter – thank you for your tolerance and persistence! 🙂
Have you considered using NOSQL databases like MongoDB or Neo4j?
Hi Eric – Yes, you’re right, of course. Have considered them, yes, but I know nothing about them other than the name. As I said above, all I know is SQL, hence why I used it in the example. I can guess that NoSQL would be a better fit, but I’d have to admit that I’m not competent to make that kind of detail-layer decision. 😐
Like I’ve said several times in various posts, I’m well aware I’m not the right person to do the implementation on this: these days I could perhaps do a (very) clunky prototype in PHP/MySQL, but the requirement would be for something much more up-to-date. Probably the most useful thing I can do is present enough of a sketch that people can tell me it’s wrong! 🙂