Yoda @ WUR

Yoda is a research data management platform that enables you and your research partners to securely deposit, share, publish, and preserve (large amounts of) research data during all stages of a research project.

Yoda allows you to store data in a simple filing structure similar to that on the W:-drive or OneDrive, while it also allows easy collaboration and addition of metadata to the data. Yoda can help researchers archive their research data (and eventually be able to publish research data, but this is not possible as of yet) meeting some of the FAIR goals. WUR Library offers Yoda at the group level (e.g. chair group or business unit), but also at the project level (e.g. project team) when the project overarches several research groups (within and / or outside WUR). Usage of Yoda@WUR is free of charge to WUR chair groups, business units and projects on condition of the Yoda@WUR terms of use.

How to get started

  • Determine who will perform general Yoda management tasks.
    To work with Yoda in your research group / business unit / or research project, someone needs to be appointed to manage general aspects of Yoda. This person will receive system rights to create new parent folders, manage users that have access to data, and receive ‘Yoda data manager’ rights to review and approve data archival submissions to the Yoda Vault. These responsibilities can be shared across multiple users within your group. Usually, the data steward of your group would fulfil these tasks, but anyone familiar with best practices in data management can receive the same rights if approved by your group.
  • Send an email to data@wur.nl with the following information:

    • For which research group or project an account needs to be created.
    • Who will perform general Yoda management for the requested account.
    • Who the project leader / business unit holder / chair-group holder is (preferably within the cc of the email; as that person will have final responsibility of data within the research group).
  • Access Yoda@WUR through the webportal at https://yoda.wur.nl or connect to Yoda with a client programme using https://data.yoda.wur.nl. Note: when using iCommands as command line interface to Yoda, a different address setup is required. Please contact data@wur.nl for more information.


Check https://servicedesk.surf.nl/wiki/display/WIKI/Yoda+user+guide for general information on Yoda usage. Join the MS Teams for Yoda users for updates, issues, information, or ask for help. If you have any questions regarding Yoda usage or would like a short demo, please contact data@wur.nl.

Frequently Asked Questions

Can Yoda serve as an alternative for the M:-drive and/or MS-OneDrive?

Yoda is an alternative for OneDrive, as it operates in a similar manner with synchronisation clients. It is not a direct replacement for the M: and W:-drive, as it does not provide a network drive capability.

How do I use Yoda on my computer?

After you have been given access to Yoda by your data manager, you can connect to Yoda in various ways:

  • Via the web portal at https://yoda.wur.nl. Here, you can upload and download data, edit metadata, archive and (soon) publish data.
  • Connecting with a local client on your laptop. See the question 'My upload speed is very slow, can I use different clients to connect with Yoda?' below for more information.

Note: even though it is possible to connect to Yoda@WUR as a standard Windows network drive, we recommend using a different client (like CyberDuck, WinSCP, iCommands, GoCommands, etc.) as they allow larger data transfers and are a bit faster in terms of transfers.

Signing into Yoda@WUR and the SRAM invitation.

In March 2024, Yoda@WUR transitioned into a new way of signing in called SURF Research Access Management (SRAM). SRAM allows other universtities that have SRAM activated for Yoda to login using their own institutional credentials once such a user was added to a folder in Yoda@WUR. Previously, those users had to create their own password and were treated like any other external user. External users that are not from an institute that uses Yoda or SRAM, now have to create an EduID so that their account can be linked to Yoda. This forces these users to also apply 2FA when logging in to the web portal, which was not possible before. This SRAM activation is another step for higher security within Yoda@WUR.

WUR users:
Once a WUR user is added to Yoda@WUR, the system will send out an SRAM invite specifying it is from Victoria Peterson (SRAM admin at WUR). If a WUR user has never accepted an SRAM invite before, they need to accept the invite before signing into Yoda@WUR. They only need to accept one invite even though they might receive multiple. Once accepted, they can keep signing in using their WUR credentials.

