Core concepts

Classes define the structure of modelled concepts. They contain attributes and can build upon other classes through inheritance.

A class is a reusable model artefact with a stable identity, rather than an anonymous structure embedded inside a larger schema. It carries its own name, version and definition, and can be referenced, extended and depended upon by other models.

A class may be marked abstract, meaning it exists to be specialised rather than instantiated directly.

Attributes describe the information carried by instances of a class. Their definitions include value types and relevant constraints.

An attribute may represent a primitive value, a reference to another class, an embedded structure defined inline, a collection, or a reuse of a shared global attribute. Which of these applies is stated by the attribute’s kind.

OOML uses inheritance to express semantic specialization and reuse. A subclass is a more specific form of its superclass and inherits the structure and requirements defined above it.

Inheritance is an “is a” relationship. It is not a general-purpose attachment mechanism: a class should extend another because it genuinely is a kind of that thing, not merely to acquire convenient attributes.

A class may extend more than one superclass. This allows orthogonal concerns to be composed independently of the primary taxonomy, without forcing every shared concern into a common base class. The specification defines how the resulting attribute set is resolved.

Where a subclass needs to adjust something it inherits — giving an attribute a clearer local name, or narrowing a constraint — OOML provides a controlled mechanism for doing so. Inherited definitions cannot simply be redeclared, so these adjustments are explicit and visible.

§12Renaming and overriding↗

Some attributes represent concepts that should be defined consistently wherever they occur.

OOML allows such an attribute to be defined once as a reusable model artefact in its own right. This makes it possible to establish shared definitions for important pieces of information — a monetary amount, a geographic coordinate, an ISO language code — rather than reproducing equivalent field definitions throughout a model ecosystem.

A global attribute is versioned and referenced like any other artefact. A class that uses one states which definition it relies upon, and that dependency is visible.

OOML provides a portable type system intended to express the logical nature and valid range of values without defining their physical storage representation.

Alongside a type, an attribute may carry constraints — a length range, a numeric bound, a pattern, a required or nullable marker. These describe which values are valid, not how those values are stored.

The full catalogue of primitive types belongs in the specification.

Reusable models require unambiguous identity. If two organizations both define a Customer, it must be possible to say which one a model depends on.

OOML gives every class and global attribute a fully qualified name: a reverse-domain namespace, the artefact’s own name, and its version. Namespaces are organisationally scoped, so the party responsible for a name is evident from the name itself.

Because identity includes the version, a reference points at a specific definition rather than at whatever a name happens to mean today.

Model artefacts evolve independently. Each class and global attribute carries its own semantic version, so a change to one definition does not force the collective re-release of everything around it.

The version scheme distinguishes changes that break existing consumers from those that do not, which makes compatibility a stated property of a change rather than a matter of inspection.

When a model references another artefact, it does so through a version range. Those references are what create dependencies: a model states what it relies upon as part of defining itself, rather than in a separate manifest that can drift out of step.

Taken together, these references form a graph of dependencies between model artefacts — which is what makes questions such as “what depends on this definition?” answerable.

§14The Dependency Graph↗

OOML uses the term model metadata for structured information that describes elements of the model itself: ownership and stewardship, provenance, governance state, mappings to external standards, generator instructions, organizational classifications.

This is distinct from metadata carried by downstream business objects. If a domain contains document metadata, image metadata or observation provenance, that information is simply domain data from OOML’s perspective and should be modelled normally.

Model metadata is typed: metadata structures are themselves defined using OOML, so metadata can be validated, reused and understood by tooling rather than being an open bag of arbitrary annotations.

Model metadata in depth →