Dorien Huijser https://www.dorienhuijser.com/blog.html Dorien Huijser's website quarto-1.7.31 Thu, 31 Oct 2024 23:00:00 GMT Work-related updates on the sol blog Dorien Huijser https://www.dorienhuijser.com/blog/2024-11-01-working-out-loud.html A while ago, our colleague Dan Rudmann had the nice suggestion to make the work and activities ongoing in our department (Research Data Support @ Utrecht University Library) more visible. He called this “working out loud” and created a new website for our department, where we can all put our work-related updates.

I recently wrote 2 posts for that website, they can be found here:

  • A summary of a meet-up we had with data and software support staff from TU Delft.
  • A bit of background about the creation of a guide for research with human-related big data at the Faculty of Humanities that I was involved in creating.

I am sure many more posts will follow, both from me as well as from my colleagues. If you want to learn more about our activities, keep an eye out on the department blog!

]]> https://www.dorienhuijser.com/blog/2024-11-01-working-out-loud.html Thu, 31 Oct 2024 23:00:00 GMT Dorien Huijser https://www.dorienhuijser.com/blog/2024-11-XX-data-roles.html https://www.dorienhuijser.com/blog/2024-11-XX-data-roles.html Thu, 31 Oct 2024 23:00:00 GMT The privacy monster Dorien Huijser https://www.dorienhuijser.com/blog/2023-01-21-the-privacy-monster.html

“I’m sending out a questionnaire to study personality development, do I have to deal with privacy?”
“I’m measuring CO2 in people’s houses, that’s not personal data right?”
“I want to use medical imaging data to improve the quality of those scans, am I allowed to do that?”

These and many more questions like this enter our inbox regularly. Alarm bells go off. Researchers realize: oh dear, now I have to deal with the GDPR 1. I’ve seen this kind of response often, both in researchers as well as data support staff. As soon as personal data is on the table, more time is needed to plan a research project, more people need to be consulted, and more administrative work is usually involved. For researchers, taking into account privacy means that they need to spend valuable time and resources to make sure they are GDPR-compliant, and are limited in what they can and cannot do with the collected data. They experience the GDPR as a limitation, a monster to defeat before they can even start playing the game of research, let alone that of open science. Why, and what can we do about it?

The monster and scientific research

If you ask any privacy professional, they would tell you that the GDPR is actually very lenient in some respects when it comes to scientific research2. Some examples:

  • Purpose limitation:
    further processing of personal data for research purposes is always compatible with the initial purpose of data collection, provided sufficient safeguards are in place (art. 5(1)(b)).
  • Storage limitation:
    personal data need to be removed if they are not needed anymore, except if they need to be stored for scientific research purposes and sufficient safeguards are in place (art.5(1)(e)).
  • Special categories of personal data:
    you can only use sensitive personal data3 in a few scenarios (art. 9(2)(j)). One of those is scientific research (provided safeguards are in place), another is explicit consent.
  • Right to erasure:
    if a participants asks you to remove their data, you do not need to do that if it would “seriously impair” the achievement of the research purpose (art. 17(3)(d)).

So in reality, when one uses personal data for research, the GDPR is much more lenient than for, say, commercial companies. The GDPR is not so much as monster to defeat, as it is a creature to tame and keep happy. Yet, researchers I have generally been in touch with do see privacy as a time- and resource-intensive monster, to be fought with each time they want to use personal data. Why?

Taming the monster

In Dutch we say “zoveel mensen, zoveel wensen” (many people, many desires), and so there is most likely no one reason that all researchers who feel limited by the GDPR do so. But I can take a guess based on the survey and subsequent one-on-one conversations we held recently. The survey for example showed that:

  • Having personal data in a project means having to fill out many more administrative forms before one can start collecting data. For example, besides a data management plan, there is the ethics assessment, a privacy scan (sometimes called “privacy review”, “DPIA-light”, or “pre-DPIA”), and officially also an obligation to register the project in a processing registry.
  • Roles, responsibilities and requirements are not always clear: who can help with figuring out how to set up a privacy-compliant project? Whose responsibility is it to be GDPR-compliant? What steps do researchers need to take before they can start collecting data?
  • A distance between researchers, who just want to hear how they have to do things, and legal staff, who point out what researchers cannot do according to the law.
  • Existing information is too abstract to use in research practice. Moreover, it is sometimes unclear which tools and techniques are available that would make things easier, or their learning curve is too steep for researchers to tackle on their own.

