YODA is one of the preferred storage options and the primary archiving solution for FGB research staff. The following faculty guide provides more information on YODA, its pros and cons, and information on how to use it safely and effectively with the faculty. The guide does not go into detail on technical information about YODA. Such details are described in the VU YODA manual. Relevant sections of the VU YODA Manual are referenced from this faculty guide.

What is YODA?

YODA (short for “Your Data”) is a software tool that helps VU researchers better manage the storage and archiving of their research data, as well as work towards making their data FAIR. A brief primer on YODA is found on this VUweb page and in this YouTube video.

What are the advantages of YODA?

YODA is a preferred storage and archiving option because:

  • YODA is approved for storing data with high privacy and/or confidentiality risks

    • NB: if your data are very high risk (a.k.a. “red” data), extra measures may be required to protect the data.

  • YODA does not have a storage limit. Storage is also free up to 500 GB and the costs beyond 500 GB are comparable to SciStor.

  • YODA is the only VU storage option that doubles as an archive. FGB researchers are required to archive all data that are used in published research articles.

  • YODA supports the creation of structured metadata for describing your datasets. This is an important step towards achieving FAIR data.

  • YODA has a data publishing option that assigns a permanent identifier to the published materials and openly publishes the structured metadata about the dataset.

    • Data published in YODA can have one of three access levels, depending on what is appropriate for your data and research. These are:
      • Open: fully, publicly accessible
      • Restricted: available for reuse upon request
      • Closed: not available for reuse
    • Metadata published in YODA can be imported into PURE to facilitate the registration of datasets used in your research articles.

What can’t YODA do?

  • YODA is not the best option for working with data that need to be regularly accessed & manipulated for processing and analysis, unless you are comfortable with the command line and programming languages.

  • YODA is not the best option for high-performance computing (HPC).

  • YODA does not provide the means to collect data itself. You will still need to use equipment, questionnaire tools or data-entry forms to collect data.

  • Aside from the structured metadata, YODA does not assist with the creation of data documentation, such as codebooks or README files.

  • YODA does not (yet) allow some files/folders to be openly available and others to be “restricted access” or “closed” within a single data publication. If some of your data and materials will be open and others will be “restricted access” or “closed”, review the guidance on folder structures and metadata & documentation.

  • YODA is not an electric lab notebook and it does not keep a record of data provenance.

  • YODA has some other technical limitations, including:


If YODA’s limitations mean it will not work for your use-case, consider the alternatives to YODA found in the FGB Storage Guide. You can also contact the FGB Research Data Stewards for guidance.

FGB procedures for working with YODA

Initial planning for YODA usage

  1. Determine total storage requirements:
    • Estimating the expected total storage will help you to estimate the potential costs of using YODA.
      • NB: This only applies if you will need to store and archive over 500GB of data. Below 500GB, storage and archiving in YODA is free.
      • NB2: You will need to determine which cost unit/order number/WBS element needs to be cited when completing your YODA request form. Even if you will not need more than 500GB of data, you need to provide this information during the intake process. If you are uncertain which cost unit/order number/WBS element to use, contact Project Control or your department manager for assistance.
  2. Determine privacy/confidentiality risks:
  3. Assess the feasibility and extent of data de-identification:
    • Try to de-identify the data you plan to store in YODA as much as possible. By planning ahead with de-identification, you can better plan how to define your folder structure and how your data will be organized. De-identification usually lowers the privacy/confidentiality risk level for your data and if you lower these risks, you can limit how many additional security measures you will need to apply.
  4. Determine an appropriate folder structure & who should have access to the data:
    • Decide on a “Group Manager”. They should be a senior researcher on the project, such as the PI, and they will responsible for adding users to your YODA group.
      • The highest level folder for your project is called the “data compartment”. When the Group Manager adds users to your YODA group, they are added at the data compartment level.
      • Assess whether everyone involved in your research project needs to have access to all of the data. Everyone given access to a data compartment has access to all of the folders and subfolders in that data compartment. The group manager can limit the rights of users to read-only, but a read-only user can still view and download data.
      • If some users shouldn’t have access to every (sub)folder and the data therein (e.g. students), you will need to request multiple YODA data compartments from the YODA admin
        • E.g. Request one data compartment for all of the data research staff is allowed to view and a separate data compartment of de-identified data that students may have access to.
    • Once you have one or more data compartments for your project, structure the folders in your data compartment(s) in a way that is understandable to you and your colleagues. Well organized folder structures make it easier to write code scripts for data processing and analysis, and a good folder structure will make it easier to archive and publish data in YODA later on, especially if some of the data and research materials will be published at different access levels. There is no one-size-fits-all way to structure your folders in YODA, but you can use the following templates as a starting point:
  5. Determine what additional data protection measures must be applied:
    • Assess the risks posed by your data and ensure any additional data protection measures are appropriate based on those risks.
      • If higher and lower risk data are all stored in the same data compartment, apply the measures necessary for the highest risk data present. The exception here is encryption: if the advice is to encrypt the higher risk data, but not the lower risk data, and they are both stored in the same data compartment, you only need to encrypt the higher risk data.

