1. Objective of the inclusion criteria for EOSC-Exchange providers and resources
The following inclusion criteria are used to validate that providers and resources willing to join EOSC-Exchange are fulfilling a set of requirements based on the EOSC Rules of Participation. The EOSC Rules of Participation are expected to evolve, with the involvement of the EOSC Association Rules of Participation Task Force, and will be formally adopted by the governance structures of the EOSC (including the EOSC Association General Assembly, European Commission and the EOSC Steering Board).
2. Inclusion criteria to onboard as EOSC Provider
This inclusion criteria applies to all Providers willing to onboard any type of resource to EOSC-Exchange.
Every EOSC Provider must either be a legal entity itself or must identify a legal entity of which it is a part or with which it is affiliated, which is accountable for the resources being onboarded to EOSC. The legal entity in question is called the "hosting legal entity" and will need to be registered in the EOSC Resource Catalogue before an affiliated provider or its services can be onboarded.
Intends to onboard resources to EOSC-Exchange that are targeted to EOSC and EOSC communities, or built on or leverage EOSC capabilities to serve some other community.
Agree on periodically updating data on service providers and their resources. This includes removing resources that are no longer operational or available.
- Provider profile information must be provided in English.
3. Inclusion criteria to onboard resources
3.1. Common inclusion criteria to onboard all resource types
Only onboarded providers will be able to onboard different types of resources to EOSC-Exchange. The resource types can be: services (being data sources a specific type of service), catalogues, research products, training resources and interoperability guidelines. This section describes general requirements for all EOSC-Exchange resource types, which are complemented by specific requirements for each type of resource to be onboarded to EOSC-Exchange that are detailed below.
Common inclusion criteria to onboard all resource types:
- Providers must first be onboarded as an EOSC Provider before being able to onboard resources.
- The resource to be onboarded is targeted to EOSC and EOSC communities, or built on or that leverage EOSC capabilities to serve some other community.
- Examples of resources targeted at EOSC and EOSC communities include: services created by researchers or for researchers, or a commercial service with an offer specifically addressed to EOSC and research customers, rather than a generic commercial service. A joint procurement framework or a call program for requesting resources targeting EOSC and/or EOSC communities are examples of the latter.
- Examples of resources built on or that leverage EOSC capabilities to serve some other community include: offerings from the Digital Innovation Hubs, which rely on EOSC expertise, resources, and capabilities to create new, innovative commercial services.
Examples of training resources targeted at EOSC and EOSC communities are the ones related to open science, research data management, and how to use EOSC resources.
- For federated or jointly provided resources, the resource onboarding must be done by the coordinating or lead provider (i.e. the coordinating or lead provider is the “Resource organisation” in the resource profile). Other providers may also onboard as EOSC Resource Providers if they wish to appear as supplementary or supporting providers. Such providers will be listed as “Resource providers” in the resource profile.
- The resource provider commits to maintain resource descriptions up-to-date, this includes removing resources that are no longer operational or available.
- Resource profile information must be provided in English.
3.2. Additional inclusion criteria to onboard a community resource catalogue
In addition to meeting the common inclusion criteria to onboard all resource types, these criteria must be met to onboard a community catalogue:
- To have a documented and methodical approach for the validation of information about resources that have been included in CO's own catalogue.
- To ensure that records are kept up-to-date and that providers are prepared to correct errors if and when they are identified during the verification (auditing) procedures of EOSC Resource Catalogue records.
- To onboard and synchronise records with the EOSC Resource Catalogue.
- To cooperate with the operators of the EOSC Portal in ensuring that policies across catalogues are consistent by participating in the EOSC Onboarding Strategy Group (E-OSG).
- To follow the EOSC Security Operational Baseline, as implemented by EOSC Future.
- To declare conformance to the inclusion criteria to onboard a resource catalogue by sending an EOSC Catalogue Onboarding Agreement.
3.3. Additional inclusion criteria to onboard a service
In addition to meeting the common inclusion criteria to onboard all resource types, these criteria must be met to onboard a service:
- Be a single and distinct service (i.e. not a generic list of services but a service in its own right). It can be an IT service, a consulting, or training service, among others (note 2).
- Be available and offer value on its own.
- Be mature, meaning a Technology Readiness Level (TRL) 8 or higher, or beta services (TRL7) that are clearly labelled as beta. Beta services are not orderable. Beta services are less mature and are expected to evolve, therefore using beta services is at your own risk.
- Use URLs that are Fully Qualified Domain Names (FQDNs) and follow security best practices; for example, using TLS with the service presenting a certificate issued by a certificate authority trusted by most web browsers.
- The service must be accessible from one or more European country (EU countries plus EEA, UK) and to European researchers.
- If the default language of the service is not in English, but in one or more other European Language(s) (note 1), basic information in the User Interface of the service must be available in English.
- The service provider must provide all key information such as Privacy statement, Service Level Agreements, Specifications and Descriptions in English, or Data and Metadata policies and licenses. Other documentation may be in a different language to English.
- The service helpdesk or support channel must be able to answer questions in English.
- The service provider must follow the EOSC Security Operational Baseline, as implemented by EOSC Future.
When the service to onboard is a data source, the provider must specify metadata characterising the data source profile.
3.4. Additional inclusion criteria to onboard a research product
Research products are onboarded to the EOSC via Data Sources of the following kinds: repository, journal archive, publisher archive, scientific database, CRIS systems, and aggregators. To onboard research products into the EOSC Resource Catalogue, Data sources must:
- Be onboarded in the EOSC Catalogue & Marketplace;
- Comply to the EOSC IF Guidelines for data sources to onboard research products (The link to the EOSC Guidelines will be added once they are approved).
Other inclusion criteria are under discussion for the future, such as a minimum FAIR score for metadata records according to the RDA FAIR Maturity Model Working Group - specification and guidelines.
Other criteria are under discussion for the future, such as a minimum FAIR score for metadata records according to the RDA FAIR Maturity Model Working Group - specification and guidelines.
3.5 Additional inclusion criteria to onboard a training resource
In addition to meeting the common inclusion criteria to onboard all resource types, these criteria must be met to onboard training resources:
- Provide metadata in English when filling-in the EOSC Training resource profile.
- Specify the learning outcomes, resource type (e.g. recorded lesson, textbook, activity plan, etc.), content resource type (e.g. video, slides, audio, etc.), and estimated duration (e.g. estimated work hours).
- Be in one of the European language(s) (note 1)
- Incorporate information about the expected level of training and expertise to be achieved (beginner, intermediate, advanced, all) and required qualifications to access the training resource.
- Comply with the FAIR principles, open and reproducible science practices, and have a defined approach to adherence to them. The provider also ensures file technical integrity (completeness of metadata to facilitate discovery and reuse, PIDs, etc.). In addition to ensuring the technical integrity of files, the provider should provide the most accurate metadata possible: all mandatory metadata is provided; all copyright, usage conditions, access constraints, licensing are declared; and all sources are credited when pre-existing resources are reused.
Provide information about the resource's provenance.
Be periodically updated and include the date of the last update to prevent outdated content. In the event that a training resource is not well maintained but is still useful, the provider must include a note that maintenance has been discontinued.
- Ensure preservation (e.g. resources are deposited in a repository/platform that can ensure that they are accessible for a reasonable (3-5 years) period of time, preferably in trusted repositories with a long-term preservation policy). EOSC does not offer long-term preservation.
3.6. Additional inclusion criteria to onboard an interoperability guideline
In addition to meeting the common inclusion criteria to onboard all resource types, these criteria must be met to onboard an interoperability guideline:
- The guidelines documentation and description (i.e. the metadata defined by the provider) is actively maintained.
Use a well-supported, commonly used and open public repository to host or publish the guidelines that is capable of version control for future versions of the documentation or software, and that will assign a PID.
Ensure that the described technical interoperability has been demonstrated in a relevant environment.
Ensure the guideline is mature, meaning that it is version 1+, or higher, that it is actively maintained and/or that it has evidenced uptake. This refers to at least part of the available software (necessary for) implementing the guideline and that it includes adequate support documentation.
The guideline must comprise the minimum required information as specified in the templates found at https://eosc-portal.eu/eosc-interoperability-framework
The guideline must have a documented and methodical approach to the description of how to implement its recommendations and related software.
URLs cited in the guideline documentation or the guideline’s EOSC-hosted metadata should have a Fully Qualified Domain Name (FQDN).
Also and specifically for EOSC-Exchange Interoperability Guidelines (thematic and horizontal interoperability guidelines as defined in the EOSC Glossary):
The Provider must be able to show evidence of prior utilisation of the guideline in the given communities if asked to do so by the evaluation team. This could be evidenced by descriptions of uptake and/or maturity.
The Provider must be able to show evidence of prior consultation with the relevant community/ies if asked to do so by the EPOT.
Notes of clarifications:
- European languages in which the resource could be available
- Research products such as documents, datasets, and a piece of software are not considered services
- There is not a minimum TRL required to onboard research products as they are products of science (e.g. articles and datasets) and this concept does not apply to them.
- There is not a minimum TRL required to onboard training resources as this this concept does not apply to them.