Essay

What Is a Data Object?

*The term Data Object is often used loosely to describe a table, file, API payload, business entity, or data product. Such ambiguity undermines the very stability the concept is intended to provide. This essay offers a rigorous definition: a Data Object is a versioned logical contract representing a coherent entity, event, state, or document-like assertion, with explicit identity, temporal semantics, attributes, relations, quality constraints, provenance, and governance. It is independent of any single source or physical storage format, though it must be implementable in concrete technologies. The essay develops a formal tuple for Data Objects, distinguishes them from source records and consumer views, and analyses granularity, lifecycle, compatibility, and ownership. Philosophically, the Data Object is treated as an institutional object: neither a natural thing nor an arbitrary schema, but a stabilised representation whose legitimacy depends on transparent rules and continued use.*

8 minute read·July 2026·Davide Scuteri Moretti

Data Objectdata contractidentitytemporal semanticslogical modeldata productinstitutional ontology

Themes

— Data Objects
— Semantics
— Contracts
— Platform Economics

Abstract

The term Data Object is often used loosely to describe a table, file, API payload, business entity, or data product. Such ambiguity undermines the very stability the concept is intended to provide. This essay offers a rigorous definition: a Data Object is a versioned logical contract representing a coherent entity, event, state, or document-like assertion, with explicit identity, temporal semantics, attributes, relations, quality constraints, provenance, and governance. It is independent of any single source or physical storage format, though it must be implementable in concrete technologies. The essay develops a formal tuple for Data Objects, distinguishes them from source records and consumer views, and analyses granularity, lifecycle, compatibility, and ownership. Philosophically, the Data Object is treated as an institutional object: neither a natural thing nor an arbitrary schema, but a stabilised representation whose legitimacy depends on transparent rules and continued use.

1. A definition

A Data Object is a governed logical representation of a coherent domain assertion. It may represent an entity such as a person or device, an event such as an administration or dispatch, a state such as an active treatment plan, or a document-like artefact such as a validated report.

Formally, define

D = (N, V, I, T, A, R, C, Q, P, G, O),

where:

$N$ : canonical name and scope;
$V$ : contract version;
$I$ : identity model;
$T$ : temporal semantics;
$A$ : typed attributes;
$R$ : relations to other objects;
$C$ : semantic and structural constraints;
$Q$ : quality rules and thresholds;
$P$ : provenance requirements;
$G$ : governance and access policy;
$O$ : ownership and service obligations.

A table that lacks most of these properties may implement part of an object, but it is not a complete Data Object contract.

2. Object, record, and product

Three concepts should be distinguished.

A source record is an inscription produced by a local system. A Data Object is a shared logical contract into which relevant source assertions are projected. A data product is a supported publication that delivers one or more objects or derived views to consumers under service expectations.

The relations can be written

S o u r ce R ecor d s ma pp in g D a t a O bj ec t s p r o d u c t i s a t i o n D a t a P r o d u c t s .

A Data Object may be used by several products. A product may combine several objects. Conflating them causes ownership confusion: domain semantics, engineering operation, and consumer experience may belong to different accountable groups.

3. Identity as the first invariant

An object must answer: what makes two representations refer to the same object? Identity may be natural, assigned, composite, context-bound, or probabilistic.

Let identity function be

I_{D} : A_{D} \to K_{D},

mapping object attributes or resolved references to key space $K_{D}$ . The key must have declared scope and lifecycle. An encounter identifier may be unique only within an organisation. A specimen identifier may be unique only within a laboratory. A state object may be identified by entity plus validity interval.

Identity should not be reduced to a surrogate key. The key is an implementation; the identity model explains what continuity the key asserts.

4. Temporal semantics

Objects exist in time differently. An event has an occurrence time. A state has a validity interval. A document may have creation, validation, publication, and revision times. An entity may have slowly changing attributes.

Define temporal component

T_{D} = (t_{e}, t_{v}, t_{p}, t_{s}),

where event time, validity time, processing time, and system-recording time are included as applicable. The contract must state which timestamps are mandatory and how conflicts are resolved.

Without temporal semantics, “latest” is ambiguous and historical reconstruction is unreliable.

5. Attributes and semantic types

An attribute is not fully defined by a programming type. float does not specify unit, scale, method, permissible range, or missingness semantics. A semantic attribute definition can be represented as

a = (nam e, t y p e, d o main, u ni t, co d e S y s t e m, n u l l M e anin g, d e f ini t i o n) .

This may be implemented through schemas, catalogues, reference tables, and documentation. The important point is that machine and human interpretation are aligned.

Attributes should be included because they belong to the object’s meaning or contractual use, not merely because a source provides them. Source-specific extras may be retained in extension structures or raw zones without contaminating the core.

6. Relations are first-class

Objects gain meaning through relations. A result fulfils an order; a medication administration instantiates a prescription; an observation belongs to an encounter; a revision supersedes an earlier report.

Define relation

r = (D_{s}, t y p e, D_{t}, c a r d ina l i t y, t e m p or a l C o n s t r ain t, in t e g r i t y R u l e) .

This is richer than a foreign key. The relation type and temporal constraint explain what the link means. For example, an administration should not precede the prescription it claims to fulfil unless the domain explicitly allows retrospective entry.

