What use is data without software?

Jan Bernoth, Firas Al Laban, Ulrike Lucke

Prof. Dr. Anna-Lena Lamprecht is Chair of Software Engineering at the University of Potsdam. In this interview she talks about Research Software Engineering (RSE), how most researchers are in practice software developers, and how making software projects open access should never be an afterthought.

Quote character

“Data obviously plays a very central role in research and good research data management is important, but in reality, without software to do something with this data, what are you supposed to do with it?”
Anna-Lena Lamprecht

Anna-Lena, how is your work related to research data and research software management?

On the one hand, I am involved in teaching software engineering in general and research software engineering in particular to students in various Bachelor's and Master's courses. But also, the focus of my research is in the area of research software, or Research Software Engineering Research, as it is now called. I'm actually quite glad that this term is now established and becomes more and more known, because in the past I always struggled a bit with where I actually belonged, what my area of expertise was called. I studied Applied Computer Science in Göttingen, not “pure” computer science, which was computer science with scientific applications.

What kind of applications were those?

I did a lot of bioinformatics and a bit of medical applications. During my postdoc period, I worked a lot with geoscientists. My computer science colleagues often referred to me as the biologist, which wasn't true. The biologists always called me the computer scientist, which was perhaps truer, but also not 100 percent true. Over the last ten years, the term Research Software Engineering has emerged, which focuses on specific challenges for research software development, that are not related to industrial software development, but to the particularities of the research context. That is what I am working on, now even in teaching.

What role does data have in that area?

I once said something bold, I think it was printed in one of the university magazines: “Without software, even the best data is worthless”. Data obviously plays a very central role in research and good research data management is important, but in reality, without software to do something with this data, what are you supposed to do with it? It is slowly changing, but many researchers do not see themselves as software developers, although for many people, writing code and managing software projects takes perhaps the majority of their working time. Yet this is not part of their self-image. I guess it varies a little depending on the task, project and discipline, whether you are doing more data management or writing more software, but on the whole, the two things are very closely related.

Anna-Lena Lamprecht

is a computer scientist specializing in (research) software engineering and scientific workflows. She is dedicated to improving research practices through the development of methods and tools that enhance the quality and efficiency of the research process, especially in the context of open science.

Why then do we have to look at software separately?

If you were to put it very simply, you could say that data is relatively static, it has been collected and measured at some point, and then it needs to be properly archived. This presents certain challenges. Software is more dynamic, you execute it. There are dependencies on other software packages that have to be developed and managed. Software has to be maintained so that it remains functional. These are challenges that you don't have so much with data. You have to change data formats every few years so that they can still be opened later. But the challenges are nowhere near as extreme as with software. That's why there is a distinction between the FAIR Data Principles and the FAIR Software Principles.

Can you tell us about a project in which research software management worked well?

One of those you can find on GitHub is called the Automated Pipeline Explorer, or APE. It can be used to automatically assemble data-analysis workflows from collections of computational tools. That's the rough idea. The workflow is defined as a pipeline of existing command line tools. The question is, how do you put them together if you want to solve a specific problem? APE gets a semantic description of all of these building blocks as input and then you can say something like, I have this type of input, I want this type of output. What options do I have? APE then suggests solutions for pipelines.

How did you make it reusable?

The aim of APE was to write a tool, a library, that can be used and integrated in other software environments. People often say that if you want to make something open source, it's best to have it out there from day one. And that's what we did with this project. Out there, it was able to grow organically. We disciplined ourselves to document the most important things and to have presentable releases. We designed it so that it could be integrated into other contexts. Additionally, of course we actively supported the project and promoted its reuse. We followed the Five Recommendations for FAIR Software, which the Dutch E-Science Center published a few years ago: Our code is available in a public repository (GitHub) and we gave a license. We included how you should reference the software and registered it with the eScience Center’s Research Software Directory so it can be found more easily. Finally, we used software quality checklist, concretely the one from the Journal of Open-Source Software (JOSS). We put a lot of energy into it, making tutorials, little films, and writing documentation to keep it somewhat up to date.
 

Did that work out? 

Even though it is a very specific application, it has been reused, even without our help. Recently there was a study published very similar to the one we did in another bioinformatics area. They just took our paper, the APE tool, the documentation and then made an analogous study and published it. We're also using it ourselves in follow-up projects, which is very nice.

After you put a lot of time into setting it up, did it influence your further research?

It sounds so banal, but checklists really help people to structure things. There's also a “How FAIR is” tool that you can use to generate a FAIRness badge for your repository and then integrate it. Then you can show that you have, for example, four out of five stars for FAIR. That helps a lot to motivate people. Unfortunately, there is a lot of research software that we don't even see because it isn't on GitHub. It is, well, not in some drawer anymore, but maybe on people's laptops, although it could be published openly if people would put a bit of work into it.

How would you publish such data? 

The Journal of Open-Source Software (JOSS) is a new kind of journal where you don't write a paper about the software, you submit the software itself. Really, you just write a little abstract and then software is reviewed. You don't have to add the software to a paper as an appendix, or somehow sneak it in, but it's the software itself that gets published and can be cited separately. This way, people can actually get direct academic recognition for their software work. People usually appreciate the idea of sharing research outputs, also in the context of open science, but in everyday research, people need a concrete incentive as to why they should do it. Something like JOSS can be quite effective.

You have now mentioned a publication organ. What else is needed to cover the complete cycle of making research data software reusable?

One is the topic of metadata. As an example from bioinformatics, there is bio.tools. This is a large directory service of bioinformatics tools of all kinds, command line tools, web services and so on. There is a link to the respective repositories and the licenses and basic data, but above all, there is an very rich metadata schema where you can provide more information about the tools. For example, you can also provide information about their functions, which uses of controlled vocabularies, so that you don't just write any free text tags. In the spirit of FAIR, this machine-readable metadata can automatically find compatible tools because a machine can understand which data types are going in and out. But the solutions are not yet well aligned. With publications you have a somewhat standardized goal, but with metadata, there are many approaches.

And besides metadata? 

Software also has the challenge of having to keep it alive somehow. Maintenance is a huge problem. Which software do you maintain and update, who does that, and over what periods? Documentation also has to be updated accordingly.

If you were to study again now, what would you pay more attention to in order to be better prepared for the challenges you face today?

What I would tell people from the time doing my PhD is that you shouldn't underestimate how much it does for visibility if you do things like open-source software and publishing open access. When I started in academia, it wasn't that common to publish open access. A few years later, looking back, I noticed that the things we published open access, the projects we made open source, were not only more visible but also more reused. I often see that younger doctoral students have a bit of reservation, especially when it comes to open source. But it's a chance for someone to contribute and help make the project even better. Reuse can help people and there's no need to be afraid of that.

You have already voted for this poll.

Opinion

How important is it to make research software open source from day one?

1: Not important 5: Essentially important

About the project

The “Automated Pipeline Explorer” is a tool that helps researchers set up complex analysis pipelines by automatically connecting different software tools. APE suggests how to link these tools based on what the researcher wants to achieve. It’s available for free and is designed to be easy to reuse and adapt for various research projects.