Can we allow to reserve OBO prefixes without admitting an ontology to the foundry?

[matentzn]

It happens now here and there that ontologies are created using OBO tools and OBO IRIs etc but the ontology does not get admitted to OBO for whatever reason. Would it be ok if we made it possible to simply reserve a namespace without being added to the foundry registry to avoid potential clashes in the future? This also makes it easier to block namespaces even if the ontology has not yet been developed.

[cmungall]

What's to prevent squatters?

How about encouraging early registration of concrete artefacts, allowing under-developed ontologies, so long as there is some kind of documented plan? We could add a status such as 'draft' or 'early development'. But it would still resolve to an ontology.

[matentzn]

My personal opinion is that squatters in the sense of: "I want this namespace and have no intention to use it" are going to be rare and can be dealt with on an ad-hoc basis. But your solution to the problem seems ok to me! As long as early registration of concrete artefacts does not involve any beyond the crudest of reviews, and acceptance wont be blocked for whatever reason (perhaps we can prevent ontologies about the anatomy of air planes), I think this would be ok. How would this look like concretely? Can we just use the initial github issue that proclaims the intention to publish an ontology as part of the obo foundry and develop a process that, as a consequence of merely putting this issue out, an entry is made somewhere which registers the draft? Should we just have a yaml file for draft ontologies, and expand our SOP to remove an ontology from draft stage once a proper md file is created? Or what do you envision?

[jamesaoverton]

I'm in favour of early registration for two main reasons:

1. technical: projects will have a proper IDSPACE they can use early. The status quo is that people just pick an OBO IDSPACE and start using OBO PURLs that they don't actually control. If they do eventually register, they don't want to change the IDSPACE they picked for themselves.
2. coordination: early registration is a chance to find collaborators and steer reuse of existing ontologies.

In hindsight, early registration would have avoided many problems we've seen.

I think we should:

1. Require a registration form (like the one we're working on) that forces new registrants to think about the OBO principles and express intent to follow them.
2. Require a GitHub repository (or any other public version control repository with an issue tracker), even if it's empty, to encourage open development from the start and open lines of communication.
3. Apply a 'draft' status (as @cmungall said) to the registry entry, putting it in a separate list.
4. Review the draft status every year and either: give the project an official status, renew draft status for another year, or drop the project.

[matentzn]

Sounds perfect! I am a bit mindful of 4 (work for the foundry); I think just blocking an idspace does no harm and should be allowed without review. Could you remind me what would have to happen to go from 1+2 (which are clear) to 3?

[jamesaoverton]

My view is that we need a lightweight manual review process before reserving an IDSPACE. That would reduce squatters but more importantly it would help coordination by requiring the operations committee to look at the request. We also need a process for dropping projects that are abandoned before they publish anything (4). I think the benefits are worth the small amount of manual effort.

Items 1-3 on my list are all about the registry entry, not really a sequence of steps. We have a registry entry (a YAML/Markdown file in this repository) for every project, no matter what the status (active, inactive, obsolete, and this proposed draft status), just to keep track of things. The form (1) would help fill out that registry entry. The registry entry would point to the project repository and tracker (2). The draft status (3) would be a field in the registry.

[matentzn]

Ok, convinced! :) thanks!

[nlharris]

Where are we on this?

[cthoyt]

The solution to a specific instance of this issue in #1677 was to registry the prefix in the Bioregistry. Follow-up discussion about requiring new prefixes to be unique with respect to the Bioregistry is occuring at #1704.

[nlharris]

So can this ticket be closed, then?

[cthoyt]

If this should be documented as a policy somewhere, then I’d wait. Otherwise yes

[cmungall]

Yes, this issue should be closed by a PR to the documentation

…

On Wed, Jan 5, 2022 at 2:46 PM Charles Tapley Hoyt ***@***.***> wrote: If this should be documented as a policy somewhere, then I’d wait. Otherwise yes — Reply to this email directly, view it on GitHub <#1039 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOP5WX53DQKGLQZGCWDUUTC45ANCNFSM4INFRUCA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[matentzn]

I think this is already done here:
https://github.com/OBOFoundry/OBOFoundry.github.io/blob/master/id-policy.md

Or were you looking for something more explicit @cthoyt, like #1740?

[cthoyt]

@matentzn thanks for putting that PR, that's definitely important since I assume many submitters won't actually read the policies. However, I don't think either of the resources you linked outline the situation in which you want to reserve a prefix that you might later add to the OBO Foundry where the solution is to directly make a request in the Bioregistry.

[matentzn]

Yeah thats right. Maybe something like adding an FAQ:

#1742

Feel free to edit at will.

[matentzn]

I think this takes care of it now:

#1742

If disagreed, reopen.

[cthoyt]

I agree, this is done! Thanks @matentzn :)