YODA during research

  • Keep your active data in the YODA “research” folder.

  • If you have data that must not be altered, but that is not ready for archiving, you can “lock” the folder containing the data by clicking the “Action” button on the top right and selecting “Lock”. The locked data are then made read-only. Locking data is reversible; simply select “Unlock” from the “Action” button.

    • “Locking” in YODA has nothing to do with encryption or preventing user access to a folder.
    • You don’t need to lock an entire data compartment. Navigate to the (sub)folder you want to lock and select the lock option from there.
    • It’s recommended to lock folders containing raw data, especially if the raw data cannot be replicated.

  • When collaborating with others, be very careful to avoid simultaneous use and modification of a data file. YODA has no way to handle simultaneous modification, so whoever saves the data last wins.

    • Make sure only one user at a time is working with a given data file.

Accessing data in YODA

As discussed in What can’t YODA do?, YODA unfortunately has a lot of limitations when it comes to data access and computing. There are ways to work around these limitations, but they require additional technical skill from the user. There are four main approaches to accessing and working with data in YODA and their usage depends on your situation.

Mounting the Network Disk Downloading and Uploading Streaming Transfer to SciStor/ADA
Method
description		 ➢ Connect directly to the YODA disk via WebDAV ➢ Download files to your device, run analyses/processing locally and upload relevant files.
➢ Downloading methods are described in the VU RDM Handbook.
➢Cyberduck can also be used for downloading/uploading.		 ➢ Connect directly to the YODA disk with the help of Python ➢ Transfer working data from YODA to SciStor/ADA for analysis
Pros ➢ No uploading and downloading of data required
➢ Data files and folders on YODA can be browsed as if they were on your own computer
➢ Small files (max a few MBs) can be processed and analysed but only with very simple operations (no complex analyses)		 ➢ Easy for any user
➢ No issues with slow or broken connections to the YODA disk
➢ No command-line skills required		 ➢ No uploading and downloading of data required
➢ Larger files can be analysed/processed without local copies; better performance than WebDav		 ➢ No uploading and downloading of data to local device
➢ Only a portion of total data in YODA on SciStor at a given time; reduces costs of SciStor usage
Cons ➢ Limited to small files and simple operations
➢ Risk of errors or changes being lost if connection is interrupted
➢ Modifying files directly on YODA increases risk of undesirable modification by accident
➢ Additional issues with this method are found in the VU RDM Handbook		 ➢ Must keep track of downloaded files and delete when no longer needed
➢ Not useful for very large files or high-perfomance computing tasks.		 ➢ Requires a stable internet connection
➢ Requires familiarity with the command-line and Python
➢ Does not automatically check if data is correct; requires manual review of data by checking size or content		 ➢ Requires familiarity with the command-line and iCommands
➢ There are costs for the portion of data stored on SciStor
Security ➢ Only one person should be working with a file at a time
➢ Disconnect the mounted disk by hitting the eject symbol when you don’t need to be connected
➢ Lock files to prevent inappropriate modification		 ➢ Keep track of where you download your files and delete them from your device as soon as they are no longer needed
➢ Review further guidance per data risk type		 ➢ Manually check that data accessed from or sent to YODA via streaming is correct
➢ If streaming with iBridges, close the session when done		 ➢ Clean up working files from SciStor when no longer in active use
➢ Ensure users have correct permissions when working with iCommands to prevent files on YODA being inappropriately overwritten when transferring from SciStor to YODA
Use-cases ➢ Very simple analyses/processing with small files
➢ Reviewing overall folder structure and what files are present		 ➢ Basic data analyses/processing that can be performed on your own computer
➢ Infrequent or one-off data processing/analyses		 ➢ Data processing/analysis of extracts of larger files
➢ Analyses of multiple small files combined together
➢ Researchers working programmatically with their data		 ➢ Heavy-duty data processing/analysis, including HPC, is required, but storage on SciStor needs to be kept to a minimum

