EAD to RiC-O Mapping

Last updated: 2026-03-25 12:11:56

Mapping EAD to RiC-O

This is the most requested feature in the RiC community. AtoM/Heratio provides automated mapping from EAD/ISAD descriptions to RiC-O triples.

Field Mapping

EAD Element ISAD Field RiC-O Property
<unittitle> Title rico:title
<unitdate> Date(s) rico:hasCreationDate
<unitid> Reference code rico:identifier
<origination> Name of creator rico:hasCreator → Agent
<scopecontent> Scope and content rico:scopeAndContent
<accessrestrict> Conditions of access rico:conditionsOfAccess
<physdesc> Physical description rico:physicalCharacteristics
<repository> Archival institution rico:hasOrHadHolder
<bioghist> Administrative history rico:history

Hierarchy Mapping

EAD Level RiC-O Type
Fonds rico:RecordSet
Series rico:RecordSet (child)
File rico:Record
Item rico:Record or rico:RecordPart

How AtoM/Heratio Handles This

When an archival description is created or edited in AtoM/Heratio, the RiC sync service automatically: 1. Creates RiC-O triples from the description fields 2. Links to creator agents via rico:hasCreator 3. Establishes hierarchy via rico:isPartOf 4. Syncs to the Fuseki triplestore

Integration with Other Systems

Any archival system that produces EAD or ISAD-compliant descriptions can integrate with the RiC layer. The mapping is standards-based and system-agnostic.

How Other Systems Can Integrate

System Integration Method
AtoM/Heratio (AtoM functionality built on Laravel) Native - automatic sync via event listeners
ArchivesSpace EAD export → RiC mapping pipeline
Archivematica METS/PREMIS → RiC Instantiation mapping
CollectiveAccess REST API → RiC triple generation
Fedora/Islandora RDF native - direct RiC-O ontology alignment
DSpace Dublin Core → RiC-O property mapping
Custom systems SPARQL endpoint + RiC-O vocabulary

Integration Approaches

1. Direct SPARQL Federation

Systems with their own triplestores can federate queries across institutions:

SELECT ?record ?title ?holder WHERE {
  SERVICE <https://other-archive.org/sparql> {
    ?record rico:title ?title .
    ?record rico:hasOrHadHolder ?holder .
  }
}

2. EAD/EAC Harvest and Convert

Export EAD XML from any system, then run through the RiC mapping pipeline:

  1. Export EAD 2002 or EAD3 from the source system
  2. Apply the XSLT transformation (AtoM/Heratio provides this)
  3. Load resulting RiC-O triples into your Fuseki/triplestore
  4. Query across all holdings via SPARQL

3. REST API Integration

AtoM/Heratio exposes RiC data via REST:

  • GET /admin/ric/data?id={recordId} - graph data for a record
  • GET /admin/ric/autocomplete?q={term} - search across RiC entities
  • GET /admin/ric/ajax-stats - triplestore statistics

4. Linked Data Publishing

Publish your RiC triples as linked data so other institutions can discover and link to your records:

  • Use content negotiation to serve RDF/XML, JSON-LD, or Turtle
  • Register your SPARQL endpoint with aggregators
  • Link agents to Wikidata/VIAF for cross-institutional discovery

How to Handle RiC in Your System

Minimum viable RiC implementation:

  1. Model records as rico:RecordSet / rico:Record - map your hierarchy
  2. Model creators as rico:Agent - link via rico:hasCreator
  3. Add rico:title, rico:identifier, rico:date - core descriptive properties
  4. Store in a triplestore - Fuseki for development, GraphDB/Stardog for production
  5. Expose a SPARQL endpoint - enables federation and discovery

Full RiC implementation adds:

  • rico:Instantiation for digital/physical carriers
  • rico:Place, rico:Activity, rico:Function for contextual entities
  • Provenance chains via rico:hasProvenanceOf
  • Temporal modelling with rico:Date entities
  • Vocabulary types (DocumentaryFormType, CarrierType, etc.)
  • SHACL validation for data quality assurance

Comments (0)

Log in or register to leave a comment.
On this page