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
Page 1 as a data-domain table of contents
The data diagram is compact, but it still gives a usable first-pass table of contents for the data domain.
An exhaustive first-pass TOC from the page is:
- Data
- Data Members
- Data Member Relationship Type
- Data Attributes
- Data Attribute Types
- Member Attributes
The page also includes important framing cues:
- L2
- Data
- Application
- Infrastructure
Those cues matter because they suggest the data page is already being read at a particular abstraction level and in relation to both the application handling layer and the infrastructure/storage context around it. So even in compact form, the diagram is not only naming data concepts in isolation. It is hinting at how data semantics sit inside a wider representational and technical chain.
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.
What the compact data diagram already implies
Even though the page only shows a small number of labels, it already implies a useful internal data-domain structure:
- a core Data concept
- a way of representing members that participate in, compose, or structure data
- a need to type the relationships between those members
- a distinction between the data itself and its attributes
- a distinction between data attributes and member attributes
- a surrounding context explicitly tied to Application and Infrastructure
That is a good sign. It means the page is already moving beyond “data is just storage” toward a more structured representational model.
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 compact TOC like the one on this page reinforces that quickly: even at a glance, data semantics seem to need entities, members, typed relationships, and structured attributes rather than one flat storage register. 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
