PID for referencing organizations and departments of Research Infrastructures for acknowledgements in publications

PID Best Practices and User Stories
1

Dear all,

I was contacted with a question on the recommended procedure for referencing organisations and their particular departments of Research Infrastructures (RIs) used to support research. RIs need to be correctly acknowledged as it provides proof for their financing streams. However, there is no matured PID for referencing particular institutions and their departments.

It seems to me ROR is a good PID; however, it is stated at https://ror.org/facts/ that:

Granularity and hierarchy
ROR is focused on being a top-level registry of organisations so we can address the fundamental affiliation use case, and provide a critical source of metadata that can interoperate with other institutional identifiers. ROR is therefore not focused on mapping university departments and similar sub-units within institutions. ROR’s data and infrastructure are openly available for leverage by and interoperability with local-level efforts focused on mapping individual hierarchies within organisations.

On the other hand, at https://ror.readme.io/docs/ror-data-structur, there is a field relationships described as Related organisations in ROR; Allowed relationship types: Parent, Child, Related. So ROR counts on keeping a basic graph of relations between the organisations.

So, my question is: What is recommended way of referencing RIs and their subparts in acknowledgements of scientific publications? Do we currently have a matured-enough PID for this use case? If ROR is the recommended way, I do not see any “versioning“ in their Data Structure description. What happens if the organisation is renamed, merged with another organisation or split into two new organisations. Will they receive a new ROR? How will the user receive information on the organisation’s accurate descriptions (metadata) at a particular time?

All the best,
Michal

2

Hi Michal, thanks for your questions. We are definitely seeing a growing interest in this use case. While it is not necessarily ROR’s main focus, there is scope for research facilities and related infrastructures in ROR. These would still need to meet the basic criteria for inclusion, so certain subsidiary units may not qualify for inclusion if they fall in the category of departments or instruments, which are not in scope for ROR.

Regarding ongoing curation of registry records, we have just implemented a new process for registry updates, which you can read about in this blog post. The best way to track registry changes at present is via the release notes for each update.

ROR IDs do not change when an organization’s name or other descriptive metadata gets updated. Merging and splitting organizations is not yet possible but the future handling with regards to ROR IDs will depend on the nature of the change (e.g., if Organization A and Organization B merge to become Organization C, we would create a new ID for C and redirect A and B to C, but if A subsumes C, we would retain the ID for A and redirect C to A).

We are considering future functionality to support created/last modified dates in ROR records and to version the schema/API. These topics are open for community feedback so that we can consider various use cases and approaches as we plan this work.