What are you working on?
We develop tools, specifically for linked data. Linked data is a set of open standards and principles, and we want to make linked open data more accessible for people who never worked with it before. We are overcoming the grey area between the development of such linked data projects, the research that I do, and how, for example, a humanities scholar can use them. For me, the patterns transcending an object is the data I work with, for a historian the object itself is the data. While the data in knowledge graphs stays the same, the questions I, for example, ask, are completely different to the questions a historian would ask. It is interesting to see these different methods come together in a network of data that are all intended slightly different, and how we can discover new patterns by combining our approaches to data.
Servers and services
What we used to do is set up a server ourselves and then share the data on that server. That was complicated. We were the ones managing it all, the data was on our server, and it was where the services ran. Now, for the first time, it is all set up within the VU IT infrastructure. That seems to work very well, albeit a bit cumbersome sometimes. It was something that I was missing; a server where we could simply set up a triple store database ourselves, and make it accessible for other people.
I understand that it is difficult, because the infrastructure we need is not standard. And what is not standard, cannot always be supported. As a department we would need more technology support staff, that can support us with our specific problems. Nonetheless, there are a lot of services that we can use, such as SURFdrive and dataverse. I never used to use them, but now that we are, I am pleasantly surprised; they seem to do what we want them to do. To be fair, we don't use data services that much, because in the end, we are not the ones interested in storing the data.
Archiving futures
Our role in linked data projects typically only lasts as long as the project does. In principle, it states in our DMPs that we are not going to host anything at the VU after the project ends. Everything is open and clearly described for others to continue hosting data. During the project we do research and build the tools. But after the project ends, it typically is all gone.
We set it up, as it is our research environment. But when a project ends, or the PhD student is gone, and we have forgotten how the program works, that program no longer exists. In the research environment that's normal. Is a feature of, not a bug. We write the papers, and that's our research outcome. Over time, the experimental environments slowly disappear. That is how it works, that's the transience of things.
Our heritage partners are good at preserving and maintaining things. But a computer science department at a university is a bad environment to keep things going. It is not our job to keep things afloat, we don't keep things up in the air, we don't store it. There is a role the UB could possibly play for services that we do want to keep up and running from the VU, to persistent keeping things afloat. Suppose we have a demo, the university library can then ensure that it still runs independently of the test server, which will no longer be running in 2 years' time. So, for example, being able to put a docker container somewhere, that might be nice. The university library could create a kind of archive of applications.
