Changes Planned for EOSC Profiles by November 2023

Summary of the upcoming changes:

EOSC Resource Profile will be disabled in the Providers Portal by the end of October, and Resource Profile API will be deprecated by March 2024.
EOSC Service Profile to be enhanced with 4 fields: Service Category, Marketplace Location, Horizontal Service and PIDs. Existing Category and Subcategory fields will be deprecated by March 2024.
Some but not all provider suggestions for new values of Controlled Vocabularies are accepted. Some fields will no longer allow suggestions of new controlled vocabulary values, since the vocabulary is reasonably broad or based on a standard reference.
All data related to existing Data Sources will be migrated to conform to the new logical structure, where a Data Source is a “subprofile” of a Service Profile (based on its Service Category).
Existing Training Material and Interoperability Framework Guideline Profiles will be enhanced with a new field: Marketplace Location.

EOSC Resource Profile

The EOSC Resource Profile type has been superseded by the EOSC Service Profile, which was introduced in June 2022. Today the two profiles are similar, as are the related API calls. However with the changes now underway, the EOSC Service Profile will be kept updated, while the EOSC Resource Profile will be deprecated in March 2024. If you are using the Resource Profile API, you need to start using the Service Profile API, including the changes described here. Updated Swagger pages can be found here: https://providers.eosc-portal.eu/openapi, along with implementation instructions and information about a sandbox instance where you can test the Service Profile with your data.

EOSC Service Profile

The EOSC Service Profile will be enhanced with several new fields:

Service Category (accepting multiple selections from a controlled vocabulary)
Marketplace Location (accepting multiple selections from a controlled vocabulary)
Horizontal Service (Yes/No)
PIDs.

Service Category

Upon initial implementation, the new Service Category field will have 4 possible values:

“Data Source”
“Compute”
“Storage”
“Other”.

This new field provides a simpler way of categorising services so that they can be more easily found by users in the Marketplace.

Many Providers are already familiar with the “Data Source” Service Category, and Services categorised as a “Data Source” also have a Data Source Subprofile record that captures information needed for Data Sources. In the future, the “Compute” and “Storage” service categories will work in a similar way, with specific subprofiles for each, allowing Providers to specify the characteristics of their compute and storage offerings to make findability, comparison and ordering easier for users.

The new Service Category field will be automatically populated based on the current value(s) for each Service in the Category field.

All services whose Category contains “Compute” or “Data Storage” will have the Service Category field populated with “Compute” and/or “Storage” respectively.
All other existing services will have “Other” set as the Service Category.

Once the new Profiles are in production, and this field is available for you to access, review and update, you can suggest additional categories of service to better annotate your offerings. However, our objective is to make this field easy to understand by users, so we will be curating these suggestions and targeting a vocabulary of approximately ten values at the most.

Marketplace Location

The new Service Category field will be complemented by another new field, Marketplace Location, which will allow each Provider to directly manage the placement of each of their services in the different sections of the EOSC Marketplace. The vocabulary for this field is as follows:

“Discover Research Outputs”
“Process and Analyze”
“Manage Research Data”
“Access Computing and Storage Resources”
“Access Research Infrastructures”
“Publish Research Outputs”
“Access Training Material”
“Find Instruments & Equipment”.

These values are defined by the Marketplace team – new values can be suggested by Providers through the Helpdesk, and as the Marketplace itself evolves, in consultation with both Providers and Users, new “marketplace locations” are possible and would be reflected in the vocabulary.

This new field will be automatically populated based on the current settings for most services, which have been established by the Marketplace team. Once the new Profiles are in production, this field will be available for you to access, review and update as you desire.

Horizontal Services

Horizontal services are defined as “a generic service or resource bringing significant value to two or more research infrastructures” (as agreed by the EOSC Technical Coordination Board December 2022). Onboarded Horizontal Services are more easily findable by users in the Marketplace.

While this field was initially created as an internal field, allowing the EOSC Portal Onboarding Team (EPOT) to designate appropriate services as “horizontal”, this decision should be made by Providers themselves. Therefore we are exposing this field to Providers, through the user interface as well as the updated Service Profile API, so that Providers can indicate their intent to provide certain services to a broader user base, and in turn making such services more easily findable in the Marketplace.

Any services marked with a “yes” in the Horizontal Service field will be reviewed by EPOT to confirm that the service aligns with the definition above.

Category and Subcategory

Category and Subcategory currently allow over one hundred values, which Providers have attempted to specify, but this information has proven too complicated to be useful to users in finding the resources they need. As described above, these fields will be replaced by the Service Category field. In March 2024, the Category and Subcategory fields will be deprecated.

PIDs

The Service Catalogue now mints PIDs internally for all resources onboarded either directly or through third party catalogues. These PIDs are stored in the field Identifiers. For example, the public API exposing resources to EOSC Core components (i.e. elevated privileges), such as:

curl --location --request GET 'https://providers.eosc-portal.eu/api/public/service/adminPage/all?quantity=10000' --header 'Authorization: Bearer <token_here>'

returns services which contain an identifiers section.

For example, for service with id csc-fi.csc_epouta, the identifiers section looks like this:

"identifiers": { "alternativeIdentifiers": [ { "type": "PID", "value": "7e960399" } ], "originalId": "csc-fi.csc_epouta" },

