Quicker, easier interface for DataVault

We are delighted to report that Edinburgh DataVault now has a quicker and easier process for users. The team have been working hard to overhaul the form for creating a new ‘vault’ to improve the user experience. The changes allow us to gather all the information we need from the user directly through a DataVault web page. The users no longer need to first login to Pure and create a separate dataset record there. Instead, that bit will be automated for them.

I have explained the new process and walked users through the new form in a new and updated how-to video, now combining the getting started information with the demo of how to create a vault:

Get started and create your vault! (8 mins)

The new streamlined process for users is represented and compared to our open research data repository DataShare in this workflow diagram. DataVault is designed for restricted access, but can also handle far larger datasets than DataShare.

The diagram shows the steps users go through in DataShare and DataVault. Common steps are deposit and approval.

The DataVault process includes the gathering of funding information, and review and deletion none of which are present in the DataShare workflow since they would not be relevant to that open research data repository.

The arrow showing DataVault metadata going to the internet represents the copying of selected metadata fields into Pure, where they are accessible as dataset records in the university’s Edinburgh Research Explorer online portal.

Our new course “Archiving Your Research Data”, featuring Sara Thomson, Digital Archivist, provides an introduction to digital preservation for researchers, combined with practical support on how to put digital preservation into practice using the support and systems available here at University of Edinburgh such as the DataVault. For future dates and registration information please see our Workshops page.

A recording of an earlier workshop (before the new interface was released) is also available: Archiving Your Research Data Part 1: Long-term Preservation.

If you are a University of Edinburgh principal investigator, academic, or support professional interested in using the Edinburgh DataVault, please get in touch by emailing data-support@ed.ac.uk.

Pauline Ward
Research Data Support Assistant
Library and University Collections
University of Edinburgh

University of Edinburgh’s new Research Data Management Policy

Following a year-long consultation with research committees and other stakeholders, a new RDM Policy (www.ed.ac.uk/is/research-data-policy) has replaced the landmark 2011 policy, authored by former Digital Curation Centre Director, Chris Rusbridge, which seemed to mark a first for UK universities at the time. The original policy (doi: 10.7488/era/1524) was so novel it was labeled ‘aspirational’ by those who passed it.

"Policy"

CC-BY-SA-2.0, Sustainable Economies Law Centre, flickr

RDM has come a long way since then, as has the University Research Data Service which supports the policy and the research community. Expectation of a data management plan to accompany a research proposal has become much more ordinary, and the importance of data sharing has also become more accepted in that time, with funders’ policies becoming more harmonised (witness UKRI’s 2016 Concordat on Open Research Data).

What has changed?

Although a bit longer (the first policy was ten bullet points and could fit on a single page!), the new policy adds clarity about the University’s expectations of researchers (both staff and students), adds important concepts such as making data FAIR (explanation below) and grounding concepts in other key University commitments and policies such as research integrity, data protection, and information security (with references included at the end). Software code, so important for research reproducibility, is included explicitly.

CC BY 2.0, Big Data Prob, KamiPhuc on flickr

Definitions of research data and research data management are included, as well as specific references to some of the service components that can help – DMPOnline, DataShare, etc. A commitment to review the policy every 5 years, or sooner if needed, is stated, so another ten years doesn’t fly by unnoticed. Important policy references are provided with links. The policy has graduated from aspirational – the word “must” occurs twelve times, and “should” fifteen times. Yet academic freedom and researcher choice remains a basic principle.

Key messages

In terms of responsibilities, there are 3 named entities:

  • The Principle Investigator retains accountability, and is responsible as data owner (and data controller when personal data are collected) on behalf of the University. Responsibility may be delegated to a member of a project team.
  • Students should adhere to the policy/good practice in collecting their own data. When not working with data on behalf of a PI, individual students are the data owner and data controller of their work.
  • The University is responsible for raising awareness of good practice, provision of useful platforms, guidance, and services in support of current and future access.

Data management plans are required:

  • Researchers must create a data management plan (DMP) if any research data are to be collected or used.
  • Plans should cover data types and volume, capture, storage, integrity, confidentiality, retention and destruction, sharing and deposit.
  • Research data management plans must specify how and when research data will be made available for access and reuse.
  • Additionally, a Data Protection Impact Assessment is required whenever data pertaining to individuals is used.
  • Costs such as extra storage, long-term retention, or data management effort must be addressed in research proposals (so as to be recovered from funders where eligible).
  • A University subscription to the DMPOnline tool guides researchers in creating plans, with funder and University templates and guidance; users may request assistance in writing or reviewing a plan from the Research Data Service.

FAIR data sharing is more nuanced than ‘open data’:

  • Publicly funded research data should be made openly available as soon as possible with as few restrictions as necessary.
  • Principal Investigators and research students should consider how they can best make their data FAIR in their Data Management Plans (findable, accessible, interoperable, reusable).
  • Links to relevant publications, people, projects, and other research products such as software or source code should be provided in metadata records, with persistent identifiers when available.
  • Discoverability and access by machines is considered as important as access by humans. Standard open licences should be applied to data and code deposits.

