How do DARIAH research outputs meet the EOSC? – a case study 

In our EOSC blog post series, we do our best to debunk the big acronym and to bring recent developments happening in the many angles of the big infrastructure and the social layers around it closer to arts and humanities scholars’ desks. So far, we wrote about the basic architecture of the EOSC, how arts and humanities relevant services can be found or how DARIAH is contributing to them but we haven’t yet discussed content dimensions, that is, how  our publications, research data, software or other content types that are important for our scholarship make their way to the EOSC. 

In the following posts, we are going to show examples for such pathways, also because we believe that this is the most concrete, tangible way to provide you with a compass to the EOSC and help you assess how you can make the best use of it. 

Have you ever thought of how to link and bring the different project outputs under the same roof? 

For a start, let us take a fairly everyday situation of working on a research project. 

Source materials, bibliographies, research data at different stages of curation, methodological notes, different versions of code used for analysis, documentation guides, codebooks, conference presentations, project reports, pre-prints and of course, the hardest currencies of present-day academia: research papers, books or book chapters – these are just random examples showcasing the richness of the content types that might be produced at different stages of a research project. Some might get deleted or lost entirely on one’s hard drive but thanks to the fast-evolving Open Access, Open Data and FAIR data mandates, the proportion of outcomes to be shared and the ones to be discarded or remain hidden is changing for the better. 

But even those out there are usually scattered across different platforms and different silos of the Internet: some stay on the project website or on GitHub, while others are sustainably shared in repositories or at the publishers’ content management systems. Notably, research teams have different levels of control over these platforms. While it is fully at their disposal to decide which content to share in a repository and under which conditions, and sometimes they can even expand descriptive metadata; as authors, their control over the overall quality of the publishing, the quality and richness of publisher metadata, their presence in indexing services or their ability to interlink author IDs (such as ORCID) or associated resources (such as a data set) is only restricted to the choice of the publisher. 

In any case, developing a clear overview of all the different outputs belonging to the same project, published in different time periods, connecting them and bringing them under the shared roof of a discovery environment, is a challenge of its own. 

Connecting dots via harvesting and semantic interlinking 

To explain how DARIAH infrastructural components can help in that and how the EOSC comes to the picture, let us take the example of a former Horizon 2020 project that is dear to DARIAH and to which many DARIAH partner institutions have contributed as project members, the CENDARI project. The project concluded in 2016 and therefore it doesn’t have an actively maintained website or contact point any longer but its outputs are still relevant and valuable and its impact and project afterlife is significant. 

The discovery environment we use to find and connect such valuable project outputs is the DARIAH-OpenAIRE Research Community Gateway. 

What is the DARIAH-OpenAIRE Research Community Gateway?  To bring together DARIAH-relevant outputs from this fragmented landscape, the OpenAIRE-DARIAH Gateway serves as a dedicated discovery hub to DARIAH-affiliated research outputs of different kinds as it brings them together from dispersed locations, and makes them searchable along different facets such as projects, content types or access conditions.  During the past years, we have been connecting thematic data services provided by national DARIAH members to the OpenAIRE Research Graph. This way, scholarly content types that are important for the arts and humanities communities (digital critical editions, audiovisual data, encoded documents, image collections etc.) became visible in the biggest publicly owned scholarly discovery system.  An increasing number of DARIAH-affiliated data services are becoming harvested by OpenAIRE and enrich the DARIAH Gateway. DARIAH-affiliated content is automatically collected to the gateway from HAL, Zenodo, TextGrid, NAKALA or ARCHE for exemple, but it is also detected and automatically identified across the OpenAIRE Research Graph that harvests a rich array of third-party databases, including that of publishers’. In addition, it is also possible to manually link content to the Gateway.