First-class relations enable lineage, process analysis, and quality checks.

7. Event, state, and document objects

Different object classes require different contracts.

An event object is immutable or append-only and records an occurrence. Its core is identity, event type, participants, event time, and provenance.

A state object represents what holds over an interval and is often derived from events. Its contract must include state rule version and validity.

A document object aggregates assertions under authorship, validation, and revision. It may be signed or legally significant.

Treating all three as generic rows obscures lifecycle. A report revision should not overwrite event history like a mutable master record; an active-state view should not pretend to be an original event.

8. Granularity

An object can be too coarse or too fine. A giant “clinical record” object becomes ungovernable and difficult to reuse. An object for every source field creates fragmentation.

A useful granularity criterion is high internal cohesion and low external coupling. Let attributes $a_{i}, a_{j}$ have lifecycle dependency $l_{ij}$ and use co-occurrence $u_{ij}$ . We seek partitions that maximise

C o h es i o n (D) = i, j \in D \sum (α l_{ij} + β u_{ij})

while minimising cross-object dependencies not represented by explicit relations.

No formula chooses granularity automatically. Domain modelling and iterative use are required.

9. Versioning and compatibility

Data Objects evolve. Additive optional attributes may be backward compatible; changed meanings or identity rules may require a new major version.

Let contracts be $D^{v}$ and $D^{v + 1}$ . Compatibility relation

C o m p a t (D^{v}, D^{v + 1}) \in {ba c k w a r d, f or w a r d, f u l l, n o n e}

should be declared. Consumers need deprecation periods, migration guidance, and test fixtures.

Versioning is not merely schema versioning. A change in code mapping, quality threshold, or state derivation may alter meaning even if columns remain unchanged.

10. Data Objects as institutional objects

A Data Object is not discovered in nature. It is constructed through domain practice, technical design, governance, and repeated use. Yet it is not arbitrary. It is constrained by the phenomena, workflows, standards, and questions it must support.

John Searle’s analysis of institutional facts is useful: institutions create durable functions through collectively recognised rules. A Data Object similarly exists because an organisation recognises its identity, meaning, ownership, and legitimate uses. Its reality is operational and contractual.

This perspective encourages humility. The object should be contestable, versioned, and revisable. Its authority comes from transparent governance, not from the visual neatness of a schema diagram.

11. A minimal acceptance test

A candidate Data Object should answer:

What does it represent?
How is identity established?
Which times are represented?
Which attributes are mandatory and why?
Which relations are valid?
How are revisions and deletions handled?
What quality rules apply?
Can every published value be traced?
Who owns the definition and service?
Which changes are compatible?
Which uses are permitted?
Can multiple sources populate it without changing its meaning?

If these questions cannot be answered, the object is still a draft schema.

12. Observability of the object itself

A Data Object requires operational observability. It should be possible to determine how many instances were produced, which sources contributed, which rules failed, how freshness changed, and which contract version consumers received. Observability turns the object from a static design artefact into an operated service.

For object $D$ at run $r$ , define telemetry

T e l (D, r) = (n_{in}, n_{o u t}, n_{q}, Δ t, f r es h, d r i f t, v er s i o n),

where input and output counts, quarantined records, execution duration, freshness, detected drift, and contract version are recorded. Statistical baselines can identify deviations even when no hard constraint is violated.

Object-level observability also enables product accountability. If a dashboard changes, the platform can distinguish a consumer defect from an upstream object change. If completeness falls, the responsible source and mapping can be located. A contract without telemetry states what should happen; an observable Data Object shows whether it did.

Conclusion

A Data Object is a versioned, governed logical contract that stabilises a coherent domain assertion across sources, technologies, and consumer views. Its defining properties are not its table name or file format but its identity, temporal semantics, attributes, relations, quality, provenance, governance, and ownership.

By treating Data Objects as institutional and computational objects, a platform gains a durable semantic layer without pretending that its models are eternal. The object is stable enough to support reuse and explicit enough to be challenged. That combination—stability with revisability—is what makes it valuable.

Conceptual references

Searle, J. R. The Construction of Social Reality (1995). Evans, E. Domain-Driven Design (2003). Kahn, R. E., and Wilensky, R. “A Framework for Distributed Digital Object Services” (1995). Guarino, N., writings on ontology-driven information systems.

Extracted images (63):

parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_1.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_10.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_11.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_12.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_13.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_14.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_15.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_16.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_17.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_18.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_19.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_2.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_20.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_21.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_22.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_23.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_24.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_25.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_26.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_27.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_28.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_29.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_3.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_30.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_31.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_32.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_33.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_34.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_35.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_36.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_37.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_38.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_39.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_4.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_40.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_41.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_42.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_43.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_44.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_45.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_46.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_47.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_48.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_49.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_5.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_50.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_51.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_52.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_53.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_54.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_55.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_56.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_57.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_58.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_59.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_6.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_60.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_61.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_62.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_63.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_7.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_8.jpg
parsed-documents://20260717-165745-276889/A_Computational_Culture_of_Data_Platforms_15_Essays.docx/images/page_9.jpg