2.1 Long-Term Accessibility

[5]Long-term preservation is a fundamental challenge in research data management. Typically, databases are hosted only for a limited time after the end of a project, as both hosting and software updates require resources that are often no longer available. Experience from previous projects illustrates this clearly.

[6]In the documentation of archival materials and findings on the construction history of Weikersheim Castle (Baden-Württemberg / Germany), a WissKI database was used as a Virtual Research Environment (VRE).‍[3] WissKI implemented the CIDOC Conceptual Reference Model as an ontology.‍[4] It became evident that the complex ontology required deep familiarity with its underlying logic and that use was only possible due to the custom digital infrastructure provided by Mainz University.‍[5] After the end of the project, access to the database was restricted to logged-in users, over time no more administrative support was available, and eventually the website was taken offline.

[7]A similar case arose in the ›Research and Training for the Palace Museum of Tomorrow‹ (PALAMUSTO)‍[6] project, which involved documenting the construction history of Arenberg Castle (Vlaams-Brabant / Belgium). To achieve a more flexible and easier-to-maintain VRE, a combination of MediaWiki and Wikibase was developed and implemented.‍[7] By using Wikimedia Foundation software, the project aimed to improve usability while keeping technical maintenance manageable through the usage of well supported and heavily used products. However, once project funding ended, hosting of the database also ceased. Additional challenges emerged because the local hosting environment provided by KU Leuven did not allow the deployment in the containerized application environment Docker at that time, resulting in unnecessarily high administrative effort for updates.

[8]Both projects also highlighted challenges with handling copyright-protected or sensitive personal data. With Weikersheim Castle, this meant that the WissKI database was not publicly accessible. Similarly, parts of the MediaWiki / Wikibase database for Arenberg Castle were also restricted to logged-in users. Within the framework of PALAMUSTO, another experience was gained concerning the accessibility of research data, when a shared database for the ten participating Early Stage Researchers (ESRs) was created using ArcGIS.‍[8] This software requires a paid license, meaning access to the data ended once funding ceased.

Figure 3: A view of the Linked Open Data web showing Wikidata, Wikibase and Wikimedia projects. [Diagram: Manuel Merz (WMDE) under CC-BY-SA-4.0, 2021]

[9]Reflecting on these experiences, WikiFAIR was created as a research data management strategy. Its goal is to make use of the Wikimedia Foundation’s infrastructure to preserve and publish project data for the long term, reducing hosting complexity where possible. This approach ensures that data remains accessible and is integrated into one of the largest open-access semantic data networks, rather than existing in isolation (cf. Fig. 3).‍[9] Consequently, research projects can prepare and share their results in accordance with the FAIR principles (Findable, Accessible, Interoperable, Reusable) without significant long-term costs (cf. Fig. 4). In the ARCHIATER project, this strategy is applied by directly integrating the collected research results into Wikidata, rather than creating a separate database.‍[10] The scope and depth of this approach is of course dependent on the project data itself; possible methods and limits are documented as part of the WikiFAIR recommendations.

Figure 4: Graphical representation of the FAIR guiding principles for data resources. [Image: SangyaPundir under CC-BY-SA-4.0, 2016].

2.2 Collaboration Within the Team

[10]Due to its wide scope and the collaboration of researchers across multiple institutions in two countries, it was essential from the very beginning for ARCHIATER to precisely coordinate the research efforts of individual contributors: how could the individual results be aligned to complement each other and contribute to a coherent overall picture?

[11]In an international project where different researchers pursue their own projects and questions, it is crucial to develop standards and guidelines from the outset, which each researcher can use as a reference in their work. Here, ARCHIATER could also build on the experiences gained in the PALAMUSTO project. In that project, ten doctoral researchers collaborated on the aforementioned shared GIS database. The insight gained – that it is crucial to agree on a controlled vocabulary or authority data system from the very beginning – has been implemented in the current project.

[12]Using the editorial system of Wikidata (as well as Wikipedia and Wikimedia Commons), the ARCHIATER team can work in a virtual research environment where every editorial action of the individual contributors is documented. This ensures not only maximum transparency and verifiability but also that each team member’s authorship is recognized – both essential requirements for rigorous scientific work.

3.1 Integration into Wikidata

[13]Uploading information on Wikidata right away allows one to directly publish all of the research results alongside the respective sources and citations and guarantees that the data will continue to be public and usable even after the end of the ARCHIATER project. Therefore, the team created a small ontology for modeling the visual culture of early modern hospitals on Wikidata with the aim of visualizing connections and other findings. Under this concept of visual culture falls not only the hospital itself, but also the associated churches and other hospital annexes, such as the master’s residence or working quarters. As with any database, it was important to strike a balance between being sufficiently precise and keeping the model as simple and straightforward as possible. A main concern was to adhere to established Wikidata community rules and guidelines and to communicate intent and scope clearly and transparently, since the project is a shared commons. So, the team established guidelines for coordinated and standardized project activities within the framework of Wikidata, starting with the definition of the early modern hospital.

