OpenRiC inisiative (Open-source RiC)

[Johan Pieterse]

Good day all,

We would like to share progress from The Archive and Heritage Group on an open-source initiative to make RiC implementation practical, operational, and usable in real archival environments.

Through OpenRiC, we are building a RiC-native open-source architecture focused on linked archival context, graph services, semantic interoperability, mappings, validation, and standards-aligned implementation. OpenRiC is designed to support both standalone semantic scenarios and integration into production archival systems. (OpenRiC)

Alongside this, we have developed Heratio, where we have modernised the AtoM application layer in Laravel while keeping the established AtoM database. This allows us to retain the strength of the underlying archival data foundation while overcoming legacy application limitations and creating space for more advanced RiC-aligned development. (OpenRiC)

The result is a model where traditional archival description and RiC contextual rendering can coexist over the same data. Users can continue to work in familiar operational workflows, while the platform enables richer contextual relationships, graph exploration, semantic outputs, provenance-aware structures, and linked-data integration. (OpenRiC)

A current example in Heratio demonstrates this direction through the Egyptian Boat object, combining archival description, digital object management, and contextual provenance presentation in one interface. (Heratio)

We see this as part of a broader effort to move RiC from discussion into implementation through open-source collaboration. We would welcome engagement from others interested in RiC-O, modelling, mappings, RDF, graph infrastructure, interoperability, and archival system design. (OpenRiC)

OpenRiC: openric.org
Example: heratio.theahg.co.za/egyptian-boat

Demo: lou...@theahg.co.za / Password@123

[Arian Rajh]

This looks fantastic! Does it work by uploading RDF serialised descriptions (TTL files, for example)? 

Arian

Dr. sc. Arian Rajh, izv. prof. 

Poslano s mojeg iPhonea

10.04.2026., u 11:10, korisnik Johan Pieterse <pieters...@gmail.com> je napisao:



--
You received this message because you are subscribed to the Google Groups "Records_in_Contexts_users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Records_in_Context...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/ba64e950-de37-4bf3-919c-61f5a3d25254n%40googlegroups.com.

[Johan Pieterse]

Hi Arian

What Heratio does have:
- RiC-O ontology support via the ahg-ric package - it serializes archival descriptions into RiC JSON-LD (see RicSerializationService)
- Fuseki/SPARQL triplestore sync - the Fuseki settings allow connecting to an Apache Jena Fuseki instance where RDF triples are stored and queried
- SKOS import - the term taxonomy system (ahg-term-taxonomy) supports importing SKOS RDF/XML files (both file upload and remote URL), which is a RDF serialization
- JSON-LD export per record - individual records can be exported as RiC JSON-LD via /admin/ric/export/jsonld
- Semantic search with thesaurus/synonym expansion, which conceptually operates in linked-data territory

What it doesn't do (yet):
- There's no generic "upload a TTL/N-Triples/RDF-XML file and have it create archival descriptions" pipeline. The ingest wizard (ahg-ingest) handles CSV and file batch imports, not arbitrary RDF.
- The RiC sync is outbound (Heratio → Fuseki), not primarily inbound (TTL → Heratio records). Heratio is the source of truth; the triplestore is a derived index.
- There's no SPARQL endpoint exposed BY Heratio — it pushes to Fuseki, which then serves SPARQL queries externally.

I have logged an issue/future enhancement to add the ability to upload a TTL/N-Triples/RDF-XML file and have it create archival descriptions.

Regards

Johan

[Arian Rajh]

Dear Johan,

Thank you for the plans for this future enhancement. It would be useful and interesting to see.

Kindly,

Arian

To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/66f7a9c0-1313-4824-b707-99070d523e4en%40googlegroups.com.

[Richard Williamson]

Dear Johan,

Apologies for the slow reply! I think there is some redirection issue
with the OpenRiC link, but here is one which works for me currently:

https://ric.theahg.co.za/

Great to see initiative being taken in this direction, thank you for
taking it, and for sharing it! If I understand correctly:

1. You envision OpenRiC as an independent software layer which can be
combined with your product Heratio to provide RiC capability?
2. As of now, the RiC support added to Heratio via OpenRiC is an
automated translation from Atom to RiC? In particular, unless I'm
missing something, the GUI does not support 'adding RiC directly'?
This is slightly different to the question Arian asked about import:
even without import, one could imagine taking an Atom description,
convert it to RiC like you already do, and thereafter be able to add
further RiC to the description, but as I understand it this is not
currently possible.
3. From what I read, you see the state of affairs of 2. as temporary,
i.e. you intend to allow what I describe in 2., and at least in the
end maybe view the potentially-elaborated-upon RiC description as
primary?

I should say again, as I wrote in reply to your message introducing
the RiC view in Heratio a few weeks, that I think the latter is
exactly (part of) the kind of interface people would like to see,
especially the 2D and 3D graph views and the ability to 'drill down'
in them which you have implemented! So it's fantastic that you are
showing what is possible! Of course one would like to see 2. in a
system for working with RiC, but I imagine that the user interface
code for viewing RiC is coded in such a way that it is ready for this
if/when it arrives in your development :-).

I like the idea of standardisation of ways to implement RiC! Thank you
very much again for taking initiative! I am speaking for myself (not
EGAD), I think I would in the end ideally see standardisation at a
level which is not tied specifically to any one product such as
Heratio, even an open-source one. This may be too much to hope for,
and I certainly don't wish to dampen enthusiasm for your initiative or
any other one! But if one could abstract aspects of your code for
viewing RiC into some form of API standard which is de-coupled from
any particular implementation, and combine this with a standard for
translating Atom to this de-coupled API, I think that would be a very
beautiful development!

