Converted from an OASIS Open Document
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:
We established a catalog of criteria to test these system against, taking inspirations from
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
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
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.