The Boston Object-Role Modeling Metamodel — Pt 1 — Concepts

Framework for a Knowledge Index

Topmost level of the Boston Object-Role Modeling Metamodel. Image by author.

Recent discussions with a colleague of mine have prompted a long overdue task…that of documenting the Boston Object-Role Modeling Metamodel.

Our discussions revolved around what my colleague found to be called a Knowledge Index, effectively a set of known and all possible indexes of knowledge, as Knowledge Graphs/Models.

To have a Knowledge Index, one must start with core principals.

How is knowledge structured? What is the least-cost-based-method of storing knowledge? If knowledge were constructed of atoms, what would those atoms and molecules look like?

This seems to be the best starting block for understanding and defining how knowledge graphs are constructed.

Object-Role Modeling (ORM), I argue, is the best methodology for capturing the essence of a knowledge graph, as at its core Object-Role Modeling is based on first-order logic, arguably limited to finite-model theory, and where first-order logic has been studied for thousands of years in one form or another.

The atom — A Concept

At the topmost level of the Boston metamodel is one very simple table, MetaModelConcept, which represents a concept.

As an Entity-Relationship Diagram Entity, MetaModelConcept looks like this:

The MetaModelConcept in the Boston metamodel. Image by author.

That is it. One very simple table with one column, Symbol.

As an ORM diagram, it looks like this:

The MetaModelConcept in the Boston metamodel. Image by author.

So, what is a Concept, and what is a Symbol?

As we will see, a Concept is not, and cannot be captured in one table, in the same way that we don’t know or understand where the Concept for a ‘Mission’ is stored within the brain, or within a Large Language Model of Artificial Intelligence fame and as has reopened the research, debate and discussion around how knowledge is stored and accessed.

But we can represent the Concept of a Mission by its Symbol, ‘Mission’.

If for one scneoed you dbuot taht ‘Mission’ is a smboyl, palese cdsndior tihs sntenece as you raed it and utnredsnad it and yuur biran palys its gmae, not a tcirk, but a gmae of dbsnemilisg this stnecnce itno wrods taht in yuor barin repersnet a concept, and for which you understand the concepts, because they are local to you and your brain. You know intuitively that ‘Mission’ is a symbol because your brain resolves it as one.

Your greater brain resolves and understands that there are more than one type of Mission:

Mission: A project to put a space satellite into orbit;

Mission: Official representation of a country abroad to maintain international relations;

Mission: Strategic operation undertaken by armed forces to achieve specific objectives;

Mission: Effort to provide aid and support to people in need;

Mission: Endeavor to spread faith and provide spiritual guidance to others;

Mission: Corporate initiative to achieve specific goals and improve company performance;

Mission: Research expedition to gather data and make new discoveries;

Mission: Individual’s self-defined purpose or goal in life to pursue;

Mission: Institutional commitment to provide knowledge and foster intellectual growth;

Mission: Initiative to preserve, promote, and share aspects of cultural heritage.

…so there are many models that incorporate the Concept of a ‘Mission’ using the Symbol, ‘Mission’.

So, at the topmost level of the Boston Object-Role Modeling metamodel is the relationship between a Concept and the Model that includes that Concept.

The Model Dictionary in the Boston Object-Role Modeling metamodel. Image by author.

We call the relationship between Models and the Concepts within that Model the Model Dictionary.

As an Entity-Relationship Diagram we have:

The Model Dictionary in the Boston Object-Role Modeling metamodel. Image by author.

So, whether the Concept of a ‘Mission’ manifests as a Value Type, Entity Type, Fact Type or even the name of a Role Constraint in our Model, is a function of it’s relationship to a Symbol and the Model it belongs to.

I.e. Value Types, Entity Types, Fact Types and Role Constraints are all subtypes of the Model Dictionary that they effectively belong to:

Central Model Dictionary in the Boston conceptual modelling software. Image by author.

Which is all to say…your representation of a ‘Mission’ outside of your mind, and into a Knowledge Index/Knowledge-Graph must at least reflect the Symbol, ‘Mission’, and the Model it belongs to. Because different Models (of the world) may use that same Symbol differently.

We now have our core atoms for a Knowledge Index and a Knowledge Graph. From here, we can flesh out the remainder of our Knowledge Graph.

In the Boston Object-Role Modeling metamodel, this is done with just 22 core metamodel object types/table/entities:

Core metamodel tables/entites in the Boston Object-Role Modeling metamodel. Image by author.

In future articles I will describe how each of these concepts map out how knowledge is stored for the four main building blocks of an Object-Role Modeling based metamodel:

1. Value Types;
2. Entity Types;
3. Fact Types (and as they are objectified);
4. Role Constraints.

With those four concepts we have the basis for minimal Object-Role Models and knowledge representation conforming to a first-order logic. When we throw Model Notes and Facts into the equation we start to build out an expressive Knowledge Graph for our Models, their Concepts and Symbols.

Thank you for reading. As time permits, I will extend this discussion on the core Boston Object-Role Modeling metamodel, Knowledge Engineering, my newfound knowledge of a Knowledge Index (thank you to my colleague), and Conceptual Modelling in general.

====================End====================