Current Issue

The first digital projects at the Faculty of Arts, Masaryk University (MUNI) were created thirty years ago and the increase in their numbers can be observed even before the Velvet Revolution in 1989. The interest of experts focused on various applications of machine text recognition, computer typesetting, statistical tools, and, in particular, tools usable in computational linguistics. A database with reports on research projects using computing technology in humanities was created as the first digital platform, along with a platform for regular meetings of experts interested in the use of computing technology in the field of humanities (Rambousek, 2000). Over a period of 30 years, the world of computing technology has changed significantly, the use of computers has expanded and it has transformed not only education, but also research including the research topics. During this period, a number of digital projects financed by grant agencies or individual departments and service units of MUNI were created at the Faculty of Arts. Despite the initial cooperation of experts, who were using the capabilities of computing technology to approach the issues in humanities, no cohesive community has been established at the Faculty of Arts MUNI. The ubiquitous use of ICT in teaching, administration and research has led to divergent developments. Although an IT support workplace has become established, the common identity among the humanities scholars is disappearing, being primarily determined by the scientific discipline instead of the application of computing methods to resolving the scientific issues of humanities. Digital platforms - the results of research projects, such as databases, geographical information systems, and other digital outputs - are not registered anywhere. They often serve to only partial goals of studies in their individual disciplines, regardless of their long-term sustainability and reuse. Awareness of the work of other experts using computing technologies as well as of the standards of the web and information environment, the role of metadata and the identity of the digital humanities in general, is disappearing. In this situation, many digital products of research activities remain unmaintained and unupdated, hidden or poorly available to a wider range of potential interested parties, unused and obsolete, despite the efforts of experts and considerable financial investments. We consider such development to be undesirable. The possibility of change has come with the engagement in the construction of a large research infrastructure LINDAT/CLARIAH-CZ.

The following paper summarizes our previous experience with building a local node of the large national research infrastructure over the 3 years of the project at the Faculty of Arts MUNI, which we would like to share with other experts dealing with or planning to approach similar tasks. In the paper, we first present in more detail the environment which the repository was implemented in, the building block of our local infrastructure node, and our plans and ideas about the implementation of the research infrastructure, which were based on the available manuals of digital curation and good practice in building repositories. Then we confront them with the obstacles and problems that we have encountered in practice. The conclusion of the paper is devoted to the chosen method of resolving problems, procedures applied to prevent them and recommendations extending the already codified best practice in the implementation of similar projects, which offers lessons learnt for all future creators of digital repositories and infrastructures in humanities.

There are a wide range of literature on the implementation of institutional repositories. Asadi, Abdullah, Yah, & Nazir divide their research topics into six categories: deployment, implementation, adoption; benefits and challenges of institutional repositories; development, content management, and policy; user behavior; research frameworks and conceptual models; and integration (2019). Most studies, over 27%, addressed the first category, issues related to repository design. The experience of implementing a repository in DSpace is described by J. Barwick (2007). The main problem in implementing the repository at the university was the restrictive copyright of publishers and the identification of versions of articles suitable for publication in the repository, which eventually led to the recommendation not to grant copyright to publishers. A. Miller (2017) discusses a partnership approach to academics that not only helps to increase the amount of content made available in the repository, but also to build a community of practice. He recommends that legal and ethical issues with copyright should be prevented at the evaluation stage of projects. Coughlin (2022) describes the process of implementing and maintaining a university institutional repository in the Samvera system, focusing particularly on the transition to a new solution based on user needs. He highlights how difficult it is to select the appropriate infrastructure to support the platforms as it is difficult to predict in advance how they will be used. Sweeper and Ramsden (2020) in their study emphasize the role of stakeholders in helping to extend the reach of the repository as well as working with faculty to engage them in using the repository, as this supports the integration of the role of the repository in the university’s strategic plans. Stein (2021) also emphasizes the need to reflect the views and needs of faculty and students who will use the repository in decision-making processes. Li and Ronghui recommend building a service-oriented repository by linking the repository to the scientific research management (2019). The COAR working group, formed in 2016 to explore the next generation of repositories, presents a vision of “repositories as the foundation for a distributed, globally networked infrastructure for scholarly communication, on which value-added service layers will be deployed, transforming the system to be more research-oriented, open to and supportive of innovation, and collectively managed by the scholarly community” (COAR, 2017). Our approach to implementing an institutional repository meets this vision. Repositories in most institutions are used to make the scholarly output of faculty members available in the form of articles and educational materials. A few repositories provide space for research data. In our paper, we describe a repository that provides access to platforms used by scientists to apply data in the research process. The resulting architecture is not oriented towards homogeneous groups of institutional employees but is tailored to different communities and scientific domains in order to assist scientific research and to foster collaborations with other scientists outside the institution. Our goal is to partner with scholars and colleagues at the university in research, offering them a repository for their structured research data, digitized cultural heritage objects, and the tools and processes they use to analyse them. Rather than focusing on the general characteristics of repository implementation, we focus in detail on decision-making process in every step involved in converting digital platforms into a repository.

