Skip to content

Overlays Capture Architecture (OCA)

OCA takes the opposite approach to a single unified document: a minimal capture base carries attribute names and core data types, and separate, content-addressed (SAID) overlays add labels, formats, units, encodings and mappings. OO-LD folds those concerns into one schema; the overlay types have direct OO-LD counterparts.

OCA (capture base + label and conformance overlays, abbreviated)

{
  "capture_base": {
    "type": "spec/capture_base/1.0",
    "attributes": { "full_name": "Text", "date_of_birth": "DateTime" }
  },
  "overlays": {
    "label": { "attribute_labels": { "full_name": "Full name", "date_of_birth": "Date of birth" } },
    "conformance": { "attribute_conformance": { "full_name": "M", "date_of_birth": "O" } }
  }
}

OO-LD Schemas (modular, mirroring the overlays)

OO-LD composes with $ref plus a remote @context (see the guide's Composition section), so OCA's overlay structure maps directly onto cross-referencing OO-LD schema modules: a base capture schema carries the structure and core types, and each overlay becomes a small schema that references the base and contributes exactly one concern (labels, a localized label set, semantics, formats) - the same distributed-authorship pattern as OCA overlays.

Base capture schema (structure and core types only):

{
  "$id": "Person.capture.schema.json",
  "type": "object",
  "properties": {
    "full_name": { "type": "string" },
    "date_of_birth": { "type": "string", "format": "date" }
  },
  "required": ["full_name"]
}

Label overlay - references the base and sets only labels (a second, differently-labelled overlay is just another such module):

{
  "$id": "Person.label-en.schema.json",
  "allOf": [{ "$ref": "Person.capture.schema.json" }],
  "properties": {
    "full_name": { "title": "Full name" },
    "date_of_birth": { "title": "Date of birth" }
  }
}

Semantics overlay - references the base and adds only the @context:

{
  "$id": "Person.semantics.schema.json",
  "@context": { "schema": "http://schema.org/", "full_name": "schema:name", "date_of_birth": "schema:birthDate" },
  "allOf": [{ "$ref": "Person.capture.schema.json" }]
}

The same concerns MAY also be consolidated into one OO-LD document when modularity is not needed; both forms are valid OO-LD.

OCA overlay OO-LD
capture base attribute + data type properties.<name> with type / format
label overlay title (and x-oold-multilang-title for languages)
conformance overlay (M/O) required
unit / format / encoding overlay format, x-oold-ui-*
attribute mapping overlay @context term IRI
a whole overlay object a schema module that $refs the base and adds one concern

The key difference is identity and semantics: OCA addresses overlays by content hash (SAID) and reaches meaning only through a separate attribute-mapping overlay, whereas OO-LD modules are addressed by resolvable $id and carry the IRIs natively in @context. When patching a schema owned elsewhere rather than layering new modules, OO-LD's own overlay delivery (OpenAPI Overlay actions for x-oold-ui-*) provides the "patch without editing" pattern.