Category Archives: Data stewardship

Research Data Workshops: DataVault Summary

Posted on by
Reply

Having soft-launched the DataVault facility in early 2019, the Research Data Support team -with the support of the project board – held five workshops in different colleges and locations to find out what the user community thought about it. This post summarises what we learned from participants, who were made up roughly equally of researchers (mainly staff) and support professionals (mainly computing officers based in the Schools and Colleges).

Each workshop began with presentations and a demonstration by Research Data Service staff, explaining the rationale of the DataVault, what it should and should not be used for, how it works, how the University will handle long-term management of data assets deposited in the DataVault, and practicalities such as how to recover costs through grant proposals or get assistance to deposit.

After a networking lunch we held discussion groups, covering topics such as prioritisation of features and functionality, roles such as the university as data asset owner, and the nature of the costs (price).

The team was relieved to learn that the majority (albeit from a somewhat self-selecting sample) agreed that the service fulfilled a real need; some data does need to be kept securely for a named period to comply with research funders’ rules, and participants welcomed a centralised platform to do this. The levels of usability and functionality we have managed to reach so far were met with somewhat less approval: clearly the development team has more work to do, and we are glad to have won further funding from the Digital Research Services programme in 2019-2020 in order to do it.

Attitudes toward university ownership of data assets was also a mixed bag; some were sceptical and wondered if researchers would participate in such a scheme, but others found it a realistic option for dealing with staff turnover and the inevitability of data outlasting data owners. Attitudes toward cost were largely accepting (the DataVault provides a cheaper alternative than our baseline DataStore disk storage), but concerns about the safekeeping of legacy and unfunded research data were raised at each workshop.

A sample of points raised follows:

  • Utility? “Everyone I know has everything on OneDrive.”
  • Regarding prioritisation of features – security first; file integrity first; putting data from other sources than DataStore; facilitating larger deposit sizes; ease of use.
  • Quickness of deposit and retrieval? Deposit was deemed more important to be quick than retrieval.
  • University as data asset owner?
    • Under GDPR the data are already university assets (because the Uni is the data controller).
    • People who manage the data should be close to the research; IT people can manage users but shouldn’t be making decisions about data. Danger that because it’s related to IT it gets dumped on IT officers. The formal review process helps to ensure decisions will be made properly. Include flexibility into the review hierarchy to allow for variation in school infrastructure.
    • When I heard that I was – not shocked – but concerned. If I move to another university how do I get access? This might be a problem. Researchers might prefer to retain three copies themselves.
  • Is the cost recovery mechanism valid?
    • Vault costs are legitimate costs.
    • Ideally should come from grant overheads, until then need to charge.
    • Possible to charge for small / medium/large project at start rather than per TB?
  • Is the 100 GB threshold sufficient for unfunded research? How else could unfunded or legacy data be covered (who pays)?
    • Alumni sponsor a dataset scheme?
    • There will be people with a ‘whole bunch of data somewhere’ that would be more appropriately stored in DataVault.

The team is grateful to all of the workshop participants for their time and thoughts; the report will be considered further by the project board and the Research Data Service Steering Group members. The full set of workshop notes are colour-coded to show comments from different venues and are available to read on the RDM wiki, for anyone with a University log-in (EASE).

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

Announcing our new “Quick Guides” series

Posted on by
Reply

Earlier this week we bid farewell to our intern for the past four weeks, Dr Tamar Israeli from the Western Galilee College Library. Tamar spent her time with us carrying out a small-scale study on the collaborative tools that are available to researchers, which ones they use in their work, and what support they feel they need from the University. One of Tamar’s interviewees expressed a view that “[the University’s tools and services] all start with ‘Data-something’, and I need to close my eyes and think which is for what,” a remark which resonated with my own experience upon first starting this job.

When I joined the University’s Library and University Collections as Research Data Support Manager in Summer 2018, I was initially baffled by the seemingly vast range of different data storage and sharing options available to our researchers. By that point I had already worked at Edinburgh for more than a decade, and in my previous role I had little need or obligation to use institutionally-supported services. Consequently, since I rarely if ever dealt with personal or sensitive information, I tended to rely on freely-available commercial solutions: Dropbox, Google Docs, Evernote – that sort of thing. Finding myself now in a position where I and my colleagues were required to advise researchers on the most appropriate systems for safely storing and sharing their (often sensitive) research data, I set about producing a rough aide memoire for myself, briefly detailing the various options available and highlighting the key differences between them. The goal was to provide a quick means or identifying – or ruling out – particular systems for a given purpose. Researchers might ask questions like: is this system intended for live or archived data? Does it support collaboration (increasingly expected within an ever more interconnected and international research ecosystem)? Is it suitable for storing sensitive data in a way that assures research participants or commercial partners that prying eyes won’t be able to access their personal information without authorisation? (A word to the wise: cloud-based services like Dropbox may not be!)


[click the image for higher resolution version]

