GRACEFUL17. A Knowledge Graph for Papal Documents of Apostolic Provisions

2.1 Availability and Scope of Sources – the Vatican Apostolic Archive

[3]Due to a lack of scholarly attention, the Datary lists in the Vatican Archive are in need of inventorisation. Given these archival conditions, we chose to shun the registers of (granted) petitions (supplications) and turned to the few remaining Expeditiones volumes for the 17th century which contain, amongst others, standardised summaries of requests for lower and middle ecclesiastical offices being ›expedited‹ (or processed) by the Datary.‍[6] Ideally, these enormous volumes each list the registrations of one single pontificate year starting with the anniversary of the reigning Pontiff’s enthronement and ending with the eve of its next anniversary (or with the date of the Pontiff’s death). For our first samples, we chose to collect the apostolic provisions from two Expeditiones volumes concerning the second year of the pontificates of Gregory XV (14 February 1622 – 13 February 1623) and Innocent XI (21 September 1677 – 20 September 1678) respectively.‍[7]

Figure 1: A single year’s piles of paper: AAV Dataria Ap. Expeditiones 22 (first year of the pontificate of Innocent XIII, 18 May 1721 – 17 May 1722). [Image: Archivio Apostolico Vaticano]

Figure 2: A page from the Ordinarius Galliarum subregister (in AAV Dataria Ap. Expeditiones 9, 1244r) dedicated to the provisions of French benefices. In the right margins a Roman curialist inserted the names of the dioceses where the benefices where situated; above we find the date of entry and / or the granting of the supplication. [Image: Archivio Apostolico Vaticano]

[4]These volumes contain, alongside the for our purposes less relevant Commissiones, five subregisters that interest us here: (1) Per Obitum (containing provisions for benefices that had become vacant because of the death of their previous holders), (2) Ordinarius and (3) Extraordinarius Sanctissimi (for other vacancies, e.g. resignations or irregularities), for benefices in Italy, the Iberian Peninsula, the Holy Roman Empire and Central-Eastern Europe, as well as two vast subregisters that were exclusively dedicated to French benefices: (4) the Codex or Ordinarius Galliarum and (5) the Extraordinarius Galliarum. Within these subregisters, dense records of usually two or three lines are listed in a chronological order, i.e. according to the Roman calendar dates which represent the date a supplication was registered and dated (hence: Dataria), the formal act before the requested papal graces accordingly gained force of law.

2.2 Recording Structured Data

[5]Modeling of data in the knowledge graph (see section below) starts with a manual transcription of an individual register entry from the archive. At this stage, alongside entries from the individual research projects (cf. above), our collective samples from Expeditiones 2 and 9 contain 16,526 transcribed entries, stored in the project database and published as ground truth data (see example below). Each entry is assigned to a source, corresponding to its respective archival volume, which in turn is linked to the holding archive itself. While the transcriptions themselves are not directly relevant for data analysis, they serve as ground truths for subsequent semantic data modeling. In this process, the semantic data is abstracted from the raw transcriptions in favor of semantic taxonomies and a comprehensive knowledge base. Since the transcriptions are also part of the knowledge graph, the structured data can always be traced back to them. It should also be noted that the structure (elements) of an entry consists of the Latin transcription and added metadata. This applies to the subregister, the place of event, the event date and the diocese. These elements are information from the margin or from headings that has been added to each individual entry. An example of an entry:

[6]»Per obitum Rome apud Smm Pridie Id Septembri a ii Senen Mattheus Cittadinus super Canonicatu et praebenda ecclesiae Senen per obitum q Marci Antonii Amaroni extra augusti prox pret defuncti vacan fructus 24 duc«‍[8]

[7]Translation: [In the subregister] Per Obitum[:] Rome at Santa Maria Maggiore on the eve of the Ides of September of the second year [of the pontificate of Gregory XV] [in the Diocese of] Siena Matteo Cittadino [is granted a provision for] a canonship in the church of Siena [i.e. Siena cathedral] vacant because of the death of Marcantonio Amaroni outside [the Roman curia] [with a tax value of] 24 ducats [of the Apostolic Chamber]