I.e. introduce concepts like '2D graph', '3D graph', node, etc, on an
'abstract' level, and view 'OpenRiC' (or something similar inspired by
it) as defining how to go from Atom to those concepts, allowing the
standard to be implemented in code in different ways. I am thinking of
something a bit like IIIF when it comes to the viewing-abstraction:

https://iiif.io/

Thoughts very welcome! But again, regardless, don't let my ramblings
get in the way at all of initiative-taking, thank you very much again
for setting the ball rolling!

Best wishes,
Richard

> To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/6686147E-34BB-471F-96CB-7CC837E24FBC%40gmail.com.

[Johan Pieterse]

Hi Richard,

Thank you - this is exactly the kind of feedback that makes an initiative stronger, not weaker, and I'm grateful you took the time to write at that length. The IIIF analogy got me thinking, and I think you are right.

Answering your three questions directly:

1. Yes - OpenRiC is intended as an independent software layer. Heratio is currently the only system that speaks it, but nothing in its design requires Heratio.
2. Yes, correctly observed. Today it is an automated translation from the AtoM-style archival description into RiC, surfaced through the 2D / 3D graph views. There is no UI yet for adding RiC assertions directly — neither on top of a translated description nor from scratch.
3. Yes, this is temporary. The roadmap already has direct RiC editing, triple-store persistence, and an eventual RiC-primary view across several phases. The current translation-only state is the first milestone, not the destination.

On your larger suggestion — standardisation at a level not tied to any one product — I agree, and I would like to act on it concretely rather than just nod along. My proposal:

Split OpenRiC into two artifacts.

- `openric-spec` - an implementation-neutral specification. Four documents: a mapping spec (AtoM / ISAD(G) / ISAAR(CPF) / ISDIAH → RiC-CM / RiC-O), a viewing API (REST + JSON-LD, in the spirit of IIIF Presentation API), a graph-primitives document defining abstract concepts like node, edge, cluster, drill, and a conformance test suite with JSON Schemas and fixture data. Spec licensed CC-BY 4.0.

- `heratio-openric` - Heratio becomes the reference implementation. The 2D / 3D viewer JS gets extracted as a standalone `@openric/viewer` package that can point at any OpenRiC-conformant server, not just Heratio. We prove the split is real by demoing the viewer against a non-Heratio backend (an AtoM adapter, most likely).

This reframes Heratio from "the product that owns the standard" to "the first and most complete implementation of an open standard" - which is a stronger position anyway, and a more honest one.

I would be grateful if, when the first drafts of the mapping spec and viewing API are ready (aiming ~4 weeks), you would be willing to read them and push back where they are wrong or over-fitted to Heratio. Entirely in a personal capacity - I'm not asking you to speak for EGAD, and I recognise the distinction. If you can also suggest one or two others whose eyes would improve the drafts, even better.

Regardless of how the spec work unfolds, thank you for the encouragement on the graph views. That part was genuinely fun to build, and knowing it resonates with people thinking about what a RiC-native interface could feel like is a real lift.

Thanks,
Johan

[Florence Clavaud]

Dear Johan,

 

After taking a quick first look, I think you should carefully review the mapping (https://openric.org/spec/mapping.html) where I could find many odd statements.

It's just a detail but in the sentence below:

"This specification defines a deterministic mapping from the traditional archival-description standards — ISAD(G), ISAAR(CPF), ISDIAH, ISDF — to the ICA’s Records in Contexts conceptual model (RiC-CM v1.0) and its ontology (RiC-O v1.0).", you quote RiC-O 1.0 but the link you provide refers to the latest version of RiC-O 1.1, which we recommend everybody uses. So I would suggest you mention RiC-O 1.1 there.

A lot of classes and properties that are listed in the mapping as being defined by RiC-O and having the RiC-O preferred namespace prefix (rico) do not exist in the ontology. For example: 

• Production, Accumulation, and SecurityClassification classes, etc.
• DateRange class (which was a class in RiC-O 0.2 and an entity on RiC-CM but does not exist any more)  and hasDateRangeSet property
• The properties wasAcquiredFrom, description, hasAppraisalInformation, hasInstantiation, hasFindingAid, hasLanguage, hasRecordPart, conformsTo, alternativeForm, hasPlace, performs, containsPersonalData, etc.

If, once you have reviewed this, some class or property does not exist in RiC-O but are needed in your project, you can of course create them, but as they would not be part of RiC-O they should be defined in an extension of RiC-O, which should have its own URI and namespace prefix (see on this topic https://ica-egad.github.io/RiC-AG/faq--how_to_extend_ric.html). If you consider some class or property you have in mind would be of general interest, you could ask that we add the class or the property to RiC-O (using this list or creating an issue on GitHuB - https://github.com/ICA-EGAD/RiC-O).

RiC-AG includes a mapping between EAD 2002 and RiC-O 1.1: https://ica-egad.github.io/RiC-AG/mappings.html; just in case you would like to have a look at it.

Best regards,

Florence Clavaud

Chair of EGAD

Lead of RiC-O development team

[Johan Pieterse]

Good day Florance

I did as you suggested and must admin I made a few mistakes.

We tried to be very strict this time and believe we came close to the real implementation requirements.

Regards

Johan