# EOSC-IF / Interoperability Guideline: Research Product Deposition

Alessia Bardi, Paolo Manghi, Jose Benito Gonzalez Lopez, Chris Ariyo, Andreas Czerniak, Paul Gondim van Dongen, Georgios Kakaletris, Raul Palma, Silvio Peroni, Diego Scardaci, et al.

<figure><img src="image_1.png" /></figure>

► To cite this version:

Alessia Bardi, Paolo Manghi, Jose Benito Gonzalez Lopez, Chris Ariyo, Andreas Czerniak, et al. "EOSC-IF / Interoperability Guideline: Research Product Deposition." 2023. 10.5281/zenodo.8091897. [hal-04634036]

HAL Id: hal-04634036

https://hal.science/hal-04634036v1

Submitted on 3 Jul 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# EOSC-IF
## Interoperability
### Guideline: Research
Product Deposition

<figure><img src="image_3.png" /></figure>
# EOSC-IF / Interoperability Guideline: Research Product Deposition

Lead by **CNR**

Authored by the EOSC Future Working Group on Research Product Publishing: Alessia Bardi (CNR), Paolo Manghi (OpenAIRE), Jose Benito Gonzalez Lopez (CERN), Chris Ariyo (EUDAT), Andreas Czerniak (Bielefeld University Library), Paul Gondim van Dongen (SURF), Georgios Kakaletris (NKUA), Raul Palma (PSNC), Silvio Peroni (University of Bologna), Hans van Piggelen (SURF), Mark van de Sanden (EUDAT), Diego Scardaci (EGI), Jochen Schirrwagen (Bielefeld University Library), Debora Testi (CINECA), Raphaël Tournoy (CNRS), Irena Vipavc (Social Science Data Archive, University of Ljubljana), Deborah Grbac (Library of Università Cattolica del Sacro Cuore di Milano), Carl-Fredrik Enell (EISCAT Scientific Association), Guido Aben (CS3MESH4EOSC), Ivan Heibi (University of Bologna), Jorik van Kemenade (SURF)

Reviewed by Michelle Williams (GÉANT)

## Dissemination Level of the Document

Public

## Abstract

Open Science calls for researchers to publish as soon as possible any type of research product in such a way their research activity can be transparently assessed, reviewed, reproduced, and rewarded in all its aspects. However, the publishing process has become more and more a burden for scientists, who must, most of the time, spend time to publish their articles, data, software, and other products in the many institutional or thematic repositories of reference. Scenarios include first-time publishing of new resource products or double-publishing of research products, to satisfy institutional mandates and community practices. Such tedious work is often incomplete, with some products ending up unpublished and others showing incomplete or imprecise metadata.

Some communities investigated and realised the integration of their research performing services, from research infrastructures and clusters, with repositories for research product deposition. The integration ensures that outcomes of such services are deposited automatically, prior authorization of the users, into a given repository, giving life to an end-to-end scientific workflow, from experimentation to publishing.

The limit of existing approaches is to be bound to a specific repository API and format; introducing multiple repositories as potential targets of deposition for the service, multiplies the problem, as bilateral interactions with the respective repository API must be established. For example, the Zenodo deposition API and the B2SHARE API are similar but different in many ways; a service willing to automate publishing into either repositories would require implementing and maintaining two different workflows.

For the EOSC to act as enabler for Open Science practices, its Interoperability Framework should guide services of research infrastructures and clusters of the EOSC on how to implement (semi-)automated workflows for the deposition and consumption of research products. To support different integration options, two modalities are supported by these guidelines: SWORD protocol v3 for push mode and a combination of COAR Notify and Signposting for pull mode. The EOSC guidelines for research product onboarding are suggested as metadata exchange format.
## Version History

<table><thead><tr><td>Version</td><td>Date</td><td>Authors/Contributors</td><td>Description</td></tr></thead><tbody><tr><td>V0.1</td><td>08/05/2023</td><td>Alessia Bardi (CNR)</td><td>Initiation</td></tr><tr><td>V1.0</td><td>28/06/2023</td><td>Alessia Bardi (CNR)</td><td>Version for submission</td></tr></tbody></table>

## Copyright Notice

<figure><img src="image_4.png" /></figure>

This work by Parties of the EOSC Future Consortium is licensed under a [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/). The EOSC Future project is co-funded by the European Union Horizon Programme call INFRAEOSC-03-2020, Grant Agreement number 101017536.
# Table of Contents

<table><tr><td>1.</td><td>Glossary</td><td>2</td></tr><tr><td>2.</td><td>List of Abbreviations</td><td>2</td></tr><tr><td>1</td><td>Intended Audience</td><td>3</td></tr><tr><td>2</td><td>Description and Response to Community Need</td><td>3</td></tr><tr><td>3</td><td>Licensing Information</td><td>4</td></tr><tr><td>4</td><td>Related Standards</td><td>4</td></tr><tr><td>5</td><td>Integration Options</td><td>5</td></tr><tr><td>6</td><td>Interoperability Guidelines</td><td>5</td></tr><tr><td>7</td><td>Examples of solutions implementing this specification</td><td>6</td></tr></table>

