An extensive manual on Yoda for managing your research data.

What is Yoda?

Yoda is a research data management service supported by Wageningen University & Research (WUR). It enables researchers, students, and staff to securely store, share, archive, and publish research data. Yoda supports data sharing across institutions, making collaboration with colleagues and external partners possible. Yoda is divided into two environments – the Research area for active research and the Vault for archiving data  (see the Glossary below for more details).

Yoda is built on the iRODS framework framework, which provides the underlying infrastructure and core data management capabilities of the system. Yoda is being developed by Utrecht University, and it is designed with the FAIR principles in mind, ensuring that research data is:

• Findable & Accessible - Yoda enables researchers to search and receive data, through means of filled metadata forms, within the Yoda portal or online once a data package is published. Once published, data is findable through a Digital Object Identifier (DOI) – providing a unique and permanent link to the data. Additionally, the data is freely available or available upon request. To protect sensitive data, only the metadata can be published.
• Interoperable & Reusable - Yoda enforces standardised and rich metadata that comply with domain standards, ensuring consistency and machine-readability. In addition, metadata can be reused across folders within Yoda.

For more information about Yoda, please see https://www.uu.nl/en/research/yoda. 

Glossary

Yoda@WUR

Many organisations, both in the Netherlands and abroad, are using Yoda. Yoda’s instance for WUR – Yoda@WUR - https://yoda.wur.nl/ is hosted by SURF (Dutch ICT of education and research). While University Utrecht is the main developer of Yoda, SURF oversees Yoda@WUR’s performance, stability, and maintenance. Yoda is listed in the WUR Approved Apps tool and is suitable for research data up to classification Serious. For more details, please see Data classifications.

Requesting a Yoda@WUR account

My research group already has a Yoda@WUR account: please contact your group’s data manager in Yoda (this is usually your data steward, find them here), and they will help you further. I don’t know if my research group has a Yoda@WUR account: please send an email to data@wur.nl and let us know with which research group you are affiliated.

My research group has no Yoda@WUR account: please follow the following steps:

• Determine who will be the Yoda data manager: to work with Yoda, someone within your research group must be appointed to manage its general aspects. See here for data manager’s tasks in Yoda. Typically, the group's data steward fulfils these tasks, but that is not a requisite. The data manager will receive system privileges to create new parent folders and manage users’ access rights.
• The Yoda terms of use need to be agreed upon.
• Send an email to data@wur.nl with the following information
  
  • For which research group or project is the Yoda@WUR account requested?
  • Who will be the Yoda data manager?
  • Who is the chair group/business unit holder or project leader? Please, include them in the Cc of the email as they will have the final responsibility of the data. 

Once data@wur.nl receives the request, one of Yoda@WUR administrators will create a Yoda category for your group and grant data manager rights to your group’s data steward or other appointed colleague.

Yoda@WUR Teams channel

Yoda@WUR has its own Teams channel, which is accessible to all Yoda@WUR users. By clicking on the link, you will be automatically added to the group - General | Yoda@WUR_Users | Microsoft Teams. In the Teams channel, you can for example read about maintenance interruptions and report issues to which Yoda admins respond.

Yoda@WUR costs

Upon creation, each Yoda category – for a research group or large project – is allocated 25TB of initial storage. Only ‘active’ data in the Research area are included in this limit. Archived data in the Vault are not included in the cost evaluation. Regularly archiving data helps to optimise both storage use and costs.

There is >25TB initial storage needed

Extra storage can be provided but must be approved by the chair or business unit holder or project lead. An email with approval must be shared with data@wur.nl. 

The 25TB is exceeded

Storage usage in Yoda is monitored regularly and reported back to each Science Group. If a Yoda category exceeds the initial 25TB, data@wur.nl will notify the data manager(s) and provide guidance on how to optimise data storage. Suggestions may include:

• Archiving infrequently accessed data to the Vault,
• Applying data compression strategies,
• Deselecting unnecessary data. 

A chair group/WR team/project that uses a disproportionate amount of storage relative to the Science Group’s total storage budget may incur additional storage charges, at the discretion of the Director of Operations of that Science Group. Additionally, the storage costs of Yoda categories exceeding 25TB is set to 100€/TB/year, equivalent to the costs of W-drive Massive storage. 

Data access and sharing in Yoda@WUR

Yoda@WUR uses the SURF Research Access Management (SRAM) method to ensure a secure log-in to Yoda through 2 Factor Authentication - 2FA. This requires users to log in with their email address and password and complete an additional verification step. While internal (WUR) users are authenticated through SRAM (SURF Research Access Management), external users use eduID.