The GDPR “monster” is relatively new, and so are the strategies we have to tame it. The fact that support may not always be findable or helpful may simply be because up until recently, there was none. Moreover, while ethical committees have been in place for years, privacy offices haven’t, and so many researchers find help from a privacy professional only when the ethics committee tells them to. This can lead to some nasty situations, where in some cases entire projects that were ready to start data collection got blocked, because their plans were not GDPR-compliant.

How can we make it easier?

The way I see it, privacy professionals can take the approach of ethics committees as an example: give researchers a recipe and all the ingredients to keep the monster happy:

  • Provide clear instructions on what steps to take when.
  • Provide ready to (re)use solutions, i.e., documents, workflows and technical solutions without a steep learning curve.
  • Provide smooth and low-threshold in-person support.

Some of these ingredients may already be there - or in development4 - and some may be combined with other recipes such as that of ethics applications and data management plans. But only all of them combined leads to a happy monster, or rather, a small pet that simply needed feeding5. Who knows, maybe handling personal data may end up as routine business for researchers, much like feeding your cat every day.

Footnotes

  1. The General Data Protection Regulation.↩︎

  2. See also this resource outlining the GDPR and its position towards research.↩︎

  3. Data on mental or physical health, racial or ethnic origin, political opinions, religion, trade union membership, genetic or biometric data, sex life or sexual orientation.↩︎

  4. Some shameless self-promotion: we are currently working on an open source resource about privacy in research that includes as concrete information and tools as possible: the Data Privacy Handbook.↩︎

  5. +1 if you’re also thinking about a chocolate bar ad saying “You are not yourself when you’re hungry” 😉↩︎

]]> https://www.dorienhuijser.com/blog/2023-01-21-the-privacy-monster.html Fri, 20 Jan 2023 23:00:00 GMT Why research data management is critical for open science Dorien Huijser https://www.dorienhuijser.com/blog/2021-03-08-rdm-for-open-science.html Source: https://twitter.com/hlrdmp/status/1357368172568076288

One of the goals of open science is to make science more transparent. There are many ways to do so, but one of the most prominent ones is to share research data, allowing others to check scientific results or to perform new research. But when are data – and accompanying materials – useful?

FAIR enough?

At the moment, there are many degrees of practicing open science. Whereas some researchers simply share nothing, others throw their data somewhere on the internet and yet another small portion uses hardcore curation. The latter is the ultimate goal: data and code should be Findable, Accessible, Interoperable and Reusable (FAIR). Despite this relatively simple sounding acronym, actually meeting the requirements of FAIR in practice turns out to be quite difficult.

No one should expect researchers to be able to do everything in the context of scientific research. This is where research supporters come in. Data stewards know a lot about research data management, because that is what they do! For example, they know how to deal with privacy sensitive data and how to anonymize them. They know how you can make sure to never lose previous versions of your files ever again. Perhaps most important for open science however: they know what is needed to make data FAIR. Although this all seems like boring stuff – which it sometimes is – it is crucial on the long term.

The crucial cat concept

Take metadata. If you share only your data, no one will be able to use them. Why? Because just the data alone do not tell you anything about the kind of data, the participants, what was measured and how. Others, including your future self, may not have a clue what the variable “var1” means in column X of your dataset. Metadata is here to provide this context. If we think of data as a picture of a cat, metadata is the date the picture was taken, the location, which camera made the picture and the file size, among others. You can take this very far at different levels, but I will not bore you with that. My point is that this requires consideration, because metadata are a prerequisite for the reuse of your data.

Forever accessible

Another example concerns persistent identifiers. You may think: why can’t I just send my data to whomever interested? Or: Why can’t I just put my data on my personal website? However, this can lead to problems. Even though (no doubt!) your intentions are good, what if you leave your job and cannot access your 2008 data anymore? Or if you decide to use a different domain name for your website? In the latter case, all of the links to the data you put in your scientific article or that were sent to colleagues become invalid. Persistent identifiers are here to save the day, and research supporters play a crucial role in pointing researchers at these issues (you’re welcome).

By now, I hope that you agree with me that research data management is an important prerequisite for pushing open science forward. A solid basis of research data management will not only make science transparent, but also sustainable and reproducible in the long run. Luckily, more and more institutions see this and hire data stewards to help researchers achieve this. The science show must go on, but that is not possible without research data management as the secret star of the show.

Images

This blog was originally posted on the Erasmus SYNC lab website

]]> https://www.dorienhuijser.com/blog/2021-03-08-rdm-for-open-science.html Sun, 07 Mar 2021 23:00:00 GMT Creating my own website Dorien Huijser https://www.dorienhuijser.com/blog/2021-02-10-First-post.html Welcome to my personal website! As this is my first blogpost, I’ll try to explain why and how I created this website.