Upon showing early versions to colleagues, I was pleasantly surprised that they often expressed an interest in getting a copy of the document, and thought that it might have a wider potential audience within the University. In the months since then, this document has gone through several iterations, and I’m grateful to colleagues with specific expertise in the systems that we in the Research Data Service don’t directly support (such as the Wiki and the Microsoft Office suite of applications) for helping me understand some of the finer details. The intention is for this to be a living document, and if there are any inaccuracies in this (or indeed subsequent) versions, or wording that could be made clearer, just let us know and we’ll update it. It’s probably not perfect (yet!), but my hope is that it will provide enough information for researchers, and those who support them, to narrow down potential options and explore these in greater depth than the single-page table format allows.

With Tamar’s internship finishing up this week, it feels like a timely moment to release the first of our series of “Quick Guides” into the world. Others will follow shortly, on topics including Research Data Protection, FAIR Data and Open Research, and we will create a dedicated Guidance page on the Research Data Service website to provide a more permanent home for these and other useful documents. We will continue to listen to our researchers’ needs and strive to keep our provision aligned with them, so that we are always lowering the barriers to uptake and serving our primary purpose: to enable Edinburgh’s research community to do the best possible job, to the highest possible standards, with the least amount of hassle.

And if there are other Guides that you think might be useful, let us know!

—

Martin Donnelly
Research Data Support Manager
Library and University Collections

Research Data Workshops: Electronic Notebooks Summary of Feedback

Posted on by
Reply

In the spring of this year (March & May) the Research Data Service ran two workshops on Electronic Notebooks (ENs) where researchers from all three colleges were invited to share their experiences of using ENs with other researchers. Presentations and demos were given on RSpace, Benchling, Jupyter Notebooks, WikiBench, and Lab Archives. Almost 70 research and support staff attended and participated in the discussions.

This post is a distillation of those discussions and we will use them to inform our plans around Electronic Notebooks over the coming year. It was obvious from the level of attendance and engagement with the discussions that there was quite a lot of enthusiasm for the idea of adopting ENs across a variety of different schools and disciplines. However, it also quickly became clear that many researchers and support staff had quite justified reservations about how effectively they could replace traditional paper notebooks. In addition to the ENs which were the subject of presentations a number of other solutions were also discussed, including; LabGuru, OneNote, SharePoint, and Wikis.

It appears that across the University there are a very wide range of platforms being used, and not all of them are intended to serve the function of an EN. This is unsurprising as different disciplines have different requirements and an EN designed for the biological sciences, such as Benchling, is unlikely to meet the needs of a researcher in veterinary medicine or humanities. There is also a huge element of personal preference involved, some researchers wish a simple system that will work straight out of the box while others want something more customisable and with greater functionality for an entire lab to use in tandem.

So, within this complex and varied landscape are there any general lessons we can learn? The answer is “Yes” because regardless of platform or discipline there are a number of common functions an EN has to serve, and a number of hurdles they will have to overcome to replace traditional paper lab books.

Firstly, let’s look at common functional requirements:

  1. Entries in ENs must be trustworthy, anyone using one has to be confident that once an entry is made it cannot be accidentally deleted or altered. All updates or changes must be clearly recorded and timestamped to provide a complete and accurate record of the research conducted and the data collected. This is fundamental to research integrity and to their acceptance by funders, or regulators as a suitable replacement for the traditional, co-signed, lab books.
  2. They must make sharing within groups and between collaborators easier – it is, in theory, far easier to share the contents of an EN with interested parties whether they are in the same lab or in another country. But in doing so they must not make the contents inappropriately available to others, security is also very important.
  3. Integration is the next requirement, any EN should be able to integrate smoothly with the other software packages that a researcher uses on a regular basis, as well as with external (or University central) storage, data repositories, and other relevant systems. If it doesn’t do this then researchers may lose the benefits of being able to record, view, and analyse all of their data in one place, and the time savings from being able to directly deposit data into a suitable repository when a project ends or a publication is coming out.
  4. Portability is also required, it must be possible for a researcher to move from one EN platform to another if, for example, they change institutions. This means they need to be able to extract all of their entries and data in a format that can be understood by another system and which will still allow analysis. Most ENs support PDF exports which are fine for some purposes, but of no use if processing or analysis is desired.
  5. Finally, all ENs need to be stable and reliable, this is a particular issue with web based ENs which require an internet connection to access and use the EN. This is also an area where the University will have to play a significant role in providing long-term and reliable support for selected ENs. They also need the same longevity as a paper notebook, the records they contain must not disappear if an individual leaves a group, or a group moves to another EN platform.

Secondly, barriers to adoption and support required:

  1. Hardware:
    1. Many research environments are not suitable for digital devices, phones / tablets are banned from some “wet” labs on health and safety grounds. If they are allowed in the lab they may not be allowed out again, so space for storage and charging will need to be found. What happens if they get contaminated?
    2. Field based research may not have reliable internet access so web based platforms wouldn’t work.
    3. There is unlikely to be space in most labs for a desktop computer(s).
    4. All of this means there will still be a need for paper based notes in labs with later transfer to the EN, which will result in duplication of effort.
  1. Cost:
    1. tablets and similar are not always an allowable research expense for a grant, so who will fund this?
    2. if the University does not have an enterprise licence for the EN a group uses they will also need to find the funds for this
    3. additional training and support my also be required
  2. Support:
    1. technical support for University adopted systems will need to be provide
    2. ISG staff will need to be clear on what is available to researchers and able to provide advice on suitable platforms for different needs
    3. clear incentives for moving to an EN need to be communicated to staff at all levels
    4. funders, publishers, and regulatory bodies will also need to be clear that ENs are acceptable for their purposes