The best way to gain an overview of the CENDARI project outputs, including the ones that had been published years (!) after the project concluded, is to visit the gateway (https://dariah.openaire.eu/) and use the ‘Project’ filter in the advanced search possibility. To be inclusive with all content types, it is important to flag them below the search bar.

Browsing through the result page, you can see that even if data and code sharing was not mandated back then, and therefore we cannot find data records, it still yields a rich array of content types ranging from conference presentation and posters through methodological notes, project deliverables, book chapters and research papers (carefully interlinked to their preprint versions) to very unique, project-native outputs, such as archival guides. The clear versioning information gathered from the data sources prevents their chaotic presentation. 

Speaking of data sources, the faceted search on the left clearly reveals how scattered this interrelated body of work is in terms of hosting: records are brought together from 10 countries and 18 data sources including institutional, preprint and thematic data repositories as well as  academic publishers. 

How does the EOSC come into the picture and what is the value of it? 

Our small exercise shows how interrelated content comes together from isolated silos in a publicly maintained discovery environment that is DARIAH-specific but at the same time, is also a part of the biggest European, publicly maintained scholarly database, the OpenAIRE Research Graph. Speaking of broader contexts, the latter has become a core service within the EOSC. This service is called the EOSC Resource Catalogue.  

Under constant development in the past few years, the EOSC Resource Catalogue gathers services and research products to facilitate their sharing and discovery. All the outputs coming from the OpenAire Research Graph are harvested by the EOSC Resource Catalogue, so there is no need to duplicate the entries. In terms of disciplinary anchoring and tagging,  although gateways like the DARIAH Research Community Gateway are not separate hubs in this big container of the EOSC Resource Catalogue, there is an ongoing development to tag resources by discipline,  by science clusters or by organization such as  DARIAH services. Because of this interoperability between EU initiatives/infrastructures/search engines and their connection to institutional or thematic repositories, archiving research outputs once populates various catalogues automatically and contributes to the sustainability strategies of project outputs.  

This way, once your scholarly records become visible, they are findable to a far broader audience than the usual suspects or users that happened to stumble upon its website. This includes all kinds of research outputs, even the ones (research data, methodological notes etc.) that usually fall out of the scope or remain invisible in academic information management systems, such as Scopus, Web of Science or Google Scholar. 

Community control: how to make your own project outputs visible in the EOSC while linking them to the DARIAH Gateway

In case you cannot find your own outputs in the gateway, we strongly encourage you to contribute to the richness of the OpenAIRE-DARIAH gateway and link your own data sets and other research outputs by following a couple of fairly easy steps described guide here.

How to make it easier? Manage your expectations towards publishing and repository services 

CHECKLIST when selecting publishers for your papers and books: 

• Does your publisher provide a Persistent Identifier (PID) for your outputs? (A DOI, typically. This is a minimum requirement for harvesting or linking it to services discussed above.) 
• Does your publisher have long-term archiving workflows in place? (This is a service usually provided by 3rd party digital preservation services, such as CLOCKSS or Portico.) 
• Does your publisher provide rich metadata with your papers or book chapters in which it is possible to make reference to associated datasets and other resources? (This is a plus.) 

CHECKLIST when selecting a repository for your research data or other outputs: 

• Is your repository owned and sustainably governed by a public body (a research institution, public research infrastructure, CERN etc.?) 
• Does your repository have a robust PID and versioning policy implemented? 
• Does your repository have an OAI-PMH endpoint or other mechanisms enabling discovery services to harvest their content?
• Does your repository have a CoreTrustSeal certification? (This is a plus.) 
• Does your repository allow interlinking different outputs belonging to the same project (through related PIDs or through other semantic web technologies)? (This is a plus.) 

An increasingly common practice is to dedicate a Zenodo collection to the research project. A clear advantage of this is that it is easy to use by different disciplinary groups (being a discipline agnostic repository service, probably the most commonly used one in Europe) and that content in Zenodo is automatically harvested by OpenAIRE and other scholarly databases. A disadvantage is that discipline-or content type specific metadata or other specific, sophisticated data publishing possibilities are not available and there are no quality assurance mechanisms in place to check metadata accuracy and quality (opposed to other services such as HAL). 

In the next episodes of the series, we highlight pathways to other, more code related or paper related content types. 

---

---