Every Source Speaks a Dialect

Abstract

Heterogeneous information systems do not merely encode the same reality in different technical formats. They often partition reality differently, assign different identities, privilege different events, and embody different professional practices. To say that every source speaks a dialect is therefore more than a metaphor for incompatible column names. It is a statement about local ontologies. This essay examines data integration as a problem of translation rather than transcription. Drawing on linguistics, philosophy of language, ontology engineering, and category-theoretic intuition, it distinguishes lexical mapping from structural and pragmatic equivalence. It proposes a typed translation model that preserves local expressions while projecting them into shared Data Objects, and it explains why some mappings are exact, some contextual, and some irreducibly lossy. The goal of a mature Data Platform is not to abolish dialects but to establish a governed interlanguage through which local systems can participate in common computation without having their differences silently erased.

1. Dialect is not noise

In many integration projects, source-specific terminology is treated as accidental clutter to be cleaned away. Columns are renamed, codes are replaced, and local distinctions are collapsed into a canonical schema. Some normalisation is necessary, but the assumption that local variation is merely noise is dangerous. A source system’s dialect often reflects the work for which it was designed.

A laboratory system distinguishes collection, accession, processing, validation, and release because those distinctions organise diagnostic production. A billing system may collapse several of those events into a chargeable service. A clinical record may privilege the signed report. A research dataset may privilege the measurement and its method. These are not arbitrary variations; they are different views generated by different practices.

Let a source dialect be

where $V_i$ is vocabulary, $R_i$ relation structure, $C_i$ constraints, and $P_i$ pragmatic use. Translation that maps only $V_i$ ignores most of the dialect.

2. From renaming to translation

A lexical mapping might declare that source field pat_no corresponds to canonical patient_id. But this is valid only if both identifiers have compatible scope, persistence, and uniqueness. One may identify a person across an organisation; the other may identify a registration episode. The names can be made identical while the meanings remain different.

A robust translation from source $L_i$ to shared model $M$ is a family of mappings:

where vocabulary, relations, constraints, and pragmatic conditions are separately addressed. In practice, ${\varphi }_P$ is often captured as mapping rationale, ownership, and permitted use rather than an executable function, but it should not remain entirely tacit.

The distinction resembles translation between natural languages. A dictionary is helpful, yet it cannot by itself translate irony, register, institutional roles, or context. Likewise, a data dictionary cannot fully determine whether two process states are equivalent.

3. Wittgenstein and the use of data terms

Wittgenstein’s later philosophy argued that meaning is use within a language game. In data architecture, this insight can be made operational. The meaning of closed, active, valid, or delivered depends on the workflow in which the term triggers actions and expectations.

Suppose systems $S_1$ and $S_2$ both expose status complete. In $S_1$, it means all technical processing ended. In $S_2$, it means a qualified professional validated the result. A lexical join over complete creates a false equivalence.

We can represent a status meaning as a transition predicate:

Two labels are equivalent only if they occupy sufficiently similar positions in their state-transition systems and support the same intended uses. Translation is therefore behavioural as well as lexical.

4. Exact, contextual, approximate, and impossible mappings

Not all mappings should be encoded as if they had the same certainty. A useful taxonomy includes:

1. Exact equivalence: source and target concepts have the same intended extension and constraints.
2. Contextual equivalence: they align only under specified conditions.
3. Approximate projection: the target captures part, but not all, of the source meaning.
4. Aggregation: several source values jointly produce one target concept.
5. Decomposition: one source field is split across several target attributes.
6. No valid mapping: the source distinction has no legitimate target counterpart.

Let a mapping have confidence and loss:

where $\kappa \in [0,1]$ is confidence and $\ell \ge 0$ estimates semantic loss. These values need not imply false precision; even ordinal categories can make uncertainty visible.

The inability to map is itself valuable information. Forcing every field into a canonical slot creates semantic corruption disguised as completeness.

5. Translation as a graph problem

In a large platform, direct mappings between every pair of source dialects are unsustainable. If $n$ dialects require pairwise translation, the number of possible mapping sets grows on the order of $n^2$. A shared interlanguage or family of domain Data Objects reduces the burden.

Let $L_1,\dots ,L_n$ map into domain model $M$:

Consumers then map from $M$ to their views. This does not mean $M$ is a universal language. It is a governed pivot model with an explicit scope. The architecture should allow multiple domain models rather than one imperial schema for the entire organisation.

Category-theoretic language offers an intuition. Systems can be viewed as categories whose objects are data structures and whose morphisms are valid transformations. A translation should preserve relevant composition: if event A precedes B and B produces C locally, the mapped model should not destroy the relation by which A contributes to C. A mere field rename is not structure-preserving.