[8]Each entry is segmented into individual labeled elements in order to atomise its relevant ›information‹. This data capture process is facilitated by machine learning technology, such as Named Entity Recognition (NER), which is described below. Individual elements – as seen from our example below – represent relevant information, such as details about institutions (e.g., dioceses), specific locations, individual persons in different roles, categorical classifications, dates, and so on and so forth. The entities assigned to individual elements are, in turn, independent records. Each of these entity records has additional metadata, such as geographical coordinates, names and description text, relationships between these entities themselves, and links to authority data, e.g., Wikidata. An exemplary and validated segmentation comprises the following elements and their respective labels:

Figure 3: Rendering the Named Entity Recognition spans with displaCy.js (cf. Explosion 2025) as HTML. [Screenshot: Christoph Sander 2025]

[9]Each element stores its label as relational information (set in bold),‍[9] has its own metadata, and is member of a specific class (coloured):‍[10]

• Persons: Identified or unidentified single persons with different name properties.
  • Providee: The name of the individual being appointed, here »Mattheus Cittadinus«, encoded as ›Cittadinus‹ (family name), ›Mattheus‹ (given name).
  • Former Possessor: The name of the former possessor of the office, here »Marci Antonii Amaroni«, as ›Amaronus‹ (family name), ›Marcus Antonius‹ (given name).
• Dates: Decoded and normalised as relative and absolute time periods.
  • Event Date: The date of the decision (i.e., the granting of the provision), here »Pridie Id Septembri a ii«, i.e., the 12th of September; »a ii«, i.e. the second year (14 February 1622 – 13 February 1623) of the pontificate of Gregory XV; the calendar year is hence 1622.
  • Vacancy Date: The date of the vacancy, »de augusti prox pret«, and thus in the past month of August, i.e. here between August 1 and August 31, 1622. Depending on the type of vacancy (see below) and the region, Roman bureaucracy only intervened following vacancies occurring in specific ›apostolic‹, months. The specific day within this timespan was hence irrelevant.
• Places: Identified or unidentified geographical points or areas with coordinates, name properties, hierarchical information, and relation to types.
  • Place of Event: The administrative location of the dating (and hence the granting) of the papal grace, here »Rome apud SMM«, i.e., one of the four major basilicas in Rome, Santa Maria Maggiore.
  • Location of an Institution: The precise location of the church here ›Senen‹ and thus the city in which the benefice is located, here Siena.
• Institution: Identified (ecclesiastical) institutions with name property and relations to places and types.
  • In Diocese: The diocese location, here ›Senen‹ and thus the diocese of Siena.
• Types: Categorical information with name property and hierarchical information.
  • Benefice Category: The awarded benefice, here: »Canonicatu et praebenda« and thus a canonship.
  • Church Category: The ecclesiastical institution to which the office is attached. Here: »ecclesiae« and thus an unspecified church, in this case the city’s cathedral.‍[11]
  • Vacancy Category: The reason for the occurrence of the vacancy and thus the reassignment of the office, here: both »per obitum« and »defuncti« mean the death of the predecessor.
  • Deceased at the Papal Court (Curia): Whether a death occurred inside the curia or outside of it, which conditioned the legal grounds of Roman bureaucratic interventions. Here »extra« indicates a death outside the curia.
  • Source Subregister: The subregister from which the data originates. Here »per obitum« and thus the subchapter that records allocations following the predecessor’s death.
• Monetary Values: Decoded and normalised absolute values and type relations.
  • Benefice Taxation: The tax valuation of the office, here: »24 duc« and thus 24 ducats, the Apostolic Chamber’s currency unit.

[10]These elements are subsequently linked in a many-to-many relationship to specific events or objects documented or referenced by each entry. ›Events‹ and ›Objects‹ thereby constitute the core of our Resource Description Framework (RDF) ontology (see the following section). Notably, the act of granting a provision for a benefice is classified as an event (›apostolic provision‹), whereas the benefice itself constitutes an object. Each element is assigned either to the relevant event or to the object it describes. Furthermore, individual elements may be connected to multiple events or objects spanning several entries. Events are themselves linked to corresponding objects, and objects may further reference additional objects.‍[12] We anticipate also the possibility to link events with each other (e.g., for those events linked to ›double entries‹), but the need to do so has not occurred just yet at this stage of research. The association of elements with events and objects explicitly conveys their semantic relationships through descriptive labeling.

