DRAFT: New Principle 19 - for OBO Operations Review #2668
Conversation
nataled
added
attn: Operations Committee
principles/fp-019-term-stability.md
Outdated
| is_obsolete: true | ||
| replaced_by: OBI:0001544 | ||
| ``` | ||
| For OBO format, there are multiple alternatives: |
There was a problem hiding this comment.
I don't think this has anything directly to do with OBO format. GO, Uberon, CL, all phenotype ontologies all use the same simple data model e.g. making use of comments because this is what browsers show more prominently, because it's simpler and more consistent. Nothing to do with format. OBO Format can represent annotation assertions at exactly the same level of expressivity as OWL
There was a problem hiding this comment.
These alternatives are listed for OBO format because they are used 'in the field' so to speak. That is, unlike ontologies in OWL format--which all seem to use the same deprecation methods--OBO formatted ontologies have been using different means. I've confirmed that either way is fine, so we say all this to acknowledge these alternatives.
principles/fp-019-term-stability.md
Outdated
| [Typedef] | ||
| id: has_obsolescence_reason | ||
| name: has obsolescence reason | ||
| xref: IAO:0000233 |
There was a problem hiding this comment.
Oops, thanks! Fixed.
principles/fp-019-term-stability.md
Outdated
| The OBO Dashboard will show: | ||
| - An ERROR if any obsolete term (that is, a term with an "owl:deprecated" property or "is_obsolete: true" tag) does not also have 'obsolete ' (that exact string, lowercase and space included, with no other punctuation) prepended to the label | ||
| - An ERROR if any obsolete term (as indicated by term label or definition) lacks an "owl:deprecated" property or "is_obsolete: true" tag | ||
| - An ERROR if an obsolete term has any associated logical axioms (including any subClassOf/is_a declarations) |
There was a problem hiding this comment.
is "associated with" the same as "referencing"?
(best to use precise terms, we generally follow the owlapi vocabulary e.g "about" "referencing")
There was a problem hiding this comment.
Yes, that's half the intent. Revising.
|
|
||
| The PRO term "phosphoprotein" (PR:000037070) is defined as "A protein that includes at least one phosphorylated residue." A study finds 2000 more examples than was previously known. In this case, no new term needs to be made (nor the original deleted) because (1) the term definition did not change; and (2) the referent--proteins with a phophoresidue--did not change (that is, the newly-discovered phosphoproteins are just additional examples of that referent). | ||
|
|
||
| Criteria for review |
There was a problem hiding this comment.
presumably this is criteria for dashboard review?
The earlier text lays out criteria about definitions changing in meaning. This could easily be checked by LLM using KGCL, but the dashboard doesn't support this yet
There was a problem hiding this comment.
The heading 'Criteria for review' intends to capture all possible types of review. Here we list what we can reasonably check. If the future adds more powerful checks, those checks will be added.
| Implementation | ||
| ------- | ||
|
|
||
| Detailed procedures for obsoleting a term are described on the OBO Academy page [Obsoleting an Existing Ontology Term](https://oboacademy.github.io/obook/howto/obsolete-term/). |
There was a problem hiding this comment.
See also kgcl:NodeObsoletion for a taxonomy of kinds of obsoletion
There was a problem hiding this comment.
@cmungall So far as I can tell, IAO has basically the same set of reasons. The benefit to mentioning this other resource is unclear.
There was a problem hiding this comment.
I like this principle very much; some general feedback:
- the principle is about "term stability", yet the focus is entirely about definitions (IAO:0000115). I think the principle text should clearly refer to all ways a meaning can significantly change, including in cases where there is no human readable definition, but a rich axiomatic structure (like say in PRO or CHEBI).
- I like the concept of "referents" very much; but what I am missing here is that the source of the mapping between and ID and its referent is solely in the head of the ontology developer. So I would like the text to reflect the idea of "as intended by the ontology developer". I think this is important because the referents are never explicit, and we need to have a source of truth for who gets to define these somewhere in the text. This also helps with deciding "if the referent changed or not" - as you say, only the ontology author can decide this.
Addresses Chris M's suggestions
No description provided.