OpenRiC inisiative (Open-source RiC)
Johan Pieterse
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
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
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.
Arian Rajh
To view this discussion visit https://groups.google.com/d/msgid/Records_in_Contexts_users/66f7a9c0-1313-4824-b707-99070d523e4en%40googlegroups.com.
Richard Williamson
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