InsightData & licensing
Data that keeps its context
A number on its own is not a data product. Observation data becomes useful, and safe to reuse, when its metadata, provenance, quality, licence and place of storage travel with it in open formats1.
An exploded stack of what turns a value into a data product: the value, its time, its place, the method and instrument, quality flags, provenance, and the licence and residency.
Key points
- A data product is a value plus the context that makes it usable: time, place, method, quality, provenance and terms.
- Open metadata standards let catalogues find and compare data from many owners.
- Provenance records how each product was made, so corrections can reach everything that depends on it.
- Quality flags and typed missing values tell users what to trust, instead of hiding problems.
- Open formats and APIs, with licence and residency stated, let data be reused without lock-in.
Why a bare number is not enough
Observation data is easy to strip. A value is copied into a spreadsheet, a chart or a model, and on the way it loses the instrument, the clock, the checks and the terms that came with it.
Once stripped, it cannot be trusted or reused safely. Nobody downstream can tell whether a spike was rain or a fault, whether a gap was a calm day or a dead battery, or whether the value may be shared.
The cost of lost context is paid later, and by someone else. An analyst spends days rebuilding what the station knew at the moment of measurement, or uses the value without knowing what it was.
The FAIR principles were written to stop this loss. They ask that data be findable, accessible, interoperable and reusable, by machines as well as by people1.
For reuse in particular, data and metadata should be richly described, released with a clear usage licence, associated with detailed provenance and meet domain-relevant community standards2.
A data product, in this sense, is a value with its context attached and kept attached. The rest of this piece follows that context from the instrument to the user.
Metadata that people and machines can read
Metadata is how data is found and understood. International geographic standards have long covered metadata so that organisations can describe geospatial data consistently, and it can be discovered, understood, trusted and reused3.
The ISO 19115 family is the core of that work, with parts for an XML implementation of fundamental concepts and for extensions covering acquisition and processing4.
A three-tier diagram: datasets from three owners publish metadata records to a national catalogue and a global discovery catalogue, which users search. A scenario takes the national catalogue offline.
Newer profiles follow web practice. The WMO Core Metadata Profile is a profile and extension of OGC API Records, encoded in GeoJSON and made available as crawlable files or through an API5.
OGC API Records itself provides a way to browse or search a curated collection of records known as a catalogue, deployed either as static files or behind an API6.
W3C DCAT does the same for data catalogues in general7. It lets publishers describe datasets and data services with a standard vocabulary, and makes federated search across catalogues in many places possible7.
Good metadata is also kept current. When an instrument is moved, replaced or recalibrated, its description changes with it, and earlier records keep pointing to the description that was true at the time.
The practical rule is simple: describe each dataset once, in an open profile, and publish the description where any catalogue can harvest it.
Provenance and corrections
Provenance is the history of a product: which readings it came from, what was done to them and by whom. Without it, an error found later cannot be traced to the products it affected.
The W3C PROV ontology gives a shared starting point8. Its core classes are entity, activity and agent, linked by relations such as generated by, derived from, used and attributed to8.
A provenance chain in four tiers: raw readings, the calibration and quality control activities, an hourly product, and a map and a report. A scenario withdraws the calibration so that every dependant is marked stale.
Those few terms are enough to describe most observation chains. A raw reading is an entity, a calibration is an activity, the calibrating laboratory is an agent, and the corrected value is derived from the raw one.
When a calibration turns out to be wrong, provenance shows every product derived from it. Each can then be marked stale, recomputed and published as a new version, with the old version kept and labelled.
Corrections should never erase. A report written last year on the old values remains explainable, because the record shows what was known then and what changed since.
The broader PROV family includes a data model, serialisations and supporting definitions, so provenance can move between systems without being rebuilt9.
Quality flags and honest gaps
Every value should say how far it can be trusted. Open sensor models already make room for this: an observation can carry a statement of result quality and the period in which the result may be used10.
Quality flags work best from a small controlled vocabulary, applied by named tests. A value marked suspect by a step test tells a user far more than a value silently dropped.
An exploded stack of quality states a value can carry: good, suspect, bad, estimated, missing and not checked, each noted with what it tells the user.
Missing data deserves the same care. A gap should be recorded as a gap, with its reason where known, and never filled with a zero or a copy of the last value.
Uncertainty belongs beside the value wherever the instrument class defines one. Users can then decide whether a reading is good enough for a warning, a design study or a trend.
Flags also travel through processing. A product built from suspect inputs should say so, and a product built with estimated values should name them, so that quality is never upgraded by accident.
Quality checks run in more than one place. A site can catch a stuck sensor at once, while a central check compares neighbours across a region and flags what no single site could see.
Open formats and APIs
Context only helps if users can reach it with ordinary tools. Open formats and web APIs let the same product serve a forecaster, a planner and a researcher without a custom pipeline for each.
OGC API Features provides building blocks to create, modify and query features on the web, and is defined in parts that each form a separate standard11.
A three-tier diagram: one store of qualified data serves features, observations, an asset catalogue, real-time notifications and bulk export, which reach analysts, applications, forecasters and archives.
OGC SensorThings provides an open, geospatial-enabled way to manage and retrieve observations and metadata from different sensor systems12.
For imagery and other files, the STAC specification describes and catalogues spatiotemporal assets, with items as GeoJSON features plus a datetime and links13.
For real-time exchange, the WMO Information System uses notification messages over MQTT, so subscribers learn of new data as soon as it is published and fetch it over HTTPS14.
Versions keep these doors stable. An interface that changes without notice breaks every user at once, so each one carries a version, and old versions are retired only after notice.
Bulk export matters as much as live access. An owner should always be able to take all of its data, with its metadata and provenance, in open formats and leave.
Residency and licensing travel with the data
Every product needs terms. A clear and accessible usage licence is part of what makes data reusable, and without one a careful user has to leave the data alone2.
Standard licence identifiers help machines read those terms. The SPDX License List gives each common licence a short identifier, a full name, the licence text and a permanent address15.
A timeline from 2012 to 2030 with the W3C provenance ontology, the FAIR principles, OGC API Features, OGC SensorThings 1.1, the WMO Information System 2.0 specifications, ISO 19115-3:2023 and DCAT 3.
Some communities set terms for whole classes of data. In the WMO Information System, core data is provided free and unrestricted, without charge and with no conditions on use14.
Discovery metadata in that system must classify each dataset as core or recommended data under the WMO Unified Data Policy5.
When products are combined, the most restrictive upstream term should carry forward, so that a derived map never quietly loosens the conditions of the data inside it.
Residency belongs in the record too. Where data is stored and processed, and under whose jurisdiction, should be stated with each product and enforced by the systems that hold it.
Nexus Observatory Inc. designs data products on these principles, so that each value leaves the site with its context and its terms attached.
Context is not decoration. It is what lets a number from one owner be trusted, combined and reused by another, years after it was measured.
Questions and answers
What is the difference between data and a data product?
A data product is data with its context kept attached: time, place, method, quality, provenance, licence and residency, described in open metadata1.
Why not fill gaps with zeros or the last value?
Because a filled gap looks like a real measurement. A recorded gap, or an estimate that is labelled as one, tells users the truth about what was measured.
Which provenance model should we use?
The W3C PROV ontology is a widely used open choice, built on entity, activity and agent8.
Glossary
- Metadata
- Information that describes data so it can be found, understood and reused.
- Provenance
- Information about the entities, activities and people involved in producing data9.
- Data residency
- Where data is stored and processed, and the jurisdiction that applies to it.
References
- Peer-reviewed or intergovernmental: The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data. . pmc.ncbi.nlm.nih.gov (accessed )
- Consortium or technical document: FAIR Principles. GO FAIR. go-fair.org (accessed )
- Standard or official statistic: ISO/TC 211 Geographic information/Geomatics: Happy Standards Day. ISO/TC 211. committee.iso.org (accessed )
- Standard or official statistic: ISO/TC 211 Normative Statements and Conformance: supported standards, including ISO 19115-3:2023 and ISO 19115-2:2019. ISO/TC 211. standards.isotc211.org (accessed )
- Standard or official statistic: WMO Core Metadata Profile (Version 2). World Meteorological Organization. wmo-im.github.io (accessed )
- Standard or official statistic: OGC API – Records Standard. Open Geospatial Consortium. ogc.org (accessed )
- Standard or official statistic: Data Catalog Vocabulary (DCAT) – Version 3. W3C. . w3.org (accessed )
- Standard or official statistic: PROV-O: The PROV Ontology. W3C. . w3.org (accessed )
- Standard or official statistic: PROV-Overview: An Overview of the PROV Family of Documents. W3C. . w3.org (accessed )
- Standard or official statistic: OGC SensorThings API Part 1: Sensing, Version 1.1. Open Geospatial Consortium. . docs.ogc.org (accessed )
- Standard or official statistic: OGC API Features Standard. Open Geospatial Consortium. ogc.org (accessed )
- Standard or official statistic: OGC SensorThings API Standard. Open Geospatial Consortium. ogc.org (accessed )
- Consortium or technical document: STAC: SpatioTemporal Asset Catalogs. STAC community. stacspec.org (accessed )
- Standard or official statistic: Guide to the WMO Information System, Volume II: WIS 2.0. World Meteorological Organization. wmo-im.github.io (accessed )
- Consortium or technical document: SPDX License List. SPDX, Linux Foundation. spdx.org (accessed )
- Standard or official statistic: OGC API – Features – Part 1: Core. Open Geospatial Consortium. . docs.ogc.org (accessed )
- Standard or official statistic: WMO Information System (WIS). World Meteorological Organization. community.wmo.int (accessed )
As of