Add prefix: obci

[github-actions]

Closes #1174

[bgyori]

Thanks for the contribution @nataled! A few comments and questions:

• I added a link to the OWL download at https://proteininformationresource.org/staff/nataled/OBCI/obci.owl which is useful to capture in Bioregistry
• In your original entry, the example ID was 0000001 (7 digits) but from what I can see in the OWL file, the IDs are all 9 digits long, e.g., (000000001). Is my interpretation correct? For the time being, I set the example ID to 000000001.
• If the ID length is consistently 9 digits now and in the future, we can make the regular expression pattern more specific by specifying the length.
• It seems there is currently no way to resolve individual IDs, e.g., PURLs like http://purl.obolibrary.org/obo/OBCI_000000001 don't currently resolve. Is that right? We might still want to curate this as the uri_format and it can be useful for CURIE/URI conversions when needed.

[nataled]

Hi @bgyori,

• The link you added is fine for now, but moving forward the official link will be different (OBO Foundry PURL), which is why I didn't specify it. I've yet to submit the ontology to that group though, so--assuming success--I can notify you when the change happens.
• Yes, the original was only 7 digits, but after reviewing the space, I decided just a day or two ago to increase the number. Thanks for catching that.
• Yes, I agree to use the more specific regex. Again, I didn't specify the length because I knew I needed to review the projected number (at the time I submitted). Probably went overboard :)
• Yes, currently the PURLs won't resolve. This is a recurring issue with new ontology submissions to the Foundry.

Thanks for your suggestions and questions!

[bgyori]

Thanks @nataled, that all makes sense! I think I will add the uri_format now, and once the Foundry submission is in place, they will resolve.

Unfortunately due to bug #1115 the PR was automatically closed but I will revive and merge it.

[matentzn]

I am not for or against this, just noting that there is a minor risk involved here:

1. we explicitly require in OBO Foundry that there may not be a prefix clash with bioregistry
2. OBO Foundry has no (operational) influence on what is added to bioregistry
3. People can now just register, semi-officially, OBO PURLs without actually being in OBO (not just by adding new prefixes, but also by editing existing ones).

I don't think we need to act on this now, just something to think about

[cthoyt]

some other thoughts on the situation in https://cthoyt.com/2023/03/11/obolibrary-masquerade.html

[bgyori]

From @nataled's comments I got the sense that this has been already submitted to the OBO Foundry and that it was only a question of time for the URLs to start resolving. So I didn't consider that possibility that it was "unsanctioned" in any way. If this is what happened here then we could make it a policy to not register OBO PURLs unless already integrated into the OBO Foundry first (and then imported via the ingestion pipeline here).

[nataled]

@matentzn I submitted this prefix in anticipation of the submitting to the Foundry. Obviously if the ontology fails that submission, I'll need to revise the purls.

[nataled]

(I'm actually going to submit probably tomorrow.)

[matentzn]

Yeah I know, this was not so much a comment about this case, just a minor comment about tightening the SOP. For example, I would, personally, forbid the manual curation of OBO PURL URI prefixes in bioregistry altogether and just wait until the ETL pulls in the prefix from obo metadata. But no strong thoughts. If you think that's too much let's leave it as is..

[nataled]

My interpretation of the 'no clashing prefixes' directive, from the Foundry perspective, is that there must not be a registered prefix from a different resource. Perhaps a minor distinction, but the effect can be major. The tightening of the SOP (I am unclear as to whether you're referring to a Foundry SOP or to a Bioregistry SOP; here I presume the former) would prevent, for example, an ontology that has been in Bioportal from later applying to be part of the Foundry. I doubt that's the intention. If you are concerned about the SOP from the Bioregistry perspective, I have less of a concern other than the one that prompted me to submit our prefix prior to Foundry submission: multiple potential projects dealing with the same domain. I already saw submission of an ontology (BMO at the time, later BMONT) that used a prefix we originally intended to use ourselves.