Internal Yoda@WUR users

After navigating to https://yoda.wur.nl, enter your WUR email address to access Yoda@WUR. You will be redirected to SRAM. Select ‘Wageningen University & Research, provide your WUR credentials, and verify your identity using the Authenticator app on your WUR phone. From July 2026 onwards, internal users do not receive any SRAM invitations when added to a new research- group in Yoda. Please see here for more information about new SRAM design.

External Yoda@WUR users

For external users, logging into Yoda@WUR differs:

• Is the external user affiliated with an institute also using SRAM? They can log into Yoda@WUR using their own institutional credentials.
• Is the external user not affiliated with an institute using SRAM? They must use eduID to log into Yoda@WUR. EduID is an authentication method for students and researchers within the Netherlands, independent of educational or research institution. To give external users access to Yoda, please send them the following steps for creating an eduID – these should be followed exactly. Note: external users should first create an eduID before accepting the SRAM invitation.
  • Download the eduID app to your phone
  • Register eduID: go to https://eduid.nl/home, click ‘Create an eduID’ and link it to your phone – follow the instructions there. Please note that you have to use the same email address that was used to grant Yoda access.
  • Accept the SRAM invitation to join the Yoda collaboration that was sent to you.
  • When asked to specify under which institute you want to ‘Login with’, specify eduID (NL).
  • Authenticate yourself with your email and eduID app.
  • Login to Yoda@WUR via https://yoda.wur.nl/.

From July 2026 onwards, external users receive only one SRAM invitation, when they join Yoda@WUR for the first time, which they need to accept. Afterwards, if they are added to other research- groups in Yoda@WUR, they will not receive any more SRAM invitations.

Access methods

You can access Yoda through various methods:

• Via https://yoda.wur.nl,
• By mapping Yoda as a network disk through Cyberduck,
• By accessing iRODS via a command-line interface (CLI) client (iCommands, GoCommands) or a graphical user interface (iBridges).

Although all methods are safe, the method you choose depends on your needs and preferences (see Figure 2 below). Detailed descriptions for all Yoda clients can be found here.

The manuals for installing Cyberduck, GoCommands, iCommands and iBridges can be found in the attachments of this article. WUR does not support Mac OS and Linux. However, instructions on how to install Yoda clients on these two operation systems can be found here. Please note; for older Yoda versions several other methods were available, like mapping Yoda as a network drive using Windows native WebDAV client or WinSCP. Both methods have compatibility issues with newer versions of Yoda and are therefore not supported any longer.

Figure 1. Functionality comparisons for different Yoda access methods. Figure source: https://www.uu.nl/en/research/yoda/guide-to-yoda/accessing-yoda 

Storing data and security measures in Yoda@WUR

Since the Yoda@WUR instance is hosted at SURF, the data are physically stored in three geographically separated SURF data centers located in the Netherlands. SURF data centers are certified with the state-of-the-art ISO 27001 Information Security Management Standard. Data are being transferred to these data centers over an encrypted network and are not scanned or inspected in any way. Additionally, data integrity is ensured through checksum computation and comparison - an algorithm detecting the smallest errors in data transmission or storage. For more information about security measures, please see here.

Yoda’s two environments, the Research area and the Vault, are stored on different storage systems. When you place your data in the Research area, it is stored on a Ceph disk in the SURF data centers. Data placed in the Vault is stored in Object store. For more information about Ceph disk and Object store, please see here for more information.

Backup and replication

The research area is backed up through a Point In Time (PIT) backup. It is stored on the Object store and retained for 2 months. Please see here for more information. The data in the Vault - placed on Object store - is replicated 3 times to geographically separated data centers in Amsterdam (Science Park, Sloterdijk and Amsterdam Zuid). 

Revisions

Whenever you save a file in the Research area using the same file name, Yoda creates a revision - a snapshot of the file at the time of saving. In case you need to restore a previous version of a file, you can simply search through revisions and select which one you want. Yoda keeps multiple revisions on a decreasing time granularity scale - more revisions in recent history and fewer revisions further back in time. The revisions are stored for a maximum of 16 weeks, after which they are deleted. To restore file versions, please see here.  

Subcategories and research groups

With Yoda, you can securely store your data in a simple and familiar ‘file-and-folder' interface (Figure 2 below), comparable to the W-drive or OneDrive. Within each subcategory, Yoda data managers can create research- folders where users with appropriate privileges can place their data. 

