UC2 data standard

The UC2 data standard came out of the Urban Climate Under Change programme as a convention for organising urban climate model output and observations consistently across the groups involved. It is a profile layered on netCDF and CF conventions, not a new format.

What makes it worth a note is that it is a concrete answer to a problem that is usually discussed abstractly. FAIR says data should be findable, accessible, interoperable, and reusable. Nobody disagrees, and nobody can act on it directly. The UC2 standard is what that turns into when a consortium actually has to exchange files: a specific list of required attributes, a naming scheme, and a validator that says yes or no.

What it specifies

• netCDF as the container, with structure expressible in CDL — which is what makes the specification reviewable and diffable rather than prose.
• CF conventions as the semantic backbone, extended where urban work needs vocabulary CF does not supply.
• Required global attributes covering source, version, conventions, dependencies, and institution — the provenance layer, which is where compliance efforts most often stop short.
• ASCII-only character arrays, chosen for tooling compatibility in the original consortium. A dated constraint, and a good illustration that standards encode the technical realities of when they were written.

It supports both model output — PALM-4U in particular — and measurement data, which is harder than supporting either alone, because the two have genuinely different metadata needs and forcing them into one schema means compromises in both directions.

Why the mandatory list is the point

The valuable part is not any individual attribute. It is that the list is fixed and machine-checkable.

“Describe your data well” is advice nobody can follow consistently, because the producer knows everything and therefore finds most of it too obvious to write down, while the consumer reads it years later knowing nothing. That asymmetry is structural and exhortation does not fix it. A required-attribute list with a validator removes the judgment call, and that is why standards like this work where guidelines do not.

The second-order benefit is that machine-checkable metadata enables things beyond human reading — automated aggregation across groups, and the sort of graph construction that needs consistent typed relationships to be possible at all.

The limits

A profile is only as good as its adoption, and adoption within a funded consortium says little about uptake outside it. Standards like this tend to be well observed while the project runs and to decay afterwards unless something keeps enforcing them.

There is also real tension between strictness and usefulness. Requirements strict enough to guarantee interoperability are strict enough that people route around them, and the failure mode is technically compliant files with attributes filled in meaninglessly.

See also: ATMODAT for a comparable profile, FAIR for the principles, metadata and provenance for the layers involved, and urban climate for the domain.