Abstract
The word data is one of the most heavily used and least precisely defined terms in computing. Standard references settle on an informal characterization of data as “raw facts,” but none of them says what structural properties a collection of facts actually needs before it can be addressed, compared, or processed by a machine. This is not just a philosophical loose end. It propagates directly into system design as schema drift, type-confusion vulnerabilities, unsound equality checks, and serialization defects, and each of these traces back to an unstated assumption about what index set or value set a piece of data is supposed to inhabit. This paper works through data, representation, and interpretation across three registers. First, we ground the concept etymologically and lexically, tracing the word datum from its Latin root through to contemporary technical usage, in order to expose a structural implication that the informal definitions all share but never state outright. Second, we formalize data as a function from an index set to a value set, with explicit totality, functionality, and codomain-consistency conditions, and we show how this framing subsumes sequences, tuples, and multisets as special cases rather than treating them as separate notions. Third, we introduce the data–information–knowledge hierarchy as the interpretive scaffolding through which machines, which operate at the data level and nothing more, are made to produce outcomes that mean something to human beings, and we argue that engineering this transition is really the central problem of data representation. From the formal definition we derive four corollaries linking specific violations of its conditions to recurring engineering failure modes, namely schema drift, type confusion, unsound equality, and serialization ambiguity, and we walk through a worked example for each. The paper closes by separating data from representation, arguing that the choice of representation is always contingent and sits outside the data itself, and that grasping this distinction is a prerequisite for reasoning clearly about encoding, type systems, and protocols.