The primary objective of the LINDAT/CLARIAH-CZ infrastructure is to make resources and data in the fields of arts and humanities available to researchers, students, and, thanks to the emphasis on open access, also to the public or companies from the industry. As one of the partners in these efforts, the Faculty of Arts MUNI contributes in several areas (see Fig. 1).

Fig. 1. 
LINDAT/CLARIAH-CZ among large research infrastructures

The most important part is building a trustworthy repository for the long-term storage of digital platforms created at the Faculty of Arts MUNI. It is called Digitalia MUNI ARTS (https://digitalia.phil.muni.cz/en). We transfer metadata of the stored platforms to the central repository of the LINDAT/CLARIAH-CZ research infrastructure (https://lindat.cz) in accordance with the adopted metadata schema, which also supports the visibility of implemented and emerging research projects, data reuse and cooperation with partners at home and abroad. We also provide support and consulting for academics who develop their own digital platforms. For our purposes, we understand a digital platform as an application framework that specifies the basic structure and functions of the system by both hardware and software means in such a way that the resulting architecture is modular, programmable, and interoperable with other applications, technologies, and services (Bogost - Montfort, 2007; Baldwin - Woodard, 2009). The digital platform serves as a virtual research environment for a user community in a given domain. When moving digital platforms and databases to the Digitalia MUNI ARTS infrastructure repository, we adapt the individual interface of each platform to the requirements of their creators and the needs of researchers, focusing on usefulness and usability with the secondary goal of enabling needs and infrastructure users modeling. In the transfer, metadata is also enriched in order to make the platforms more effective in research. The unrealized goal so far is data enrichment, supporting the use of digital research methods to find answers to long-term as well as current questions in humanities and social sciences. For this purpose, we plan to use tools supporting digital research, e.g. using the NameTag tool (Straka & Straková, 2014) for the recognition of named entities in selected text platforms. By combining services and data sources, infrastructure becomes an integral part of research. Technology and its configuration delimit the questions that can be subsequently asked by means of them. Thus, the infrastructure becomes the way how to ask questions and its structure identifies what is [storable], while the identification determines its structure at the same time (Derrida, 1996). However, formulating meaningful questions depends on experts, as does the resulting interpretation of the obtained data. Another goal is to support the consolidation and growth of the community of digital humanities scholars at the Faculty of Arts MUNI and the promotion of digital humanities. In the following chapters, we will focus on the building of the local infrastructure for digital platforms at the Faculty of Arts - Digitalia MUNI ARTS (see Fig. 2).

Fig. 2. 
Situating Digitalia MUNI ARTS in LINDAT/CLARIAH-CZ

One of the first steps of the project was setting up the team and preparing the environment for building the infrastructure. The core of the team consists of the main project researcher (at the same time, the coordinator with the role of information requirement analyst), project manager, metadata librarian, and two programmers. This core became the basis of a wider project team, which has changed over time. Since its inception, the project has involved 14 people in a total of 2 FTE/year. Other roles represented in the project team: digital curator, digital humanities specialist or discipline-specific consultant.

To transfer the already existing platforms to the Digitalia MUNI ARTS infrastructure, we have set up a specific procedure in the form of a checklist, modified for individual platforms. In general, it contains four stages divided into several parallel sub-processes: domain model - data migration - interface creation - user testing. The division into four phases is the result of a combination of several sources (Miller, 2015; Van Tuyl, Gum, Mellinger, Ramirez, Straley, Wick, & Zhang, 2018; Hardesty & Homenda, 2019) and empirical expertise of individuals within the team (digital curation, programming, project management). Each successfully published platform was a source of learning and improvement of applied practices.

Fig. 3. 
Digitalia MUNI ARTS workflow

∙ User testing

1) User testing of the prototype

