JSON-LD mappings
Per-overlay JSON-LD @context files that map each overlay's JSON property names to ontology terms. Bridges the JSON-Schema world to the RDF world.
The Content negotiation page
in the Ontology manual covers the HTTP-layer side: how
Accept: application/ld+json requests against
https://w3id.org/opda/<resource> URIs resolve to JSON-LD responses,
and which named graphs back those responses. This page covers the authoring of the
@context files that make JSON-LD round-tripping work.
This is a stub for upcoming work. The structure below is what we plan to populate; existing artefacts in source/ that feed it are cited inline.
What already exists
PDTF has already started JSON-LD work — see source/03-standards/trust-framework/public/contexts/.
That gives us an upstream baseline; the new work is to author overlay-specific contexts that map BASPI / TA6 / etc. property names to ontology terms.
Approach
- For each overlay (BASPI v5 first), author a
@contextmapping JSON property names → RDF terms. - Resolve cross-context concepts via
skos:exactMatchwhen same meaning, distinct classes when different meaning. - Validate by round-tripping: JSON instance → RDF → JSON, asserting equivalence.
- Publish contexts at stable URLs under
trust.propdata.org.uk/contexts/for production use.
Worked example (BASPI v5 — first overlay)
BASPI v5 is the candidate for end-to-end worked example because:
- Most active overlay (current HBSG standard)
- Has explicit human-readable spec from HBSG (the BASPI v5 doc)
- Maps to schema.org concepts cleanly for most properties
Targets
Output folder: source/00-deliverables/semantic-models/mappings/.
baspi5-context.jsonld— first mapping (anchor example)ta6-context.jsonld— secondnts2-context.jsonld— third (and tracks MHCLG successor)...one per overlay
Comments