EA metamodel: two questions

Following on from the previous work on EA metamodels, I keep coming back to those two questions from Graeme Burnett: for everything in a context, we need to be able to ask “tell me about yourself?” and “tell me what you’re associated with?”.

That focus does help to keep things simple here…

(Please remember that this is still very much a thought-experiment, but I do believe we’re getting closer now to something that really is implementable.)

To recap, we’d previously ended up with the concept of a ‘mote’, a kind of very-low-level entity that consists merely of an ID, something a bit like a role or opcode, a single optional parameter, and an optional list of related-motes. Conceptually, an individual mote looks a bit like a bacillus:

On its own, it’s tiny – really tiny, and almost meaningless. But that related-mote list turns out to be incredibly powerful – much more powerful than I thought it would be, in fact. It’s also looks like it’d be surprisingly easy to implement.

Even more interesting, it actually removes the distinction between metamodel-layers within implementations, because with this mote-structure they’re all the same: everything is a mote. Whether it’s a model, a metamodel, a metametamodel or metametametamodel, everything is either a single mote or a collection of motes, all with the exact same structure.

Everything’s a story, too: “tell me about yourself” returns a mote’s own story, whilst “tell me what you’re associated with” returns the story that this mote shares with others. The story may be very simple – as it is with a tag-mote – or very broad and complex – as it would be with a mote that represents that represents an entire model – but it’s still just a story, retrieved from each mote in the same way.

More interesting still, the mote-structure also in effect defines a file-structure that can be used both to exchange models between toolsets, and exchange model-types and notations between toolsets. And in essence, subject to a certain amount of intelligence in the toolset, all of that exchange can be done with text-files in a standard structure-format such as JSON or XML. Which gives us a fully non-proprietary file-format for just about everything we would need in an EA toolset.

(Toolsets would differentiate themselves by their user-interface and user-features: what we’re describing here is just a data-structure and file-format, and a conceptual API to drive everything within that structure – not a full features-specification for toolsets!)

And what’s perhaps most interesting of all is that all of that arises from those two questions: “tell me about yourself”, and “tell me what you’re associated with”.

Interested?

A database-structure for motes

To show that this is implementable, start with a database-structure in which to store motes. (The only data-structures that I know are flat-files – which probably won’t work well for this – and SQL relational-databases – which probably will work, if not very efficiently. I’ll use SQL-type structures, but I’ll leave it to others to translate into something more effective with current data-technologies.)

It seems that we’d need just two SQL tables for the whole repository: one for the body-section of motes (MoteBody), and the other for the related-mote lists (MoteReln).

These would need only a few minor tweaks and additions to the provisional mote-structure described earlier in the post ‘EA metamodel – a possible structure‘.

Suggested structure for the MoteBody table:

• MoteID – globally-unique ID (e.g. UUID?)
• MoteNamespace – namespace for the role/opcode (shortish text, e.g. CHAR(64))
• MoteRole – ‘role’ or opcode for the mote (shortish text, e.g. CHAR(64))
• MoteParam – parameter-value for this mote (could be anything, but type can be identified by an attached mote – i.e. could be BLOB or LONGTEXT or a self-identifying polymorphic, dependent on database type and capability)
• MoteIsReadOnly – says whether or not the parameter-value can be changed (boolean)

That’s it: the motes themselves really are tiny. (I added ‘MoteIsReadOnly’ to deal with the likelihood that some parameter-values of some mote-types would need to change, whilst many others should not: it would typically be inherited from the master-template for that mote-type, anyway.)

Namespaces possibly aren’t essential, because it could be part of the MoteRole anyway. But I can see that a lot of people would prefer to keep them separate, so as to link specific roles (opcodes) with specific model-types or notations. (We might also add a category-identifier for the same reason, particularly for parameters and for relation-types.)

What I’ve described as ‘roles’ would actually be a bit more like opcodes (as in assembler-language), or perhaps closer to root-level operators in a ‘word’-based language such as FORTH. In effect, roles would act as a kind of API (or API-interface) for the overall meta-language implied by this structure. There are quite a few examples summarised in the ‘EA metamodel – a possible structure‘ post.

Suggested structure for the MoteReln table:

• MoteRelnID – locally-unique ID (e.g. AutoNum – only needs to be locally-unique because it won’t appear in any file-transfer)
• MoteRelnParent – unique-ID of the ‘parent’-mote, the mote for which this forms part of its related-mote list (type as per MoteBody table)
• MoteRelnDest – unique-ID of the ‘attached’-mote, the mote nominally referenced in the ‘parent’s related-mote list (type as per MoteBody table)
• MoteRelnSubst – either null etc (i.e. no substitute), or unique-ID of a ‘substitute’-mote, replacing the previously-attached mote in the related-mote list (type as per MoteBody table)

Again, that’s it: it’s very simple. The table’s search-order is significant, by the way: the related-mote list develops in time-order, with new attachments appended to the end of the list. Hence we probably don’t index this by MoteRelnID – though we might well do so by MoteRelParent.

The ‘substitute’ is a suggested part of a mechanism to handle versioning. To go back to a previous version, we simply stop the search or scan when we hit an appropriate version-identifier mote, reading forward from the start of the list. The ‘substitute’ tells the scan that this entry has been replaced by the substitute. [Hmm… I may have this somewhat back-to-front? – it needs further thinking, anyway. But the overall principle of versioning via identified ‘substitutes’ does seem sound, and again does keep everything very simple.]

For indexes, there’s the usual trade-off between speed, efficiency and index-size. In principle we might need to index everything. In practice, it’d probably be essential to index the MoteIDs, but probably not much else.

“Tell me about yourself”