Data protection in YODA

The following YODA data protection measures are in addition to the basic security measures that apply to all research situations.

“Red” Data

You may not be able to use YODA for very high-risk data. First contact the FGB REPS team for further assessment.

If YODA can be used to store your data, you must follow these basic security measures, as well as any additional measures advised on an individual basis by the FGB research data stewards and/or YODA administrator.

Encryption

Multifactor Authentication

  • All users who have access to folders containing “Red” data must have multi-factor authentication (MFA) activated. MFA is automatically active for all YODA users.
    • MFA for both internal and external users is provided via SURF’s SRAM system. This manual explains how to set up MFA for both existing users and new users.
    • Ensure that any external users (anyone without a VU account) use their institutional/professional e-mail address to sign in to YODA; it is not allowed to use personal e-mail addresses for this purpose.

Handling of Downloaded Data

  • If you opt to upload and download data in YODA, e.g via Cyberduck or other methods, remember that these files will be copied locally to your device. When working with “Red” data this means:
    • It is imperative that you have full-disk encryption activated on your computer
    • Manage where the files are copied to on your computer, so that you can keep track of them. If using Cyberduck, define to which directory (folder location) the downloaded files should be copied to. This allows for:
      • Better management of local files
      • Prevents accidental overwriting of these files
      • Simplifies deletion of files when they are no longer needed on your computer. Delete these files as soon as you no longer need them.
    • Ensure that read-only users are aware of these rules. Even though they are not able to modify any data in YODA, they can still download data. Ensure that all read-only users will properly manage data that they have stored locally and that they remove the data from their computer as soon as it is no longer required.
    • When working with “Red” data, all users must use a work computer for local data storage. Do not use your personal device. If you have absolutely no other option that to use your personal computer, you must:
      • Ensure you are following all of the basic security measures required by the faculty
      • Obtain a hardware-encrypted external hard drive and protect it with a strong password. All locally copies data must be copied to this hardware-encrypted external hard drive, not your personal computer’s hard drive. Once the data on this hard drive is no longer needed, the data must be permanently removed from the external hard drive or the external hard drive must be destroyed.
        • NB: This hard drive must be dedicated to this single research project and must be kept safe and secure at all times. This external hard drive should not be used for any other purpose and it should only be physically transported from one location to another when it is absolutely necessary. Using an encrypted external hard drive partitions the “Red” data from all other data on your personal computer making it easier to delete later. It is not intended for day-to-day physical transport of the data.
        • If this option is not feasible, contact the FGB REPS for further guidance.

Students & YODA

  • It is generally not recommended to allow students access to “Red” data. If this is absolutely necessary, then in addition to the measures described here, students must follow all of the requirements on this page, particularly the requirements for the storage of “Red” data.

