2.1 Building History of Arenberg Castle

[10]Arenberg Castle in Heverlee (Figure 3) was a fitting choice for a case study because it is both well studied and of a manageable scale. The first mention of a castle in Heverlee dates back to 1371, although a fortified building can be assumed to have existed for centuries before that. The donjon of which we know from pictorial representations seems to have been built in the first half of the 15th century under Raas van Graven or Antoine I de Croÿ.[2] The decisive expansion into a representative hunting lodge happened under William de Croÿ, probably between 1505 and 1520, when the southern wing with the two corner towers and significant parts of the western wing were built. The most important pictorial and written sources for the early history of the castle were created under the reign of Charles III de Croÿ around 1600.[3]

Fig. 3: South facade of Arenberg Castle, above [image: KU Leuven / Koufopoulos et al. 2021]; aerial view of the main building, left [image: KU Leuven / Koufopoulos et al. 2021]; floor plan of the ground floor with color labeling of different structural units, right. [Image: atlas plan, KU Leuven, Technical Services]

[11]In the late 18th century, a new building replaced the burned-down parts of the west wing, the east wing was built in two campaigns and the already existing rooms were redivided in the style of Baroque and Classicism and some mezzanines were installed.[4] In the late 19th century, the castle underwent further extensions and additions in the neo-Gothic style by the architects Joseph Claes, Joris Helleputte, Alexis Raskin and Jules Picquet.[5]

[12]After the castle was handed over to the University of Leuven, further transformations by Emile Goethals in 1925 continued to follow the neo-Gothic style. Between 1958 and 1971, Raymond Lemaire’s restoration work attempted to recreate the state of the first phase of construction. As the last major interventions in the building structure, further additions in a post-modern look were designed between 1973 and 1998 by Paul Van Aerschot.[6]

[13]For more than 25 years, professors, lecturers, and students of architecture or the Master in Conservation of Monuments and Sites program at KU Leuven have been studying the architectural history of the palace. In projects such as the ArchDoc program on documenting findings of building archaeology, over 20 experts and staff members have collected rich experience over the years, which has been documented in various forms, some only in analogue form, some already in digital form. Pooling this knowledge and making an overview of the collected information available online is the task that the De Jonge Wiki aims to serve. As one of the honorary professors, Krista De Jonge led the various research projects over the entire period mentioned. On the initiative of the researchers of the Wiki project, she therefore agreed to the usage of her name for the database.

2.2 MediaWiki and Wikibase

[14]The documentation of the architectural history of Arenberg Castle builds on the findings and insights made by Jan Lutteroth and Frieder Leipold under the direction of Stephan Hoppe within the interdisciplinary cooperation project Kulturliegenschaften 4.0.[7] In this project, a digital, semantic research database was created for the building history of Schloss Weikersheim in Baden-Württemberg, Germany.[8] This database was set up as a WissKI database following the ontology of CIDOC CRM. The digital infrastructure for this project was provided under the direction of Piotr Kuroczyński and Peggy Große at Mainz University of Applied Sciences.[9]

[15]While the Weikersheim database was thus created with a software that has been developed for academic research, the database on the building history of Arenberg Castle was created with Wiki software. By doing so, two basic requirements were to be fulfilled above all others. The first requirement was the modelling of the data according to international standards, so that the records are machine-interpretable. For this, the software Wikibase was used, which also forms the basis for the semantic database Wikidata. However, such collections of data sheets that are linked together according to the principle of knowledge graphs are difficult to grasp for human users without prior knowledge and education.[10] They contain the danger to appear like reference deserts without a human touch and can have a repulsive effect – especially for researchers from the humanities.

[16]Because of this, the second main concern of the project was to strive for a user interface based on Wikipedia, so that users will be spared the anxiety threshold of the new and unknown. Instead they should be able to move in an environment where design and functions are known to them from their daily use of Wikipedia. To achieve this goal, it was obvious to use MediaWiki, the same software with which Wikipedia is operated. In addition, it also offers all opportunities for joint editing and documentation of editorial changes that are offered by Wikipedia as well. It can thus be used as a Virtual Research Environment (VRE)[11] for the exchange between the different researchers involved. First projects with students also showed that the infrastructure of the De Jonge Wiki is particularly well suited for Peer Assisted Learning (PAL) in academic education, where students support each other with their respective skills in mastering a task. Another advantage of using an established software ecosystem is the variety of additional tools and functionalities, for example the accessibility for users with disabilities and their tools such as screen readers.

[17]An additional benefit of using Wikimedia Foundation software is the possibility of linking to other platforms besides Wikidata and Wikipedia, such as Wikimedia Commons. In this media repository, free-to-use images, sound documents and videos as well as other media such as 3D objects can be published. In digital infrastructures, which are based on Wikibase or MediaWiki as software, these media can be integrated as preview images by simple linking, while hosting and all related activities are taken over and provided by Wikimedia Commons. This not only has the advantage that the hosting is outsourced, but also that the media in question can also be found in an environment used by a wider public.