To answer the question “Tell me about yourself?” for a single mote, we do a straightforward tree-walk, starting with this mote, and then, in linear order, every member of its related-mote list, following the trees for their related-mote lists, and so on.

(Note that that would return everything related to this mote. In practice we would probably want to apply some kind of filter on what we return from the tree-walk, so as to constrain the resultant ‘story’ to whatever is meaningful in the context.)

The result would be a collection or table, very similar to the structure of MoteBody, containing only the mote-bodies (because we’ve unpacked all of the related-mote lists into this collection). We would probably need one extra field, to identify the ‘parent’ for each mote-body in the list – in other words, the mote in whose related-mote list this was referenced; the ‘parent’ for the mote with which we started is effectively itself. Note that we may well end up here with multiple copies of the same nominal mote, because they were referenced in different ‘parent’-motes’ related-mote lists.

The motes in this collection are not ‘triples’ as such – in other words entities made up of ‘subject / verb / object’ – but in practice they usually do end up being interpreted in that form. The subject is the ‘parent’-mote; the verb is implied by, or is, the role; and the object is the mote’s parameter.

If we take the simplest example, a tag-mote, which should have an empty related-mote list: its ‘story’ would be “I am a tag from the whatever namespace labelled something“.

A parameter-mote, with a related-mote list of parameter-type, and label in a specific language, might be: “I am a parameter whose integer value is 42, and my label in en-GB is ‘What do you get if you multiply six by nine?'”. [Yup, it’s correct, in base-13: an inside-joke for fans of Hitchhiker’s Guide To The Galaxy… 🙂 ] The label’s language-identifier is in the related-mote list for the parameter-label – it didn’t need to be referenced in the parameter-mote itself, because we could find find it via the tree-walk.

It’ll get tedious if I give any more examples, but you can see how the principle works here. Because every mote ultimately has the same structure, we can do the same kind of tree-walk for any kind of mote – including much larger motes such as an entity, a relation or a model, or even the entire contents of the repository.

I know I haven’t described the exact details of where all the verbs and sentence-structures come from, but I hope it’s evident that it should be fairly straightforward to implement. For an already-existing example of the same principle being applied in real-time ‘storytelling’ interpretation of models, see the MyCreativity add-on to the Southbeach toolset.

Everything could be described in text form in this way. For a “tell me about yourself” in a graphic sense – such as in a visual model – the details on how the mote should display itself (if at all) would be in presentation-motes referenced in the mote’s related-mote list. These would usually be derived from the mote used as the base-template for this mote. This would apply primarily to entity-motes, relation-motes, model-motes and other items that would usually be presented in graphic form.

“Tell me what you’re associated with”

Deriving the same kind of story for “tell me what you’re associated with” for each mote will vary somewhat, because the meaning of ‘associated-with’ is somewhat different for each mote-type.

Again, the simplest case is a tag-mote, for which ‘associated-with’ in effect means ‘motes in which I’m referenced’. For this, all we need do is scan the MoteReln table for self-references as ‘MoteRelnDest’, and look up the details of the ‘parent’ (the referencing mote, as identified in the matching ‘MoteRelnParent’ field) in the MoteBody table – a very simple query in SQL or the respective equivalent.

A relation-mote is associated with (usually) two entity-motes (or other motes), but is also associated with a model, because the relation would itself have been defined within that model. These associations should actually be part of the “tell me about yourself” question, because the motes that denote these links should all be referenced in the relation-mote’s related-mote list.

The “tell me what you’re associated with” story is a bit more complicated for entity-motes, because an entity‘s relationships are referenced in the relation‘s related-mote list – not that of the entity-mote. In effect, we have to run the search somewhat backward: scan the MoteReln table for MoteParent of type ‘relation‘, and MoteDest of type ‘source‘ or ‘destination‘, where the parameter for that source or destination (i.e. the referenced MoteID) is that of the entity with which we started. The relation in effect gives us the verb for a triple; the fact of being either source or destination indicates whether this entity is the subject or object of the triple; and, in turn, the item that’s at the other end of the relationship. The relation would also indicate – via the parent model-mote referenced in its related-mote list – the model in which the relationship was defined.

There’s obviously a lot more detail that needs to be worked through to implement all of this for real, but the principle does seem straightforward enough.

A note on access-control

All of the above in effect assumes that everyone should be able to see and use everything. That ain’t how it works in the real world… 😐

So to cope with that reality, I’ve assumed that, other than for fairly harmless root-level mote-types such as tags and language-identifiers, almost every mote will need some kind of access-control. The mechanism I would suggest for this would be yet another mote-type, such as described for the responsibility mote or namespace in the ‘Some key mote-types’ section of the ‘EA metamodel – a possible structure‘ post.

The content of this responsibility-mote would act as a second-order filter on the results returned from the “tell me about yourself” and “tell me what you’re associated with” scans. (This assumes that the mote in question can be viewed at all under the respective access-rights, of course.) The filter in effect enacts simple information-hiding: if it can’t be seen under these access-rights, it doesn’t get returned by the scan. This is one of the reasons why relation-links are not cross-referenced in the related-mote list for entity-motes and the like. This also means that we don’t return a full count of all possible relation-links: we only return a count (or the like) of relation-links that can be shown.

Because the access-control mechanism uses the same extensible structure as for every other type of mote, it can be adapted to just about any conceivable security/access-control need. It’s also fully granular, right down to the level of individual motes.

— —

Best I stop there for now? I’ll write another post soon on how I think the mote-‘role’ or opcode mechanism would work, and how it could drive or link into a toolset-API, but that can wait until later.

Anyway, comments, as usual, if you would?

[A special thank-you to Anthony Draffin, who chased me to get back to writing more on this!]