# Glossary

EOSC Future project Glossary is incorporated by reference: https://wiki.eoscfuture.eu/x/JQCK

## List of Abbreviations

<table><thead><tr><td>Acronym</td><td>Definition</td></tr></thead><tbody><tr><td>API</td><td>Application Programming Interface</td></tr><tr><td>COAR</td><td>Confederation of Open Access Repositories</td></tr><tr><td>EOSC</td><td>European Open Science Cloud</td></tr><tr><td>EOSC IF</td><td>European Open Science Cloud - Interoperability Framework</td></tr><tr><td>HAL</td><td>Hyper Article en Ligne</td></tr><tr><td>PID</td><td>Persistent identifier</td></tr><tr><td>URI</td><td>Uniform Resource Identifier</td></tr><tr><td>URL</td><td>Uniform Resource Locator</td></tr><tr><td>WG</td><td>Working Group</td></tr></tbody></table>
<figure><img src="image_5.png" /></figure>

EOSC Future

eoscfuture.eu

# 1 Intended Audience

These guidelines target the technical experts responsible for services used by researchers for generating or publishing research products. Examples include, but are not limited to: e-infrastructure services, thematic services, data repositories, institutional repositories, data archives, overlay journals, publishing platforms.

# 2 Description and Response to Community Need

Open Science calls for researchers to publish as soon as possible any type of research product in such a way their research activity can be transparently assessed, reviewed, reproduced, and rewarded in all its aspects.

The publishing process has become more and more a burden for scientists, who must, most of the time, spend time to publish their articles, data, software, and other products in the many institutional or thematic repositories of reference. Such tedious work is often incomplete, with some products ending up unpublished and others showing incomplete or imprecise metadata. As a solution to these problems, some communities investigated and realised the integration of their research performing services, from RIs and Clusters, with repositories. The integration ensures that outcomes of such services are deposited by the services, prior authorisation of the users, into a given repository, giving life to an end-to-end scientific workflow, from experimentation to publishing. The limit of existing approaches is to be bound to a specific repository API and format; introducing multiple repositories as potential targets of deposition for the service, multiplies the problem, as bilateral interactions with the respective repository API must be established. For example, the Zenodo deposition API and the B2SHARE API are similar but different in many ways; a service willing to automate publishing into either repositories would require implementing and maintaining two different workflows.

With these guidelines, research infrastructures will be able to easily integrate any compliant deposition platform without the need of developing and maintaining any platform-specific API. Fig. 3.1 illustrates four scenarios that would benefit from the adoption of the guidelines for research product deposition.

## 1. Scenario 1 - thematic service and deposition options

A researcher uses a thematic service and produces a research product (e.g. a dataset) that is stored in a storage resource of the underlying e-infrastructure. The thematic service can propose to the researcher several deposition options, targeting repositories that are known to be compatible with the EOSC Interoperability Framework for research product publishing.

## 2. Scenario 2 - Automatic deposition into repositories of reference

A researcher deposits a research product (e.g. a publication) on a thematic repository. By knowing the affiliation of the researcher, the thematic repository can automatically deposit the publication also in the institutional repository of reference. In a similar way, if the researcher deposits the publication in the institutional repository and provides information about the co-authors, the repository can automatically deposit the publication in the institutional repositories of the co-authors.

## 3. Scenario 3 - Automatic Open Access deposition from e-infra service

A researcher uses a thematic service and produces a research product (e.g. a dataset) that is stored in a storage resource of the underlying e-infrastructures. The researcher wants to deposit the product on an Open Access repository, but has to wait for an embargo period. The storage resource, based on a configuration provided by the researcher, can automatically deposit the product on an Open Access repository when the embargo period ends (so the researcher does not need to remember that the asset prepared months before can now be made available in Open Access).

## 4. Scenario 4 - Seamless submission process via publishing platform and overlay journals

Overlay publishing platforms and overlay journals typically suggest their users to deposit their research assets in repositories and get back with the identifier/PID/URI of the deposition so as to proceed with the publication workflow. With the EOSC IF for research product publishing, the platforms and overlay journals could offer their users an integrated experience.
<figure><img src="image_6.png" /></figure>

<figure><img src="image_7.png" /></figure>

<figure><img src="image_8.png" /></figure>

<figure><img src="image_9.png" /></figure>

<figure><img src="image_10.png" /><figcaption>Figure 1 Scenarios that would benefit from the EOSC IF guidelines for research product deposition</figcaption></figure>

## 3 Licensing Information