Secure Archiving & Publishing

  • When archiving and publishing “Red” data in YODA, the data access option must never be “Open - Freely retrievable”. When filling in the metadata form, under “Data Package Access” choose “restricted access” if you plan to provide access upon a valid request to reuse the data. Choose “closed access” if the data should never be accessed except for verification purposes.
    • You are required to plan for ongoing access requests. This means you must determine and document in your data management plan:
      • Who will grant access to the data on the long-term?
      • What is a valid request? Who can make valid requests?
      • Are the data allowed to be reused for new purposes? (This depends on whether consent was obtained for this purpose. Discuss this further with the FGB Privacy Champion before sharing any data for new purposes.)
      • What legal considerations are necessary to share the data, e.g. data sharing agreements?
        • For assistance with data sharing agreements, contact
  • When filling in the metadata form, select “Custom license” in the “License” field
    • See below for more information on licensing data
  • When filling in the metadata form, the “Data classification” field for “Red” data should be entered as “Very High”

*NB: When archiving encrypted data, there needs to be a plan for the long-term storage of the de-encryption keys. Contact FGB REPS for further support and a plan for storing the de-encryption keys.

“Orange” Data

Key Files

  • If the “Orange” data in question are key files these should be stored in a separate YODA data compartment from the rest of your data. Access to this data compartment must be limited to only those research team members who need to be able to identify your research subjects.
    • If it is not feasible to organize and save your key files in a separate data compartment, the key files should be encrypted * and kept in a separate subfolder from the de-identified research data. Only the research team members who need access to the key files should be given the de-encryption keys.

Multifactor Authentication

  • All users who have access to folders containing “Orange” data must have multi-factor authentication (MFA) activated. MFA is automatically active for all YODA users.
    • MFA for both internal and external users is provided via SURF’s SRAM system. This manual explains how to set up MFA for both existing users and new users.
    • Ensure that any external users (anyone without a VU account) use their institutional/professional e-mail address to sign in to YODA; it is not allowed to use personal e-mail addresses for this purpose.

Handling of Downloaded Data

  • If you opt to upload and download data in YODA, e.g via Cyberduck or other methods, remember that these files will be copied locally to your device. When working with “Orange” data this means:
    • It is imperative that you have full-disk encryption activated on your computer
    • Manage where the files are copied to on your computer, so that you can keep track of them. If using Cyberduck, define to which directory (folder location) the downloaded files should be copied to. This allows for:
      • Better management of local files
      • Prevents accidental overwriting of these files
      • Simplifies deletion of files when they are no longer needed on your computer. Delete these files as soon as you no longer need them.
    • Ensure that read-only users are aware of these rules. Even though they are not able to modify any data in YODA, they can still download data. Ensure that all read-only users will properly manage data that they have stored locally and that they remove the data from their computer as soon as it is no longer required.
    • When working with “Orange” data, you must use your work computer. Do not use your personal device. If your personal device is your only option for accessing the data, you must:
      • Ensure you are following all of the basic security measures required by the faculty
      • Obtain a hardware-encrypted external hard drive and protect it with a strong password. All locally copies data must be copied to this hardware-encrypted external hard drive, not your personal computer’s hard drive. Once the data on this hard drive is no longer needed, the data must be permanently removed from the external hard drive or the external hard drive must be destroyed.
        • NB: This hard drive must be dedicated to this single research project and must be kept safe and secure at all times. This external hard drive should not be used for any other purpose and it should only be physically transported from one location to another when it is absolutely necessary. Using an encrypted external hard drive partitions the “Orange” data from all other data on your personal computer making it easier to delete later. It is not intended for day-to-day physical transport of the data.
        • If this option is not feasible, contact the FGB REPS for further guidance.

Students & YODA

Secure Archiving & Publishing

  • When archiving and publishing “Orange” data in YODA, the data access option must never be “Open - Freely retrievable”. When filling in the metadata form, under “Data Package Access” choose “restricted access” if you plan to provide access upon a valid request to reuse the data. Choose “closed access” if the data should never be accessed except for verification purposes.
    • You are required to plan for ongoing access requests. This means you must determine and document in your data management plan:
      • Who will grant access to the data on the long-term?
      • What is a valid request? Who can make valid requests?
      • Are the data allowed to be reused for new purposes? (This depends on whether consent was obtained for this purpose. Discuss this further with the FGB Privacy Champion before sharing any data for new purposes.)
      • What legal considerations are necessary to share the data, e.g. data sharing agreements?
        • For assistance with data sharing agreements, contact
  • When filling in the metadata form, select “Custom license” in the “License” field
    • See below for more information on licensing data
  • When filling in the metadata form, the “Data classification” field for “Orange” data should be filled in as “High”

