upper-level slims - develop definition, SOP, technical architecture & implement test cases.

dosumis commented 1 year ago

Problem:

Services that rely on CL annotation to provide indexing, grouping and summaries of annotated data need a set (or sets) of high level terms to which they can map their annotations in order to drive summaries/faceting. For visualization purposes, they typically want summaries to provide single inheritance classifications.

To solve these problems, I propose that we develop and maintain one or more upper-level slims that consumers of the ontology can use for mapping-up their annotations. This should be co-ordinated with an increase in the addition of disjointness axioms - as these can potentially be used, together with upper-level slims, to reliably generate single-inheritance visualisations. (Where disjointness axiom may be unsafe, we might consider some other form of flagging of potential disjoints with APs).

Description of approach:

upper slims should follow a naming convention so that they can be distinguished from other uses of the subset tag. Suggest: {some_name}_upper_slim
Each slim should be maintained in a ROBOT template & built using ODK - for ease of editing/update. @anitacaron to train editors to set these up as needed.
Add disjointness axioms between classes in the slim that we are very confident do not overlap
For each slim, we need to define a scope against which coverage will be tested. Scope = one or more classes or class expressions. e.g. immune slim may have scope 'hematopoietic cell', eye slim 'cell that overalps some eye'.
For each slim we should aim for 80-90% coverage where this is defined as % of cells in scope that are subclasses of terms in slim, excluding superclasses of terms in slim. @ubyndr to provide infrastructure for calculating scope and reporting terms that fall outside of scope.

Test cases