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.7.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.4.0 normative
Reconciliation-friendly identifiers for places, rules, and activities. The profile that turns a catalogue into a knowledge graph.
Graph Traversal v0.6.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.
Digital Object Linkage v0.7.0 normative
Concrete carriers of records - digital files, physical copies, checksums, MIME types - plus ISDF Functions. Optional POST /upload + thumbnail derivative for working catalogues.
Round-Trip Editing v0.7.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.
Provenance & Event v0.8.0 normative
Tightened Activity shapes: Production MUST carry results + participants + dates. Who did what to which record, when. Depends on Authority & Context.
Export-Only v0.10.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.
SPARQL Access v0.1.0 draft
Read-only SPARQL 1.1 query endpoint (/sparql, /sparql/info), public-read, rate-limited, Update rejected.
Governance v0.44.0 draft
The meaning layer - pinned standards, two-layer IRI policy, deprecate-not-delete stable IRIs, SHACL as a merge gate, versioned change process.
Portability v0.43.0 draft
Anti-lock-in - lossless JSON-LD/Turtle round-trip (proven by test), DCAT/VoID dataset descriptor + /changelog, optional validate-on-export.
Inferred-Provenance v0.43.0 draft
AI inference is never passed off as fact - prov:wasGeneratedBy + assertionStatus/confidence/receipt on machine assertions; absence ⇒ asserted fact.
Graph-Grounding v0.43.0 draft
Read-only GET /ground so any agent/RAG disambiguates against the graph; vector↔graph join on the public entity IRI; fail-open.
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.
Declaring a profile
Servers advertise supported profiles in the service description at GET /:
{
"name": "Your Service",
"version": "2.4.1",
"openric_conformance": {
"spec_version": "0.55.1",
"profiles": [
{ "id": "core-discovery", "version": "0.7.0", "conformance": "full" }
]
}
}
The conformance probe reads this field, runs the profile-specific test subset, and emits a pass/fail report:
BASE=https://your-server/api/ric/v1 bash conformance/probe.sh --profile=core-discovery
See Conformance for the full testing model.
What’s next7 profiles are normative and 5 are 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 normative set is stable; the drafts are open for comment. The path to v1.0 runs through the governance gates (a second independent implementation, an external institution committing to deploy, sustained non-maintainer contributors), not through 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 any profile are welcome: see Review OpenRiC, technical interoperability.