*NB: When archiving encrypted data, there needs to be a plan for the long-term storage of the de-encryption keys. Contact FGB REPS for further support and a plan for storing the de-encryption keys.

“Yellow” Data

Multifactor Authentication

  • All users who have access to data compartments containing “Yellow” data must have multi-factor authentication (MFA) activated. MFA is automatically active for all YODA users.
    • MFA for both internal and external users is provided via SURF’s SRAM system. This manual explains how to set up MFA for both existing users and new users.
    • Ensure that any external users (anyone without a VU account) use their institutional/professional e-mail address to sign in to YODA; it is not allowed to use personal e-mail addresses for this purpose.

Handling of Downloaded Data

  • If you opt to upload and download data in YODA, e.g via Cyberduck or other methods, remember that these files will be copied locally to your device. When working with “Yellow” data this means:
    • It is imperative that you have full-disk encryption activated on your computer
    • Manage where the files are copied to on your computer, so that you can keep track of them. If using Cyberduck, define to which directory (folder location) the downloaded files should be copied to. This allows for:
      • Better management of local files
      • Prevents accidental overwriting of these files
      • Simplifies deletion of files when they are no longer needed on your computer. Delete these files as soon as you no longer need them.
    • Ensure that read-only users are aware of these rules. Even though they are not able to modify any data in YODA, they can still download data. Ensure that all read-only users will properly manage data that they have stored locally and that they remove the data from their computer as soon as it is no longer required.

Students & YODA

Secure Archiving & Publishing

  • When archiving and publishing “Yellow” data in YODA, the data access option must never be “Open - Freely retrievable”. When filling in the metadata form, under “Data Package Access” choose “restricted access” if you plan to provide access upon a valid request to reuse the data. Choose “closed access” if the data should never be accessed except for verification purposes.
    • You are required to plan for ongoing access requests. This means you must determine and document in your data management plan:
      • Who will grant access to the data on the long-term?
      • What is a valid request? Who can make valid requests?
      • Are the data allowed to be reused for new purposes? (This depends on whether consent was obtained for this purpose. Discuss this further with the FGB Privacy Champion before sharing any data for new purposes.)
      • What legal considerations are necessary to share the data, e.g. data sharing agreements?
        • For assistance with data sharing agreements, contact
  • When filling in the metadata form, select “Custom license” in the “License” field
    • See below for more information on licensing data
  • When filling in the metadata form, the “Data classification” for “Yellow” data should be filled in as “Medium”
“Green” Data

The following information applies to lower risk personal data. If your data are not personal data, and they have a low confidentiality risk, they can be handled as “Blue” data in YODA (see next tab). * NB: It is the researcher’s responsibility to determine whether or not the data are personal data. If you are uncertain, contact the FGB Privacy Champion before making the data open.

Green data may be lower risk, but it is still wise to prevent unauthorized access to the data, since that could cause corruption or loss of the data. The following guidance will help with this.

Multifactor Authentication

  • MFA is automatically active for all YODA users.
    • MFA for both internal and external users is provided via SURF’s SRAM system. This manual explains how to set up MFA for both existing users and new users.
    • Ensure that any external users (anyone without a VU account) use their institutional/professional e-mail address to sign in to YODA; it is not allowed to use personal e-mail addresses for this purpose.