[14]The first and most important property of an entity in Wikidata is instance of (P31), which determines the ontological category to which the entity belongs (cf. Fig. 5). One fundamental decision was to initially treat hospitals as architectural entities, that is, to classify them as instances of a building (Q41176) or a building complex (Q1497364). Alternative approaches could have been to treat hospitals mainly as organizations or legal institutions. These options were, however, set aside in favor of prioritizing the building itself as a physical object.‍[11]

Figure 5: A labeled graphic showing the organization of information on Wikidata. [Image: Charlie Kritschmar (WMDE) under public domain, 2016]

[15]Then, under the property has use (P366), the applied data modeling provides the historical designations and functions that could fall under the category of ›hospital‹ in the early modern period: poor house (Q1929784), poor hospital (Q48689779), Seelhaus (Q14585499), almshouse (Q15548045), béguinage (Q12816129), Leper colony (Q1406569), leprosy sanatorium (Q29631000), pest house (Q7171457), Lazaretto (Q859247), Hotel-Dieu (Q1643052), Heilig-Geist-Spital (Q1594896), pilgrim’s hostel (Q2094954), Bimarestan (Q1293141), xenodocheion (Q1517445), and orphanage (Q160645). In this way, multiple designations and functions can also be recorded over time if needed. Throughout the item page qualifiers such as start time (P580) and end time (P582) are used to specify the information and to model the history of the building.

[16]Based on these analyses, gaps and errors could be identified and, if possible, corrected: some entities appear to exist twice and should be combined in one, for example leprosy sanatorium (Q29631000) and leper colony (Q1406569) or poor hospital (Q48689779) and poorhouse (Q1929784). Another example was the misclassification of contemporary or modern healthcare facilities hospital (Q16917) as historical institutions for the needy which should have been assigned the category hospital (Q180370). Furthermore, the classification as former hospital (Q64578911) should not be used due to its imprecise and often misleading use, being attributed also to former modern hospitals.

[17]The Heilig-Geist-Spital Munich (Q1594901) was used as example to apply the data model. It is an instance of a building complex, containing among other things separate buildings for women, men and children, as well as a church, stores, stables and so on.‍[12] Its inception (P571) was 1208, which is the value given for the property, as well as the qualifier for start time (P580). Over the centuries it was used (P366) as a hospital (Q180370), a Heilig-Geist-Spital (Q1594896) and a pilgrim’s hostel (Q2094954). This modeling is necessary to distinguish later changes, for instance it was only an orphanage (Q160645) as well from 1451 onwards.‍[13] To model stages of development of the hospital, the property significant event (P793) can be used additionally.

[18]The properties funder (P8324) and operator (P137) link the hospital to persons associated with it. While the Heilig-Geist-Spital Munich was first funded by Louis I (1173–1231), Duke of Bavaria, it was run by the Canons of the Holy Spirit. Alternative properties for the latter could have been affiliation (P1416) or occupant (P466). These properties show slight semantic differences and might be better suited for individual cases. To ensure consistency, the team assigned all entities responsible for the functioning of daily operations to the property operator (P137), so that they are displayed uniformly in visualizations.

[19]Another aspect of interest concerned the types of spaces in which the needy were housed. Did they sleep in a big dormitory or individual cells? Among the existing properties, has facility (P219) corresponded most closely to this characteristic. One aspect that was initially intended to be included in the analysis with regard to the aesthetic qualities of a hospital proved too complex. The aim had been to document the presence of arcades and columns, which are often found separating naves, in the cloister, or forming a loggia at the main entrance. Ultimately, this intention failed due to the incoherent terminology with which the relevant terms are used across different disciplines and languages.

[20]One of the challenges of using a WikiFAIR data management strategy for a research project is how to blend open data modeling with original scientific research. Explicitly marking which records were created and editorially curated within the framework of the project was one of the declared objectives of the project itself. To achieve this, a dedicated property was assigned in Wikidata to indicate these project-generated records. It can be filtered at any time via the statement research project that contributed to this data set (P13459) in connection with the Wikidata entry on the ERC Project ARCHIATER (Q126737400). With this property, it is not only possible to document that the research project is connected to and has studied a given hospital, but also to filter query results so that visualizations include only hospitals curated within ARCHIATER. This makes the property a powerful tool for other research projects using Wikidata.

[21]In addition, to indicate the scholarly literature consulted, one can provide a reference for each statement on Wikidata by adding the property described by source (P1343) and then referring to the relevant passages through the identifier page(s) (P304). All of these standards and guidelines have been recorded and made available in the Wikidata:WikiProject Spital, where they can be refined further as needed.

