1. DataverseNL Laura Huis in ’t Veld & Paul Boon Dutch Dataverse
DataverseNL is hosted by DANS, so I will first give you an introduction about DANS and why we host a Dataverse instance.
After that, I will talk about about our cooperative service model we have set up for DataverseNL. What is it, and what are the challenges when using this model?
The second part of the presentation will be given by Paul. He will tell you more about the technical side, our installation specifics, our work in progress and technical challenges.
Laura Huis in ’t Veld & Paul Boon
Application managers DataverseNL
June 14th Dataverse Community Meeting 2018

2. DANS & DataverseNL Three core services: And: Training and Consultancy
(Inter)national projects
DataverseEU
DANS stands for Data Archiving and Networked Services. We are a Dutch institute of the Academy of Arts and Sciences and Netherlands Organization for Scientific Research. Our mission is to promote and provide permanent access to digital research resources.
In order to do that we offer three core services, NARCIS, EASY and DataverseNL.
NARCIS = A national portal that provides access to scientific information, it aggregates metadata of scientific publications and datasets of all the Dutch universities and a number of other Dutch research institutes.
EASY = Online archiving system for depositing research data. It offers sustainable and certified archiving for the long term.
DataverseNL = We offer DataverseNL for storing digital research data during the research phase and for mid term archiving. Up to 10 years.
Besides these three services we also offer Training and consultancy on the subject of research data Management, and we participate in several international projects.

3. The DataverseNL team
Account manager Application manager Functional application manager Software developer Software developer / consultant ICT support
At DANS we have a dedicated DataverseNL team that consists of an account manager, software developers, ICT support and application managers. Paul and I are both application managers, but Paul is responsible for the technical side. I am responsible for the user support, e.g. I help our partners with the configuration of dataverses, do software testing from a user perspective and I discuss the software requirements with our partners. So who are these partners? (over to the next slide)

4. Cooperative service model
Front-office (institutions), Back office (DANS)
Sharing costs and knowledge
different priorities and policies
For DataverseNL, we work with a cooperative service model.
This means that the responsibilities for the service are divided between DANS and the participating partners.
DANS serves as back office and is responsible for the servers, storage and software development. We are the ’superadmin’.
The DataverseNL partners - logo’s on the slide - are mostly universities and higher education institutions. They are responsible for Research Data Management support for their own staff and researchers. They are also responsible for the content in their institutional dataverses. Each partner has an assigned local administrator, who has the admin role for the dataverses of their institution. They serve as front office for their researchers.
Advantages of this model:
Shared cost, shared knowledge. There is a regular meeting with all the local administrators where we keep each other informed about dataverse issues, but also about Research Data management in general.
All datasets available through one interface.
But this model also comes with some challenges.
Different institutes, different policies…(Mid term, or long term archive? Should it have Core Trust Seal or not?)
Different max. amount of storage needed, different use agreements
So, now you now about our service model, I will hand over the floor to Paul who will explain how this model reflects on our software development.
SLA and collaboration agreement
Advisory board and committee of local administrators

5. Our current installation
Customized Github fork of version 4.8.6
Persistent identifiers with Handles
Institutional login with Shibboleth
Automated deployment with Vagrant and Ansible
‘Movertool’ for moving datasets
Hi, I am Paul and I will give the next, slightly more technical, part of this presentation.
First a short summary of what we have in place for the Dutch Dataverse.
We have adapted parts of the code, so run a fork of version 4.8.6
For persistent identifiers, we use Handles instead of DOIs
We use Shibboleth for the institutional login (SingleSignOn)
Automated deployment, for upgrades and testing, is done with Vagrant and Ansible
An we have added a separate ‘Dialog application’ for moving Datasets from one verse to another.

6. Work in progress
Miniverse adaptation statistics for institutional verses
Sword deposit - bridge to archive for long term preservation (EASY)
Local storage vs. cloud storage based on institution demands?
We are currently working on several functionalities.
Miniverse, this is adapted to show statistics for the set of institutional verses, based on affiliation. Each institute can inspect its own ‘statistics’. (Slava’s work)
Support Sword deposits of datasets from the DaverseNL archive to our long term preservation archive (EASY). (Eko’s work)
These two are ‘almost’ finished and mainly the work of Slava and Eko.
We are ‘thinking’ about developing functionality to allow individual institute's to have their data stored in the cloud.

7. Challenges Make our additions useful for the community And share it
What we think are the main challenges for the development of Dataverse (NL)
These have to do with the ‘open source’ nature of Datavesre
It is way simpler to make something that ‘just works for us’, than it is to make it work for everyone.

8. Challenges Achieve a common goal Instinctive vs Orchestrated
Related to this is to keep going in the ‘same’ direction to achieve some ‘common’ goals.
Where are we going, and how much orchestration do we need?

9. Summary DataverseNL – in a nutshell Cooperative service model
Development of additions is driven by wishes of multiple institutions
Open source development is a community effort
So, to summarize, DataverseNL is based on a cooperative service model. This means we have one back office, but each partner institution has his own front office and their own user requirements. Our challenge is to develop the software in a way that every institution is satisfied with the end result. In addition to this challenge, we also want to be part of the dataverse open source community, so we need to think carefully about how we develop our code. Being at the Dataverse community meeting is a good way to achieve common goals.

10. Any questions? dans.knaw.nl https://dataverse.nl
This was our short explanation of what we have at DataverseNL
If you have any questions, please ask