Case Study 6: Process Recording and Digital Research Notebooks

Home » Case Study 6: Process Recording and Digital Research Notebooks

Authored by:

Cerys Willoughby, Samantha Kanza, Colin Bird, Nicola Knight, Charlie Holdship, Jeremy Frey, Simon Coles

School of Chemistry, Faculty of Engineering and Physical Sciences, University of Southampton, Southampton, SO17 1BJ

Download a .pdf copy of this summary report

Download a .pdf copy of the full detail report

Key focus and activity

This case study focused on assessing the digital landscape around process recording and scientific notetaking, with a particular interest in Digital Research Notebooks (DRNs). This work builds on decades of pioneering and experience in tools and approaches to enable digital research.

As part of this work, we designed and circulated a survey to explore researchers’ working practices. We also examined the diversity of digital notetaking tools available and technologies for improving process recording. The user requirements and interactions were explored through development of a series of personas, storyboards and user/data flows.

Area of Physical Sciences covered

Exploring the requirements for recording of research process, this case study is necessarily not directly focusing on a single research area, but is applicable across all research areas. In this work we have explored user stories predominantly in Chemistry

Applicability to the Research Data Lifecycle

Due to the cross-cutting nature of process recording, this would influence many, if not all, of the areas within the research data lifecycle. However, there is particular focus on those areas in:

  • Data creation and deposit (Plan and Design, Collect and capture)
  • Managing active data (Collaborate and analyse).
JISC Research Data Lifecycle
Figure 1 – JISC Research Data Lifecycle Model [1]

Main outputs

In order to explore user requirements relating to process recording we utilised User Experience design tools in this case study. This includes a series of 6 scenarios and personas across astronomy, chemistry and geosciences. From these, a series of storyboards and user flows were worked up, including some provisional user interface designs for the user flows. The collection of user experience designs can be found at: https://casestudy6978019029.wordpress.com

We also ran a user survey exploring current working habits in relation to process recording and use of software, which was compared to previous research carried out in 2018. This can be found in section 3 of our detailed report.

Outcomes and Recommendations

Our research and findings further support many of the conclusions outlined by research in the field over recent years. There is a clear requirement for better digital tools to enable scientists to conduct, share and publish their research, and yet there is still no one single system that supports this endeavour. This is namely because, based on the diverse and extensive physical sciences community and the sheer level of different software requirements and tools available, this is extremely unlikely to ever be possible. It is crucial to move away from the idea that we can create “one ELN to rule them all” and focus on how we can best use, improve and integrate the tools we have today.

There are two main areas that need to be considered:

  • Improving digitisation
  • Improving our digital records

Both of these need to be addressed (separately and in conjunction with one another) if we are to reach a point of a cohesive digital physical sciences community. We therefore propose that rather than try and reinvent the wheel again, we expend effort in training and educating our community to embrace digital recording of research. Further, the most effective approach to engage researchers is to design and develop methods to enhance existing ways to digitally record research process. It will be necessary to facilitate links between existing domain-based software, and improve metadata design and capture. In other words, we need to create a fully-fledged infrastructure that can support this. In terms of PSDI this means:

PSDI core should facilitate:

  • Links between DRNs (e.g. OneNote) and Domain Based Software
  • Common data standards that can be used across DRNs and Domain Based Software
  • Common metadata standards that can be used across DRNs and Domain Based Software
  • Ontologies/Taxonomies to describe scientific data
  • File format translator
  • Adequate description of chemical structure
  • General infrastructure features e.g. data management, storage and handling
  • DOI generation / linking

A Digital Research Notebook on or integrating with PSDI should:

  • Interface with domain-based software
  • Work with a number of different standard scientific data formats
  • Include generic and domain-based metadata
  • Include semantic technologies where appropriate
  • Links to hybrid tools
  • Secure data storage
  • Export / import data in different formats

Recommendations

Our key recommendations are as follows:

Process Recording: This should be embedded in all parts of PSDI.

PSDI Core: PSDI will need a core element, which will provide the relevant services and functionalities such as those listed above. Then there will be additional technologies surrounding the core that will interface with these core services.

Technology Integration: Software and services within the system need to be interoperable to allow them to be tailored to the different environments of the individual researchers. To facilitate this usage, the full extent of the current technology landscape needs to be understood and links need to be established between existing technologies.

Develop Prototype: Develop a prototype plugin to demonstrate an interface between a generic DRN and an established, documented service to show proof of concept. (Short Term)

Metadata & Standards: To underpin these recommendations in CS6, models are required for the metadata and standards used in domain data. Where these don’t exist currently, resource should be invested in developing them.

Future ways of working: The proposed or developed systems need to factor in changes to working practices, advances in technology and the evolving nature of scientific research.

DMPs: PSDI should enable researchers to develop or interact with Data Management Plans and support them in enacting them.

User Experience & Adoption: This is a sociotechnical task, and as such as need to consider people in the design of the system and social aspects in the rollout/implementation of any system. More training and education needs to be provided in the areas of research data management, and handling data at all stages of the research data lifecycle.

A more detailed list of proposed activities to carry out in the exploration and implementation of these recommendations can be found in section 6.2 of our detailed case study report.

Loading...