Levels of the model being addressed ​

An ontologist can build an ontology (usually referring to an applied ontology and model) not only of their own (customary) subject area, but also of any subject area, not only in the customary upper-ontology, but also in any other specified one in which it is clear what types exist, their properties, and what foundational ontology is.

For now, it can be assumed that the foundational ontology does not change from project to project - objects and relationships exist everywhere, and objects are what is, and relationships are what they do to each other. Although, of course, if you wish (and decide that it suits the project's goals), any other one will do just fine!

We can also represent objects as relationships and relationships as objects using attention - essentially, we have already encountered this operation when we talked about tuples: (programmer [writes]{.underline} code)/([programmer writing code]{.underline}).

The upper ontology is chosen carefully for the subject area and tasks, and there is a long list of them^ https://en.wikipedia.org/wiki/Upper_ontology. Not everything in the long list is popular and suitable for constant use, and much of what is in the list seems similar to each other and is based on similar principles. Many top-level ontologies explain why they are structured that way, and their creators produce works of a philosophical-industrial nature with arguments as to why these basic types will work well in that set of situations for which this upper-level ontology is suitable.

Next comes the creation of an applied ontology and simultaneously a model (if it is not given to domain experts or enterprise employees). When it comes to an unfamiliar area, there are several significant differences from a familiar one:

• Initially, there is a completely incomprehensible practice of using words and phrases that are far from neatly distinguishing levels of models, role positions, system levels, and so on. However, in the end, everyone truly benefits if this practice of use is made more precise.
• You do not know in which documents, standards, textbooks, BOK's high-quality meta-models are contained, and it is not easy to identify this quickly through independent search.

You only know the general scheme of what you need to find role positions to be able to define interesting system levels and levels of abstraction; use types from the meta-model in the model and types from the meta-meta-model in the meta-model, and so on; to make the ontology shared among all roles, it is better to search for a meta-U-model and then tailor it to your situation; choose modeling tools that will suit the users of your model.