External users:
External users, not from an institute using SRAM (such as WUR), now have to first create an EduID. Once an external user is added to Yoda@WUR, the system will send out and SRAM invite specifying it is from Victoria Peterson (SRAM admin at WUR). If the external user has never before, they need to accept the invite before signing into Yoda@WUR. To accept the SRAM invite, they need to start creating an EduID and follow the steps afterwards. Then the SRAM invite needs to be accepted using the EduID created. After SRAM acceptance, the external user can sign into Yoda@WUR, in the screen that follows after typing the email address they have to choose 'EduID'(by typing and then selecting EduID NL).

What is the storage capacity a user gets on Yoda? 

Yoda@WUR is offered free of charge to WUR chair groups / business units / project (Yoda category) on condition of the Yoda@WUR terms of use.

There is no limit, but at 25TB of storage within a category, Data Management Support will contact the chair group / business unit / project to advise on optimisation of Yoda usage.

Note that the Yoda@WUR trash (only accessible on iCommands) is emptied every month for files older than 30 days.

For more information please email data@wur.nl.

Will the M: or W: drive be phased out in favour of Yoda? 

Yoda is not intended to replace the M: or W:-drive.

My upload speed is very slow. Can I use different clients to connect to Yoda?

We recommend the use of two different clients to synchronise data with Yoda:

  • Cyberduck is compatible with Windows and Mac. This is the easiest client to use, but provides less advanced options.
  • WinSCP works on Windows only, but allows more advance features for continuous synchronisation and other features.

Both clients are free to use and installable through the WUR Software Center. Please note that many other clients do not offer the ability to connect through a network drive (including CyberDuck), you will be using the user interface of that client to upload and download data. Also note, as of Yoda 1.8, the Yoda webportal is greatly improved and allows large data uploads and downloads.