[22]Newly created datasets, initially compiled in spreadsheets, were subsequently integrated into Wikidata as data exports. Using the powerful data wrangling tool OpenRefine enabled the team to handle both small and large data sets. Editing and reconciling can be done directly in the uploaded spreadsheet, and a few simple steps show which data sets are already available, what needs to be added, and where there might be some gaps to fill before the upload. All the necessary steps have been documented in a tutorial video.‍[14]

[23]A key challenge of this approach concerns data that does not meet the notability criteria of Wikidata. To ensure completeness and interoperability, such data can be managed in a parallel Wikibase instance, for example FactGrid or in the Wikibase Cloud. Federated queries can be used to retrieve data from such separate Wikibase instances together with the Wikidata ecosystem.

3.2 Modeling Artworks and Objects

[24]Furthermore, exemplary models were developed to define the types of information to be recorded for stationary artworks such as wall and ceiling paintings linked to architectural components, as well as for movable objects.‍[15] Networks of patrons, artists, and artifacts are mapped, drawing on Actor–Network Theory (ANT) and sociological systems theory. The following examples provide a schema that can guide research on individual case studies.

Figure 6: Main ceiling fresco of the central nave of the Heilig-Geist-Kirche in Munich. [Photograph: Tuxyso under CC-BY-SA-4.0, 2025]

[25]Inside the church Heilig-Geist-Kirche Munich (Q251087), the ceiling of the middle nave displays four frescos by Cosmas Damian Asam: Foundation of the Heilig-Geist-Spital (Q130997968) (Fig. 6), King David with the harp (Q130999991), Angels worship the Holy Spirit (Q130999922) and The Seven Gifts of the Holy Spirit (Q130999932).‍[16] The individual entries for these artworks are linked to the entry Ceiling of the nave of the Church Heilig-Geist-Kirche Munich with the property part of (P361) and listed there under the property has part(s) (P527) to express the structural relationships between the interrelated elements. Individual characteristics such as measurements and topics are recorded under the individual entry, while shared features belong to the ceiling of the nave as a whole, which is itself a part of to the church and the hospital. This separation of entries might lead to repetitions, such as of the creator (P170) Cosmas Damian Asam (1686–1739). The principal difficulty lay in modeling the destruction during the Second World War and the overpainting of the ceiling paintings. This is why Asam is not the only creator listed. The re-creator Karl Manninger (1912–2002) is recorded here as well. Only the qualifiers point in time (P585), start time (P580) and end time (P582) achieve a clear distinction between the artist who originally painted the fresco in 1724, and the one who over- or repainted them between 1971 and 1975 and again in 1990. If the year is only known approximately, the qualifiers earliest date (P1319) and latest date (P1326) might be better suited, adding the qualifier sourcing circumstances (P1480) and the value ›circa‹ is a way to clearly communicate uncertainty. An example for this is the property dissolved, abolished or demolished date (P576) of the ceiling paintings, which must have been circa 1944 or 1945.‍[17]

Figure 7: Hammerthaler Muttergottes shrine in the Heilig-Geist-Kirche in Munich. [Photograph: Ricardalovesmonuments under CC-BY-SA-4.0, 2016]

[26]An artwork that served as a model for processing movable objects was the Hammerthaler Muttergottes (Q130880363), a statue of Mary with the infant Jesus, which is currently located in a side aisle of the aforementioned Heilig-Geist-Kirche in Munich (cf. Fig. 7). As a first point of reference on how to incorporate a work of art via statements into the Wikidata network served the Pietà by Michelangelo (Q235242). However, this quickly revealed the following challenges: on the one hand, the Hammerthaler Muttergottes is not only a sculpture, but also an image reputed to work miracles. On the other hand, its date of creation has only been estimated in the 15th century. Furthermore, it is no longer located in its original place of installation, the Augustinerkirche in Munich.

[27]The modeling of the change of location drew upon comparable objects from the Uffizi Gallery, which were made for hospital churches and chapels and only later brought to the museum.‍[18] However, no solution had yet been found in Wikidata for recording a change of location of these objects. To encode the Hammerthaler Muttergottes’ change of location (P276), the original site was added to the same statement alongside the current location (Heilig-Geist-Spital Munich, since 1803) and limited in time by start time (P580) and end time (P582). This makes it immediately apparent that the Hammerthaler Madonna was located in the Augustinerkirche from 1624 to 1803.‍[19]

