EOSC RoP Legal & Ethics Compliance - Description and Documentation

Purpose

This tool is the output for Task T4.3 that focuses on the aggregation, improvement and development of tools covering the increased demand for providing technical solutions to address the needs for researchers to publish in FAIR/open modes. The tool, being actively developed, targets the ecosystems of tools for open and FAIR assessors Legal needs, which are tools that allow for IPR, ethics and data protection compliance both at the policy and legal level, aligned with the EOSC governance. Specifically, NI4OS-Europe with this tool aims at providing an aggregated procedure for legal and ethics compliance by integrating a set of model procedures including:

Model procedures for Copyright acquisition, management and dissemination policies
Model Copyright clearance processes, documentation and tools
Model Data Protection (GDPR compliant) processes, consent forms and data sharing agreements
Decision support trees for data protection policies
Model IPR and data protection documentation

The tool will be made available for integration into EOSC channels.

Intended use

The intended use of the tool is to provide an aggregated guided assessment for EOSC RoP focusing on legal and ethics aspects compliance. Targeted users may be service providers, researchers and research organisations. The tool integrates a number of existing modeled procedures, under a structured flow providing logic steps for testing a potential EOSC service/dataset against current RoP. The platform will eventually evolve to automatically check the validity of provided resources for at least the obligatory steps of the assessment. Legal and ethics are two important aspects in the RoP that require particular focus due to their nature and the difficulties associated (specialised knowledge, experience, etc.) and as such they have not yet been addressed adequately from other FAIR-related tools. As such the RoP legal and ethics compliance tool provides a specialised service for a need that has no been covered yet by other relevant tools.

Background: Legal aspects

According to EOSC RoP working group, "The Rules of Participation shall embrace the principles of openness, transparency and inclusiveness. They shall guarantee an open, secure and cost-effective federated EOSC with services of documented quality.", while leaving room for differentiating the rules to apply to different EOSC users...

Workflow

*Main Workflow*

The service platform tries to adopt an elastic approach in the workflow allowing users to follow varying paths to compliance with EOSC's RoP, while emphasizing and embracing the principles of openness, transparency and inclusiveness. As RoP is set to guarantee an open, secure and cost-effective federated EOSC with services of documented quality, the tool guides users through these obligatory and common requirements, while focusing mainly on the legal and ethics aspects of RoP rights and obligations that will govern EOSC transactions between EOSC users, providers and operators. Service provides a logic sequential flow starting at collecting relevant resource information to identify and validate and categorise the resource. Then follows in checking essential IP, statistical, cultural, personal and ethics related information. The procedure then checks for the most common obligations for a service/data provider being openness and findability and proceeds to Terms of Service (ToS), licensing information, limitations and access restrictions. Depending on the given answers in the previous steps the guide advances to specific sets of questions for each of the relevant key-rules identified in the previous steps. The final step aggregates the collected information in a downloadable documented response providing service/data providers a clear picture of their current state in relation to the most recent RoP. The guided assessment procedure is presented in the Main Workflow figure.

The tool is intended to handle RoP compliance procedure for pure datasets apart from services which are the main target. To achieve this, based on the resource type chosen, the workflow is designed to start evaluating compliance on the most basic obligatory requirements and add to that further obligatory and common requirements when services are considered and when drilling down to more specific sections for key-rules. The concept is presented in Compliance drill down figure.

Compliance drill down

Tool Use Case Scenario

The following mockup slides present the tool's front end user experience and the guided procedure sequence offered by the application wizard. Users are guided through the numerous steps involved in the legal and ethics RoP compliance in an intuitive way, simplifying the tedious procedure.


Users are landed on the login screen given the choice to either login as registered users or proceed without login. Differences in functionality will include user history, editing previous compliance choices, downloading a previously generated report, comparing previous with current results. At Stage 1, users will...

Compliance drill down

Compliance drill down

Compliance drill down

Overall Architecture

*RoP Legal & Ethics Compliance block-diagram*

