Help! PIDs for facilities and instruments

Hi all,

This is an 11th hour panic button request before a meeting tomorrow at which I’m being asked by a university what PIDs they should use in their RIMS for facilities and instruments. Noting that these are two different things with two different PID types likely - what are people using?

I’ve heard of some who are using GRID or ROR for facilities. What else is being used and why?

There is a PIDs for instruments RDA group. I understand they have come up with a schema (seen it on GitHub) but have not yet decided which PID type to use. Can someone give me a further update on this? It will be hard to say to this university: capture the metadata according the RDA group schema but do not assign a PID yet…

I’m aware that ORCID records can include in the resource type, PIDs for equipment (instruments) and infrastructure (facilities). Can someone point me to an example record?

Any thoughts, corrections, suggestions greatly appreciated!

Thanks,
Natasha

Hi Natasha, possibly a bit late for your meeting: PANGAEA is the FREYA partner who has been most involved in activities around PIDs for Instruments. Perhaps @tdohna could point you to relevant updates?
I don’t know of the facility PIDs that might currently be in operation.

1 Like

Hi Natasha, yes, you are right in everything you stated. As an update: Datacite will adapt their metadata schema to include essential aspects of the RDA group schema for instruments by sometime later next year. At the moment, members of this RDA group are using the current Datacite schema to register their instruments and to mint DOI’s. They use ‘other’ where ever input cannot be provided. Your community can do the same, i.e. mint DOIs for their instruments now, with the RDA instrument metadata schema in mind, so they can include this information when the Datacite schema has been altered. ROR ID’s are for research organizations, so I believe research facilities would fall under this, unless the facility is itself a large instrument, which I think you are indicating. In this case a DOI, for example, can be the right choice. The consensus in the RDA group was that an initial DOI for each instrument would work well. If, however, the instrument should receive a new identifier every time it is overhauled or calibrated or deployed etc. then a second more flexible system (using the initial DOI of the instrument as a connecting identifier) would be useful. This of course depends on what granularity is to be achieved and so depends on the use case. I hope this info helps with your meeting tomorrow and I’m very happy to see that the community is eager to adopt PIDs in their institutional workflows.
Best,
Tina

2 Likes

In case it’s still helpful @NatashaS , there’s some good information about research resources in ORCID records here, including a great video from EMBL about how they’re using this section: https://orcid.org/organizations/research-orgs/resources

1 Like

Thanks so much for this @tdohna. Super helpful! My meeting went well here. I’m now organising an Australian zoom call to discuss this topic. That call will aim to get everyone up to speed with the international thinking on this and help people from different research institutions to make a decision about which PIDs to use in their systems for facilities and instruments. It’s good to hear that DataCite will adapted their metadata schema for instruments which makes DOIs a very clear option I think. With regard to ROR, we have a large research organisation here who are choosing GRID over ROR. The main reason is that GRID is cited in WofS and Scopus by their peer organisations and their primary goal is tracking research impact through the organisation PIDs. I’m very aware of the value ROR gives to the community in being open, not-for-profit, transparent etc but it may be a while longer before RORs are cited for research facilities in WofS and Scopus which is what’s needed to enhance their adoption. I’m happy to be corrected on this. Thanks again for your input!

This is helpful but if I understand correctly, it is possible for a research facility (lab, instrument, etc.) to use EITHER DataCite or ROR identifiers. Is that correct?

My question would be: Which is a best practice? Is it bad manners to register a facility both at DataCite AND ROR? And for DataCite, there is a resource type called “Physical Object” Would that be appropriate?

Many thanks in advance for your replies. I feel that many of my colleagues are facing the same questions so I would bet that your answer will be helpful to more than just me.

-Alvin

I could have a go at answering this but I think the people who could answer it best are @Helena and @mariagould

I appreciate the questions being raised here and I think this is a good topic for further discussion among the community.

ROR IDs are intended to be an identifier for research output affiliations. In many cases this is an institution/university, but this can also include facilities and the ROR metadata includes “facility” as an organization type (e.g., https://ror.org/0518wrr32). Perhaps one useful way to think through the type of scenario posed above is that the ROR ID could be used to identify the facility itself, whereas a DOI might identify an instrument used at the facility. What do others think?

This seems a related thread to the question I have, so I’m posting here. We just received a request from someone at our university to assign a DOI for a server that is provided for use by faculty in a specific school. The URL they want the DOI to point to is http://rcpedia.stanford.edu/yen/. Is this an appropriate use of a DataCite DOI? It did not initially strike me as appropriate, but after seeing this, I started to wonder. Would you classify this as a resourceType of Service or PhysicalObject? Or Other? Thanks!

Actually, it looks like our Dean of Research’s office has been going with RRIDs for facilities and such and is interested in doing that here as well. But I’m still interested in finding out if people do use DOIs for servers or other things and what may be included in the schema in the future. Thanks!