So, what next? The Research Data Support service will now take all of this feedback and use it to inform our future Electronic Notebook strategy for the University. We will work with other areas of Information Services, the Colleges, and Schools to try to provide researchers in all disciplines with the information they need to use ENs in ways that make their research more efficient and effective. If you have any suggestions, comments, or questions about ENs please visit our ENs page (https://www.ed.ac.uk/information-services/research-support/research-data-service/during/eln). You can also contact us on data-support@ed.ac.uk.

The notes that were taken during both events can be read here Combined_discussion_notes_V1.2

Some presentations from the two workshops are available below, others will be added when they become available:

Speaker(s) Topic Link
Mary Donaldson (Service Coordinator, Research Data Management Service, University of Glasgow) Jisc Research Notebooks Study Mary_Donaldson_ELN_Jisc
Ralitsa Madsen (Postdoctoral Research Fellow, Centre for Cardiovascular Science) RSpace 2019-03-14_ELN_RSpace_RRM
Uriel Urquiza Garcia (Postdoctoral Research Associate, Institute of Molecular Plant Science) Benchling
Yixi Chen (PhD Student, Kunath Group, Institute for Stem Cell Research) Lab Archives 20190509_LabArchives_Yixi_no_videos
Andrew Millar (Chair of Systems Biology) WikiBench
Ugur Ozdemir (Lecturer – Quantitative Political Science or Quantitative IR) Jupyter Notebooks WS_Talk
James slack & Núria Ruiz (Digital Learning Applications and Media) Jupyter Notebooks for Research Jupyter_Noteable_Research_Presentation

Kerry Miller, Research Data Support Officer, Research Data Service

DataVault is now live

Posted on by
Reply

After extended development, the Research Data Service’s DataVault system is now operational, adding value to research data for principal investigators and their funders alike by offering a long-term retention solution for important datasets.

DataVault is a companion service to DataShare, the institutional digital repository for researchers to openly license and share datasets and related outputs via the Web. DataVault comprises an online interface connected to the university’s data centre infrastructure and cloud storage.

Each research project can store data in a single vault made up of any number of deposits. DataVault is currently able to accept individual deposits (groups of files) of up to 2 TB each; this will increase over time as project development continues.

DataVault sprint meeting before launch

Immutable

DataVault is designed for long-term retention of research data, to meet funder requirements and ensure future access to high value datasets. It meets digital preservation requirements by storing three copies in different locations (two on tape, one in the cloud) with integrity checking built-in, so that the data owner can retrieve their data with confidence until the end of the retention period (typically ten years).

Secure

The DataVault interface helps to guide users in how to deposit personal and sensitive data, using anonymisation or pseudonymisation techniques whenever possible, as prescribed by the University’s Data Protection Officer (DPO). Because all data are encrypted before deposit, they are protected from unauthorised disclosure. Only the data owner or their nominated delegate is allowed to retrieve data during the retention period. Any decisions about allowing access to others are made by the data owner and are conducted outside the DataVault system, once they have been retrieved onto a private area on DataStore and decrypted.

Discoverable

Although DataVault offers a form of closed archive, the design encourages good research data management practice by requiring a metadata record for each vault in Pure. These records are discoverable on the Web, and linked to the respective data creators, projects and publications.

In exchange for creating this high level public metadata record, the Principal Investigator benefits from the assignment of a unique digital object identifier (DOI) which can be used to cite the data in publications.

The open nature of the metadata means that any reader may make a request to access the dataset. The data owner decides who may have access and under what conditions. Advice can be provided by the Research Data Support team and the DPO.

University data assets

DataVault’s workflow takes into account the possibility/likelihood that the original data owner will have left the university when the period of retention comes to an end. Each vault will be reviewed by representatives of the university in schools, colleges or the Library, acting as the data owner, to make decisions on disposal or further retention and curation. If kept, the vault contents become university data assets.

Plan ahead for data archiving

The Research Data Support team encourages researchers to plan ahead for data archiving, right from the earliest conception stages of the project, so that appropriate costs are included in bids, and enabling the appropriate steps to be carried out to prepare data for either open or closed long-term archiving.

The team can be contacted through the IS Helpline and offers assistance with writing data management plans and making archival decisions. See our service website and contact information at https://www.ed.ac.uk/is/research-data-service or go straight to the DataVault page to learn more about it, get instructions for use, or look up charges. An introductory demo video is available  at  https://media.ed.ac.uk/media/Getting+started+with+the+DataVault/1_h4r4glf7 .

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