Document SOP for all Uberon curators

[matentzn]

• Changes to classifications of terms from the 2x, 3x and 4x range should be reviewed by @cmungall https://github.com/obophenotype/uberon/issues/2514#issue-1258390659
• The higher up you are in the ontology, the more care/oversight required. Changes to the classification of terms higher than leaf nodes and their direct parents should be reviewed by @cmungall
• Don’t trust a term to mean what you expect by the label. Think through implications (make sure you understand the semantic diff, i.e. the new inferred axioms. - if there are many axioms in the diff more care is required)

More to add. We need a general getting started guide for editors which cover some of these secrets.

[cmungall]

example: you might be a world-class expert in evo-devo and neuroanatomy, and you might think there should be a develops-from between brain and neural tube. Adding this would result in changed entailments for 1000s of terms across multiple ontologies - all neurons in CL, many developmental terms in GO. And it would be wrong: uberon is metazoan and brains include non-vertebrate brains. In this case this would likely be caught be existing QC but there are many potential wrong changes that would not be caught.

[shawntanzk]

I'll place this in the docs board, happy to work on it but need more guidance, will discuss in next docs meeting

[shawntanzk]

High risk in: 1) reclassifying anything 2 levels from leaf 2) taxon constraints Low risk: 1) annotations 2) leaf nodes

curators: two main thing: 1) editing terms that might rearrange graph <- needs Chris or David to review 2) adding or editing what are usually leaf nodes <- other curators can review

Cleaning up assertions that are not needed -> should be routine

SOP: in contributing.md State clearly: "Curators should read this before making and changes to the ontology" eg if diff has logical rearrangement (eg >3 change subclass relationships) -> seek review from senior person A term that should have a lot of children, but is a leaf node -> because of uberon history (how it was created), you need to be careful. Checking things like xref might hint on why (eg xref from XAO). -> perhaps it should be merged rather than populated.

[shawntanzk]

Include in uberon SOP - around a 5 step guide on how to review a PR -> things that cannot be caught by CI should be reviewed by human -> needs discussion but shawn to start

[matentzn]

Add: There must be a logical pattern for each term which should be referred to by dcterms:conformsTo, for example:

UBERON:123 dcterms:conformsTo <http://purl.obolibrary.org/obo/uberon/patterns/dosdp-patterns/partOf.yaml>

[dosumis]

Add: There must be a logical pattern for each term which should be referred to by dcterms:conformsTo, for example:

Please don't!

Forcing logical definitions is a really bad idea.

[dosumis]

Happy to say - consider using a logical pattern & pointing users to patterns that we have. But it is much more important to have a guide to which relations to record what. We could built that up incrementally by generating a doc with all relations used + defs if available and gradually fleshing out a guide with examples.

[matentzn]

No no I didnt mean to force a logical definition. Just: if you are using a logical definition, it should adhere to a pattern!

[github-actions[bot]]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.

[github-actions[bot]]

This issue has not seen any activity in the past 6 months; it will be closed automatically one year from now if no action is taken.