Skip to content

OO-LD Reference Schemas

Data is easy to serialize and hard to share. The structure travels fine, a CSV or a JSON file opens anywhere, but the meaning does not: the same quantity, process or dataset is modelled differently by every ontology, every schema language and every information system. Picking one ontology to settle it excludes everyone aligned with a different one.

This is not a problem peculiar to one field. A quantity with a unit means the same thing to a laboratory, a structural engineer, a manufacturer and a customs declaration, and each of them has a different vocabulary for it.

These are modular reference schemas written in OO-LD, where one document is at once a valid JSON Schema and a referenceable JSON-LD context. Structure and semantics live in a single source that ordinary developer tooling can consume, so the same schema validates a file, generates code and a form, and expands that file to RDF, instead of three artefacts drifting apart.

One syntax, several readings

The interesting part is what happens when two communities model the same thing differently. A schema here does not pick a winner:

  • the default @context carries a consensus mapping drawn from general, widely deployed vocabularies (QUDT, DCAT, CSVW, PROV, schema.org);
  • every further community mapping rides along as a per-term synonym under x-oold-context, tagged with the mapping set it belongs to and the exact ontology version it was validated against, and round-trippable to SSSOM;
  • selecting a mapping set promotes those synonyms into the context, so the same instance document exports as EMMO-flavoured or PMDco-flavoured RDF. Terms with no synonym in the selected set fall back to the consensus reading, so a partial alignment still works.

Nothing about the instance changes; only its RDF reading does.

Introduction with a worked example How the mapping works

What is here

Schemas are grouped into modules, each versioned and conformable on its own, so a consumer in civil engineering, manufacturing or trade can adopt quantities without taking on anything domain-specific. Domain modules sit on top of neutral ones rather than replacing them. See Modules for the full set and their status.

Each schema is published at a versioned, dereferenceable path, so a profile IRI resolves to the schema itself rather than only to a page about it:

https://w3id.org/oo-ld/schemas/quantities/1.0
  -> https://schemas.oo-ld.org/quantities/1.0/QuantityValue.schema.json

Because structure and semantics sit in one document, the schemas are also the source for generated assets: typed code bindings, schema-driven user interfaces, API descriptions, and the SSSOM mapping sets themselves.

Status

First iteration. The module structure is complete by design, but only representative examples are filled in, so the approach, the representations and the tooling can be discussed before the inventory is completed. quantities is the worked example; the other modules carry a scope note and are open for contribution, in any domain that shares the pattern.

Everything published here is checked in CI: schemas against the OO-LD meta-schema, instances against their schemas, and every mapping-set reading for a lossless round-trip through RDF.