Figure 4: Assignment of elements to events / objects in the underlying conceptual framework. Sankey diagram created with SankeyMATIC (cf. Bogart 2014). [Diagram: Christoph Sander 2025]

2.3 Encoding Data in a Knowledge Graph

[11]Within the semantic Resource Description Framework, we conceptualise the data structure outlined above as a knowledge graph.‍[13] This approach relies primarily on our domain-specific Web Ontology Language (OWL)-compliant‍[14] ›GRACE‹ ontology that has been created by the entire project team of researchers and developers.‍[15] The core of our approach involves transforming textual segments, i.e. the elements, into unique entities – individuals of OWL classes – such as persons, dates, places, institutions, and more. The labels of these elements are primarily modelled as direct OWL object properties, although more complex relationships are also considered. For instance, for some element with some label, as previously described, we express the label’s meaning through a specific property (grace:providee for the label ›Providee‹) and create an entity for the element (e.g. a person for the element ›Mattheus Cittadinus‹). By employing this direct use of labels as properties, we establish meaningful relationships between specific entities in appropriate roles or aspects using distinct predicates for specific phenomena described by the sources. This method offers a streamlined alternative to more cumbersome approaches that rely on reified properties to model specific aspects or roles of generic relationships.‍[16]

[12]OWL datatype properties are mainly used to encode metadata for individual entities, particularly normalised and enriched literals, such as appellations or numerical values. The complete ontology, encompassing almost 2,000 triples, almost 200 (sub)properties, and around 100 (sub)classes, is too extensive to be fully explained here. However, its simplified structure is illustrated in the following manually crafted diagram.

Figure 5: The ontology diagram visualises the encoding of historical data as a knowledge graph. This ontology is specifically designed to model relationships between various entities centered around the granting of ecclesiastical offices in the 17th century through the Apostolic Datary. It is fully compliant with the Web Ontology Language (OWL). [Diagram: Christoph Sander et al. 2025]

[13]The core of our knowledge graph consists of two primary classes: grace:event and grace:object.‍[17] At this stage, events are mainly papal graces, specifically apostolic provisions for benefices, while objects primarily include benefices, pensions, commendas and other codified immaterial objects of church administration. This central connection between object and event is reflected in our ontology through the relationship between these two classes using the symmetrical properties grace:object_related_to_event and grace:event_related_to_object. Besides these core classes around which the ontology is structured, the diagram displays our primary classes as well as their relationships, expressed through properties that define how a particular entity is related to an event or object. The main (super-)classes are grace:place, grace:institution, grace:person, grace:event, grace:entry, grace:type, grace:monetary_value, grace:source, and grace:archive. Some classes are structured as superordinate classes that can be further subdivided into subclasses: for example, the class grace:apostolic_provision is a subclass of grace:event, just as grace:benefice is a subclass of grace:object.

[14]Each church office or benefice, i.e., all objects,‍[18] are described by properties in their domain, including, e.g., the office’s institutional affiliation, most importantly the diocese (e.g., grace:pertains_to or grace:in_diocese with grace:institution in its range) as well as multiple categorical information (grace:type). In contrast, particularly date-related (with grace:date in their range), person-related (grace:person), and monetary value-related (grace:monetary_value) properties are used to describe an event.‍[19] Whether a property has grace:event or grace:objects (or both) as its domain depends on semantic reflection on the phenomenon or thing being modeled: while, e.g., the location, church institution, and characteristics of the benefice object generally remain stable,‍[20] event-related properties (including taxing yearly revenue in that specific context by this Roman bureaucracy) describe the contingency of ›what happened‹ to the object at some point, entailing, most importantly, to person stakeholders and an event date. As a corollary, objects logically are presupposed for events to relate to these objects.

