Skip to content

Introduction

The problem these schemas address

Structure travels well. A CSV, a JSON file or a Parquet table opens anywhere, and two labs can exchange files all day without either of them learning anything about the other's data.

Meaning does not travel. The same quantity, process or dataset is modelled differently by every ontology, every schema language and every lab information system, and the differences are rarely disagreements about the science. They are disagreements about representation: whether a value and its unit sit on one node or two, whether a duration is a quantity or a temporal region, whether a unit is a class or an individual.

The usual response is to pick an ontology. That works inside one project and fails at its boundary, because picking one excludes everyone aligned with another. The boundary is often a domain boundary: a measured quantity crosses from a laboratory to an engineering calculation to a product declaration, and each side has its own vocabulary for the same number. Ontology alignment is supposed to fix that afterwards, but alignment between whole ontologies is a research problem, while the practical need is much smaller: make this schema readable by those communities.

One document, two standards

An OO-LD document is at once a valid JSON Schema and a referenceable JSON-LD context. Nothing new is invented; two existing standards are put in one file.

That single move has an outsized effect. The same artefact validates an instance, generates typed code and a form, and expands that instance to RDF. There is no separate context to keep in sync, no generated copy that drifts, and no build step between the developer's view and the semantic view. A developer who never says the word "ontology" still produces linked data.

Tiered semantics

Where communities genuinely differ, the schema does not choose:

  • the default @context carries a consensus mapping, taken from general, widely deployed vocabularies (QUDT, DCAT, CSVW, PROV, schema.org). It is what a consumer gets by default, chosen because agreement is likeliest there;
  • every further reading is a per-term synonym under x-oold-context, carrying the mapping set it belongs to, the ontology it targets and the ontology version it was validated against;
  • selecting a mapping set promotes those synonyms into the context, producing an effective schema that differs from the declared one only in its @context.

The instance document never changes. Only its RDF reading does, and terms that a community has no term for fall back to the consensus reading rather than failing.

Because the synonyms carry SSSOM metadata, the mappings round-trip to a standard mapping set: they can be reviewed, cited and reused by people who never open a JSON Schema.

See it work

The smallest complete example is a quantity value, a number with a unit and an optional uncertainty. It is the building block reused by nearly every other schema, and it is contested enough between QUDT, EMMO and PMDco to exercise the whole mechanism.

  • QuantityValue, the base schema and the reasoning behind each decision
  • Time, the per-quantity subclass, with one instance shown in three community readings
  • Mapping profiles, the mechanism in general, including its limits

What this is not

It is not an ontology, and it does not compete with one. Ontologies define what things are, with far more expressivity than a schema can carry. These schemas describe how data is shaped and which ontology terms that shape corresponds to, in the subset that survives a round-trip through ordinary tooling. Where an ontology's structure cannot be reached by term mapping, that is stated plainly rather than papered over.