PIDs that have already been minted by the Providers for their resources will be also included in the identifiers section as alternativeIdentifiers.

Controlled Vocabulary Changes for Provider and Service Profiles

A number of fields linked to controlled vocabularies in the Service Profile and Provider Profile allow Providers to suggest new values for these vocabularies when they select “Other”. These suggestions have been reviewed – and several changes will be implemented as part of the new release:

In the EOSC Provider Profile:

In the Provider's Area of Activity: new options are added: “Research Infrastructure”, “Publisher”, and “Social Network”. Selecting multiple values will be allowed.
For Provider Legal Status, several new options have been added. Going forward, if an appropriate option does not seem to be available, Providers are encouraged to request additional values through helpdesk@eosc.eu.
For Provider Societal Grand Challenge, we will add the individual possibilities from the UN Sustainable Development Goals (SDGs). Selecting multiple values will be allowed.
For several fields (Provider ESFRI Type, Provider Life Cycle Status, Provider MERIL Scientific Domain and Subdomain, Scientific Domain and Subdomain), Providers are encouraged to find the value(s) that best match their situation, since the vocabularies are reasonably broad, or we are using vocabularies defined by other organisations. For some of these, selecting multiple values will be allowed.

In the EOSC Service Profile:

Access Mode is enhanced with another value “Free Initially, then Paid”. Otherwise Providers should be able to find appropriate values in the existing vocabulary.
Funding Body and Funding Program are expanded to include several suggestions, either as suggested or with edits. The “Other” choice remains for both fields, allowing Providers to make suggestions, but since the current vocabulary list is long, we encourage Providers to try to find the value(s) that best match their situation before suggesting a new value. Please also respect the difference between Funding Bodies and Funding Programmes. Funding Bodies are more persistent than Programmes, although we acknowledge, e.g., that the names of ministries sometimes change with new governments.
Target User is enhanced with several values: “Any”, “Citizens” and “Publishers”.
For several fields (Access Type, Order Type, Scientific Domain and Subdomain), Providers are encouraged to find the value(s) that best match their situation, since the vocabularies are reasonably broad, or we are using vocabularies defined by other organisations. For some of these, selecting multiple values will be allowed.

EOSC Data Source Subprofile

No functional changes are planned for the EOSC Data Source Subprofile.

New technical logic will be implemented that links each Data Source Subprofile record to a related Service Profile. These changes will not change the behaviour of the Data Source section of the Provider’s Portal or of the related Data Source APIs.

In addition, the definition of a Data Source has been expanded [1] to allow the onboarding [2] of a variety of sources of data that would not have met our original definitions for these resources, such as aggregators and CRIS systems.

It will now be possible to onboard three categories of Data Sources:

Data Sources that refer to or host research product resources that comply with the EOSC Research Product profile [3], and which can be harvested so that the individual research products are visible and can be searched in the Marketplace. Currently this requires the data source to be harvestable using one of several supported harvesting protocols [4], such as OAI-PMH.
Data Sources that refer to or host research product resources that comply with the EOSC Research Product specification [3], but which can only be harvested using protocols that are NOT yet supported by EOSC. In this case, the research products will not be onboarded into the EOSC Resource Catalogue but will still be available to users via the access points defined for the Data Source.
Data Sources that refer to other data assets that do NOT comply with the EOSC Research Product specification [3]. For example, many data sources provide one or more API interfaces to query and search for certain kinds of data, e.g. based on geographic location or biological taxonomy, with the API returning the selected data in chosen formats. While this data cannot be onboarded onto the EOSC Resource Catalogue, it is of course valuable to Users and available via the access points defined for the Data Source.

For categories 2 and 3, the Data Source Provider is encouraged to describe the harvesting protocols and API specifications that a user would need to use to query and search for the research resources they need. Ideally each of these protocols and specifications would be documented in an EOSC Interoperability Framework Guideline, which can then be linked with the Data Source record to support increased interoperability and utility.

Relevant links:

EOSC Training Material Profile

The EOSC Training Material Profile was introduced to EOSC in March 2023. Following the approach described above for Service Profiles, a new field, Marketplace Location, will be added to the Profile, to give Providers direct control of the placement of their Training Materials in the EOSC Marketplace. While most Training Material Profiles would logically be displayed in the Marketplace section “Access Training Material”, other choices will be available, and providers can manage these choices directly.

EOSC Interoperability Guideline Profile

The EOSC Interoperability Guideline Profile was introduced to EOSC in April 2023. Following the approach described above for Service Profiles, a new field, Marketplace Location, will be added to the Profile, to give Providers direct control of the placement of their Interoperability Guideline in the EOSC Marketplace. As a default Interoperability Guidelines are displayed in connection with the resources that comply with them. Providers now have the option to request display in other sections of the Marketplace as well.

EOSC Catalogue Profile

New fields have been introduced for Catalogue Profiles, all related to information needed for the catalogue to be onboarded:

Description of the Catalogue scope: a short description of the purpose of the Catalogue as a collection of resources with specific characteristics of domain
URL for Inclusion Criteria: a link to the Inclusion Criteria used to populate the Catalogue
URL for Validation Process: a link to the document describing how validation is done and how the assessment against the Inclusion Criteria is performed