Object-Oriented Modelling Language
A technology-independent language for defining reusable, versioned object models.
OOML provides a canonical modelling layer for information that needs to outlive any particular database, API, serialization format or programming language.
Define the meaning and structure of your domain once, then map or generate the representations required by the systems that use it.
Why another modelling language?
Modern organizations describe the same information repeatedly. A business concept may appear as a database schema, a JSON payload, a TypeScript interface, a Java class, an Avro schema, an API contract and a data catalogue entry.
Each representation serves a useful purpose, but none necessarily constitutes the technology-independent definition of the concept itself. Over time these representations diverge. Implementation details begin to define business meaning, and changing technology can mean redefining the model.
OOML provides a layer above those implementations: a place to define the model itself. It is designed for models that should be shared, extended, versioned and reused independently of the technologies through which their data happens to be stored or exchanged.
A canonical modelling layer
OOML separates what information means and how it is structured from how a particular system represents or transports it.
That distinction allows the same model to inform multiple implementations without making PostgreSQL, JSON, Java, Protobuf — or any other technology — the canonical source of truth.
OOML does not attempt to replace these technologies. It gives them something stable to implement.
Familiar by design
OOML deliberately borrows its core mental model from object-oriented programming. Classes have attributes. Classes can inherit from other classes. Attributes have types. Models can be composed and extended.
This makes OOML approachable to software developers while retaining the technology independence expected of a modelling language.
The similarity to programming-language type systems is intentional for a second reason: models should be suitable for reliable code and schema generation without being designed around any single target language.
Models are building blocks, not documents
OOML models are composed from independently identifiable and versioned artefacts. Classes can build on other classes. Shared definitions can be reused instead of copied. Dependencies are explicit. Models can evolve while retaining clear identity and compatibility boundaries.
This makes it possible to build model libraries ranging from small shared vocabularies to larger domain and enterprise models without requiring every model to be maintained as one monolithic schema.
Model metadata as a first-class extension mechanism
Real modelling environments need information that is not part of the downstream business object itself. Who owns this model? What source definition was it derived from? Which external vocabulary does it correspond to? What governance state is it in? How should a particular generator interpret it?
OOML supports typed model metadata: structured information attached to model elements, defined using OOML itself.
Because metadata is modelled rather than reduced to arbitrary key/value annotations, it can itself be typed, validated, versioned, inherited and reused. That turns metadata into more than documentation — it becomes a controlled extension point through which organizations, standards and tools can add specialized semantics without continually expanding the OOML core language.
Make required context part of model validity
Policies often state that every model must identify an owner, source, classification, lifecycle state or external mapping. In many modelling environments, compliance with such policies depends on documentation and manual review.
Typed model metadata makes another approach possible. Organizations can define modelling conventions in which particular kinds of models require particular metadata. Missing governance information can therefore become a model-validation problem rather than merely a documentation problem.
One layer among several
OOML occupies the canonical semantic and logical modelling layer. It complements technologies concerned with other parts of the information lifecycle.
| UML | can visualize and communicate models. |
| JSON Schema | can validate JSON representations. |
| Avro and Protobuf | can define serialized messages and wire formats. |
| OpenAPI | can describe HTTP APIs. |
| ODCS | can define operational contracts for delivered data products. |
| OWL | can add formal ontology semantics and machine reasoning. |
| SQL DDL | can define physical relational storage. |
OOML’s role is to provide a stable model from which such representations can be related, mapped or — where suitable tooling exists — generated.
See how OOML fits into the ecosystem →A small core, an open ecosystem
OOML is an open-source specification intended to support an ecosystem of models, libraries, validators, generators and modelling tools.
The core language aims to remain small enough to be understandable and portable, while its class system and typed model metadata provide extension mechanisms for specialized domains and technologies.