Figure 2. Three examples of subcategories within a category.

Note that a subcategory is not an iRODS object but is created for easier group management and overview and is therefore only visible in the Yoda web portal and not in other clients. 

A research- group, functioning as a parent folder for e.g. a project, is the main folder where you store your data and it always starts with the word research-. Here, users with appropriate privileges can handle their data, create new subfolders, add metadata, and share their work with colleagues.  The Yoda data manager oversees the creation of new research- groups and adding new members who can have different priviliges/roles: 

• Viewer: can only view and download (read only access) the data within a research- group. 
• Member: can view, upload, download, modify or delete data (read/write access) within a research- group.
• Manager: has read/write access and can add or remove members to the research- group.

Please note that whoever has access to a research- folder automatically obtains access to all its subfolders.  

When creating a new research- group, a vault- group is simultaneously created, and automatically linked to that research- group. Because the Vault is set up in a way that does not allow any changes to the data package within, including the name of the vault- group, this means that once a research- group is created, it cannot be renamed. It is therefore crucial to think about your folder structure beforehand. If you want to rename your research group, you must create a new research group and copy all your data to it. The research- group and the vault- group are iRODS objects and are therefore visible and accessible in all Yoda clients, contrary to the (sub)category. 

Note: do not store data in the subcategory system. Each category (e.g. afsg-fch) has a subcategory called system, which function is solely to specify who the Yoda data manager of that category is. Please do not put any data in the system subcategory - moving data between subcategories is not a simple task. 

Data classifications

To secure your data properly, they first need to be correctly classified. Yoda uses different terminology in classifying data than WUR. See in the table below how the classification terms of Yoda and WUR relate to each other.

Metadata in Yoda@WUR

One of the core functionalities in Yoda is the ability to add metadata to the research- group level and its subfolders and is a key step to making your data more FAIR. Using Yoda, researchers can add structured metadata to their research group and its subfolders. When creating a new group (research- folder) the Yoda system automatically preselects the metadata schema named default-3. This default option is supported by WUR.

Please note, with future upgrades, the name of the default metadata form may change to default-[number>3]. Regardless, the default choice by the system will always be supported by WUR. Other metadata forms are available here.

In Yoda, a metadata schema contains more information than just the metadata itself. A metadata schema validates the metadata of a data package and contains information about how this metadata is displayed in the Yoda web portal. Therefore, a Yoda metadata scheme consists of two parts:

• A JSON schema file that is used to validate metadata of a data package.
• A UI schema file that contains information about the display of the schema in the web portal. 

When you click on the Metadata button within your research- group, an online metadata form appears. After filling it in and saving your changes, your metadata will be stored in a  yoda-metadata.json. This file is editable in other (source code) editors as well. Adding metadata is mandatory before archiving or publishing your data. If you decide to publish your data package, we recommend completing the metadata form – please see the Curation checklist for data packages in Yoda@WUR for more guidance.

Default-3 metadata schema

The default-3 metadata form conforms to the DataCite metadata standards, making the data package easily findable in data catalogues once published. It broadly describes the data package, and how it can be reused and cited. The fields in the metadata form have clear short descriptions. Please see the default-3 metadata description, the default-3 metadata description from SURF and the Curation checklist for data packages in Yoda@WUR for more detailed information about each of the fields.

Customised metadata schema

It is possible to customise your own metadata scheme, which can be incorporated into Yoda@WUR. Such schemes, however, require regular maintenance and updating. Maintenance of customised schemas must go along Yoda maintenance and updates schedule and is not such a simple feature. Therefore, data@wur.nl will not take responsibility for maintaining customised data schemes. They are the responsibility of the research group that developed them. Before starting a customised metadata schema in Yoda, please carefully read Metadata schemas in Yoda. 

If you would like to create a customised metadata scheme in Yoda: 

• Carefully read the instruction Metadata schemas in Yoda to get a general overview of what is required for a new metadata schema. Note, experience with programming and command line interfaces is required.
• You must include all the fields from the core-2 metadata schema.  
• Think about the structure of your schema and design it. We would recommend you start with the default-3 schema, study it and adjust it to your needs.  
• Give your metadata schema a name.
• After doing the preparation detailed above, contact data@wur.nl. We will arrange a meeting to discuss your wishes about your schema and give access to our Yoda@WUR test instance where you can test your new schema.
• Document your work well so that others from your group have sufficient information to maintain the new schema in the future. 