[28]For the date of origin, the accuracy qualifier (sourcing circumstances (P1480)) was used, whereby the assumed period can be specified as earliest date and latest date, adding the time frame from circa 1450 to 1460 to the statement of inception (P571). The additional significance as a miraculous image was incorporated in the statement instance of (P31). This made it possible to express that the Hammerthaler Muttergottes was declared a so-called Gnadenbild (statue of grace (Q1533007)) in 1638 (start time (P580)) by Veit Adam of Gepeckh (conferred by (P1027)).‍[20]

[29]To summarize, qualifiers such as start and end time, earliest and latest date or sourcing circumstances are key elements to model and incorporate artworks and objects, whether movable or stationary, in Wikidata’s ontology. They allow the integration of uncertainties and a range of information which can’t be expressed in less complex formats, and to model scientific and art historical data in Wikidata in a traceable way.

4.1 Geographic Evaluation

[33]In addition, customized queries can be formulated that lead to insightful visualizations. The process of generating graphs or graphical visualizations from Wikidata involves two key stages. First, a SPARQL query must be defined to select the datasets of interest. A SPARQL query is a structured request used to extract and analyze data from a semantic database, such as Wikidata, by specifying patterns and relationships among entities. For example, one can search for all entities that either have the property instance of (P31) or has use (P366) in connection with the entity of a pre-modern hospital (Q180370) or one of its subclasses (subclass of (P279)), and for which geographic coordinates are available (coordinate location (P625)).

Figure 11: Graphical representation of hospitals and subclasses recorded in Wikidata (Q180370), with a focus on Europe. [Screenshot of query result: Frieder Leipold, 16 January 2026, 15:39]

[34]In a second step, the queried data is transformed into a graphical format using the built-in visualization tools of the Wikidata Query Service (WDQS), which offers various chart types and diagram options for presenting the results. The results can then be displayed on a map, with examples of different hospital types shown in different colours, providing an impression of the spatial distribution of these datasets (cf. Fig. 11).‍[24]

[35]However, this distribution does not represent a statistically meaningful distribution of hospitals; it only reflects the (often small) subset of hospitals for which data is already available. For instance, it appears that data on almshouses (almshouse Q15548045) in England is been systematically and comprehensively recorded.

[36]The menu on the right allows users to filter the results. For example, users can separate almshouses or potentially modern institutions, such as orphanages (Q160645) or orphanage hospitals (Q3644180), and choose to display only these layers (cf. Fig. 12) or hide them (cf. Fig. 13). This functionality enables a focused analysis of specific categories of institutions directly within the interactive map.

Figure 12: Graphical representation of almshouses and orphanages recorded in Wikidata, with a focus on Europe. [Screenshot of query result: Frieder Leipold, 16 January 2026, 15:45]

Figure 13: Graphical representation of pre-modern hospitals without almshouses and orphanages recorded in Wikidata with a focus on Europe. [Screenshot of query result: Frieder Leipold, 16 January 2026, 15:47]

[37]In this way, the tally of the just over 300 hospitals initially identified has been increased to more than 2,300 results. Further queries can then filter the results for a certain city (located in the administrative territorial entity P131) and reveal the hospital landscape in such urban case studies:

• Munich
• Florence
• Regensburg
• Augsburg
• Venice
• Heidelberg

4.2 Networks and Quantitative Evaluation

[38]The visualization of SPARQL queries using the WDQS allows for the discovery of complex network structures as a form of Distant Reading – beyond geographical location, for example, relational patterns within the visual culture of hospitals can be made visible.‍[25] Based on the Wikidata ontology and drawing on Actor–Network Theory (ANT) as well as sociological systems theory, networks can be developed that represent objects, donors, artists, and institutions within a web of relationships.‍[26] These networks range from the immediate connections between donor and work to complex questions of materiality and iconography.

Figure 14: Graph of network around hospital artifacts. [Screenshot of query result: Frieder Leipold, 13 October 2025, 13:46]

[39]The various forms of visualization, such as graph networks that reveal connections between people and objects (cf. Fig. 14)‍[27] or diagrams such as bubble charts that illustrate typological groupings (cf. Fig. 15),‍[28] allow us to analyze social, governmental and economic structures. The usage and enrichment of data in Wikidata and its visualization opens perspectives when it comes to questions of longue durée and provenance research. For example, the network of hospitals such as Santa Maria Nuova in Florence can potentially be reconstructed, as can the migration of objects across institutions and centuries, as many of these objects later passed into museums such as the Uffizi, the Bargello or the Galleria dell’Accademia.

Figure 15: Bubble chart on subclasses of hospitals. [Screenshot of query result: Frieder Leipold, 13 October 2025, 13:32]

[40]Ultimately, the limitations of this method lie in the quantity and quality of the data provided. The data determines the spectrum of relationships that can be represented, from simple to complex models. Restrictions exist particularly in highly active parts of Wikidata, where uncoordinated interactions with the community can lead to trouble.