[18]Due to the limited capability of Wikimedia Commons to display 3D objects,[12] three alternative methods for embedding 3D files via iframes were evaluated. The first method, using Sketchfab, was technically straightforward but does not comply with the FAIR/O principles. FAIR/O principles advocate for data to be Findable, Accessible, Interoperable, and Reusable/Open, aiming for broader and more effective sharing of digital resources, which is not fully supported by commercial software like Sketchfab. Consequently, this solution can only serve as a temporary fix.

[19]For future digital 3D model integrations, the use of the Kompakkt platform is planned. Kompakkt, developed by the Department of Digital Humanities at the Faculty of Arts and Humanities of the University of Cologne, extends the e-learning software ILIAS and aligns with FAIR/O principles. Another alternative is Semantic Kompakkt[13], an advancement within the NFDI4Culture initiative, which offers a free, open-source toolchain for viewing and enriching 3D model data. Like the De Jonge Wiki, Semantic Kompakkt utilizes Wikibase for processing structural data.

[20]However, experiments carried out in collaboration with Lozana Rossenova from the Technische Informationsbibliothek (TIB) in Hanover indicated that integrating Semantic Kompakkt into the logic of Wikibase records from the start of the De Jonge Wiki project would have been more advantageous. The best-case scenario would have been to use a single Wikibase to power both applications, in order to avoid any issues from federating the two data sets. Despite this, both Kompakkt and Semantic Kompakkt present promising options for future projects.

2.3 Data Structure

[21]Basically, it can be said that there are several options when creating a scientific research database. On the one hand, there is the Relational Database Management System (RDBMS), in which entities are assigned different properties, in the style of different columns in tables. On the other hand, there are graph databases in which information is stored as knowledge graphs, that means as different entities that can be linked to one another by properties. One possible concept for such graph databases are Labeled Property Graphs (LPG), which means that the connection between certain entities is expressed in main properties which are attached to a node and additional simple key–value pairs: »Lauren Bacall (date of birth: 16.09.1924; place of birth: The Bronx) was married to Humphrey Bogart«. In contrast, information in Resource Description Framework (RDF) graphs is expressed in so-called semantic triples consisting of Subject–Predicate–Object: »Lauren Bacall was married to Humphrey Bogart; Lauren Bacall was born on 16.09.1924; Lauren Bacall was born in the Bronx;« or »Prinsenzaal is accessible from the Hertogenzaal« in Arenberg Castle. This means that all entities are interconnected by a particular property, thus forming a semantic triple. The Wikibase division of the De Jonge Wiki is such an RDF database.

[22]The structure of a castle is particularly suitable for a clearly defined and structured database with a hierarchy or taxonomy. In this case, the entire complex of the castle with its topography and all associated architectural facilities is defined as the highest level. The initials AC for Arenberg Castle as part of their name mark all elements that are components of this complex. The main buildings of the castle are referred to by the initials MC for Main Castle. This Main Castle is in turn divided into the various wings and construction volumes, each defined by initials, such as for example EW for the East Wing. These wings again consist of different floors as well as facades and roofs, such as the first floor expressed as 1F. At the lowest level are the individual rooms designated by the currently used room numbers. The entire name of letter pairs thus refers to the position of the room in question (Figure 4) like coordinates, as it were. In a way, this approach corresponds to the traditional room books[14] used in older architectural research and can provide the information given there in a more flexible and digitally networked manner.

Fig. 4: Structure of the room designations in the De Jonge Wiki. [Chart: Frieder Leipold 2021]

[23]For each such architectural unit an entry was created in the De Jonge Wiki both as a MediaWiki file and as a connected Wikibase file. In the MediaWiki entry, the information is published as text and images in the style of Wikipedia and – if possible – gives an overview of the findings to the respective building history. In the Wikibase entry, however, statistical information is stored in the form of RDF knowledge graphs.

[24]These relationships are modelled according to a defining system, a so-called ontology, as for example CIDOC CRM (Comité International pour la Documentation Conceptual Reference Model). In a database, an ontology forms the intended frame of reference, which is then filled with the contents of the respective data records. The Wikibase datasheets of the De Jonge Wiki are based on the ontology on which also Wikidata is based. This decision was made, on the one hand, because this type of data modelling is applied by an influential and internationally accepted structure as Wikidata and, on the other hand, because this ontology is not a rigid and hierarchical taxonomy, such as CIDOC CRM, but flat and flexible and can be adapted to the requirements of the respective records. This makes it easily possible to integrate new insights and research approaches seamlessly into existing data.

[25]Due to the aim that users should be able to make data entries in the De Jonge Wiki with as short a training as possible, the structure was deliberately kept as simple as possible. There are only three page categories in the frontend (Figure 5), namely:

• architectural structures (rooms, floors, facades, roofs, wings)
• scientific sources (articles, research reports, scans and photogrammetric images)
• historical sources (archival records, artefacts and historical photos)

Fig. 5: Structural logic of the page categories. [Chart: Frieder Leipold 2021]