How it started: “Cool, my own website!”

At the start of 2020, I came across a tutorial by Dan Quintana to create a personal website via GitHub. As I had just started learning how to use git and GitHub at OpenMR Benelux 2020, I thought: let’s save this resource for later.

Of course, in practice this meant simply leaving the tab open on my phone for ages.

Some ages and 20 tabs later, I figured my phone battery would be much better off if I closed some tabs. The tutorial now moved from my phone to my never-ending to do list, where it risked complete neglect and finally, removal. However, in the summer, I joined a few projects where I got into GitHub again:

  1. I volunteered for website maintenance at the OHBM Hackathon 2020, which took a lot more time than I thought, but did result in major GitHub activity:
  2. I joined the organizing committee of OpenMR Benelux 2021, where we also started updating the website for the new 2021 edition
  3. Together with my colleague Eduard, we started a wiki for our lab (the SYNC lab) with all kinds of useful information surrounding our research. This also meant figuring out how to deploy text files onto a website

By the way, I am far from technically skilled. But I will always be a Dutch person, and therefore I will always take an opportunity to do something without spending money on it. So in these collaborations, I slowly and steadily learned a few different ways to host a website for free! My confidence grew that it may actually be something I could do. It couldn’t be that hard, right?

I was wrong.

Actually building a website

As a total html-noob, I got to work. Translation: I got to googling. Where did I put all those handy links again?

When I finally found them, it seemed rather simple. I was lucky to already have all necessary software installed - I use Windows 10, which actually is a nightmare with all cool software project thingies. All I needed to do was choose a theme and fill the website with personal content, it seemed.

Ok, so that disappointed a little. I broke my navigation, removed critical html files and failed to include even simple hyperlinks in my text. Google truly became my best friend for literally everything. A small selection of search terms: “hyperlink html”, “yml file error”, “change background color html”, “center text”, etc.

Finally…

Because I used my free time to make this website, I did not track how much time I spent on it. I can assure you, it is more like a couple of months than a couple of days. In Dutch, we say it is a process “van de lange adem” (“of the long breath”), basically meaning it is a long-term process.

So here it is! I’m still not entirely content with it, but: there is some basic functionality and some content. Google will remain my BFF though. I guess my main takeaway of this is that if a tutorial marks something as “easy”, I will probably still need a couple of days to get it. Oh wel, live and learn (a lot).

Want to do this too?

If you only came here for yourself - who didn’t? - I also wrote a short introductory tutorial that shows how I got things to work. Hopefully, that will save you some precious time.

]]> https://www.dorienhuijser.com/blog/2021-02-10-First-post.html Tue, 09 Feb 2021 23:00:00 GMT How to for dummies: creating a static website with Jekyll and GitHub Pages Dorien Huijser https://www.dorienhuijser.com/blog/2021-02-10-How-to-build-a-Jekyll-website.html Prerequisites:

  • A bit of knowledge on git
  • A bit of knowledge on Markdown (HTML is useful but not necessary)
  • Time

There are different ways to create a static website with Jekyll, probably a lot that I don’t know about! Here are the steps I followed myself, a bit more fine-grained than on the Jekyll website itself. I hope they’re useful! If not, then I’ve made some documentation for my future self 😊

Step 1: Install Ruby, RubyGems and Jekyll

Note: if you are using Windows (like me ☹), consider downloading the Ubuntu app from the Windows store (i.e., using the Linux Subsystem for Windows). Then follow the steps from this instruction video.

Use a command prompt or the Ubuntu app for the commands listed.

We need to install:

  1. Ruby, a programming language that can run Jekyll

    1. Check your version: ruby -v (preferably version 2.1 or higher)
    2. Download it for Windows here (Mac already has it installed)

  2. RubyGems: a package manager for Ruby that can install, update and maintain Ruby programs. We later use it to install Jekyll

    1. Check your version: gem -v

  3. Jekyll through using RubyGems: gem install Jekyll bundler

    1. Check your version: jekyll -v

Step 2: Create a Jekyll site in a git repository

If you haven’t already, install git and make a GitHub account

Now, you can go two ways: either A) create a Jekyll website from scratch, without any prespecified formatting or B) copy a repository using a specific theme and personalize it.