Use data repositories to achieve FAIR data:

  • Research data must be offered for deposit and retention in a national or international data service or domain repository, or a University repository (see next bullet).
  • PIs may deposit their data for open access for all (with or without a time-limited embargo) in Edinburgh DataShare, a University data repository; or DataVault, a restricted access long-term retention solution.
  • Research students may deposit a copy of their (anonymised) data in Edinburgh DataShare while retaining ownership.
  • Researchers should add a dataset metadata record in Pure to data archived elsewhere, and link it to other research outputs.
  • Software code relevant to research findings may be deposited in code repositories such as Gitlab or Github (cloud).

Consider rights in research data:

  • Researchers should consider the rights of human subjects, as well as citizen scientists and the public to have access to their data, as well as external collaborators.
  • When open access to datasets is not legal or ethical (e.g. sensitive data), information governance and restrictions on access and use must be applied as necessary.
  • The University’s Research Office can assist with providing templates for both incoming and outgoing research data and the drafting and negotiation of data sharing agreements.
  • Exclusive rights to reuse or publish research data must not be passed to commercial publishers.

Robin Rice
Data Librarian and Head, Research Data Support
Library & University Collections

New feature in Edinburgh DataShare: the REST API

Ever wanted to get a table of the details of all the datasets on DataShare to do with Scottish history? Or matching some other criteria, possibly on specified fields? If so, the new API (Application Programming Interface) can help.

DataShare now has a REST API, which you can use to query our metadata. An API makes the database’s contents accessible for requests from external servers, through a command-line, which allows external users to script such requests. The DSpace API also provides its own web-based query client and report client. These pages allow users to use a graphical interface to quickly build a query and see the results in a table, all in the browser.

The DataShare REST API page starts with a link to our plain-English explanation of how the API can be used:

Edinburgh DataShare DSpace REST API 

We would like to hear from anyone who wants to use the API. Please try it out and let us know what you find useful! Email us at data-support@ed.ac.uk .

Examples using the graphical query builder

I wanted to find datasets where I could add a link to the associated publication. This is a bit of a challenge for us, since users typically deposit their data with us under embargo before the associated paper has been published, and we do not have an automatic way to detect when or whether an associated publication has appeared.  I used the query builder to find the IsReferencedBy value for deposits accessioned in 2017. The plain-English guide on the wiki provides the steps I went through to do so:

How to use the DataShare REST API 

This feature may be of use to colleagues who support organisational units at University of Edinburgh which don’t align precisely with the Collections structure of DataShare – the API lets you query on multiple collections through the reporting tool. We’d love for colleagues to contact us if their teams have published a new paper containing a data citation of their DataShare deposit, so we can add the details of the publication to the DataShare Item’s metadata, resulting in a hyperlink appearing on the dataset landing page.

I wanted to find datasets with an embargo date in December. This is a challenge for us because users often set their embargo expiry date to Hogmanay, which means their one-week reminder would arrive on Christmas Day right in the middle of the university’s winter break. But many other fields contain dates with December in them, so it has not been practical for me to search for this using the graphical interface. So I used the API to search specifically in the dc.date.embargo field. See the screenshot below. The API helped me find the datasets whose embargo date we needed to extend, or else lift the embargo outright, allowing us to contact the depositors in good time to ask them whether a paper had been published or more time was needed.

Screenshot of the output of the REST API

Results showing datasets with an embargo date in December 2021

Thirdly, to demonstrate the power of this tool relative to the non-specific Search I chose a topic with very common words to show how to use the query builder to focus in on results avoiding spurious matches.

Using the existing ‘Search’ function on the homepage I searched for ‘history Scotland’. This produced 39 matches, some of which have nothing to do with historical research or Scotland, but merely mention a funder “NHS Research Scotland”, and mention the history of the research field in passing to provide a little context. Most of the matches are interesting, but some are not relevant.

Whereas when I set the API query builder to search for ‘history’ in the research area (subject classification), and ‘Scotland’ in the field for geographical metadata ie dc.coverage.spatial. This provided me with a short list of high quality matches, three datasets of historical research to do with Scotland – see the screenshot. This is a useful tool for narrowing a search.

Screenshot showing the input, and the output on the API query builder webpage

A search for two very common words in specific fields produces high quality results

Enabling the API

The REST API is a feature of the underlying DSpace repository software. Our sysadmins configured the API with great care to block certain commands and enable only the ‘GET’ commands that are needed for appropriate queries using DSpace config settings (further info DSpace 6 Documentation on the Lyrasis wiki ).

The Future

In the international DSpace repository community, we’re aware the API is used for integration with at least one CRIS (Current Research Information System) and quality tool applications (Andrea Bollini, 4Science, private communication). We understand the API of the newer DSpace 7 contains significant changes compared to that of DSpace 6, which we’re using for Edinburgh DataShare.

We’re aware of only a few examples of the API being used by individuals for occasional metadata queries. But we will watch with interest to see how the DSpace 7 API will be used.

 

Pauline Ward
Research Data Support Assistant
Library and University Collections
University of Edinburgh