The EOSC-hub project has ended. This space is READ ONLY

Principal Investigators: Thomas Exner

Shepherds: Stefano Nicotri

Entry in the community requirement database: 

About the pilot

Description of supported work

OpenRiskNet is providing an e-infrastructure to the communities involved in safety assessment, including toxicology and especially predictive toxicology, systems and structural biology, bioinformatics and its subtopics toxicogenomics, cheminformatics, biophysics and computer science specifically targeting the EU’s chemical manufacturing industries, e.g. pharmaceutical companies, chemical and agrochemical industries and cosmetic industries, and the corresponding regulatory agencies. 

During the lifetime of OpenRiskNet (2016-2019), 45 services were integrated, that can be grouped into seven categories: 1) Toxicology, Chemical Properties and Bioassay Databases, 2) Omics Databases, 3) Knowledge Bases and Data Mining, 4) Ontology Services, 5) Processing and Analysis, 6) Predictive Toxicology and 7) Workflows, Visualisation and Reporting. The service integration also included the development of workflows to support the case study work by automating complex tasks only achievable by the combination of multiple services. Additional services will be integrated over time to complete the portfolio to allow full risk assessment of chemical compounds and nanomaterials. This is specifically supported by the infrastructure project NanoCommons developing, and harmonizing such services for the nanosafety starting community represented by the projects of the EU NanoSafety cluster.


Objectives

  • Integrate and enlarge the catalog of available OpenRiskNet/NanoCommons services within the EOSC marketplace
  • Integrating EOSC AAI system in OpenRiskNet services
  • Making the OpenRiskNet infrastructure fit for integration in EOSC Cloud Compute and Storage services


General

After the end of the OpenRiskNet project in November 2019, one of the partners (Johannes-Gutenberg-Universität Mainz) agreed to provide cloud resources to sustain the infrastructure for additional two years. To guarantee a long-term sustainability and deep integration into the European infrastructure environment, the infrastructure should now already be prepared for moving onto the EOSC infrastructure to be ready when the short-term solution in Mainz is not available anymore.

The requirements to do so can be grouped in three categories:

  1. OpenRiskNet services must be findable and directly accessible on the EOSC platform: OpenRiskNet is running its own service catalogue with description of the services and direct-access links to the data resources and computational services. In an early approach, a small number of OpenRiskNet services have also been described according to the templates provided by EOSC and are now listed in the EOSC marketplace. To avoid this double work and to ensure consistency between the two catalogues especially when new services are added to OpenRiskNet, a more automatic way to transfer the information from OpenRiskNet to EOSC is sought. Technical support from EOSC-hub will be needed to define the information needed to be transferred and to specify the transfer procedure, mechanism and exchange format (JSON or XML).
  2. User management: EOSC users should acquire direct access to all the OpenRiskNet services without the need to register specifically to the platform. OpenRiskNet already offers a single-sign-on mechanism linked to different AAI providers (LinkedIn, GitHub, ELIXIR). Technical support is needed to extend this to the EOSC AAI.
  3. Usage of EOSC cloud and storage resources: Even if the availability of the infrastructure is secured for at least one more year, long-term sustainability still has to be achieved. Discussions have been started to provide such sustainability as part of one of the new infrastructure proposals. Therefore, technical support is needed to prepare the OpenRiskNet infrastructure to be moved to EOSC cloud and storage providers, even if the actual transfer would be performed in the coming year. Besides specifying the optimal resources for the OpenRiskNet virtual environment running on EOSC, requirements for adaptations of the OpenRiskNet containerization and orchestration concepts needed for a seamless deployment on the new cloud system, possibilities for monitoring and management and linking to other EOSC services should be outlined. Additionally, support would be needed to define possibilities to link OpenRiskNet with other projects providing services on EOSC like ELIXIR and EOSC-life and improve the interoperability. The estimated required resources are: 200 CPU cores, 360 GB of RAM, and ~1TB of disk space.

Team

ParticipantRoleName and Surname
Edelweiss ConnectPIThomas Exner
Edelweiss Connect
Daniel Bachler
Informatics Matters
Tim Dudgeon
Informatics Matters
Alan Christie

ShepherdStefano Nicotri

Technical Plan

The full technical plan can be found here: 

Work planned for Q1

  • scouting of currently available OpenRiskNet services
  • definition of a plan to insert suitable OpenRiskNet services into EOSC catalogue
  • scouting of the resources for long-term support of OpenRiskNet services

Work planned for Q2

  • integration of EOSC AAI into OpenRiskNet services
  • definition of the transfer procedure and exchange format for the “synchronization” of OpenRiskNet and EOSC catalogues
  • feasibility study for “automatic” import of services from OpenRiskNet catalogue into EOSC catalogue
  • deployment of OpenRiskNet services on EOSC cloud resources

Work planned for Q3

  • integration of a preliminary subset of OpenRiskNet services into EOSC catalogue
  • defining approaches for better harmonisation and interoperability of OpenRiskNet services with other service providers on EOSC by discussing and reviewing successful implementations performed in other EOSC-hub Early Adopter Programme activities
  • management and update of deployed services

Work planned for Q4

  • finalising the deployment of the “architecture” of OpenRiskNet service catalogue within EOSC marketplace, standing the outcomes of Q1, Q2, and Q3
  • management and update of deployed services

EOSC services and providers

Providers

Services


  • No labels