[15]Any information, or property assignment, about events and objects is testified (grace:testified_by) by one or many entries further linked to sources and archives (as instances of grace:entry, grace:source, and grace:archive, from which metadata can be retrieved via grace:in_source, and grace:in_archive). Additionally, each instance of any class has a specific grace:type instance, rendering its super-property grace:has_main_type a functional property. Just as classes are divided into superordinate and subordinate classes, the properties defining relationships between classes are hierarchical, too, using rdfs:SubPropertyOf. Some properties are more general than others, connecting many (or even all) classes: for example, grace:has_participant has all grace:person instances in its range (thus, in all roles, instantiated as subproperties),‍[21] while grace:refers_to is fully agnostic to range restrictions and will return entities of any class. The more specific properties are, the more constrained is their range of classes and the smaller their extension. Properties with a large extension facilitate queries and make these much more performant.‍[22]

[16]Datatype properties for literals encode names, dates, monetary values, geographical coordinates (represented here as WKT‍[23] and GeoJSON‍[24]), etc. Having hierarchical datatype properties allows for direct literal searching in SPARQL queries, retrieving literals of any datatype property of some node, e.g., using grace:appellation_literal.

2.4 Linked Open Data

[17]In alignment with the principles of Linked Open Data, the GRACEFUL17 project models its data to support structured interlinking, semantic querying, and interoperability across platforms. This ensures that the dataset can be reused, referenced, and integrated within the wider knowledge graph ecosystem. In GRACEFUL17, we primarily use Wikidata as a hub for Linked Open Data. Where possible, our data links directly to entities in Wikidata, particularly institutions such as individual dioceses and specific locations. When no corresponding entity exists in Wikidata, we plan to create the necessary Wikidata items and link them to our dataset. For this purpose, the property P13367 ›Graceful17 ID‹ is used to connect Wikidata items (e.g., persons, dioceses, places) to their corresponding entities in our dataset via a unique identifier. The base URI of the entities is https://g17.dhi-roma.it/resources/, extended by the relevant resource class and a sequential identifier (person_[0–9]+, place_[0–9]+, institution_[0–9]+, etc.). Using this property enables straightforward integration of our data into federated SPARQL queries and facilitates referencing our dataset in other academic or public projects.

[18]The geodata – in particular for boundaries of dioceses and ecclesiastical provinces – are derived from public geospatial sources, primarily the Earthworks project at Stanford University‍[25] and the dataset Bistumsgrenzen Altes Reich um 1500 from the Germania Sacra project of the Göttingen Academy of Sciences and Humanities.‍[26] The goal of our project is not to reconstruct an exact geography of ecclesiastical administration. The (multi)polygons used represent simplified approximations of historical boundaries at around 1650 and thus do not account for any diachronic changes. These data instead are primarily used to draw geographical inferences about the belonging of places to certain regions. This kind of detection – performed via geospatial joins, a method to combine two datasets based on a specific spatial relationship between their geometries – is significantly more efficient than manual case-by-case analysis or relying solely on hierarchical associations, especially when such spatial relationships are already implicit in the data and can be made explicit.

[19]We map the RDF data to higher-level ontologies: CIDOC CRM‍[27] (for modeling cultural heritage information) and RiC-O‍[28] (for archival classification and provenance concepts). Thus, the RDF triples in the ABox – the facts about individual things in our knowledge graph – can be queried using these widely adopted standard ontologies. Although the full semantic richness of the data is only accessible through the GRACE ontology, this mapping enhances interoperability and significantly improves the reusability of the data. For easier access, the RDF triples are organised into separate named graphs according to the specific ontology they conform to.

[20]The controlled vocabularies and thesauri developed in the project (categories of benefices, churches, religious orders, ecclesiastical provinces, etc.) are represented by Simple Knowledge Organization System (SKOS) objects in the form of hierarchically organised taxonomies.‍[29] To describe the specific contributions of each author or collaborator to the research project, we use the CRediT taxonomy.‍[30]

2.5 Data Entry and AI Support

