Model metadata
OOML can model more than domains. It can model the information required to understand and govern the models themselves.
Metadata about models, not instance data
Model metadata is structured information attached to model elements rather than to their runtime instances. The distinction is important.
A Document class may contain an author attribute because authorship is information about each downstream document. The Document model may separately have metadata identifying the team responsible for maintaining its definition.
The first is domain data. The second is model metadata.
customerNumber
registeredAddress
external vocabulary mappings · generator hints
What model metadata is used for
The kinds of information that describe a definition rather than the things it defines.
Ownership and stewardship
Which team is responsible for maintaining this definition, and who should be consulted before it changes.
Provenance
Where a definition came from — a source standard, a prior system, an imported vocabulary.
Governance state
Whether a model is proposed, approved, deprecated or withdrawn under an organization's own lifecycle.
External mappings
How this model corresponds to a definition in an external standard or vocabulary.
Generator instructions
Decisions a generator cannot infer from the core model alone when producing a specific representation.
Organizational classification
Sensitivity, retention class, jurisdiction or other classifications an organization applies to definitions.
Typed, not arbitrary
Unlike unstructured annotations, OOML model metadata follows OOML-defined structures. A metadata structure is an ordinary OOML class, which means metadata can have known types, required values, constraints and reusable definitions.
A tool encountering metadata does not have to guess at the shape of a free-form string. It can rely on a definition that is itself published, versioned and validatable.
Governance through types
Organizations can use metadata definitions to make information such as ownership, provenance or classification part of the requirements for valid models.
Governance requirements can therefore become machine-checkable at modelling time, rather than depending on review to notice that a required piece of context is missing.
Tooling and generation
Metadata can also communicate with tools.
A generator may define metadata describing decisions that cannot be inferred from the core model alone. An ontology generator, for example, might consume metadata expressing OWL-specific logical semantics that core OOML does not itself express.
This allows specialized tooling to evolve without forcing specialized constructs into OOML core.
Modelled with the same mechanisms
OOML uses its own modelling capabilities to define metadata structures. The same mechanisms that make domain models structured and understandable — classes, attributes, types, inheritance, versioning — apply equally to information about those models.
This keeps the language small. Metadata required no separate annotation language, no second type system and no parallel set of rules, because the modelling language was already sufficient to describe it.