Implement the subset you can support. Nothing more, nothing less.
OpenRiC profiles are named, bounded conformance targets. Each profile defines a fixed endpoint set, minimum field set, and SHACL shape set. A server declares which profiles it supports; consumers know exactly what to expect — and nothing more.
Why profiles
Before profiles, OpenRiC conformance was all-or-nothing — implement every endpoint and every entity type, or don’t claim OpenRiC at all. That suits exactly one kind of implementer: a fully-featured GLAM platform. It turns away everyone else — aggregators, authority services, viewers, legacy catalogues with a read-only window.
Profiles fix this. Each profile is a small, reviewable, badgeable commitment. An institution with a legacy catalogue claims Core Discovery and gets listed today. Over time they add Authority & Context, then Provenance, then Digital Object Linkage — every step a public, verifiable capability upgrade.
This is the pattern that turned IIIF from aspirational spec to eight-hundred-institution reality. OpenRiC is adopting it deliberately.
Profile catalogue
Core Discovery v0.30.0 normative
The minimum "I can be queried" claim. Ten read-only endpoints, three entity types, no graph traversal. Every OpenRiC server starts here.
Authority & Context v0.31.0 normative
Reconciliation-friendly identifiers for places, rules, and activities. The profile that turns a catalogue into a knowledge graph.
Provenance & Event v0.35.0 normative
Tightened Activity shapes: Production MUST carry results + participants + dates. Who did what to which record, when. Depends on Authority & Context.
Digital Object Linkage v0.33.0 normative
Concrete carriers of records — digital files, physical copies, checksums, MIME types — plus ISDF Functions. Optional POST /upload + thumbnail derivative for working catalogues.
Export-Only v0.36.0 normative
OAI-PMH v2.0 harvest (with the rico_ld prefix carrying full RiC-O JSON-LD) plus content-negotiated per-record dumps. Built for aggregators that already speak OAI-PMH.
Round-Trip Editing v0.34.0 normative
Write surface gated by API-key scopes (write, delete) with a public audit trail via /{type}/{id}/revisions. A client that mutated an entity can verify its own change landed.
Graph Traversal v0.32.0 normative
Cross-entity walks keyed to a root URI + depth. Plus full-graph SHACL shapes for hygiene: orphaned records, unlinked agents, duplicate identifiers, typed-link mismatches.
How profiles compose
Profiles are orthogonal, not hierarchical. A server can claim any subset — there is no “you must implement Core Discovery before you can claim Export-Only.” Some profiles have dependencies (Provenance depends on Authority & Context because activities reference agents), but within the dependency graph any combination is valid.
Profiles are also independent from conformance levels. A server can be Level 2 (API conformance) on Core Discovery and Level 1 (mapping conformance only) on Authority & Context. See Conformance §2 for levels.
Declaring a profile
Servers advertise supported profiles in the service description at GET /:
{
"name": "Your Service",
"version": "1.0",
"openric_conformance": {
"spec_version": "0.3.0",
"profiles": [
{ "id": "core-discovery", "version": "0.3.0", "level": "L2", "conformance": "full" }
]
}
}
The conformance probe reads this field, runs the profile-specific test subset, and emits a pass/fail report:
./probe.sh --profile core-discovery https://your-server/api/ric/v1
See Conformance for the full testing model.
What’s next
All seven profiles are normative as of v0.36.0. Core Discovery, Authority & Context, Graph Traversal, Digital Object Linkage, Round-Trip Editing, Provenance & Event, and Export-Only. The profile matrix is complete — subsequent work narrows to the v1.0 governance gates (a second independent implementation, an external institution committing to deploy, sustained non-maintainer contributors) rather than to more profile definitions. Provenance & Event is the one profile where the reference implementation’s serializer can emit the required shape but the backing data has gaps; see its §9 Q5 and the drift log for the honest accounting.
Comments on the profile framework or the Core Discovery draft are welcome at the GitHub Discussions.