What's in a Word? MetaDATA vis-à-vis MetaMODEL

To distinguish FactMiners agenda from that of others, let's clearly distinguish these two these terms; metadata and metamodel. Wikipedia interestingly, and I think appropriately, redirects the term 'metamodel' to the page/term 'Metamodeling' which subtly suggests the active and transitional nature of metamodeling as a preparatory step in service to a further goal. That is, we metamodel as a way to gain leverage in subsequent modeling and development activity.

I have a hyper-sensitivity to the metadata/metamodel distinction having spent over twenty-five years as a hardcore Smalltalk software designer/developer. (True Smalltalkers are both, never one or the other.) As a model-oriented Smalltalker, I have learned and experienced the Mind-meld Power of the rigorous application of metamodeling – that is, the power of sharing a commitment to a model that guides and constrains the design of new models. In my 90's era case, these new models were Smalltalk software architectures strictly derived from metamodels. And that's the simplest explanation of what a metamodel is, "a model about models" that we use to build other models.


Here, for example (click to enlarge), is a top-level metamodel roughly derived from my work in the mid-90's on "role-actor executable business models." This model isn't about a specific role-actor model; it captures a shared understanding about how to design and build such agent-based role/actor systems.

Interestingly and relevant to the current discussion, a derivative of this metamodel will be found in the META:Process partition of the FactMiners embedded metamodel subgraph to handle plug-and-play composition of workflows for what Mia refers to in the Participatory History Commons diagram (referenced in Part 1 of this series, and linked here directly) as "typical crowdsourcing microtasks."

Whenever we derive the design of a new model for a specific system from a metamodel like this one, we are guaranteed to get a level of interoperability and tool-sharing "auto-magically" despite the fact that no derived model will necessarily be anything like any other. This is a significant and important feature; near-infinite variety in the generation of instances from the metamodel, yet guaranteed similarities that are traceable to the derivation from the metamodel. And it is this powerful feature that will give the FactMiners game platform its unique power and flexibility.

If I were to characterize my (layperson's) understanding of metadata as routinely referenced by those in the LAM community, it would be that LAM metadata is all about the "model elements" in a metamodel. But metadata in no way supplies the rest of what a metamodel does, which is, to provide a rigorous set of rules and recommendations about how these model elements may be put together.


From what I know so far about Metadatagam.es and Tiltfactor's Metadatagames.org – and it is important to note that these projects are already doing amazing games where FactMiners is just in our formative/design stage – current "LAM metadata" social game designs focus on some variation of 'community tagging' or folksonomy. Depending on the game design and host collections' visitor engagement goals, such tagging gameplay may include solicitation of user-contributed content, such as personal reflections and artifact-inspired storytelling. I've written about this shared interest in "FactMiners: More or Less Folksonomy?" which was my first "open shout-out" to the museum informatics community.

FactMiners is completely on the same page with others as far as our shared interest in contributing to the growing '#LODLAM cloud' (Linked Open Data for Libraries, Archives, and Museums). However, our FactMiners Fact Cloud design and associated platform architecture are unique innovations specific to our project.

FactMiners is building our #LODLAM social gaming platform based on an embedded metamodel subgraph design pattern to create "self-descriptive" graph databases that we call FactMiners Fact Clouds. Our graph database of choice is the Neo4j graph database, but the design pattern is not vendor-specifc. I believe that the combination of this software design pattern plus the uniquely powerful and solution-design-appropriate capabilities of today's property graph database technology will allow FactMiners to move into qualitatively new and different LAM social gaming territory.

In the next part of this series, "Piercing the Veil and Moving the Bar," we'll look at two specific areas where the innovative FactMiners platform can make substantive contributions helping to shape the infrastructure supporting the Participatory History Commons.