Fundamentals of Modeling in Ontological Work
Published on: April 24, 2025
Continuing my study of systems engineering through SSM courses, I have finally gotten a bit closer to modeling and ontological work.
It seems that a model is something very complex, perhaps even overwhelmingly complex. But this is just my subjective feeling, which crumbles at the first questions – what do I know about models and modeling? And why do I think I know this?
I know nothing, let’s figure it out!
Today we will cover everything briefly, that is – basically. More details and dives into Systems Engineering ahead, this is a long run, stay tuned!
What is a model?
Previously, I wrote about representations in the context of discussing composure, attentiveness, and grounding in reality.
Is a representation a model? Yes, it is. The fact that our representations can be far removed from the physical, real world does not deprive them of the properties of models.
For one simple reason – any of our representations is a certain “particle” of our thinking. And thinking itself, in principle, is modeling.
This is precisely why we say it’s very important to check our representations for freshness (are we not too far behind reality?) and for sanity in general – because what models of reality we build in our heads depends on them.
We will understand a model as something that helps to reason about something else (the modeled entity).
But the models that interest us are far from being just the results of thinking based on ungrounded subjective representations.
Models can be tangible-material – literally a model of, for example, an airplane or a car; or intangible-informational – diagrams, tables, programs, and other textual descriptions.
Why do we need models?
We need models to ground ourselves well. By being well-grounded, we can effectively transfer information between people and/or AI agents.
Thanks to a good model, we can reason more thoroughly, more concretely. If you look a little closer, our thinking is permeated with modeling, otherwise how could we even minimally (even if sometimes not very effectively) plan our daily activities?
It would be more correct to even say – human thinking is modeling.
From this naturally follows a very simple heuristic – to approach mastering the modeling of complex systems, one must first understand one’s own thinking — “observe” how this modeling happens in our mind when we plan something, study, or work on projects.
Modeling Languages and Their Role
One shouldn’t think that modeling necessarily requires using complex formal languages, like those from mathematical disciplines and similar fields. Although such languages are convenient for modeling (deriving) theorems, one must first learn to model using natural language.
Such modeling can go very far because natural language covers a much larger layer of our worldview than any special language.
Ontology and Models
If we try to express the main goal, we can say that it is the construction of an ontology for the system we are modeling.
In other words, it turns out that modeling is part of ontological work.
Here, we will understand ontology as a system of representations about the physical world.
It seems to me it would be correct to say even this – a good model of a complex system should form and reflect an ontology, and not just any ontology, but one within which different agents involved in working within/on this system can communicate productively with each other and work effectively.
Reality and Modeling
The Best Model of Reality
“…the best material model for a cat is another, or preferably the same cat…” Arturo Rosenblueth and Norbert Wiener, “The role of models in science”
At first glance, the phrase might seem paradoxical, but in reality, it reflects very well the idea I tried to express earlier – a good model should follow reality as quickly and closely as possible.
Here, a material model of a cat is also considered. We can materially draw a cat very beautifully and in detail, even anatomically schematically in cross-section. Or we can make a three-dimensional model “cat” from some materials, which overall gives an even more detailed representation of the animal’s insides.
But another living cat is an even better model of cat N, closer to reality, simply because it is alive. In its “system,” another cat as a model carries much more information about cats; it not only shows how a cat looks, but also how it moves, meows, and carries out other life activities.
And still, if we take “this other cat” as a model for our cat N, then cat N is an even better model of itself because it is maximally close, “grounded” in itself.
Objects and Roles in Modeling
Perception and Object Identification
The neural network in a newborn baby’s head can’t do anything; it needs a long time to learn to distinguish parents’ faces from light patches, individual sounds of their voices from the general noise, then somehow form a speech center, and undergo many other metamorphoses over many years.
What the child initially perceives is the background. But as they grow up, the background doesn’t disappear. In fact, “by default,” we continue to constantly experience this background with our senses.
We have many representations, “knowledge” about objects, but we don’t consciously think about all objects all the time; we cannot keep everything in focus at once.
But we can identify individual objects and hold them in our attention. This ability to extract is key for directed modeling/thinking.
Context and Roles in Object Perception
It’s also important how our object extraction works depending on the context. If we are in a context where we take on the role of a builder, we will primarily be interested in objects like tools (each needed for specific work) and building materials.
The weather will interest us only as something that hinders or doesn’t hinder our work, and everything else… for example — how much the noise from our work disturbs the people around us, will likely not concern us much, as long as we work within legally permitted times and decibel levels.
We also won’t care about the color and style of the clothes we wear at work – as long as we don’t mind getting them dirty/ruined.
But then the same builder might suddenly find himself in another role, for example, a boyfriend preparing for a date, and then clothes, weather, and the opinions of surrounding people start to stand out as “relevant” objects.
The Significance of Roles for Modeling
The importance of a role must be understood in this specific way – the objects necessary for performing a particular task depend on the role.
Well-read effective managers, when discussing roles, might immediately fall into notions of boundaries typical of bad models, where different roles sit in their ivory towers and communicate with each other through an overloaded, bureaucratic, and extremely inefficient apparatus.
A dreadful misconception. Don’t forget that we are talking about everything in the context of State-of-the-Art (SoTA) Systems Engineering, where our main goal is to achieve maximum efficiency and productivity.
And today, in this material, I am writing about ontology, about “developing a language” for communication between roles. So what do hopelessly outdated notions have to do with this? Nothing at all.
Without defining roles, it’s impossible to determine the background and worldview of that role. Without which, in turn, it’s impossible to correctly identify the objects and functions needed for the work of that role.
Another common misconception is that clear boundaries are bad; one needs to be agile, diffuse, to work effectively.
Digression about Agile
Firstly, agile is, IMHO, a vague, heuristic set of guidelines for organizing work methods; secondly, look at the manifesto:
**Individuals and interactions** over processes and tools
**Working software** over comprehensive documentation
**Customer collaboration** over contract negotiation
**Responding to change** over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
As I said – although reasonable, it’s pure heuristics, which may or may not be useful. A whole zoo of work methods has grown and continues to grow around agile, and this is probably a normal evolutionary process.
The only thing I don’t see is any mention that “clear boundaries” are bad.
“Individuals and interactions over processes and tools?” – excellent, but what individuals, interactions, processes, and tools are we actually talking about?
“Working software over comprehensive documentation?” – it’s hard to argue here, but it’s also unclear what documentation we’re talking about. In any case, documentation shouldn’t be “comprehensive” just in terms of volume, but should be: 1) up-to-date, 2) effective.
“Customer collaboration over contract negotiation” – well, if we consider that “the value of the items on the right is not denied,” then it’s generally okay, but there are also questions about collaboration.
“Responding to change over following a plan” – perhaps this is the line that the conservative mind clings to and deceives itself with? We are all so “diffuse” and ready for change, but then “based on my experience and 45 hopelessly outdated books” – clear role boundaries are bad. Do you sense it?
Agile doesn’t teach systems engineering, Agile doesn’t teach software engineering, Agile doesn’t teach anything specific – it’s not a practical guide, but an attempt by a group of respected and experienced scientists to express the most important things based on their collective subjective experience. Is there value in the Agile Manifesto? Of course, there is! Is the Agile Manifesto alone enough to build an effective and rational process? It’s not enough.
Looking at the Agile Manifesto through the lens of systems engineering, one could boldly update it slightly like this:
- Roles and ontologies are more important than processes and tools because without them, you cannot choose the right tools or build effective processes.
- Readiness for change and evolutionary change itself – are invariants accompanying any activity of a system/organization.
Everything else is not interesting right now. Behind these lines lies a huge layer of ontological and methodological work that needs to be done at the beginning of the work/transformation of each system, before things can get moving.
Clear roles mean responsibility and work that will have to be done. Readiness to constantly change means readiness to kill/sell/give away/throw out your old beliefs as soon as they are not confirmed by metrics.
Systems engineering is not about heuristics and not for the weak.
Roles and Functions of Objects
In everyday situations like the ones I mentioned earlier (builder / boyfriend), being aware of your role is not very interesting and not very useful.
But in any reasonably complex, project-related, or work situations, realizing your role turns out to be dramatically important.
For example, if we find it very difficult to reach an agreement with someone at work, it might be enough to realize our own role and/or the role of the interlocutor to make agreement easier (or even possible).
The main thing is to find the answer to this question – who is who.
Awareness of the role sufficiently specifies the context, the “worldview” within which this “role” operates, which naturally helps in choosing the necessary objects and words.
Necessary objects are those that possess the required function to be useful in the course of performing our work (according to our role).
For example, if we are still in the “builder” role and our task is to break up a pile of blocks to fill the foundation, it would be good to have a hammer drill for this job. But suddenly it turns out there is no hammer drill, and the foreman can’t provide one for another 3 days, but the work needs to be done. We’ll have to use what’s available – a pickaxe.
It turns out that to perform the work, we were looking for an object with the function of “breaking”.
Here it’s also important to note that our role is, in fact, also a function.
The concept of “role” is more correct and convenient to apply to autonomous agents – people, robots, AI systems – than just “function”.
Reflective Questions for Object Identification
So, in order to effectively identify roles and objects in our work, we need to ask ourselves similar reflective questions:
- What role am I currently in? (The basic question in the role-based approach)
- What are the functions of my role? What work methods does my role involve? (What should I be doing?)
- What context am I in and will I be working in? (Need to define the boundaries of the whole world and our ‘working world’, understand the background against which we will identify objects)
- What objects with what functions will be useful for me to perform my work? (e.g., breaking, scooping, writing, saving, etc.)
Shared Ontologies and Collective Work
Ontology as a Common Language
An ontology must be usable by other agents, not just ourselves. This means that good ontologies must be shareable.
Repetition is the mother of learning – an ontology is not just a description of objects and functions; it is the language spoken by agents working in the same domain (or perhaps even in slightly adjacent ones!)
And the domain, in turn, is the set of objects understood by a large number of agents who share the roles operating within that domain.
Multiplicity of Agent Roles
To someone unfamiliar with SoTA systems engineering, it might easily seem that if we define roles in a company, it automatically means 1 role == 1 agent, and nothing else.
We call Fyodor an Architect, and so this Fyodor sits somewhere in the backwaters of Slack, performing his role, handing down regulations, decisions, and procedures that we, like indentured servants, must execute.
This is completely untrue.
Role and Agents can very well be a many-to-many relationship, not necessarily one-to-one. Each agent in an organization can act in the same context (background) in different roles, and often – simultaneously!
Yes, this places certain demands on the skill of executing the methods of each role and even more so on the performer’s composure: one must understand which role they are in at every moment.
The whole point is that while performing each role, the agent must focus their attention on different objects with different functions necessary for the work, and possibly even use different mental models and work methods for the duration of that performance. I dread to think how this could be organized where there are no clear role definitions – it can’t.
It’s also possible that the same objects interest different roles, either entirely or just specific characteristics of the objects.
Moreover, they might all call the same objects by different names or, conversely, use the same words but understand/imply different characteristics.
And this applies to all areas. You at your job and your colleagues likewise have different worldviews (your brains are not yet connected by wires), which is why endless difficulties arise when trying to agree on “obvious” objects and how to work with them.
“That backend developer is an idiot! I’m so tired of explaining the same thing to him! 😡”
Besides communication problems, in collective activity, your work actions can also affect objects in your colleagues’ worlds, and vice versa. This happens constantly and inevitably.
The work aimed at developing one convenient language for all roles and reaching agreements with all agents within their roles to increase the rationality and productivity of collective work – this is ontological work.
Something Like an Epilogue
Today, we remember:
Whatever model/system we start working with, we must first define the ontology.
The more roles use our ontology, the better; the more benefit we gain in all collaborative work.
Who needs your language that only you speak, and using incomprehensible words at that! So, you will somehow have to push through, agree on the ontology, then start using it, and then agree on processes, work, tools/objects, and so on.
Creating a Commonly Understood Ontology
Distinguishing between creating an ontology and adapting an existing one is conceptually difficult, but there is one important rule – it is much better for the ontology to choose words familiar to the roles.
Such a familiar description by roles of their domains is called a viewpoint, and it is very important for us to know this “point of view” as well as possible when we perform the role of an ontologist; otherwise, we won’t be able to build a working and convenient ontology.
The Essence of the Ontologist’s Work
To summarize the work of an ontologist, it consists of:
- Understanding the domain — realizing its boundaries, distinguishing it from the universal background,
- Needing to “put on” these roles, understand their worldview to grasp their viewpoint; otherwise, it will be impossible to determine with high accuracy which objects and functions are useful for which role.
- Then, against this background, find the objects of interest, those that can be useful for performing work by different roles,
- And also identify the agents (Only here do people appear) who perform the roles and for whom the established objects might be interesting.
Based on all these findings, documents expressing the ontology must be compiled/written, after which agreements must be reached with all agents (in all roles) regarding the established objects and the working methods of the roles.
This is large, complex, not a one-time task, but rather evolutionary work, and very interesting.