The EOSC RoP Legal & Ethics Compliance application at its core contains a schema description that corresponds to the data that need to be filled in for processing by the compliance application. This description constitutes of a number of sections and questions, capturing all the needed information about the resources (services, data), including descriptive metadata and users' scoring (yes/no at this version) in each question. It also defines the ordering of the sections and questions, any dependencies among them and the vocabularies used to fill in possible answers. This description will evolve with time and will be enhanced with additional data points. Aiming at being flexible, we map all the questions, the sections they belong to and the possible list of responses (if any) into a JSON (https://www.json.org/json-en.html) document stored in a NoSQL database MongoDB (https://www.mongodb.com/). This schema is retrieved by the front-end application, which dynamically creates a form-based wizard.

Components

The application is composed of two main services, the back-end service and the front-end application. The back-end service is responsible for implementing all the business logic of the application and providing all the necessary methods to the front-end one for interacting with it and making available to the end-users the User Interface for checking the compliance level for their service/data with the RoP. The back-end service is composed of a number of different components, each one of them responsible for a different part of the system. Initially, these will be:

The user’s management component for managing the available users and their roles,

The data management component for managing all the data and interacting with the data access layer,

The configurator component for manipulating the schema description and

The compliance validator component.

Data are stored either on a NoSQL database or to a relational one. The image on the left presents the block diagram of the application. Some components have not been yet implemented but will be available during the next versions of it.

Schema Description

The structure of the schema description is presented below using an example. Each section of the schema is described in a separate section.

Section Description

    "id": "s01",
    "name": "Resource Information",
    "description": "Information and resource identification",
    "order": 1,
    "mandatory": true,
    "acceptsMultiple": false

The fields above describe a section. Each section contains:

id: The id of the section. For internal use only
name: A name to be displayed to the end-user
description: A description to be displayed to the end-user
order: The order of this section, compared to the other sections
mandatory: If the section is mandatory or not
acceptsMultiple: A field that indicates if the user could add multiple resources/responses in this section.

Question Description

     "id": "q013",
     "name": "Resource type",
     "description": "Select the type of resource",
     "sectionId": "s02",
     "order": 7,
     "mandatory": true,
     "responseType": "DropDown",
     "dependingQuestionId": "q011",
     "public": true,
     "vocabularyId": "v001"

Each question contains the following fields:

id: The id of the question. For internal use only
name: The name to be displayed to the end-user
description: The description to be displayed to the end-user
sectionId: The section it belongs to
order: The order of the questions in the section it belongs to
mandatory: If the question must be answered or not
responseType: The type of the expected response. Currently, we support: ShortText, Text, Checkbox (for Boolean questions), FileUpload, * * DropDown (responses are limited to a specific list)
public: If this response will be public or not
vocabularyId: valid only for responseType: DropDown. An ID to the vocabulary from which the responses will be used.
dependingQuestionId: if the responses for this question depend on the response to the previous question.

Vocabulary Description

     "id":"v003",
     "name":"Intellectual Property Rights",
     "description":"Kinds of IP the resource includes",
     "terms":[
       {
         "id":"v003_001",
         "name": "Copyright"
       },
       {
         "id":"v003_002",
         "name": "Trademarks"
       },
       {
         "id":"v003_003",
         "name": "Patents"
       }
     ]

Each vocabulary constitutes of an Id, a name and a description and a definite number of terms. Each term has an Id and a name/label.

Back-end service

A REST web service will be implemented using the Java EE and the Spring Boot framework. The service will offer an API (Application Programmatic Interface) with all the required methods for serving the application’s needs.

Front-end application

The front-end application will be implemented using Angular (https://angular.io/), a TypeScript-based open-source web application framework. In its first version, it will offer a draft version of the RoP compliance form wizard. The wizard will be created at runtime, supporting the dynamic schema description presented above.

Version features

Version 1, November 2020:

Initial version provides a proof-of-concept mockup.
Will initially provide documented self-assessment.
General RoP compliance formulated.

Team

Vassilis Kifonidis, Panagiota Koltsida, Christos Liatas, George Panagiotopoulos, Panoraia Spiliopoulou, Eleni Toli, Elli Papadopoulou, Electra Sifakaki