One graph, many projections.

Each type answers a different question, works under a different logical regime, and therefore lives in its own file — even when they describe the same concept.

Likewise, controlled values — policy:PolicyStatus, claim statuses, perils, lines of business — are SKOS concept schemes, not OWL classes. They change on a business cadence (new peril codes) independent of the model, so they live in their own vocabulary/ files and are referenced by both the ontology (as ranges) and the shapes (as sh:in value sets).

Two axes compete: group by module (everything about Policy together) or by artifact type (all shapes together). The artifacts have very different import scopes and lifecycles — the TBox is imported everywhere; shapes and samples are imported nowhere — so the top level is organized by type. Cohesion is recovered through a shared filename stem, so one grep policy.* finds every artifact for a module.

This is an evolution of the current fnd/ ins/ misc/ resource/ layout: misc/→competency/, resource/→samples/, and the new vocabulary/ shapes/ context/ trees. The IRI schemes extend the ones already in use:

The existing header directives (# baseURI / # prefix / # imports) and owl:versionIRI conventions carry over unchanged — they remain the metadata that must mirror the real owl:imports.

All authored artifacts are RDF, and RDF has several serializations. We author every one of them in Turtle and treat that as the source of truth. The reasoning:

Because all five artifacts share the RDF substrate, a single format for all of them keeps the mental model and the tooling uniform: the same editor, the same diff, the same loader for a shape, a code list, a CQ, and a sample. Turtle is the authoring surface; any other serialization a consumer needs is produced by conversion, losslessly.

JSON-LD is JSON that is RDF. A @context maps ordinary JSON keys to ontology IRIs, so an application developer consumes idiomatic JSON while the payload remains a precise RDF graph. That makes JSON-LD the format of the boundary — where the semantic core meets applications that speak JSON — not of the core itself.

The same graph, two serializations

@prefix policy: <…/ontology/ins/policy/> .
@prefix res: <…/resource/> .

res:policy/PN-100
  a policy:Policy ;
  policy:policyNumber "PN-100" ;
  policy:producer     res:party/acme ;
  coverage:hasCoverage res:cov/c1 .

{
  "@context": "…/context/policy.jsonld",
  "id": "…/resource/policy/PN-100",
  "type": "Policy",
  "policyNumber": "PN-100",
  "producer": "…/resource/party/acme",
  "hasCoverage": "…/resource/cov/c1"
}

Both expand to the identical triples. The bridge is the context — itself a small, versioned, generated artifact that maps friendly keys to ontology terms:

// context/policy.context.jsonld — generated from policy.ttl, served at a stable URL
{
  "@context": {
    "policy":   "https://data.chubb.com/ontology/ins/policy/",
    "coverage": "https://data.chubb.com/ontology/ins/coverage/",
    "id": "@id", "type": "@type",
    "Policy":        "policy:Policy",
    "policyNumber":  "policy:policyNumber",
    "producer":     { "@id": "policy:producer",      "@type": "@id" },
    "hasCoverage":  { "@id": "coverage:hasCoverage", "@type": "@id" }
  }
}

In practice a single resource is served in either format by content negotiation: Accept: text/turtle returns the Turtle, Accept: application/ld+json returns the JSON-LD — two projections of one stored graph, so they can never disagree.

Five artifacts describing the same concepts will drift unless drift is made to fail loudly. Two mechanisms enforce it: a dependency direction (derived artifacts point at the ontology, never the reverse) and an executable check for every dependency, run in CI.

The dependency rules & their enforcement

The CI pipeline that runs those checks

There is no CI committed today — adding this pipeline is the single highest-leverage step. Loading all modules into one graph at the “merge” stage is what catches dangling IRIs and orphan imports (the kind of defect the identifier.ttl orphan represents).

Governance: one change obliges its dependents

The rules become a PR checklist. Adding a property is never a one-file edit — it cascades:

• Ontology — declare the property, its domain/range, axioms.
• Shapes — add/adjust the constraint that governs it.
• Vocabulary — if its values are enumerated, add the code list.
• Competency question — add the CQ that justifies it (or it shouldn’t exist).
• Sample — extend a fixture so the CQ has data to bind.
• Context & docs — regenerate; bump owl:versionInfo.

Modules are versioned together via owl:versionIRI/versionInfo; a tagged release bundles version-stamped files, with the matching JSON-LD contexts and generated docs shipped alongside so a consumer of version N gets a context that agrees with ontology N.

The whole design in one sentence: author every artifact once, in Turtle, as RDF; let competency questions prove they agree; and project to JSON-LD only at the edge, from a generated context that is versioned with the model.