[26]As already discussed, the architectural structures represent the basic units. In their Wikibase data sheets, statistical information such as length, width, maximum height and area are given, but also to which next higher category the architectural structure belongs (Property:P34 ›part of‹). In addition, it is indicated through which other rooms the room in question can be entered in the current situation (Property:P16 ›Accessible from‹).

Fig. 6: Example of a data sheet in the Wikibase database. [Screenshot De Jonge Wiki]

[27]All of this information is indicated on the frontend using a template and can be seen as an info box at the top right there. To get to the frontend, you simply have to click on the link in the data sheet at the bottom right. Conversely, to get from the frontend to the corresponding data sheet, there is the ›De Jonge Wiki item‹ function in the left-hand column, which takes users to the Wikibase data sheet.

Fig. 7: Example of a front-end article for a room. [Screenshot De Jonge Wiki]

[28]Other important information given in the data sheet are references to scientific and historical sources where information about the architectural structure in question can be found. The cells with these references are linked directly to the entries on the relevant articles in the info box. These links are generated automatically by entering the titles of the articles in the Wikibase data sheet. However, the article pages of this source material are only visible in the frontend to users who are logged in. The reason for this access restriction is the fact that content in this category is specially affected by copyright and data protection law. Some of the research projects listed here were part of student education and are treated as personal data.

[29]Further information and previous research results can be discussed in the text sections in the pages on the historical sources. In the case of written archival material, the scan of a page and both the transcription and a translation proposal can be displayed next to one another in a list.

Fig. 8: Example of a front-end article on a historical source. [Screenshot De Jonge Wiki]

[30]In the case of scientific sources, on the other hand, usually only editorial information such as authors, year and place of publication or number of pages is given (Figure 9). Historical sources and scientific sources can also be linked directly to one another when the historical one is one of the main subjects of the scientific one (Property:P28 ›Main subject‹). In this way, one obtains a clear listing of all investigations that have already been carried out on a specific part of the architecture.

[31]Thus, the De Jonge Wiki tries to prepare diverse research data according to the FAIR/O principles: Findable, Accessible, Interoperable, and Reusable with the help of free Open license software. By adopting the digital infrastructure developed as a prototype, other scientific projects or cultural organizations can prepare their data effectively and valuable and make it publicly accessible in a user-friendly way.

Fig. 9: Example of a front-end article on a scientific source. [Screenshot De Jonge Wiki]

2.4 Open Questions and Challenges

[32]Fortunately, when the basic considerations were implemented in a functioning database, all of the intended aspects could be set up without major problems. When the data was entered by student research assistants, it was found that the structure can be understood intuitively after a short briefing. This made it possible that the student research assistants could follow the underlying logic intuitively and suggest and implement their own additions in order to optimize the database. In practice, however, there were also some challenges that could not be optimally met within a very limited time and budget framework.

[33]Even at the beginning of the implementation, it became clear that the web space, which was kindly provided by KU Leuven, did not enable an easy way to use the Docker version of Wikibase. This is mainly due to the fact that the University is primarily interested in protecting its own research achievements from access by third parties. A classic virtual machine (VM) service operation as an execution environment for Docker or other container systems was classified as too vulnerable in regard to data security. Therefore some practical additional services such as the ›Query Service‹ are not yet available at the De Jonge Wiki. This would have offered a simple, user-friendly possibility to design queries in the SPARQL scripting language via the dataset in Wikibase, as well as the graphic representation of these search results. In addition, overview pages cannot simply be generated in this way, for example a list of all items that are identified as rooms (Property:P2 ›instance of‹; Item:Q257 ›Room‹). In order to still be able to have a classification, the articles in the frontend must be tagged and marked in accordance with the categories in Wikibase. This requires a double administration, which may eventually result in inconsistent information.

[34]The fact that Docker cannot be used also means that software updates have to be installed manually with more effort, which is why a certain amount of expert knowledge is required in dealing with MediaWiki software. However, administrators often have experience in using these solutions, especially at universities which provide wikis to support teaching, and should therefore be able to cope with this challenge. The De Jonge Wiki is in the process of moving to an environment in summer 2023 where Docker and SPARQL queries can be used and where the data will be backed up on a local server for improved security.

[35]Another unavoidable issue is that the datasets are not perfectly uniform because of the human factor, as several employees work on the same datasets in different daily conditions. These inconsistencies would also have been easier to identify and fix if certain Wikidata approaches had been integrated into the project; among other things, the query service, but also restrictions on property fields or shape expressions would have been valid approaches to reduce these problems, but have not yet been implemented.[15]

[36]In addition, once created, data types of properties cannot be changed afterwards. Inventory numbers that are created as a numeric data type cannot be converted into a textual data field afterwards. Also the search function for both namespaces of the wiki has not yet been completely standardized and only works in a case-sensitive manner.

[37]It should also be emphasized that the software of the Wikimedia Foundation is designed for Creative Commons-licensed content, that is for content that can, in principle, also be shared. Data to which this does not apply, for reasons of copyright or personal rights, can only be made accessible to a limited extent as an article in a private area. However, this is only a protection for article pages. With the sites of individual files such as the images uploaded in the wiki, this function does not exist.