Note: only data packages using default-n metadata schemas will be findable online after publication. Customised metadata schema will not be visible once published. 

Archiving data in Yoda@WUR

The Vault is another name for the archive in Yoda. This is the environment where you can store your data for the long term. When archiving, a ‘snapshot’ of your data package -data and documentation - is placed in the vault. Once there, no changes to the data nor metadata are possible. If, however, you would like to modify your archived data package in the future you can easily copy it back to the Research area. You can recognise you are in your Vault area by prefix vault- preceding your folder name.

You can archive your entire research- folder or a subfolder within by submitting that folder to the Vault. When placing data in the Vault, you are strongly recommended to delete it from the Research area. There are several reasons to archive data in the Vault:

• Safeguard data at key moments, e.g. secure a version of the raw data, after data processing or analyses.
• When data is not actively or infrequently used.
• To free Yoda's storage and subsequently reduce storage costs.

Placing your data package in the Vault is a mandatory step for publishing. Once your data package has been accepted to the Vault, you can submit it for publication with a simple click (see below). Please, see here for more information and examples on archiving data in Yoda.

Deaccession of your Yoda package

In case the retention period of a data package has expired (set to 10 years by default) or if a data package needs to be removed for contractual reasons, it can be removed from the Vault or deaccessed. In the process of deaccession, the manifest file, listing the original data before deletion, is created. For published data packages, the landing page and DataCite metadata will be updated, providing a sort of tombstone of the deaccessed data package.

Publishing data with Yoda@WUR

Prepare your data package

When publishing your data package, it needs to be documented (e.g. README file, metadata form), organised (e.g. clear folder structure and file names), the data files need to be complete and personal data or otherwise sensitive data should be absent. To help you curate your data package, please have a look at the curation checklist for data package in Yoda@WUR. When your data package is ready for publication, it must be placed in the Vault. Your Yoda data manager then needs to accept the data package after which it can be submitted for publication.

Submit your data package

Please follow these step-by-step instructions on how to submit your data for publication. Yoda data managers and/or WUR data librarians will evaluate your submission for publication. There are two evaluation outcomes:

• Approval: you have provided everything specified in the WUR curation list and your data package is ready for publication (see below). 
• Request for improvements: there are several improvements to be made to increase the reusability of your data package. To do so, you will have to first copy the data package back to the Research area. After improvements, you can place it in the Vault again and resubmit it for publication.

Publishing your data package and access rights 

Once your data package is ready for publication, a data manager and/or data librarian will approve it, and within a few minutes, your work can be available online. Upon publishing your data package, you will have to agree to the Terms and Conditions (see below) - these pop up during the publication process. Read them carefully before agreeing.

You can publish your data with different access rights depending on the sensitivity or classification of the data:

• Open: the data package and metadata are published open access and therefore findable and accessible online.
  Example: https://publication.yoda.wur.nl/full/WUR01/WHMZ2L.html
• Restricted: only the metadata is published open access and therefore findable and accessible online. Access to your data package needs to be requested.
  Example: https://publication.yoda.wur.nl/full/WUR01/8PT7T6.html
• Closed: only the metadata is published open access and therefore findable and accessible online. Access to your data package cannot be requested.
  Example: https://publication.yoda.wur.nl/full/WUR01/OAETKJ.html

Once published, your data package will obtain a permanent digital object identifier – a DOI and a public landing page. With the DOI, the data package can be cited and promoted through social media. Additionally, data packages published through Yoda@WUR are automatically registered in Pure. The public landing page, starting with https://publication.yoda.wur.nl will contain all metadata about your data package and information about data access. The metadata form is registered in DataCite to facilitate findability of your data package.

Publishing a new version of your published data package

If you made some new progress with your research and would like to add these new results to the already published data package, that is possible in Yoda, too. During the publication steps (see step-by-step instructions) you can choose to link the publication to an existing one. Yoda will assign the new data package to the same base DOI and register it as a new version of the earlier data package.

De-publishing your data package

Generally, when a data package is published it stays published. However, it is possible to de-publish your data package in Yoda when there is a good reason, such as for example, privacy issues. Contact data@wur.nl for de-publishing your data packaged. When de-published, the reason why the data package is unavailable should be stated on the landing page. Note that your data package becomes unfindable online, but that the DOI will still be registered in Pure. Therefore, if you would like the DOI to be removed from the system as well, please contact data@wur.nl.

Questions & Support

Do you have any questions? Feel free to contact us at data@wur.nl.