Ontologies and business language
An ontology is an explicit model of the concepts in a defined domain, their properties and relationships, and the constraints or logical commitments governing their meaning. A formally specified ontology makes those meanings precise enough to support machine interpretation and, where supported, logical reasoning.
A business ontology might describe customers, orders, products, commitments and payments. Its value comes from defining how these concepts are understood and connected within a stated scope.
Start with meaning
Consider the sentence:
CycleXplore has twenty customers with open rental orders.
To interpret it consistently, people and systems need to know what “customer,” “rental order” and “open” mean. Does a customer include someone who has only made an inquiry? Is an order open before it is accepted, after the bicycle is collected, or until payment is settled?
The answers depend on the business's definitions. An ontology makes relevant distinctions explicit, allowing an Enterprise Vocabulary to express CycleXplore's chosen meanings.
The scope matters too. CycleXplore needs information relevant to renting bicycles. Its customer model does not need to describe every aspect of a person's life.
Objects, properties and relationships
An object model gives structure to these meanings.
| Element | Example | What it expresses |
|---|---|---|
| Object type | Rental Order | A defined kind of business entity, event or concept |
| Attribute | Requested start date | A value recorded for instances of a type |
| Relationship type | Rental Order is placed by Customer | A defined kind of connection between instances |
| Constraint | End time must be later than start time | A condition that valid information must satisfy |
| Instance | Rental order CX-R-1042 | A particular recorded occurrence conforming to a type |
The timing constraint is an illustrative local requirement. MONJO supplies the means to express relevant definitions; the business determines which requirements apply to its situation.
Classification and subsumption
Subsumption expresses class inclusion: every instance of a more specific class is also an instance of its more general class.
In a reference hierarchy where Customer is a subtype of Trading Partner, and Trading Partner is a subtype of Participant, a Customer is also a Trading Partner and a Participant. The applicable meaning and inherited definitions follow that classification.
Other connections have different meanings:
| Statement | Relationship meaning |
|---|---|
| Customer is a type of Trading Partner | Classification / subsumption |
| A Rental Order is placed by a Customer | An association between distinct instances |
| An Order Line belongs to an Order | Composition or dependency, as explicitly defined |
| An order moves from Draft to Approved | A lifecycle transition, requiring a defined state model |
An order placed by a customer does not become a subtype of Customer. Likewise, being part of something does not mean being a kind of that thing. These distinctions remain important even when a software tool uses related mechanisms to configure or display them.
MONJO supports classification-based lifecycle modeling. Its detailed state and selector conventions are explained in the Object Model material. A hierarchy's classification meaning and the rules for changing state should be understood separately.
Related terms
Taxonomy
A taxonomy organises concepts into a classification scheme. In a class taxonomy, the central question is “What is a kind of what?” Broader navigation schemes may also group concepts by subject or perspective; their links need clear meanings.
MONJO's Business Object Taxonomy helps users locate reusable business concepts. Its classification view serves a different purpose from a complete description of all the relationships between those concepts.
Nomenclature
Nomenclature concerns the names, identifiers and naming conventions used for concepts. It helps distinguish concept identity from the words used to display it.
For example, one organisation may prefer “Client” while another uses “Customer.” Similar labels do not prove identical meanings, and different labels do not necessarily indicate different concepts. Definitions and context determine whether a mapping is appropriate.
Glossary
A glossary gives readers access to terms and their definitions. It can be carefully governed and is valuable for communication. An Enterprise Vocabulary adds structured modeling elements such as types, attributes, relationships and constraints.
Enterprise Vocabulary
In MONJO, an Enterprise Vocabulary is the organisation- or project-specific semantic specification composed using the Object Model and relevant reference content. It is more extensive than an ordinary list of words. Read Enterprise Vocabularies and reference content for the full explanation.
Semantic model
A semantic model represents meaning and relationships. An Enterprise Vocabulary is such a model; a focused view can show the part relevant to billing, rental management or another concern.
A diagram is a way to present that model. A machine-readable representation is another. Neither the visual layout nor the storage format, by itself, establishes the model's meaning.
Ontologies, databases and application rules
An ontology describes meaning. A database stores information according to a particular design. A runtime carries out operations and enforces applicable executable rules. These roles can be closely integrated, as they were in Bizcloud's metadata-driven architecture.
A conventional data model can also define structure, relationships and constraints. The important question is how consistently meaning is captured, shared and preserved across applications and uses.
A statement such as “a rental order must reference a customer” needs an appropriate implementation if it is to prevent invalid records. It may inform form validation, API checks and database constraints. Recording the requirement in a semantic model provides the basis for those checks; the surrounding implementation performs them.
Ontologies and AI
Shared semantics help AI interpret the business's intended concepts. A development assistant given CycleXplore's approved definitions can work from its actual rental model rather than invent a generic booking system.
To make that useful, the development process needs to supply the relevant definitions, preserve their identifiers and relationships, and check proposed outputs against the model. Factual answers also need grounding in relevant evidence or records. Ontology-based meaning and factual evidence solve related but different problems.
Formal standards
Standards such as SKOS, OWL and SHACL provide ways to represent concept schemes, express formal semantics and validate graph data. They have different purposes and assumptions. MONJO's interoperability work must specify how its constructs map to the chosen standards and what those mappings preserve.
Their mention here explains the wider context. It does not imply that the current MONJO tools implement those standards.