Adopt Records in Contexts (RiC) when your holdings have complex, overlapping relationships that a single-parent hierarchy distorts — records with multiple creators, shifting custody, or rich links to functions, people and places — and when you have the linked-data skills and infrastructure to exploit a graph model. Hold off when your collections are stable and hierarchical, your team lacks RDF experience, or you simply need clean, discoverable finding aids today. RiC is powerful but front-loads cost; the question is whether your sources actually need it.

What problem does RiC actually solve?

Traditional standards (ISAD(G), ISAAR, ISDF, ISDIAH) force records into a tree: one fonds, one creator, one parent. Reality is messier — a record series can be created by two successive agencies, relate to several functions, and document many places. RiC reconceives description as a graph: entities (Record, Agent, Activity, Place, Date) joined by typed relations. Multiple provenance, parallel custody and cross-collection links become natural rather than awkward workarounds.

RiC has two parts: RiC-CM, the conceptual model, and RiC-O, the OWL ontology you implement in RDF.

When is RiC the right call?

Strong positive signals:

• Multiple or shifting provenance — agencies that merged, split or transferred functions.
• Linked-data ambitions — you want to publish to the LOD cloud or query across datasets with SPARQL.
• Dense interrelations — people, organisations, places and events you want to traverse, not just list.
• Cross-repository discovery — federating with other graph-described holdings.

Weak or negative signals:

• Small, stable, single-creator collections.
• A team with no RDF/SPARQL experience and no time to acquire it.
• A near-term deadline to get finding aids online.

adopt_RiC = (complex_provenance OR linked_data_goal)
            AND has_rdf_skills
            AND not deadline_driven_basic_access

How does RiC compare with ISAD(G) for daily work?

Dimension	ISAD(G)	RiC
Data shape	Hierarchy (tree)	Graph (entities + relations)
Multiple provenance	Awkward, via notes	Native
Skills needed	Cataloguing	Cataloguing + RDF/ontology
Tooling maturity	High (AtoM, CALM, ASpace)	Partial, emerging
Querying	Browse, search	SPARQL graph queries
Best for	Stable, well-bounded fonds	Complex, interlinked, LOD-bound

ISAD(G) is not "wrong"; it is a good fit for a large share of real collections. RiC earns its keep on the hard cases.

What does adoption actually cost?

Be honest about the bill:

1. Training — staff need RDF, the RiC-O ontology, and graph thinking.
2. Infrastructure — a triplestore (GraphDB, Blazegraph) or graph database, plus modelling tools like Protégé.
3. Migration — converting EAD/ISAD(G) to RiC-O is non-trivial; mappings exist but need curation.
4. Maintenance — graph data with weak governance becomes inconsistent fast.

This is why a phased approach makes sense: model conceptually in RiC-CM first, keep producing ISAD(G)/EAD for access now, and convert when tooling and skills mature.

How do I pilot RiC without betting the institution?

A low-risk path:

1. Pick one complex, well-understood collection — ideally one where hierarchy already hurts.
2. Model it in RiC-CM on paper: list entities and the relations you care about.
3. Express a slice in RiC-O RDF and load it into a triplestore.
4. Write 3–4 SPARQL queries that answer questions ISAD(G) could not.
5. Evaluate honestly: did the graph reveal something, or just add overhead?

If the pilot answers real research questions, scale up. If it does not, you have spent a small budget to learn that ISAD(G) still serves you.

Key Takeaways

• RiC models records as a graph (RiC-CM + RiC-O), making multiple provenance and rich relations native.
• Adopt it for complex, interlinked holdings and linked-data goals — not for small, stable, hierarchical collections.
• It requires RDF/ontology skills and graph infrastructure; budget for training, tooling and migration.
• ISAD(G) remains the dominant working standard; RiC is the successor direction, not an instant switch.
• Pilot on one hard collection before any institution-wide commitment.
• The decision hinges on your sources' relationships and your team's skills, not on novelty.

Frequently Asked Questions

What is Records in Contexts (RiC)?

RiC is the ICA's standard that unifies ISAD(G), ISAAR, ISDF and ISDIAH into a single conceptual model (RiC-CM) and ontology (RiC-O). It describes records as a graph of entities and relations rather than a fixed hierarchy.

Does RiC replace ISAD(G)?

It is designed as the successor framework, but adoption is early and ISAD(G) remains dominant in working catalogues. Plan for RiC as a direction of travel, not an overnight replacement.

Do I need to be a graph database expert to use RiC?

To exploit RiC fully you need RDF, an ontology, and ideally a triplestore or graph database — so yes, real linked-data skills help. You can model in RiC-CM conceptually first without that stack.

Can RiC represent multiple provenance?

Yes, and this is one of its main advantages. Because relationships are first-class, a record can connect to several creators, functions and contexts without the single-parent constraint of a strict hierarchy.

What tools support RiC today?

Support is maturing: RiC-O is published as an OWL ontology, and projects use tools like Protégé, triplestores (GraphDB, Blazegraph) and converters from EAD. Mainstream catalogue software support is still partial.

Is it worth adopting RiC for a small repository?

Usually not yet. The payoff comes from complex, interrelated holdings and linked-data ambitions. A small, stable collection is better served by solid ISAD(G) or DACS description for now.

Related reading

• How to Choose ISAD(G) vs DACS
• Beginner's Guide to Authority records with ISAAR
• An introduction to linked open data for heritage
• An introduction to CIDOC CRM
• Write SPARQL queries