In the last stage, user testing is performed using the created prototype of the transferred platform. The aim is to find out how effective and intuitive the platform interface is. We prepare a list of tasks for the testers to complete in the database. We design tasks in such a way that they require using various functions of the platform, such as filtering the content, downloading data, and comparing search results. Then, we observe the testers during the performance of tasks and conduct a short interview with them to explain some of the steps. Based on the results of testing and feedback from users, modifications of the platform are made and the accompanying technical and curation documentation of the platform is completed.

2) Presentation to the public

After the modifications are finished, the platform is transferred from the Dev server to a live version intended for publication. The final form of the platform is publicly presented to the academic community, students, project partners, and other interested experts at the announced meeting. Primarily, new functionalities and possibilities of working with the accessed research data and digital objects are presented.

Fig. 4. 
Platforms migration to infrastructure

During the migration of the platforms, which was implemented according to the procedure proposed on the basis of the above-described general principles, we encountered several problems that hindered or otherwise complicated the completion of the entire transfer process. Each iteration of the procedure revealed different problems. After the completion of the transfer of each platform, the entire core team assembled at a joint meeting to analyse the identified problems and reflect them in a modified procedure. The problems that we had to deal with can be classified as communication problems, problems of external dependence, and management problems.

Communication problems primarily concerned misunderstandings between our team and the team of creators and administrators of the converted platform. In the course of cooperation, it was necessary to clarify the concepts that were used with a different meaning or were not understood by the humanities experts. Concepts such as platform, research infrastructure, digital library or metadata were particularly difficult to understand. The result was a series of concerns that sometimes led to refusal. The scholars feared that their platform would become buried and lost among other platforms in the infrastructure, the visibility of the platform would decrease, the access of the designated community to the results of their work would become more difficult, or there would be a loss of control over the data or the entire platform. We also encountered a refusal to process metadata, because it did not contribute to the research itself and its creation was seen as unnecessarily time-consuming. Often, these misunderstandings and concerns can be overcome by explaining the state of affairs and the usefulness of the procedure, but even this is not necessarily the rule. We also experienced a misunderstanding with the partner who eventually withdrew from the platform migration; this is also the reason why one of the planned platforms was not transferred to the infrastructure and was replaced by another platform according to the order. It was necessary to formalize the transfer protocol and also to clearly define the competences and obligations of the parties, including the assurances on the copyright of the creators of the platform.

Also, it is necessary to clearly formulate what input data and information will be needed from the administrators to move the platform and regularly inform them about the course of work on the transfer. For more effective communication, it is also necessary to get better acquainted with the terminology and theories of the modelled knowledge domain, which requires a deeper immersion in the topic than just relying on interviews with experts and creators. The concept of open science and open data, including FAIR principles, also needs to be communicated clearly. Although the resistance and distrust of scholars to the concept of open science has been relatively rare, the desire to monetize the outputs of their research work or to make it somehow exclusive, as well as the pressure resulting from the evaluation of research work, still block the way to some interesting platforms that have a high potential for research in digital humanities. However, a more frequent problem concerns licences to the contents of the platforms. For some of the sources, it is not clearly determined who the intellectual property belongs to, especially if some of the authors are already dead or where the digitized source was created as a result of cooperation of a number of authors from several institutions. When communicating and tackling these problems, we also used consultations and cooperation with a lawyer and the MUNI Open Science support group to assist us in the selection of appropriate licences.

This brings us to the problems of external dependence. The pace of progress on the project must be harmonized and often adapted to the pace of the various organizational units of the university. Continuity with the faculty or university environment is also in the adopted information policy of the institution, which, in addition to licences, determines also the treatment of the work made for hire, the policy of self-archiving, reporting the results of the research work, including reporting the use of the infrastructure itself. We also had to resolve a serious security problem associated with a hacker attack on one of the infrastructure servers. The programmers faced a DDoS attack and were assisted by the MUNI Cybersecurity Team, which performed a forensic analysis and helped with providing server security.

