In this paper we describe the EPISA Platform, a technical infrastructure designed and developed to support archival records management and access using linked data technologies. The EPISA Platform follows a client-server paradigm, with a central component, the EPISA Server, responsible for storage, reasoning, authorization, and search; and a frontend component, the EPISA ArchClient, responsible for user interaction. The EPISA Server uses Apache Jena Fuseki for storage and reasoning, and Apache Solr for search. The EPISA ArchClient is a web application implemented using PHP Laravel and standard web technologies. The platform follows a modular architecture, based on Docker containers. We describe the technical details of the platform and the main user interaction workflows, highlighting the abstractions developed to integrate linked data in the archival management process. The EPISA Platform has been successfully used to support research and development of linked data use in the archival domain in the context of the EPISA project.
Linked Data is a broad concept describing both a set of design principles and a set of
specific technologies that have the goal to improve data management and access, specifically by
contributing to data description and data integration. The term linked data was coined by
Tim-Berners Lee in 2006 in the context of the semantic web project [
Archival records management presents itself as a complex information context where linked data has the potential to impact at diferent levels, from record creation and description, to record access and exploration. The EPISA Project1 is a Portuguese funded project that explores this opportunity to develop standards, processes, and technologies to support linked data use in the ⋆This work is financed by National Funds through FCT - Foundation for Science and Technology I.P., within the CEUR Workshop Proceedings archival record management context. A key piece of the project is the technical infrastructure that supports linked data storage, management, and overall user interaction.
In this paper we describe the EPISA Platform, the computational infrastructure developed
to support the use of linked data in the archival records management context. Among the
obstacles hindering the use of linked data technologies is the lack of tools, specifically software
and resources [
The remaining of this paper is organized as follows. In Section 2 we survey existing solutions and examples of computational infrastructures designed to support linked data use in the archival domain. Section 3 presents a high-level view of the EPISA Platform, which adopts a client-server model composed by the EPISA Server, presented in Section 4, and the EPISA ArchClient, a web application designed to support user interaction and presented in Section 5. In Section 6 we highlight two use cases to showcase the application of the linked data paradigm to records management, specifically record creation and description, and record navigation. Finally, the conclusions and future work perspectives are presented in Section 7.
In this section we identify works that detail the technical aspects of solutions developed to support linked data use in the context of archival records management systems. The majority of the existing works focus on exposing information as linked data, and ofering views to query and navigate record collections, not focusing on the process of creating linked data.
Wikibase2 is the software that supports Wikidata, an open, large-scale, collaborative,
knowledge base designed to manage “factual information”. As of May 2022, Wikidata contains nearly
100 million items3. Wikibase is also used to support other knowledge bases, including archival
contexts (e.g., German National Library, Europeana)4. Diefenbach et al. [
metaphactory is a commercial software platform designed to support knowledge graph
applications [
the data layer, making the platform independent of specific database management systems. At
the user interface level, a customizable templating mechanism is used. In the EPISA Platform
we also use programmable user interfaces to easily accommodate diferent data representations.
methaphactory showcases a wide list of application deployments, including ResearchSpace [
Our work contributes to the state of the art by presenting and describing a platform to support linked data storage and management, querying and visualization, and data authoring through graphical user interfaces. Our work is supported on open technologies and planned to be released using an open license.
The EPISA Platform architecture, depicted in Figure 1, consists of two main components – the EPISA Server and the EPISA ArchClient. The platform adopts a client-server paradigm between these components, at a lower level, it follows a microservice oriented architecture as both components constitute a group of independent services.
The EPISA Server is responsible for storing and performing reasoning over the archival data, manage access to the data, and to provide an efective search mechanism. These duties are handled by the diferent microservices contained in the component. Storage and reasoning is performed by an Apache Jena service, and the search aspects are implemented with an Apache Solr instance. Additionally, a Spring Boot application acts as a middleware and connects to the storage and search services. Ultimately, it provides a gateway for external componets to access the EPISA Server’s features.
The EPISA ArchClient is a web application responsible for providing an interface for archivists to access, manage and describe collections of archival records, using the components implemented by the EPISA Server. The ArchClient is composed of a Laravel application, that serves both the frontend and the backend of the provided web application.
As the platform’s underlying architecture follows a microservice strategy, the services are implemented and deployed as individual Docker containers. Each of the aforementioned services is an instance of a Docker image running in its own environment. However, the services share a network that allows them to communicate with each other. This comunication, at the component level, is mediated by the middleware service that provides a REST API to perform all actions and operations that the EPISA-Server yields. Through this API, the ArchClient, as its only client, is able to search for, access, create and curate archival records and the entities that are mentioned in them.
In the following sections we detail both components, as well as their underlying services.
The EPISA Server component comprises three microservices to deliver its several features: Apache Jena Fuseki, a SPARQL server responsible for data storing and reasoning; Apache Solr, the search platform; and a Spring Boot application for managing authorization. This section fully depicts each of these microservices and the middleware that connects them.
The EPISA Server incorporates a Spring Boot application that acts as a middleware to connect the remaining microservices, Apache Jena Fuseki and Apache Solr. Figure 1 demonstrates how the microservices in the EPISA Server are internally connected, and also the connection between the EPISA Server and the EPISA ArchClient. The middleware is the component responsible for managing the interaction with the clients of the EPISA Server component, through the EPISA Client API it implements. Moreover, the middleware also connects to the Apache Solr service through the use of the SolrJ API and to the Apache Jena Fuseki through the several APIs provided by the Apache Jena framework. Details on the Apache Jena Fuseki and Apache Solr services can be found in the next subsections.
As the core element of the EPISA Platform, the middleware needs to complete a sequence of
operations and interactions with the other microservices to kickstart the platform and to enable
the distribution of the features it maintains. This process is depicted in Figure 2 where we
can identify multiple stages: Stage 1 corresponds to the migration of records to the ArchOnto
ontology [
comprises the creation of internal identifiers. Even though the ArchOnto ontology describes a schema for representing identifiers of documents, events, and entities, such identifiers are from within the context of the archival description. For this, they may not ensure the properties needed for the proper functioning of the EPISA Server component. The EPISA Server requires a guaranteed unique and individual identifier for each document, event, and entity object present in the system. To fulfill this condition, the middleware generates a unique identifier to attribute to each document, event and entity using Java’s UUID library6 and appends it to the model. In Stage 4, documents, events and entities are indexed in the Apache Solr service. This process is described in Section 4.3; Stage 5 and 6 represent the initialization of the EPISA Client API and the operations performed upon the arrival of an HTTP request from the EPISA ArchClient.
The EPISA Client API is responsible for making all the features of the EPISA Server available
over HTTP. Table 1 contains a short description of the endpoints available in this API. The
responses provided by this API are in JSON format. In the case of an archival record, the JSON
response is structured into five diferent sections: identity, context, access and use conditions,
linked resources, and linked data. These sections are based on ISAD(G) areas of descriptive
information [
record identify its physical location, technical requirements related to its physical condition, language and access conditions. The linked resources zone identifies the resources linked to a determined entity or archival record. Lastly, the linked data zone identifies archival records and entities related to a specific archival record or entity.
As the EPISA Platform brings linked data concepts into the archival domain, all the data from the archival records is stored in the form of RDF triples. A native triplestore was adopted for data storage, specifically Apache Jena 7 was choosen since it is an open-source, high-performance solution, with a frequent release cycle, and supports a rich set all of APIs to process RDF data. For querying and updating the RDF data, Apache Jena Fuseki is being used for exposing the RDF data as a SPARQL endpoint accessible over HTTP, providing REST-style interaction with the underlying data.
Additionally, the Eclipse RDF4J framework8 is used by the middleware to create SPARQL queries programmatically, particularly the SparqlBuilder API, which eases the process of querying the Fuseki service to obtain data. Moreover, Apache Jena also supports inference over the stored triples, a fundamental process when dealing with RDF data and OWL. Apache Jena comes with several reasoners that difer on the level of reasoning provided. The reasoner currently being used is the OWL Micro reasoner, layered on top of the datasets belonging to the Fuseki service. Table 2 shows the constructs supported by the OWL Micro Reasoner that provide the inference support for the EPISA Platform.
Apache Solr9 is used to implement the keyword-based search engine in the EPISA platform. A Solr Docker container is initialized with two diferent cores (i.e., indexes), one to index the archival records and other to index the entities (people, places, organizations, and events). The indexing process is started once the data is loaded to the triplestore and the Fuseki service obtains all the necessary information about each record or entity. When there is the need to search for information, the search keywords are matched against the indexes in the Solr cores to retrieve the matching results. At the user interface level, search results are presented separately in two rankings, one for records, and another for entities.
As the archival records and entities in the EPISA platform are described using the ArchOnto ontology, the indexing process relies on the specificities of that model to provide more accurate results, for example, by indexing specific properties and relations. The information indexed refers to archival records’ and entites’ identity, linked data and linked resources zones. It also expands ArchOnto properties and classes by parsing and translating them to Portuguese, allowing more complex searches and the use of the Portuguese language.
Figure 3 shows an RDF subgraph with a partial representation of the birth of Person1. In this case, when indexing information about Person1, the linked entity Birth1 will be expanded. By doing so, Person2 and the property P96 by mother will be associated to Person1 in the index. Moreover, the properties P98 by mother and P96 was born will also be translated to portuguese so that the search for the birth or the mother of Person1 can be done in portuguese. In the case of Person2, the reverse will happen and Person1 will also be associated to its index as a child.
The EPISA ArchClient is a web application that provides archivists an interface to access, manage and describe collections of archival records and entities such as people, places, groups, organizations, and events supported by the records being described. It intends to exploit the capabilities of connecting information and concepts that linked data concepts and technologies provide, and thus provide increased detail in the representation of archival information.
The ArchClient is implemented using Laravel10, a full stack, open-source PHP web framework. The option for this framework is justified by the requirement of having a light, low demanding web application on the client side. Therefore, both the frontend and the backend of the provided web application are implemented with Laravel and standard web technologies. The web application implements the Model-View-Controller pattern, a common approach in web frameworks that Laravel’s guidelines lightly enforce. Despite this, the application comprises only two main components, the View and the Controller components. In this case, given that the data is held and pulled from the EPISA Server component through HTTP requests to the EPISA Client API, the Model component is not implemented. Instead, the EPISA Server acts as the application’s Model by being responsible for, among other tasks, the storage of the data required by the ArchClient. The web application’s implemented components are the typical View and Controller components of an implementation of the MVC pattern.
The Controller is assigned with the duty of implementing the logic of the application, more specifically the actions that need to be executed according to the requests and input received from the View. Thus, this component’s main tasks are handling and routing the View’s requests, validating the input attached to them and performing the required HTTP requests to the EPISA Server component’s Client API. The View is responsible for defining the actual frontend of the application. In its implementation in the ArchClient we used a PHP templating engine in Blade for producing and structuring the application’s pages and TailwindCSS libraries11, CSS, and plain JavaScript to style and enhance them.
For the event’s view, as the attributes are event type specific, a programmable user interface was developed. This interface constructs its fields according to the data the EPISA Server provides and works for both the event’s visualization and the event’s creation and edition. It becomes possible using Micro-form12, a library to translate any datasource into into HTML form elements. The EPISA Server provides a JSON object with the necessary elements and their properties (type, name, verifications, etc) and the EPISA ArchClient interprets it and builds the layout of the interface with the corresponding fields.
In this section, we describe the user interaction abstractions by presenting two illustrative use
cases for the archivist user – search and navigation, and the description process. The adoption
of linked data opens up many opportunities to improve data description and access, but user
10https://laravel.com
11https://tailwindcss.com
12https://github.com/marcomilon/micro-form
interaction with linked data, in particular for authoring data, is still a challenge with many open
problems [
/ doc/ <uui d>
Archival Record Information Events Entities / event / <uui d>
Event Information Linked Records / ent i t y/ <uui d>
Entity Information Linked Events Linked Records
In the EPISA ArchClient, the end user is presented with three central information concepts — the records, the events, and the entities, as illustrated in Figure 4. Although all data is stored in a single underlying graph using the ArchOnto model, these concepts are introduced at the logical level to structure user interaction. The records represent the collection of archival documents, described at diferent levels (e.g., fonds, collections, records). The entities represent the concepts (i.e., persons, places, organizations) that are mentioned in the records being described. Finally, the events allow the creation of more complex structures linking records and entities — e.g., birth and death events, marriages, places of domicile.
Search and Navigation An archivist can use the EPISA ArchClient to perform a search on the records and entities held by the system. The system provides four categories of search: (i) simple search, where a full-text search is performed with the text term given by the archivist; (ii) hierarchy search, where the archivist can navigate through the hierarchy of records and entities and find and see the relationships between each one of them; (iii) advanced search, where archivists can add to their search, filters with diferent existing categories; and (iv) structured search, where the archivist can build a complex query to find the desired records/entities. Each individual record, event, and entity work as direct entry points in the EPISA ArchClient, i.e. each has a unique address. Figure 5 shows the record view. From each record, the user can navigate to associated events or directly to specific entities. Similarly, from each entity, the user can navigate to the associated events.
Description Process The description process always starts with the creation of a new archival record. For each record, the standard description properties can be defined (e.g., description level, support, languages, access). Additionally, each record can be associated with multiple events. Events are created using custom user interfaces that can be defined programmatically.
We have described the EPISA Platform, a computational infrastructure developed to support archival records management using linked data technologies. The system is currently under active development with internal prototypes being evaluated by professional users. This work contributes to the development and the adoption of linked data technologies by providing details about a real-world implementation in the context of the archival domain. Future work includes the design and implementation of an authorization mechanism to support fine-grained control of data access. Also planned is the design and organization of user studies with professional archivists. These studies are central to understand how the proposed user interface abstractions and overall workflows fit the archivists processes. Additionally, these user studies will also include the evaluation of the keyword-based search – which is expected to greatly impact the way information is retrieved, taking advantage of the links between data items.