If you are uploading massive amounts of data, then using the command line tool iCommands or the iRODS API (for example in python https://github.com/irods/python-irodsclient) is recommended. As iCommands requires an elaborate set-up on Windows systems (using Windows Subsystem for Linux), please contact data@wur.nl for more information and to get started with iCommands. If you’re familiar with Linux or python, take a look at https://servicedesk.surf.nl/wiki/pages/viewpage.action?pageId=19824798 or https://github.com/irods/python-irodsclient.

Are different clients better security wise? Is one client more safe than the other?

No, recommended clients (CyberDuck, WinSCP, iCommands) are safe for all types of data that can be placed in Yoda. The only reason to use different clients is for better upload speed, stability, or configuration options.

Can files of Yoda users be searched in the research and vault environment on various criteria such as submittal status or metadata items?

Yes, a faceted search is available. Use the search bar at the top of the page. After the initital search you will be able to select the item to search in (filename, folder, metadata, status, revision).

Default metadata scheme.

The metadata scheme to choose when creating a parent folder in Yoda@WUR (i.e. a research group), is the scheme called 'default-[number]'. As of April 2024, the latest updated scheme is default-3. This is also the metadata scheme automatically selected by the system when creating a new parent folder. Other metadata schemes are available to be chosen, but these were not created in collaboration with WUR (part of general Yoda software) and WUR currently does not fully support these. In addition, once publication through Yoda@WUR is possible, the 'default-[number]' metadata schemes ensures that the DataCite metadata is harvestable by DataCite and, therefore, better findable online.

For more information on the default metadata scheme see the documentation at https://www.uu.nl/en/research/yoda/guide-to-yoda/i-am-using-yoda/documenting-your-data. To determine what the other schemes consist of, see https://github.com/UtrechtUniversity/yoda-ruleset/tree/development/schemas.

Technically, the Yoda software can customize metadata schemes, but is currently not supported at WUR. It might be that in the future new metadata schemes can be supplied to SURF to be incorporated into Yoda@WUR. Such schemes, however, require regular maintenance and updating along with Yoda maintenance and updates while being harvestable when data is published, and is therefore not an easy feat to implement and maintain.

What is the difference between groups and (sub)categories?

A category is a top level hierarchy, it contains all user research-groups within your Yoda environment. Subcategories can be used to further organise these research-groups. A research-group is a folder that the user sees as top level folder / parent folder. Users can only see folders and their data for the research-groups (read parent folders) that they are a member of. So you can use groups to separate data access for different users.


  • animal-sciences-group (category)

    • chairgroup-adp (sub-category)

      • research-project-health (parent folder)
      • research-project-dekoning (parent folder)
      • etc.
    • chairgroup-ezo (sub category)

      • research-project-zoology (parent folder)
      • research-project-flight (parent folder)
      • etc.


  • chair-group-adp (category)

    • adp-behaviour (sub-category)

      • research-project-tailbiting-pigs (parent folder)
      • research-project-enriched-vs-barren (parent folder)
    • adp-immunology (sub-category)

      • research-project-nabs (parent folder)
      • research-project-selection-lines (parent folder)

Note that the 2 example are different ways in using Yoda. In the first example, the costs of Yoda usage are carried by the animal sciences group, in the second example by the ADP chair group. The Yoda costs (and allocation of the first free TB) are carried by the category.

What data classification should I select: Public, basic, sensitive, critical? Can I restrict user access by doing this? 

At the moment, the Yoda data classification is just a label in the Yoda system with no technical distinction. All data in Yoda is handled as serious, regardless of the label. However, it is good practice to try and classify data appropriately. For example, ‘Public’ for public data, ‘Basic’ for common projects, ‘Sensitive’ for personal data or data to remain internal, and ‘Critical’ when special types of personal data (religion, sex, etc.) are collected or, for example, company secrets. If you believe you have data with a ‘Critical’ classification, please contact data@wur.nl to discuss security measures in detail. Note that WUR uses the terms ‘Negligible’, ‘Some’, ‘Serious’, and ‘Disruptive’, which (unofficially) conform to the Yoda terms, respectively, ‘public’, ‘basic’, ‘sensitive’, and ‘critical’.

See also here for a guide on how to classify data using the WUR terms.

What is the Yoda Vault?

The Yoda Vault is an area within Yoda where data cannot be overwritten or deleted by users (only possible by Yoda system admins). This is different from the Yoda Research environment (the work environment) in which a user can access, modify, and work with the available files. It is useful to safeguard data within the Vault at key-moments in research so that a secure version of the data as it was during deposit to the vault is retained and available. One could imagine sending data to the Vault when all raw data are collected and / or at the end of the project. Note that submitting data to the Vault counts in the total used storage space (a copy of the data is sent to the vault). This means that if you have 1TB of research data in the Research environment (your work environment) and send that data (i.e., a copy of that data) to the vault, you are using 2TB of storage space. It is, therefore, recommended to determine beforehand what the key moments are to submit to the vault within your research. When you’re done with the project and do not need to work from the research environment anymore (you do not need direct access to the data) and you submitted the data to the Vault, you can delete the data in the research environment to save on storage space.

How do I approve data to the Vault?

If you have Yoda data manager rights, then it is expected that you approve Yoda Vault submissions. Go to Yoda, sign in, and select in the search bar ‘Search by status’ and select the required status to search for. Any submission requests are now visible. You need to check a submission on:

  • whether a good and consistent folder structure is applied.
  • whether a good and consistent naming structure is applied.
  • whether thorough and elaborate documentation is present that explains the folder structure, data, abbreviations, etc.
  • whether the Yoda metadata form is completely and accurately filled in.
  • whether non-preferred file formats are used (use in the webportal the button ‘actions’ --> ‘check for compliance with policy’ --> choose ‘DANS preferred formats’).
  • whether data is conform best practices in data analysis for your discipline (should conform to commonly used data representation; for example: no spaces in column names, first row in spreadsheets should contain column headers and not the third row, column headers should not be spread over multiple rows, should be consistently named between files, data should be similarly represented between files, etc).
  • whether personal data is present and whether they conform to appropriate security measures or whether they are allowed to be stored (for example, are the researchers allowed to store this data, do they have informed consents of participants).

See the appropriate pages at https://www.wur.eu/rdm for more information on documentation, organising files and folders, file formats, and sharing data.

If the submission is evaluated and there are no issues, then you can click in Yoda on the button ‘actions’ --> ‘approve submission’. A copy of the data will then be transferred to the Vault.