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 "EOSC RoP Legal & Ethics Compliance" - RoLECT (https://rolect.ni4os.eu/) 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 ethical aspects of 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 the 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.

Legal aspects and tool structure

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. Based on this, NI4OS-Europe developed the RoLECT tool that allows the providers of different resources to the EOSC ecosystem to ensure their compliance with the key legal and ethical aspects of the respective Rules of Participation. In order to achieve this objective, we have followed a two stage methodology:

a. In the first stage, we have deconstructed the EOSC RoPs so that for each one of them we could identify a series of legal and ethical rules.

b. In the second stage, we have re-constructed units of rules that have to be respected for a resource to be admitted to the EOSC ecosystem.

Since the way in which the various RoPs are to be adopted, monitored and enforced by the EOSC Association is still under formation, the tool is currently still at the stage of supporting the increase of the maturity of various resource provisions rather than an enforcement tool. By asking a series of questions, it allow the resource providers to increase the quality of their resources and the adherence to the EOSC RoPs. The tool is structured along the following lines:

• It initially asks a series of questions related to the overall transparency of the various licences, Terms of Service or other legal documents under which the resources may be made available. These conditions will allow the users of the resource to easily understand and assess the terms under which such resources are made available to them.
• At a second stage, different types of restrictive regimes, such as confidential information or trade secrets are identified and classified.
• At a third stage, the tools identifies the type of Intellectual Property Rights subsisting in a resource and makes again an assessment of the content, type and version of the licence under which the resource is made available. The tool focuses particularly on the standardization, openness and interoperability of the licences.
• It subsequently explores the degree to which personal data subsist on a particular resource and whether the conditions for lawful processing of such data have been met and the relevant notices communicated to the end-user.
• At a fourth stage, the resource provider may include specific ethical rules based on Codes of Conduct or other ethics documents that limit the dissemination of material or allow it only under specific rules, such as rules of attribution, provenance or specific notifications (e.g. regarding publishing).
• At a final stage, the tool assists the resource provider in identifying different types of Public Sector Information, from generic one to specialized one such as in the case of statistical or cultural information. This is then further assessed in terms of the obligations of openness as well as specific legal and ethical limitations that may accompany the use of such data.

As mentioned above, while the tool does not constitute an exhaustive enforcement mechanism, it is ideal for the current stage of EOSC development as it will allow resource providers to assess the legal and ethical maturity of their resources and increase the overall legal health of the EOSC ecosystem.

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 ethical 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 with 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 enter the wizard where they will provide all the preliminary information required to identify the resource and distinguish it between a service or a pure dataset (Stage 2).
In Stage 2, Service Transparency Provisions, users are guided through Terms of Service (ToS) related considerations and may provide related resources to build and justify the ToS contents. Following sections deal with Intellectual Property Rights, including types of IP, whether Public Sector Information exists, statistical, cultural, personal information entry and ethics restrictions and include essential conditions, providing an assessment for the most important RoP general availability and transparency provisions that must be absolutely satisfied. Checks, will also be included, as to if the resource is listed in a publicly accessible registry and is findable and more specific resource related conditions.
In Stage 4, additional legal and ethical requirements, according to the answers provided in stages 1-3, users are guided to additional key-rules and are asked relevant questions by thematic sections. The questions shown in the relevant figure are only a portion of the total questions provided in the application. RoLECT, provides an overall assessment summary and a chance to review the responses given in each section, by following the steps backwards. If users decide to make any changes they may go back to relevant stages and alter their initial responses. When satisfied with what they have provided they may `submit` their input to proceed. Application will confirm successful submission and informs about the creation of the assessment results report. Users may download their reports using the provided links.

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.

 {
   "id": "s02",
   "name": "Service Transparency Provisions",
   "description": "Questions about service's ToS",
   "order": 2,
   "mandatory": false,
   "dependingQuestionId": "q003",
   "dependingAnswerIds": [
       "v002_001"
   ]
 }

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
• dependingQuestionId: A field that indicates if the section depends on the answer of previous question in another section.
• dependingAnswerIds: A field that indicates the answer that should be expected from the previous question to enable this section.

 {
   "id": "q002",
   "name": "Is the resource listed in a publicly accessible registry?",
   "description": "",
   "sectionId": "s01",
   "order": 2,
   "mandatory": true,
   "responseType": "DropDown",
   "vocabularyId": "v001"
 },
 {
   "id": "q003",
   "name": "Provide the registry URL",
   "description": "",
   "sectionId": "s01",
   "order": 3,
   "mandatory": false,
   "responseType": "shortText",
   "dependingQuestionId": "q002",
   "dependingAnswerIds": [
       "v001_001"
   ]
 }

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)
• 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.
• dependingAnswerIds: A field that indicates the answer that should be expected from the previous question to enable this 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.

Release 0.1, March 2021:

• Working wizard forms guiding users through the compatibility checks.
• New branding logo and app theme.
• Production server reached at https://rolect.ni4os.eu/
• Documentation, questions shortcut button.
• Privacy Policy.

Team

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