Paving the Way to Linked Open Data: Evaluating the Path to LOD for the Census of Antique Works of Art and Architecture Known in the Renaissance

poster / demo / art installation
Authorship
  1. 1. Oliver Pohl

    Berlin-Brandenburgische Akademie der Wissenschaften (BBAW) (Berlin-Brandenburg Academy of Sciences and Humanities)

  2. 2. Andrea Notroff

    Berlin-Brandenburgische Akademie der Wissenschaften (BBAW) (Berlin-Brandenburg Academy of Sciences and Humanities)

Work text
This plain text was ingested for the purpose of full-text search, not to preserve original formatting or readability. For the most complete copy, refer to the original conference program.


The
Census of Antique Artworks and Architecture Known in the Renaissance (henceforth Census) identifies and collects antique monuments and related Renaissance documents in a database, such as works of architecture, statues, frescoes, sarcophagi, paintings, drawings, sketches, manuscripts and more. Established in 1983, data has continually been added to the database. Since then, the fundamentals of the underlying relational data model of the Census did not have to be changed. Its main focus is to help researchers in art history expand their understanding about the relation between works of art produced in the Antiquity and their reception and perception in the Renaissance.

Although the data model is robust, the research environment using the Census database does not meet current user expectations like a modern and responsive user interface and search capabilities that are easy to understand. Moreover, the site does not make use of best practices established in the Digital Humanities community, such as providing a RESTful API or making use of Linked Open Data (LOD) technologies. Another issue the Census project is currently facing is the fact that the website runs on a proprietary digital asset management system (easydb 4) which handles data entry, retrieval front- and back-end. The support for easydb 4 will be running out shortly. In order to address the issues of a) openness, b) usability and c) maintainability, the we are currently currently evaluating how to port its data and research supporting functionalities in the coming two years into an open source-based system with LOD capabilities that also provides a modern user experience.
In the beginning of the evaluation process, the Census project looked at solutions of other projects in the domain history that seem to fit the requirements mentioned above. While researching and speaking to other members of the Digital Humanities and art history community, we identified the following software solutions as possible contenders for the future of the Census project:

Software

Description

Developer / Maintainer

conedaKor

Open source web application for storing arbitrary entity types and interconnect them.
coneda (Germany)

Omeka-S

Open source web publishing platform and content management system for cultural heritage collections with LOD in mind
Roy Rosenzweig Center for History and New Media (USA); George Mason University (USA)

researchSpace

(Partly) open source Semantic Web environment for research and collaboration
The British Museum (UK); Metaphacts (Germany)

WissKI

Drupal extension for annotating arbitrary data using LOD Data in a CMS-based research environment
Germanisches Nationalmuseum (Germany)

arches

Open source data management system for (cultural) heritage data

Getty Conservation Institute (USA)

easydb 5

Closed source successor of the current Census system with open source extensions

Programmfabrik (Germany)

We established a catalog of criteria to test these system against, taking inspirations from

Jackson et al. (2011)

and

Knodel and Naab (2016)

while also taking advice from other members of the Digital Humanities community. This list includes criteria and questions such as:

How easy is it to re-use the current data model of the Census in the new system?
Is the new system easy to understand and handle for users and developers?
Does the system have built-in LOD capabilities?
Can the new system be installed and deployed easily?
Can you extend the new system’s front-end and back-end components without breaking upgradeability?
Is the new system available as open source software and is there (commercial) support available?
How big is the user community for the new software?

While Omeka-S, researchSpace, WissKI and arches are built with Semantic Web technologies in mind, conedaKOR just focuses on employing a non-RDF-based graph model. When comparing the systems regarding usability and maintainability, Omeka-S offered the best documentation, modern user interface with CMS functionalities as well a modular approach for extending its source code. researchSpace impressed us with its software architectural design by only relying on a triple store and possibilities to visualize any data using React

components. However, it turns out researchSpace is very hard to deploy and complicated to maintain on a source level.

While testing all these systems, we noticed there would not be an easy plug-and-play solution to re-use the Census database. These system either require a specific yet generic data model and/or Semantic Web ontology. Thus, we would have to re-design the current structure of Census relational database and thereby risk losing important data and relations without even having re-implemented basic functions such as searching and data entry.
Instead of settling on a holistic system that covers database interaction, front-end, back-end and Linked Open Data, we had to rethink our approach to a new software architecture for the Census: We intend to establish a modular software architecture revolving around a RESTful LOD-API. Having a well documented API, e.g. in form of an OpenAPI specification

, allows us to build front-end components using that API endpoint for presentation and research, while also developing a back-end system that handles data base interactions and preparing the data for the API at the same time, In other words, having an API centric software architecture makes it programming language agnostic, making it easier to swap, extend and update front- and back-end components as well as the database if the need should arise, as long as the API still functions as specified.

The Census project recently turned 35 years and aims to continue doing its research in the future. We conclude to not adapt the next “one size fits all” solution for the Census database, and instead focus on establishing a modular approach to remain flexible for future technologies and best practices.

Bibliography

Jackson, M., Crouch, S. and Baxter, R. (2011).
Software Evaluation: Criteria-Based Assessment. Software Sustainability Institue
.

Knodel, J. and Naab, M. (2016).
Pragmatic Evaluation of Software Architectures. (The Fraunhofer IESE Series on Software and Systems Engineering). Springer International Publishing
//www.springer.com/de/book/9783319341767 (accessed 27 November 2018).

If this content appears in violation of your intellectual property rights, or you see errors or omissions, please reach out to Scott B. Weingart to discuss removing or amending the materials.