Difference between revisions of "License Clearance Tool - Description and Documentation"
Eleni Toli (talk | contribs) |
Eleni Toli (talk | contribs) |
||
Line 49: | Line 49: | ||
"mandatory": true, | "mandatory": true, | ||
"acceptsMultiple": false | "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 | ||
+ | * AcceptsMultiple: A field that indicates if the user could add multiple answers in this section. | ||
=== Version features=== | === Version features=== | ||
* Initial version provides a proof-of-concept workflow. | * Initial version provides a proof-of-concept workflow. | ||
* Will initially provide guidance for existing standard open-source licenses only. | * Will initially provide guidance for existing standard open-source licenses only. |
Revision as of 14:48, 26 June 2020
Intro - Aim & purpose of the tool
This tool is the output for Task T4.4 that aims to mainstream concrete certification standards, tools and mechanisms for open research data management and certification schemes for data repositories, aligning with activities and results of INFRAEOSC-5c. It targets both data intensive RDM (through cloud compute) and the curation and handling of the long tail of science with the aim of establishing consolidated models of RDM activities in the target countries. Building on the work undertaken in T4.2 and T4.3, this task delivers a certification tool for supporting trustworthiness of data repositories and ensuring their FAIRness in a standardised and interoperable fashion, with the objective to support the onboarding of repositories to EOSC.
Newly produced datasets, but mostly the creation of derivative data works, i.e. for purposes like content creation, service delivery or process automation, is often accompanied by legal uncertainty about usage rights and high costs in the clearance of licensing issues. NI4OS-Europe, with the "Data Clearance" tool aims to facilitate and automate the clearance of rights (copyright) for datasets that are to be cleared before they are publicly released under an open licence and/or stored at a publicly trusted FAIR repository. It will additionally allow the crowd-sourced documentation of the clearance process. Main aspects of the tool include:
- Data clearance not bound to the user that initiated the procedure, so it can be started and finished by different users.
- Potentially include crowd-source clearance.
- Clearance metadata will be an open-source resource.
- Provides equivalence, similarity and compatibility between licenses if used in combination, particularly for derivative works.
Related Work
OpenMinted set out to create an open, service-oriented e-Infrastructure for Text and Data Mining (TDM) of scientific and scholarly content. They created the The OpenMinTeD License Compatibility Matrix tool as a service to help users understand whether they can combine together works, software and services available under different licenses or terms of use and determine what they can do with the outcome of their combination. The work done for this tool can be seen as a predecessor to the work currently been done for the NI4OS-Europe Data Clearance Tool at a larger, more complex and business oriented scale.
Targeted use
The intended use of the tool is to provide a guided approach for establishing the proper open-source licence required for the creation of a new (or synthetic) dataset, or for the re-use of an existing unlicensed one. The procedure takes into account many potential data managers (users initiating or completing a data clearance procedure). Potential users may be researchers and research organisations.
Workflows
Overall Architecture
The Dataset License Clearance Application at its core contains a schema description that corresponds to the data need to be filled in for processing a clearance application. This description constitutes of a number of sections and questions, in order to provide all the needed information about the new, generated dataset and the existing exploited datasets (from which the new one is derived), including descriptive metadata and the available/desired licenses. 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 during time and be enhanced with additional questions. Aiming on 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, that is stored into 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 by 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 clearing the license of a new dataset. The back-end service is composed by a number of different components, each one of them responsible for a different part of the system. Currently these are:
- a 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 license validator component.
Data are stored either on a NoSQL database or to a relational one. The image below 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 is described in a separate section.
Section Description
"id": "s01", "name": "DataSet Information", "description": "Information about the generated dataset", "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
- AcceptsMultiple: A field that indicates if the user could add multiple answers in this section.
Version features
- Initial version provides a proof-of-concept workflow.
- Will initially provide guidance for existing standard open-source licenses only.