Handling of Downloaded Data

  • If you opt to upload and download data in YODA, e.g via Cyberduck or other methods, remember that these files will be copied locally to your device. When working with “Green” data this means:
    • Manage where the files are copied to on your computer, so that you can keep track of them. If using Cyberduck, define to which directory (folder location) the downloaded files should be copied to. This allows for:
      • Better management of local files
      • Prevents accidental overwriting of these files
      • Simplifies deletion of files when they are no longer needed on your computer. Delete these files as soon as you no longer need them.
    • Ensure that read-only users are aware of these rules. Even though they are not able to modify any data in YODA, they can still download data. Ensure that all read-only users will properly manage data that they have stored locally and that they remove the data from their computer as soon as it is no longer required.

Students & YODA

  • Students who have access to the data must follow all of the requirements on this page, particularly the requirements for storage of “green & blue” data.

Secure Archiving & Publishing

  • When archiving and publishing “Green” data in YODA, the data access option cannot be open by default because the data are still technically personal data under the GDPR. However, if you obtained valid consent from your participants to the public sharing of their data, then open data access may be possible. In that case, you can choose the “Open - Freely retrievable” option under “Data Package Access” in the metadata form.
    • NB: You must discuss this with the FGB Privacy Champion prior to obtaining consent from your participants and prior to openly publishing the data.
  • If the “Green” data cannot be openly published, then when filling in the metadata form, under “Data Package Access” choose “restricted access” if you plan to provide access upon a valid request to reuse the data. Choose “closed access” if the data should never be accessed except for verification purposes.
    • You are required to plan for ongoing access requests. This means you must determine and document in your data management plan:
      • Who will grant access to the data on the long-term?
      • What is a valid request? Who can make valid requests?
      • Are the data allowed to be reused for new purposes? (This depends on whether consent was obtained for this purpose. Discuss this further with the FGB Privacy Champion before sharing any data for new purposes.)
      • What legal considerations are necessary to share the data, e.g. data sharing agreements?
        • For assistance with data sharing agreements, contact
  • When filling in the metadata form, the “License” field should filled in with “Custom license” if the data are archived as “restricted access” or “closed”. If the data are archived as “open - freely retrievable”, select an appropriate license from the available options.
    • See below for more information on licensing data
  • When filling in the metadata form, the “Data classification” for “Green” data should be:
    • “Medium” if the data must be archived as “restricted access” or “closed” (see previous point)
    • “Low” if the data can be archived as “open - freely retrievable” (see previous point)
“Blue” Data

Even if your data are anonymous/anonymized or non-personal data with a low confidentiality risk, there are measures you should apply to keep the data safe. Even though the data are fairly low-risk with regards to privacy and confidentiality, they still have value to you and you don’t want them to be publicly disclosed before you are ready to share them. You should also prevent unauthorized access to the data, since that could cause corruption or loss of the data.

Multifactor Authentication

  • MFA is automatically active for all YODA users.
    • MFA for both internal and external users is provided via SURF’s SRAM system. This manual explains how to set up MFA for both existing users and new users.
    • Ensure that any external users (anyone without a VU account) use their institutional/professional e-mail address to sign in to YODA; it is not allowed to use personal e-mail addresses for this purpose.

Handling of Downloaded Data

  • If you opt to upload and download data in YODA, e.g via Cyberduck or other methods, remember that these files will be copied locally to your device. When working with “Blue” data this means:
    • Manage where the files are copied to on your computer, so that you can keep track of them. If using Cyberduck, define to which directory (folder location) the downloaded files should be copied to. This allows for:
      • Better management of local files
      • Prevents accidental overwriting of these files

Students & YODA

  • Students who have access to the data must follow all of the requirements on this page, particularly the requirements for storage of “green & blue” data.

Secure Archiving & Publishing

  • When archiving and publishing “Blue” data in YODA, the default is to make the data open. When filling in the metadata form, under “Data Package Access” in the metadata form, choose the “Open - Freely retrievable” option.
    • If the data are about human research subjects, it is the researcher’s responsibility to determine whether or not the data are truly anonymous/anonymized. If you are uncertain, contact the FGB Privacy Champion before making the data openly accessible.
  • When filling in the metadata form, select an appropriate license from the available options in the “License” field
    • See below for more information on licensing data
  • When filling in the metadata form, the “Data classification” for “Blue” data should be filled in as “Low”