A) Create a Jekyll website from scratch

  1. Move to the local folder where you want to store your local site files: cd /my/folder/

    1. Note: if using Ubuntu on Windows, it took me some time to figure out how to move through folders. My C drive was for example reachable through cd /mnt/c/Users/dorie/
    2. Note 2: Use the TAB key to autofill commands!

  2. Create a new Jekyll site: jekyll new [nameofsite]

    1. Note: aptly name the project!
    2. If you want to use GitHub Pages to host your website, the easiest way is to create a project named githubusername.github.io

  3. Version control the Jekyll folder by typing: git init. The folder is now a git repository: all contents are now tracked by git (except what is listed in the .gitignore file)

  4. You can now either create completely new layouts, or install a Jekyll theme. They are available via multiple websites, read all about themes here. For example, for the theme minimal mistakes, see the installation steps here and a preview here

  5. Edit your files, see Step 3

  6. add (stage) and commit your changes (basic instructions here)

  7. Finally, push your changes to GitHub (instructions)

B) Copy a repository of an existing theme to your GitHub account

  1. Choose a theme for your Jekyll website. They are available via multiple websites, read all about themes here.

  2. Once you have chosen a theme, fork (i.e., copy) the repository belonging to that theme to your personal GitHub account.

  3. In the repository settings, change the repository name to githubusername.github.io

  4. Now in order to work on your website on your local PC, clone the repository to your PC

    1. Move to the folder location where you want to clone your repository to: cd /my/folder

      1. Note: if you use Ubuntu on Windows, it took me some time to figure out how to move through folders. My C drive was for example reachable through cd /mnt/c/Users/dorie/
      2. Note 2: Use the TAB key to autofill commands!

    2. Clone the repository to that location: git clone https://github.com/username/username.github.io.git

Step 3: Customizing your website

It will probably take some time to get used to the way a Jekyll website is built, especially if you want to change more structural parts of it. In the latter case, some html knowledge would be useful, but I can assure you that Google is your best friend in this case (as it was for me)!

Standard folders in a Jekyll website can be found here. Here’s some introductory tips how to personalize your website.

General steps during customization

  1. Make sure to move into the folder of the repository: cd githubusername.github.io

  2. Make sure you are working on the correct branch: git checkout [branchname] (e.g., master)

  3. To see your changes locally, run bundle exec jekyll serve and open the URL that Jekyll provides in a browser, probably something like http://127.0.0.1:4000/

  4. If you are happy with your change, stage the change: git add [filename] or git all -A . (if you want to stage ALL changes made)

  5. Commit your staged files: git commit -m "Edit x"

  6. Push your changes to your fork (online repository): git push origin [branch name]

Editing pages and blogposts

  • Open the markdown (.md) files of the pages you want to edit - these may or may not be located in a pages folder (note that the index.md files is always the homepage.

  • If you want to create a blog post, create a new .md files in the _posts folder. Or if you don’t want to publish your post yet, in the _drafts folder.

  • Use Atom, Typora or any other markdown editor (cheat sheet) to edit the pages

  • In order for your pages and posts to display correctly, be sure to include correct front matter in each page file (more info here)

Editing the structure of the website

The structure of your website is determined largely by the following files:

  • _config.yml contains all your website’s configuration details. You may want to set your title: “your website’s title”, slogan: “your slogan here”, description: “site description here and other details

  • The _data folder may include a navigation.yml file (or something similar) that defines the navigation menu on your website. It may also contain other data files that you can personalize, depending on the theme you are using. And of course you can create new ones to be used in pages through site.data.*nameOfDatafile*

  • If you keep including the same component on several pages, you can create includes. These are files that can be included on multiple pages without having to edit that component multiple times. Includes are therefore a way to make your website more modular, flexible and efficient as they prevent creating enormous page files.

Note on .yml files: .yml files are terribly precise and give an error if you type even an extra space. Use a yaml validator (like this one to check where your .yml error is!

Editing the looks of your website

  • The _layouts folder contains html files with layouts in which content is wrapped. If you change anything in these layouts, all pages using that layout are changed accordingly

  • Layouts can also include files from the _includes folder, e.g., a sidebar.html or footer.html. Again, this increases the modularity and efficiency of your website, since all those components are specified separately

  • If you want to change colors, fonts, etc., you should go to the _sass folder. This usually contains some .scss files (a more modern version of the .css file) which specify all this.

Step 4: Publishing your website

  • If you are happy with your website, push all changes to the branch of your GitHub repository that you want to publish

  • Go to the settings of your GitHub repository

  • Scroll down to “GitHub Pages”

  • Select the branch that you want published on GitHub Pages

  • If you want, use a custom domain for your website (instead of username.github.io)

  • Wait a few minutes and tadaa! Your website is published.

Good luck and have fun! Any questions are welcome.

]]> https://www.dorienhuijser.com/blog/2021-02-10-How-to-build-a-Jekyll-website.html Tue, 09 Feb 2021 23:00:00 GMT What the hack? Bringing about a practical tool through open collaboration Dorien Huijser https://www.dorienhuijser.com/blog/2020-07-06-What-the-hack.html

