Part of specification v0.55.1. Earlier versions are preserved as tagged releases.

OpenRiC Profiles

Last revised in: v0.50.2

1. Purpose

A profile is a named subset of the OpenRiC spec a server can claim conformance to. Profiles bound expectations. Instead of a single monolithic “OpenRiC-conformant” claim (all endpoints, all entity types, all write verbs), each profile defines a capability axis with a fixed endpoint set, minimum field set, and SHACL shape set.

Design inspiration: the way IIIF Presentation API separates into Level 0 / 1 / 2, and the way OGC WMS defines named conformance classes. Both patterns have the same effect - they let implementations opt in at their current capability without over-claiming.

2. Profiles are the conformance unit

A server declares the profiles it supports, each at a profile version. There is no second dimension: the four conformance levels (L1 to L4) of earlier versions are legacy, described only in the appendix of Conformance. The 12 profiles are listed in §6.

3. Composition rules

Profiles are additive, not hierarchical. Authority & Context is not a superset of Core Discovery; they are orthogonal. A server may implement any subset.
Dependency declarations. Some profiles have hard dependencies - for example, Provenance & Event depends on Authority & Context because Activity entities carry rico:hasOrHadParticipant references. A profile document lists its dependencies; declaring a profile without its dependencies is a conformance failure.
Forbidden-field rule. A response under one profile MUST NOT emit fields from a profile the server does not claim. A Core-Discovery-only server that emits rico:isOrWasSubjectOf edges lies about its capabilities and fails conformance.

4. Versioning

Each profile has its own version, independent of the specification version (Core Discovery Q8). A profile’s version changes only when the profile changes; the profile page and §6 show both the profile version and the specification release that last revised it. What a change bumps, and when a release may break a conformant server, is set by change control.

5. Declaration

Servers declare supported profiles in the service description at GET /:

{
  "name": "Example Archive Catalogue",
  "version": "2.4.1",
  "openric_conformance": {
    "spec_version": "0.55.1",
    "profiles": [
      {
        "id": "core-discovery",
        "version": "0.4.0",
        "conformance": "full"
      }
    ]
  }
}

Field	Meaning
`id`	Profile identifier, kebab-case, from the profile catalogue below
`version`	Profile version the server targets
`conformance`	`"full"` or `"partial"`; if partial, a `"notes"` field is required

Consumers MUST read this field before issuing any requests that depend on a specific profile’s endpoints.

6. The profiles

Profile	Status	Scope
Core Discovery	normative · v0.7.0	Read-only Records, Agents, Repositories, vocabulary, autocomplete. The minimum “I can be queried” claim.
Authority & Context	normative · v0.4.0	Places, Rules, Activities as first-class entities with reconciliation-friendly identifiers.
Graph Traversal	normative · v0.6.0	`/graph`, `/relations`, `/hierarchy` - cross-entity walks plus full-graph SHACL hygiene shapes.
Digital Object Linkage	normative · v0.7.0	Instantiation carriers (MIME, checksums, extent, record-backlinks) plus ISDF Functions. Optional `POST /upload` + thumbnail derivative.
Round-Trip Editing	normative · v0.7.0	Full write surface - POST/PATCH/DELETE on every entity + relations, gated by API-key scopes, with a public audit trail via `/{type}/{id}/revisions`.
Provenance & Event	normative · v0.8.0	Tightened Activity shapes - Production/Accumulation/Activity with required results, participants, dates. Depends on Authority & Context.
Export-Only	normative · v0.10.0	OAI-PMH v2.0 harvest (`oai_dc` + `rico_ld`) plus content-negotiated per-record JSON-LD / Turtle / RDF-XML dumps.
SPARQL Access	draft · v0.1.0	Read-only SPARQL 1.1 query endpoint (`/sparql`, `/sparql/info`), public-read, rate-limited, Update rejected.
Governance	draft · v0.44.0	The meaning layer - pinned standards, two-layer IRI policy, deprecate-not-delete stable IRIs, SHACL as a merge gate, versioned change process.
Portability	draft · v0.43.0	Anti-lock-in - lossless JSON-LD/Turtle round-trip (proven by test), DCAT/VoID dataset descriptor + `/changelog`, optional validate-on-export.
Inferred-Provenance	draft · v0.43.0	AI inference is never passed off as fact - `prov:wasGeneratedBy` + `assertionStatus`/confidence/receipt on machine assertions; absence ⇒ asserted fact.
Graph-Grounding	draft · v0.43.0	Read-only `GET /ground` so any agent/RAG disambiguates against the graph; vector↔graph join on the public entity IRI; fail-open.

7 profiles normative, 5 in draft. Normative: Core Discovery, Authority & Context, Graph Traversal, Digital Object Linkage, Round-Trip Editing, Provenance & Event, Export-Only. Draft, open for comment: SPARQL Access, Governance, Portability, Inferred-Provenance, Graph-Grounding. The v0.43 governance-line drafts were each ported from a working Heratio reference implementation. v1.0 has one gate: a second implementation, built outside AHG, passes the probe for at least one profile. Institutional deployment and outside contributors are maturity goals, not v1.0 conditions (governance).

7. Conformance testing

The conformance/probe.sh script (shipped in this repo) supports profile-scoped testing:

BASE=https://ric.theahg.co.za/api/ric/v1 bash conformance/probe.sh --profile=core-discovery

The probe reads the server’s declared profiles at GET /, runs the endpoint-specific checks for each, and emits a pass/fail report per profile per endpoint. A server that declares a profile but fails any of its required endpoints fails conformance for that profile, regardless of what it does elsewhere.

8. Why profiles matter strategically

Without profiles, OpenRiC is a fixed bar - “you implement all of it or you don’t implement it.” That suits exactly one kind of implementer (a fully featured GLAM platform) and turns away every other kind (aggregators who only harvest, authority services that only publish agents, viewers that only need read, legacy systems that can expose a subset).

With profiles, OpenRiC becomes a growth path. An institution with a legacy catalogue exposes Core Discovery and gets listed. Over time they add Authority & Context, then Provenance, then Digital Object Linkage. Each step is a small, reviewable, badgeable commitment rather than an all-or-nothing decision. That is how IIIF went from aspirational spec to eight-hundred-institution reality, and it is the shape OpenRiC is adopting deliberately.