Organizational requirements and recommendations

Depositing research data

One of the most important organizational requirements is to implement the assumption that research data is entered independently by researchers wishing to deposit their data. Since the data entry process is not a simple tak, and it requires certain knowledge, it is assumed that the university implementing the module organizes a special service to support data entry by researchers. The following roles are envisaged in the system:

1. the role of the repository manager

2. the role of data-stewards - these are people who support researchers in the process of entering data.

Data that can be deposited in the repository are result:

1. of national or international projects acquired by the University - it is necessary to link the data to the corresponding project and publication (if created)

2. from national and international projects, not acquired by the University, but the employee is e.g. a grant contractor - there is a possibility to add information about the source of funding in the appropriate field;

3. arising from internal grants (i.e. university grants, e.g. IDUB; departmental funds, etc.). The possibility was created to add this information in the appropriate field about the source of funding

The role of the University Knowledg Base (UKB) is to collect as complete information as possible about the achievements of the University's researchers, so it is assumed that in addition to the deposited data, the repository also collects metadata about research data deposited outside the UKB (reference records).

Permanent identifiers

An important requirement is the identifiability of research data. The most important global identifier is the DOI (Digital Object Identifier). The Findability condition under FAIR conditions dictates the need to implement DOI assignment capability. The ability to broadcast DOIs requires the "buy-in" of a specific service. Interoperability with the DataCite organization has been implemented in this regard. It is assumed that the University will implement certain procedures related to the purchase of DOI numbers and the assignment of identifiers to research data.

Documents related to the operation of the Research Data Repository

Rules and regulations should be drawn up to explain to the University's researchers exactly the purposes of the repository and ways of depositing, as well as to report the need for consulting assistance.

In conclusion, the following actions of the implementation team are recommended

Data deposition cycle

The system provides for the following cycle of depositing data or subsequent versions of data:

1. Record: Initiation and editing of the record (researcher) - can only be done by the researcher on his own initiative.

2. Version: Initiate and edit version (researcher) - as above.

Both (1) and (2) can take place in several stages - the record/version is in the phase of metadata input, uploading data files and editing their attributes (licence, accessibility). The sequence of events involved is as follows:

1. When a researcher begins the process of editing metadata, the system automatically notifies the person responsible for coordinating support (the role of researchdatacoordinator);

2. The coordinator assigns the steward assigned to the researcher's unit to the started record (enters it into the metadata);

3. If the Scientist is inactive after 10 working days, the system automatically notifies the steward and directs queries/requests to the Scientist. After another 10 working days of inactivity, the system notifies the Research Data Repository Manager. A determination with the Researcher of the reasons for the stoppage of work takes place and a decision is made to leave the started record or delete it.

Assigning a new editor (researcher, record owner) - the author can designate another UKB user and grant him/her the rights to edit a given record/version of research data. Granting editing rights to another user is possible only if the new editor is listed in the author's list as a co-author of the deposited data. This step causes only the new editor to have access to the record editing function, and the existing editor loses editing access.

Research data file management (researcher) - files can be entered from the metadata entry form, along with metadata, or they can be entered and managed in the next phase, i.e., after the metadata has been saved. In both cases, one can collectively upload multiple files and collectively define their properties (availability) and licenses. In the second case, it is more convenient to have a view and the ability to define properties, so the latter case is recommended when there are a plenty of files.

Submit a query/request to a steward for help (researcher) - a researcher can send an email with a query to a steward at any time.

Closing the edit phase and requesting verification (researcher) - the researcher can report the closing of the edit phase of the record and sends an email to the steward and/or editor requesting verification and approval.

Verification of the record (data steward) - the steward verifies the record. As a result, he/she makes one of the decisions:

Publish the data - stweward determines that the record is correct, assigns a DOI (optional) - the record is given persistence status;

Withdrawal after improvement - in case of errors, the data steward sends a list of postulates to the researcher to complete the data - the record has no permanence status and can be edited or deleted