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. As Martin Fenner pointed out in an earlier talk in the session, creating a new set of PIDs that is actually used requires a lot of effort, including careful thinking about uniqueness, persistence, descriptiveness, interoperability, and governance. It’s clear that the organization ID working group has been thinking about all these things, and has done good work in providing potential answers, but listening to the Org ID talk and discussion, I wonder if this is a case where we should be thinking of abstractions first.
We currently seem to have one basic abstraction for most PIDS, based in large part on the Handle system, on which DOIs are built. This system use the namespaces abstraction, making it parallel in one dimension: each handle has a prefix (naming authority) and a suffix (local name).
I propose that we consider a group as a new abstraction, to support another dimension of parallelism.
Grouping PIDs is not a new idea, but it is currently buried in the metadata, rather than being exposed as a first-class concept. In DOIs, for example, it can be accomplished by using the recommended Relators, which, for example, is implemented in DataCite’s metadata schema using the relationType property.
If we accept the idea of groups of PIDs as a valid high-level abstraction, there would be no need for a new PID for organizations, as this could be handle by a group of ORCID IDs. And it would enable the same group PIDs to support both formal organizations (for example, university, non-profits, etc.) as well as informal organizations (such as projects.)
Group PIDs would also help software, where a software project could be a group of software version PIDs, as I’ve previously discussed. And it also likely would help in data, where there are issues about PIDs for datasets, PIDs for data collections, and PIDs for individual datum within them.
I don’t know how this group abstraction should be implemented, but some PID enthusiasts might have ideas. Maybe we can talk about this at PIDapalooza? If anyone want to work with me to propose something about this topic for that meeting, please let me know. I’m told the deadline has been extended to today (Friday, 22 Sept.)