Ontology and DSL — model, behaviour, contract
Ontology describes data meaning: types, relationships, fields and constraints. DSL selects the exposed surface and unit behaviour. An exposition describes the contract for the platform and clients. Each artifact has its own role.
Model kinds
| Kind | What it describes | How to read it |
|---|---|---|
| Foundation model | Shared concepts and relationships | Definitions, not a finished application |
| Domain model | Concepts of a particular domain | The model’s version and dependencies |
| Framework | Mapping rules and generated unit infrastructure | Compatibility with model and Composer |
| Vocabulary | Values and classifications | Preserve IRIs, imports and types |
| Fixture | Synthetic case demonstrating a tool | Example, not a customer business model |
File names and extensions do not determine serialization. An .owl file may contain Turtle; do not select a parser by extension alone. Historical and experimental variants must be labelled EXPERIMENTAL or PLANNED, rather than moved into the current model.
Composer pipeline
The OWL/Turtle path passes through the reasoner and model IR. A .unit surface selects operations, graph access, actions and event rules. Validation binds type and field names to IR. A plan selects the backend and required capabilities; the generator emits code and exposition. A host supplies the process and platform connection.
There is also a surface with record/object/enum declarations without an RDF model. Do not equate it with the full graph path. YAML, Turtle and historical .eca are not interchangeable inputs. Use syntax and dependencies supported by the selected release.
The complete TODO example includes both inputs and commands. It begins with a simple aggregate rather than a large industry model.
Extension and versioning
Preserve namespaces and IRIs of existing concepts. Declare a new type, field or relationship in the model; add operations and rules to the surface. Resolve imports explicitly using the reasoner configuration. Do not create a second definition of the same property under a superficially similar prefix.
Framework SemVer, tool release and contract major are separate decisions. Compatibility assessment must include required fields, types, operation names, scopes, event payloads and data migration. Arbitrary versions have no automatic compatibility guarantee.
CURRENT describes the current documented path. MANUAL / POSSIBLE TODAY means a capability available with manual configuration. EXPERIMENTAL, PLANNED and UNKNOWN do not promise deployed capabilities. The approved domain model and change owner for a particular customer: information to be supplied.