So it begins: the brainstorm

In October 2019, the Open Science Community Leiden helped me organize a brainstorm session for university employees who were interested in sharing MRI data. During my work, I had already noticed that most people I spoke to didn’t have much experience with sharing MRI data. Therefore, with this brainstorm session, I hoped to hear more points of view on the matter or find out about regulations I wasn’t yet aware of. Most importantly, I hoped to reach consensus on what to do, because from where I was standing, it seemed as if there wasn’t any.

The session was well-attended, not only by researchers from the Social Sciences faculty, but also by support staff and staff from the University Medical Center. Together, we came to a few important conclusions:

  1. We weren’t the only ones with little experience sharing MRI data;
  2. Many researchers didn’t know how privacy regulations apply to MRI data;
  3. Researchers were unaware that support staff was there to help and support staff, in turn, had no idea what MRI data was and were unsure how to get in touch with researchers.

With these conclusions in mind, we decided to draft a guide about the subject. We formed a group consisting of both researchers working with MRI data as well as research support staff to tackle the issue and got started.

Appointments followed and a few months went by. Apparently, getting together with both researchers and support staff had been a good idea: we complemented each other’s knowledge and were all prepared to explain our view on the issue. During our get-togethers, we realized that there were many aspects that play a role in sharing MRI data (type of MRI scans, stage of research, location of data collection, etc.). We therefore decided to keep the first tool small, focusing on the Dutch situation, as this was by itself already a challenge.

A knack to hack

In January, Open MR Benelux 2020 took place, a small-scale event for Benelux researchers who work with neuroimaging data and are interested in open science. This was where I joined my first hackathon and I was quite nervous about it. The word “hackathon” sounds very advanced and since I do not have much programming experience, I worried it was going to be a disaster. Luckily, the opposite turned out to be true.

What are hackathons?

The word ‘hackathon’ originates from the programming world and stands for “hacking marathon”. Originally, hackathons are large meetings of smart people trying to build some kind of working software in a(n impossibly) small amount of time. Nowadays, an academic hackathon is typically a period in which academics collaborate fully on one specific project which will probably advance the field in one way or another. Admittedly, many projects do focus on developing tools, but they can also be tools that have nothing to do with programming. In fact, hackathon organizers increasingly stimulate making projects open to those with little coding experience. In recent hackathons, participants also do not only “hack”, but also have possibilities to follow training sessions and participate in “unconferences” – basically open and unplanned discussions for everyone to join. In this much more open way, hackathons are a great place to get to know new people, learn from them and have fun in the meantime.


At OpenMR Benelux, I proposed our MRI guide as a hackathon project to receive more input. Despite the fact that there weren’t many participants to help, I received valuable input from an associate professor from Erasmus MC (Stefan Klein), who provided some more technical and medical insights. The rest of my time there, I spent helping with an existing initiative (eCOBIDAS). I was pleasantly surprised to realize that I learned more from my – very patient – collaborators than I imagined was possible in 3 days. Recently, I joined a second hackathon (OHBM Brainhack), which basically repeated this experience: I learned so many new things in a short amount of time. The best part about both these experiences wasn’t only to learn new skills. It was also getting to know colleagues and initiatives outside of the Netherlands that turned out to be very relevant to my own work. In addition, these events were both so informal and accessible that my embarrassment to ask things I didn’t know quickly faded.

In the meantime, the first version of the MRI data sharing guide has been published and we have already received feedback for a next version. My conclusion from this is that community-driven efforts, such as hackathons and our sharing guide, can contribute to scientific advancement in an extremely meaningful way. For me, this meant bringing the right people together to try to figure out the complicated issue that is sharing MRI data. For others, this may mean something different. Overall, I think that community-driven initiatives can have large impact, not only because they result from collaboration, but also because they have personal benefits: you can learn about projects happening in the world, get to know new people and collaborate on projects that you would otherwise never have thought about. It would be great if our MRI data sharing guide could be followed by something more widely applicable and will be just as widely supported as many preceding hackathon projects. In the meantime, I will keep on hacking.

This blog was originally posted on the Erasmus SYNC lab website

]]> https://www.dorienhuijser.com/blog/2020-07-06-What-the-hack.html Sun, 05 Jul 2020 22:00:00 GMT