Model Data
This page explains the data domain of the model. It is the layer where meaning becomes representable, storable, exchangeable, and evidentially reusable through records, structures, metadata, and history-bearing artifacts.
Intro
The data model matters because organisational meaning eventually has to be represented in forms that can be stored, exchanged, queried, validated, and used as evidence. But data should not be treated as the origin of meaning. It is one of the representation layers through which meaning becomes operationally manageable.
That is why the data domain is important. It sits close to application, evidence, history, and runtime traceability, while still depending on stronger semantic commitments from higher layers.
Diagram
The data domain at a high level
At a high level, the data model should help explain:
- how information is represented
- how records and structures are organised
- how evidence is preserved
- how history and change become traceable
- how application handling and storage structures relate to semantic meaning
This makes the data domain more than a storage concern. It is a representational and evidential concern as well.
Data is not just storage
A strong data model should not be reduced to fields, tables, or files. It also needs to account for:
- representational structure
- identifiers and references
- metadata
- provenance
- history-bearing records
- evidence support
- constraints and quality
That is what allows data to support reasoning and traceability rather than only persistence.
How data relates to the other domains
The data model is often handled through applications, but it should not be collapsed into the application model.
It needs to remain connected upward to:
- business meaning
- service commitments
- governance requirements
- performance and evidence logic
It also needs to remain connected sideways and downward to:
- application handling logic
- deployment context
- storage and infrastructure participation
This is why the data layer should be read as a semantic artifact layer, not just a technical payload layer.
What the data model needs to distinguish
Several distinctions become important here:
- conceptual meaning versus represented record
- data structure versus evidence artifact
- identifier versus referenced thing
- current state versus historical record
- asserted value versus verified value
- stored representation versus semantic interpretation
These distinctions help the data domain support quality, provenance, and evidential use.
Why this matters for ontology
The data layer is one of the main places where semantic drift can occur if the model is weak. A mature ontology should help clarify:
- what the data is about
- which structures are canonical versus projected
- what provenance and quality expectations exist
- how represented records connect back to business, service, and application meaning
- how historical and evidential semantics are preserved
Without that, the organisation may have lots of data while still having weak knowledge.
Next direction for this page
The next evolution of this page should make the data semantics more explicit around:
- record, metadata, and reference structure
- provenance, freshness, and quality
- data as evidence and historical trace
- distinction between canonical semantics and stored representation
- traceability between application handling and business meaning