Metadata & documentation in YODA

The metadata form in YODA must be completed to archive data in the YODA “vault”, but you can start adding metadata at any time during your research. Use the following tips to meet the FGB requirements for your metadata & documentation.

  • Follow this FGB guidance on data packages that covers both the general and data-specific requirements for metadata and documentation. Pay attention to these requirements during your active research to avoid extra work when it’s time to archive your data.
  • The mandatory fields in the YODA metadata form don’t account for all of the information required by the FGB archiving guidelines. Review the guidelines and ensure all fields required by FGB have also been filled in.
  • The YODA metadata form can be also be filled in at a subfolder level. This can be useful if:
    • You have a folder structure set up for some data and materials to be open and some to be restricted or closed.
    • There is additional information to add about the contents of a subfolder, e.g. a more specific time frame of data collection, a specific sub-study of the larger study etc.

      You can save time by entering metadata that is consistent across all folders at the level of the “parent” folder (the folder that contains all of the subfolders) and then “cloning” this information into the various subfolders. NB: You do not need to fill in all of the required metadata fields at this point, since that information may vary for each of your subfolders. Required fields only need to be completed when you are ready to submit a folder to the vault.

  • Ensure that the metadata fields for “Data package access”, “License”, and “Data classification” are in line with the secure archiving & publishing requirements for the risk level posed by the data within a given (sub)folder.
    • Ensure this information is accurate at the level of the (sub)folders, e.g. when one subfolder will be “restricted access” and one will be “open”.
  • Save your README and custom license (if applicable) at the highest level folder that you will submit for archiving in the “vault”.
    • If the folder you are archiving is “restricted access”/“closed”, the README and custom license won’t be openly available for others to review. You should either:
      • Publish a copy of the README and custom license on DataverseNL.
      • Save a copy of the README and custom license in your “open” subfolder, if you organized your folder structure in such a manner.

YODA after research

Archiving in YODA

When it’s time to archive your data, you can double check that you’ve met all the requirements in this YODA archiving checklist. Most of these requirements have already been addressed in earlier sections on folder structure and metadata, so this document simply serves as a final check.

  • You can submit data and related materials to the YODA “vault” at the level of any (sub)folder, however the access level you entered for “Data package access” will only be considered at the level of the folder submitted to the vault. In other words, if you submit one overarching folder to the vault with subfolders that have different levels of access, only the access level of the overarching folder will apply to all of the subfolders. This means data that is meant to be “restricted access” could be “open” and vice versa if you are not careful.
    • Instead submit your data package to the YODA “vault” at the folder level where the access levels diverge, e.g. one submission for the “open” data package and one for the “restricted access” data package. Make sure to crossreference these submissions to each other as needed.
  • When you submit your data package, an FGB YODA data manager will review the metadata, documentation and organization of your files to ensure that everything sufficient and complete. NB: The data manager is not responsible for checking whether you have chosen the correct setting for the “data classification” and “data package access” fields. It is up to you to have determined this prior to submitting your data to the vault. You can get support ahead of time from the FGB privacy officer.
  • After data are accepted to the vault, they can no longer be changed. The metadata however can still be modified if necessary.

Publishing in YODA

  • After your data package is archived in the YODA “vault”, it can also be published.
    • Your data package must be published if the data have been used for a research article.
    • The access levels you selected continue to apply even after publishing!: restricted access and closed data are not made publicly available upon publishing, only the metadata you entered in the YODA metadata form.
  • Metadata can be updated after publishing if changes are necessary, such as linking related data packages.
  • If you publish in YODA, the metadata from that publication can be imported into PURE.
    • PURE registration of datasets is a requirement whenever data are archived & published.

Who can I speak with for assistance?

At FGB, start by contacting the faculty data stewards. If they are unable to assist you, you will be forwarded to the YODA administrators.

Reference materials

  • VU YODA manual: provides technical guidance on the processes described above, such as how to carry out the group manager function or how to set up a connection with Cyberduck.

  • SURF YODA manual: provides further technical advice that supplements the VU YODA manual.