[21]Researchers enter data using a commercial cloud database provided by Ninox and hosted by a private, dedicated server.‍[31] While Ninox offers its own scripting language and Application Programming Interface (API), the database’s functionality is significantly extended through the integration of an external Representational State Transfer (RESTful) API application called DATAria.‍[32] This Python-based application, run in a Docker container and accessible via a public HTML User Interface, enhances data entry through a series of modular components. Although a comprehensive description of all API endpoints is beyond the scope of this paper, one of its key modules significantly facilitates data entry. Semantic segmentation, as outlined earlier, is performed using the spaCy NLP Python package, specifically leveraging the NER and SpanCat pipelines.‍[33] To accommodate the diverse requirements of individual researchers and varying sources, custom models are frequently trained (active learning) and then called from within the database application to automatically generate the described elements. DATAria also supports fuzzy entity matching to align elements with actual entities – such as places, dates, and other named entities – by employing Python’s RapidFuzz package and Levenshtein distance.‍[34] Additionally, the assignment of elements to events or objects is aided by a gradient boost classifier (a machine learning technique aligning multiple models in a sequence so that they can learn from the errors), utilising the CatBoost framework and Python package. These automated assistance tools are carefully supervised, as they are trained on validated data and their predictions are immediately reviewed by researchers in real time. Their primary purpose is to accelerate data entry without excluding researchers from the data validation process. This greatly enhances the feasibility (and future funding prospects) of a humanities research project aiming to collect and publish comparably large amounts of data without jeopardising their complexity and accuracy.

2.6 Serialising RDF and SPARQL

[22]The transformation of relational data into RDF is accomplished through a sophisticated serialisation process based on JavaScript Object Notation for Linked Data (JSON-LD)‍[35] within DATAria. This process involves namespace management / mapping and ontological reasoning to ensure compatibility with RDF standards. The serialisation itself is performed using Python’s RDFLib, which is enhanced by customised JSON-LD streaming to facilitate the processing of large files, potentially in the range of gigabytes.‍[36] The resulting RDF data is converted into Turtle (Terse RDF Triple Language) or N-Triples files and stored in dedicated named graphs in a Oxigraph triple store.‍[37] This transformation process is designed to be easily repeatable, enabling regular updates to the graph database while preserving data history. To ensure semantic consistency, Ninox also parses the GRACE ontology as an OWL-compliant encoding. The resulting OWL RDF file is then utilised to dynamically generate ontology documentation through WIDOCO‍[38] and OntoSpy‍[39], producing static HTML files that allow users to explore definitions and axioms interactively. Additionally, the graph’s structure is specified with the help of Shapes Constraint Language (SHACL),‍[40] which provides the basis for a dynamically adaptable graphical query builder, Sparnatural.‍[41] This tool simplifies the construction of SPARQL queries through an intuitive graphical interface.‍[42] Query results can be visualised as tables, maps, or diagrams using built-in plugins. The use of the integrated dockerised app SHMARQL, a linked data publishing platform, provides immediate and dynamic insights into the RDF data through templates generated on the fly.‍[43] For each data point, SHMARQL enables users to view all relevant RDF data in tabular views with simple clicks, providing an accessible and efficient interface for examining the knowledge graph.

2.7 Analysis

[23]Data analysis primarily addresses social, geographic, and chronological data, with a strong focus on identifying correlations and clusters that are then examined through temporal and spatial aggregations. This analytical approach offers deeper insights into the dataset at any stage, enhancing the flexibility and iterative use of data during the data entry process. The core analytical features are facilitated by the DATAria API, which provides various methods for complexity reduction, statistical analysis, and decision tree classification. Additionally, it integrates geographic functions from widely used Python libraries such as Shapely‍[44] and Geopandas.‍[45] This functionality enables robust geographic queries for data aggregation and supports the streamlined adjustment of imported geodata, making it highly relevant for digital humanities projects concerned with spatial analysis. A lightweight Python package named DATAria Utils acts as a wrapper to simplify data access and processing.‍[46] This package allows researchers to interact with the dataset via SPARQL queries, rendering analyses directly within Jupyter notebooks.‍[47] The outputs are highly customisable and can be produced in various formats, including static visualisations (e.g., plots, maps, charts), tabular data (e.g., CSV files, pandas.DataFrame), and interactive widgets for in-notebook exploration.