This is a third (and last) in a series of short (ok, the first and second were actually short, even if this one isn’t) blogs related to talks and discussions at the 10th RDA Plenary. Software Heritage Software Heritage (as described in a recent white paper) is a really interesting and very ambitious project that started (or at least was announced) last summer.

This is the second of a set of short blogs based on thoughts at the RDA Plenary 10.  (The first was on agency and dynamicity as key properties of software.) In the Persistent ID (PID) interest group session at the RDA meeting, there was a talk by Patricia Cruse  about an organization ID project, which aims to create a new set of PIDs for organizations, followed by some discussion.

Having just returned from a short trip to the RDA Plenary 10, I’ve been thinking about a few things that will be the subject of a couple of hopefully short blogs in the near future.  This first one is about software identification, specifically as related to citation.

The FAIR data principles, defined as “a set of guiding principles to make data F indable, A ccessible, I nteroperable, and R e-usable,“ came out of a meeting in Jan 2014 that “brought together 25 high level participants representing leading research infrastructures and policy institutes, publishers, semantic web specialists, innovators, computer scientists and experimental

This post is a cross-post from the UK Software Sustainability Institute blog on 14 June 2017). By Daniel S. Katz, Assistant Director for Scientific Software and Applications at the National Center for Supercomputing Applications, University of Illinois Urbana-Champaign. This article is part of our series: A day in the software life, in which we will be asking researchers from all disciplines to discuss the tools that make

The new international initiative, Initiative for Open Citations (I4OC), that started this week with the aim of promoting the unrestricted availability of scholarly citation data, is a wonderful idea.

This post begins with an idea from a response to an NIH request for information that I wrote with Kyle E. Niemeyer and Arfon M. Smith, discussing what I then thought were the two needed roles to make software citation work: creating/publishing and citing, which I referred to as push (creating the object to be cited) and pull (actually citing it.) Upon further thought, I now believe that there are really three relevant steps, which can

This blog is based on part of a talk I gave in January 2017, and the thinking behind it, in turn, is based on my view of a series of recent talks and blogs, and how they might be fit together. The short summary is that general software reproducibly is hard at best, and may not be practical except in special cases.

I’m currently the Steering Committee chair for the IEEE International Conference on eScience series.  (Note that I’m going to talk about IEEE in this blog, but the problem is really much more general;

Open Science is a great concept (and recently described really nicely by Titus Brown, who said in part, “scientific progress relies on the sharing of both scientific ideas and scientific methodology.”) This is a wonderful ideal, and it describes how a lot of scientists would like to act. But as we know, most scientists don’t actually act this way, or at least not as strongly as they could. Why not?