Management problems mainly concerned the timing of processes and procedures. Interviews with creators and experts as well as the examination of users and their research practices led to the identification of a large number of requirements and needs, the satisfaction of which would require considerable work commitment and time capacities. Due to the large number of platforms and the pace at which more are created (around ten per year) and the limited number of people working on the infrastructure, only limited attention can be paid to each platform. This leads to the necessary prioritization of the identified requirements; the part of the requirements categorized as “nice to have” is moved to the documentation and postponed for an unspecified future time. The problem occurs also if the platform does not have sufficiently cleaned or metadata-described data. The involvement of our team in data cleaning is not desired, due to limited time capacities; we refer the platform developers to data analysts that they can hire for data cleaning. We also entrust the metadata description to the original team. Nevertheless, we offer at least a little help with fine-tuning the results, still, only to a limited extent, so that it does not interfere with our ability to ensure the transfer of data to a high-quality platform architecture with a user-friendly interface.

The last major problem that we had to address so far consists in the very nature of research data and platforms. The infrastructure is used for research and, by its nature, requires not only accessibility, but also modification and expansion of data sets. At the same time, research data in individual platforms needs to be stored in the long term with all appropriate archival procedures provided. The digital library and digital archive meet in the infrastructure with their presentation and archiving functions: the infrastructure ensures the archiving of live data. This raises the problem of clearly defining the difference between small and large changes with consequences for subsequent archival and also citation practices.

After identifying the problems, we complemented the platform migration procedure in order to prevent possible problems and speed up the transfer process. These modifications, complementing the general principles of the procedure, are the result of practices that have proven their value and have helped streamline the whole process of transferring platforms to the infrastructure.

• ∙ A joint introductory meeting - at the beginning of the transfer of the specific platform, before the commencement of discussions with experts, we organize a clarification meeting of the creators, programmers and administrators of the platform with the entire core team of the infrastructure. At the meeting, we explain the selected concepts, which will help us not only streamline communication and prevent misunderstandings, but also realistically define the expectations of what we can provide to the target group. We pay particular attention to the concepts of large research infrastructure, repository or digital library and metadata. We also pay attention to the unification of terminology, as the same terms may have different meanings in other domains.
• ∙ A handover protocol - in the preparation stage, we set up a handover protocol on the transfer of the platform to the infrastructure, to be signed by both parties, i.e., the creators/administrators and the representatives of the infrastructure team. The protocol clearly sets out the responsibilities and obligations of the parties involved.
• ∙ Expert consultation on licences - still in the first stage, it is also necessary to set up the rights and licenses for the entire content of the platform and decide on the degree of data openness. We will invite a lawyer and the Open Science MUNI group to assist in the selection of appropriate licenses.
• ∙ Identification of theories - during domain modelling, we study expert articles by researchers in order to understand the theoretical background and how to use the collected data to produce knowledge in a given domain, which is beneficial mainly in the stage of designing the platform functions.
• ∙ Progress report - we try to prevent communication misunderstandings by regularly reporting on the progress of work. In the course of the platform transfer process, platform developers/ managers are informed at fortnightly intervals about the progress and results of the platform transfer to the infrastructure.
• ∙ Requirement prioritization - we have included two core team meetings in the process of transfer of each platform, to go through and evaluate the requirements and identified needs of users and creators. The first prioritization meeting takes place after the creation of the list of functions and recommendations based on the analysis of interviews with creators and users, the second one after user testing and demonstration of the platform prototype to creators. Each requirement or need is evaluated on a must-have, nice to have, long term and not needed scale with an estimate of the time demand of its implementation into the platform. Requirements that will not be incorporated into the final version of the prototype are recorded together with an estimate of time demand as an addendum to the handover protocol.

Cultivation of data culture is a long-term strategic goal, which is systematically addressed by delegated groups at the university. We try to contribute to its development by educating students in a faculty-wide course, annually organizing several thematic workshops for students from the academic community, inviting also colleagues from partner institutions or other large research infrastructures, as well as meetings with the professional public when presenting the transferred platforms. Despite the increasing availability of digitized sources and data, research practices of experts do not undergo significant changes. Easier accessibility and searching in digital sources are used, using the potential of computational methods for analysis is less frequent. Therefore, in the future, we plan to focus more on the implementation of language technologies provided by the LINDAT/CLARIAH-CZ repository into individual platforms and semantization of the administered data using crowdsourcing workshops, where we expect to create a virtual research environment supporting data analysis by non-technological users and form groups of enthusiasts around platforms who will learn methods of more advanced work with the research data accessed in this way. The creators of new platforms also often ask us for recommendations of programmers to help them implement their plans. Therefore, we are going to create a tool for sharing time and expertise that would connect both expert groups.