This work by Parties of the EOSC Future Consortium is licensed under a [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/). The EOSC Future project is co-funded by the European Union Horizon Programme call INFRAEOSC-03-2020, Grant Agreement number 101017536.

Signposting the Scholarly Web by http://signposting.org is licensed under a [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/).

## 4 Related Standards

<table><caption>Table 1: Related Standards</caption><thead><tr><td>Title</td><td>Short Description</td><td>relatedIdentifier</td></tr></thead><tbody><tr><td>Name or Title of the Related Standard</td><td>To describe the context in which the Interoperability Guideline uses or depends on these standards, protocols, APIs and guidelines, rather than providing a short description of the standards, etc, themselves.</td><td>Identifiers of related resources. These must be globally unique identifiers. ref EIG.BAI.22<br>e.g. https://argoeu.github.io/argomonitoring/docs/Monitoring/guidelines/</td></tr><tr><td>SWORD v3</td><td>To implement (semi-)automatic deposition workflows in push mode</td><td>https://sword.cottagelabs.com/swordv3/</td></tr><tr><td>COAR Notify</td><td>To implement (semi-)automatic deposition workflows in pull mode</td><td>https://www.coar-repositories.org/notify/</td></tr><tr><td>Signposting</td><td></td><td>https://signposting.org/</td></tr><tr><td>OpenAIRE Guidelines v4.0</td><td>For the metadata exchange format</td><td>https://guidelines.openaire.eu/</td></tr></tbody></table>
# 5 Integration Options

These guidelines suggest two options:

* Push mode with SWORDv3

* Pull mode with COAR Notify + SignPosting

Both options can be used to send/receive payloads and metadata of research products or only metadata.

# 6 Interoperability Guidelines

## Push mode: SWORD v3

SWORD v3 comes with detailed documentation. In particular, the [Protocol Behaviours document](#) describes the requirements of clients and servers for a specific request.

A complete deposition succeeds when both metadata and files are successfully accepted and stored by the server.

According to the SWORD specification, servers must support Metadata Document in the DCMI format. This recommendation suggests the adoption of the format of the EOSC guidelines for research product onboarding, in particular the format of the [OpenAIRE guidelines version 4](#), which are based on the Datacite format.

The support must be declared by servers and used in clients' request as explained in [Section 19 Metadata Deposit](#), the identifier of the format (in form of URI) has to be decided.

Domain-specific communities may agree to accept additional metadata formats to support domain-specific use cases that cannot be addressed without domain-specific metadata formats.

Requests that are relevant in our context are:

* Creating new objects

* Appending to objects (to add metadata document and/or files)

## Pull mode: COAR Notify + Signposting

The service can inform the repository that something new is available at a given accessible location (with COAR Notify) and the repository can then use the Signposting protocol (implemented by the service) to know where to get the content and metadata for the deposition.

COAR Notify + Signposting: the service can inform the repository that something new is available at a given accessible location (with COAR Notify) and the repository can then use the Signposting protocol (implemented by the service) to know where to get the metadata and payload file(s) for the deposition.

1. Notify the target that a research product is available for ingest: [Request Ingest Pattern of COAR Notify](#). The id of the object must be a URL based on which it is possible to know where to find the metadata and the payload file(s)

2. The target fetches the payload file(s) via the object url element of the request

3. The target extracts the id and uses Signposting to know where to fetch the metadata record with the [Bibliographic Metadata Pattern](#). To specify the metadata format, a dedicated mime type (as done by Crossref and others) or a dedicated profile must be defined as described in the [Signposting conventions page](#).

## Recommended metadata exchange formats

1. Latest versions of the [OpenAIRE guidelines](#) (EOSC guidelines for onboarding of research products)

2. Other community specific format may be adopted in addition to them
<figure><img src="image_11.png" /></figure>

EOSC Future

eoscfuture.eu

## 7 Examples of solutions implementing this specification

* HAL and Episciences implemented the COAR Notify and Signposting protocols in production, while other use cases, including the one between HAL and Peer Community In are planned to be implemented by Summer 2023.

* OpenAIRE is including the implementation of the framework in its roadmap to improve the metadata integration with Zenodo and other repositories.

* Episciences and Software Heritage are working on the implementation of COAR Notify in the context of the FAIRCORE4EOSC EC project (first version by Dec 2023).

* SWORDv3 is implemented by SoftwareHeritage and was used for the implementation of deposition workflow with HAL, Zenodo, and episciences.org

### References:

* https://www.inria.fr/en/hal-opening-up-to-software

* https://www.softwareheritage.org/2020/10/27/connecting-scholarly-repositories-with-the-software-heritage-archive/

* https://github.com/inveniosoftware/invenio-swh

More information about the work of the EOSC Future Working Group on Research product Publishing can be found in the wiki page of the WG.