OBO ontology (not term) deprecation policy

[matentzn]

Currently, I do not see an official strategy on the OBO website that describes under which conditions an ontology, once accepted, can be removed again from the OBO foundry active ontology list, i.e. obsoleted. Obviously, the purpose here is not to create a weapon to nuke ontologies we don't like, but to create a way to clear the OBO ontology library of ontologies that have been superseded or that grossly violate the OBO philosophy.

First, the definition of obsolete: this is simply to mark an ontology as obsolete in the OBO metadata and list them as obsolete in the library. Importantly, the ontology, at least IMHO, still retains their ID space, so we don't get any conflicts down the line.

I can think of three main reasons for obsoletion:

1. the ontology is inactive/orphaned and superseded
2. the ontology significantly violates OBO foundry principles
3. the ontology owners declare the ontology as obsolete, see #1442 as an example.

@pbuttigieg formulated it similarly here:

The ontology is either inactive or orphaned, and the original developers do not recommend using existing versions of it, either because another project is available that supersedes it, or because previous produced versions have serious issues that make them less usable, and/or are not available at all.

For 1, inactive and superseded, I would suggest these criteria:

1. The ontology owners have been unresponsive (according to the responsiveness principle the EWG is drawing up)
2. There is another ontology that can demonstrate significant overlap in scope and term coverage

I think both criteria should be true for an obsoletion request to be submitted.

For 2, a significant violation of OBO Foundry principles, I would say develop a list of criteria like

1. Changed to a commercial license
2. Does not provide a working primary (ont.owl) purl - either unparseable or not there in the first place

I am not sure whether something like "violating OBO principles in general" is a bit too.. extreme.. and causes issues. In the worst case, we can use the code of conduct mitigation team to deal with an issue beyond the hard criteria (1/2) above.

Procedurally I suggest this:

1. We require an obsoletion request here on the repo (issue template?) that gives the reasons clearly as outlined above
2. We tag the owners in the issue, and send a separate email to inform them of the request
3. We give 3 months to respond, chasing once every month.
4. After the three month, we move the ontology to obsoleted.

What do you think?

[cmungall]

A simpler proposal:

An ontology is obsolete if the owner declares it as obsolete

We have other flags such as inactive that can be applied in cases of inactivity

We haven't seen the case yet of someone changing to a commercial license. If this were to happen I think we should have another mechanism/flag rather than overloading the concept of obsoletion. We should stick to the dictionary definition of obsolete "no longer in use or no longer useful"

[nlharris]

Related tickets: #1126, "Document the distinctions between active/inactive, orphaned, etc.", and #733

[matentzn]

Just to be clear, if the obsolete tag is the problem with this proposal, then lets invent a new tag or use another (inactive or whatever). The point here is that we should have some formal procedure to remove an ontology from the primary library or at least visually distinguish it when it is broken and not being fixed, see for example https://github.com/HUPO-PSI/mzIdentML/issues/117 (the only current such case). I would also like to consider to obsolete GAZ and merge it into wikidata (because of this), but I don't know which groups rely on GAZ atm.

[nlharris]

See also: Define intended behavior for obsolete ontologies in ontology browsers #1454

[cmungall]

I don't care so much about the name but each kind of status/flag should have defined behavior. I realize we have not done this for obsolete: made a ticket #1454.

I suggest a tag such as permantly_unavailable for the xlmod case. The behavior would be:

• display in strikeout at bottom on obo site
• mark as permanently unavailable on OBO ontology page
• browsers SHOULD not attempt to index this (removing false positive 404s that they need to report back to us)
• browsers MAY include a stub for this and mark it as the same way as on the OBO page
• QC checks like dashboard SHOULD ignore entirely (or MAY include an informative line with an X at the end and other columns blank)

GAZ is a tricky case. I will follow up on the ticket

[matentzn]

Perfect, sounds good to me :) I am happy with permanently_unavailable!

[matentzn]

From the operations commitee meeting:

• Lynn suggested to ensure that the ontology is not otherwise used (for example by other ontologies). We should ensure that by checking the dashboard results, but also do a quick search around (OLS, ontobee)
• @bpeters42 to increase the time of notice to six months and at least 5 communication attempts
• xlmod is not case for immediate obsoletion, i will try harder to get their attention

[matentzn]

As there are no open cases, I vote for closing this issue and reviving when a new one comes along. @cmungall managed to establish contact with the xlmod people. Thanks all for the input :)