2026-10-27 –, LUMC03
In this talk you will learn about the sea of different software identifiers that exist, and where they are used. If you study this topic, you may feel you are drowning. Which identifier seems most natural for you to use probably depends on your role, whether you are a publisher, librarian, software developer, software user, informatics researcher, etc. Your discipline may also matter, as there are different identifiers in use in different fields, such as life sciences, astronomy, math, etc. We'll talk about this and how all of these identifiers are related. Hopefully you will be able to help, including using persistent identifiers (PIDs) as much as possible. By the end of the talk, perhaps you will no longer be drowning but will be swimming comfortably.
Have you ever tried to identify software? If so, you'll have realized that it's not easy to do, for a few reasons. First, you have to decide what you want to identify, from the concept of a software project (e.g., SciPy), to a version, to a file, to a set of lines. Software has complex granularity in both space and time. Second, you have to decide what kind of identifier you want to use, from an external identifier such as a repository URL or a package manager URL or a general identifier (e.g., DOI) or a specialized identifier (e.g., RRID, ASCL ID, swMATH ID) to an intrinsic identifier (e.g., SWHID). You may feel that you are swimming or drowning in a sea of different types of identifiers.
Your aim (your case and how you engage with software) also matters:
- As a software developer, you may want credit when people use your software, so you could try to make it easy to cite and then ask people to cite it when they write papers about it.
- As a publisher, you may also want software to be cited, or you may want software to be described in a methods section without a formal citation, but even so, you probably want to encourage reproducibility, so persistent identification is still important but difficult for non-experts to support.
- As a researcher of software, you will have to deal with the fact that most software is accessible in repositories and package managers, both of which have identifiers, but these are generally not persistent in an archival sense, as well as the fact that some research software is commercial, and mainly identified by product name and version.
- As a funder, you probably want to track the software that you've supported, including all its versions, and you also may be interested in what other software this software enables.
Extending the metaphor, the sea contains people swimming with a variety of strokes, swimming in different directions, and it's vast and complex.
Some of the challenges associated with software identifiers also relate to challenges around software metadata, and you will have to consider where you can find the metadata associated with the software, which may include one or more identifiers. This metadata can be stored with the software itself, or in a scholarly repository or registry, associated with but separate from the software. The metadata is key to understanding the software and finding it. Depending on your role, you may want different types of metadata, describing a different facet of the software. This further complexifies the software ocean ecosystem and muddies the waters.
Overall, you will see that there are a large number of challenges related to software identifiers, with some possible solutions. After this session, you should have a good idea of what the challenges are, and how you can contribute to addressing them. Maybe we can make the dangerous-looking sea into a safe and comfortable pool.
At the University of Illinois Urbana-Champaign, Dan is Chief Scientist at NCSA and Research Professor in the Siebel School of Computing and Data Science and in the School of Information Sciences. He works on issues at the triple point of research software, people, and policies.