search

biopragmatics / bioregistry

📮 An integrative registry of biological databases, ontologies, and nomenclatures.
https://bioregistry.io
MIT License
119 stars 51 forks source link

Proposal for Bioregistry SOP: "No manual registration of OBO URI prefixes" #1212

Open matentzn opened 1 week ago

matentzn commented 1 week ago

Some context.

I would like to suggest the following addition to the bioregistry SOP:

OBO URI prefixes such as http://purl.obolibrary.org/obo/ABC_ are automatically synchronised with the OBO Foundry metadata and prefixes. To avoid misusing bioregistries community driven editorial workflow to squat OBO PURLs for ontologies that are not officially accepted in OBO, we disallow manual curation of OBO URI prefixes in favour of full automatic synchronisation with the OBO prefix file.

@nataled that is what I meant - if OBCI say is accepted in OBO, the OBO URI prefix will automatically finds its way into bioregistry through the OBO metadata.

nataled commented 1 week ago

@matentzn I understood. We'll need a suitable revision to the Foundry NOR instructions to account for this: In addition to checking the Bioregistry and BioPortal, submitters will need to also check (at least) the NOR Dashboard (for ontologies in the in-between).

cthoyt commented 6 days ago

This should be more generic to say that new resources should not park on external IRI spaces. This isn't only applicable for OBO Foundry, but also the Crop Ontology IRI space, Identifiers.org IRI space, Name-to-Thing IRI space, RRID IRI space, or anything similar. For people trying to pick something that is PURL-like, they could consider w3id.org or similar

We can't make a technical solution that says non-OBO prefixes can't use OBO IRI space, as I've linked a few times in this discussion, there are people doing this whether we like it or not, for a variety of reasons. Therefore, I propose that what you're asking for is articulated in terms of improving reviewer guidelines. How can you educate Bioregistry reviewers to spot these situations, and help them to explain to submitters why they shouldn't be doing this? Then, how can you guide them towards a better solution? Will one of you take the lead on writing a more coherent explanation?

matentzn commented 3 days ago

I framed it a bit differently, lets work on this and see what you think: https://docs.google.com/document/d/1aIP8YjyVnMzKnksMbBu1kYriV9jlMejWDrZ7E3GmXlY/edit?usp=sharing