Rethink the role of CARO

[cmungall]

Since CARO was initially constructed

1.I am less sure of the utility of some of the BFO/FMA-esque groupings

2. it's not clear how much CARO is truly used - as in, if it blinked out of existence, what woul break
3. we now have COB
4. uberon is used predominantly for metazoans, either directly, or indirectly for ssAOs

None of this denies the important role of CARO in getting us where we are, this issue is purely about the future

1 is maybe a bit controversial but I think some of the distinctions CARO draws at the top level such as whether something is connected or not can be done at deeper levels as e.g. PATO characteristics

2 a single CARO class is used in CARO,

id: GO:0048856
name: anatomical structure development
namespace: biological_process
def: "The biological process whose specific outcome is the progression of an anatomical structure from an initial condition to its mature state. This process begins with the formation of the structure and ends with the mature structure, whatever form that may be including its natural destruction. An anatomical structure is any biological entity that occupies space and is distinguished from its surroundings. Anatomical structures can be macroscopic such as a carpel, or microscopic such as an acrosome." [GO_REF:0000021]
subset: goslim_chembl
subset: goslim_generic
subset: goslim_plant
synonym: "development of an anatomical structure" EXACT []
is_a: GO:0032502 ! developmental process
intersection_of: GO:0032502 ! developmental process
intersection_of: results_in_development_of CARO:0000003 ! connected anatomical structure

it's not even clear this is correct, and the disconnect (ho ho) between the broader label (connectedness neutral) in GO and the more specific one in CARO is a red flag.

Perhaps 3 is a bit of a red herring:

• Currently in the COB release, COB IDs are rewired to CARO (where equivalents don't exist)
• Some genuinely useful COB classes like "anatomical entity" don't have equivalent IDs in COB as COB still essentially follows BFO and dividing the world into material and immaterial rather than domain scientist friendly groupings
• COB doesn't have many of the other mid-level groupings

However, there is still an issue that for uberon (and ssAOs) to properly link up to either COB or CARO there needs to be subclass bridging axioms or species-equivalents.

We supply these in http://purl.obolibrary.org/obo/uberon/bridge/uberon-bridge-to-caro.owl

e.g.

    <owl:Class rdf:about="http://purl.obolibrary.org/obo/CARO_0000011">
        <owl:equivalentClass rdf:resource="http://purl.obolibrary.org/obo/UBERON_0000467"/>
        <obo:IAO_0000589 rdf:datatype="http://www.w3.org/2001/XMLSchema#string">anatomical system (CARO)</obo:IAO_0000589>
        <oboInOwl:id rdf:datatype="http://www.w3.org/2001/XMLSchema#string">CARO:0000011</oboInOwl:id>
    </owl:Class>

These are actually wrong since you end up inheriting taxon constraints

We have similar axioms for CL, but these are coherent because although the scope of CL is metazoa, formally the top level classes are truly species neutral. In which case we should just obsolete cells from CARO as they cause confusion.

For gross anatomy we have the option of

1. generalizing the CARO-equivs in Uberon so they are truly equivs and not taxon-equivs
2. More formally committing to them being species equivs

I think 1 is probably easiest. We don't really lose any useful axioms (and these are retained as GCIs anyway). Note this would mean that some PO and FAO classes would become subclasses to general Uberon classes

If we carry on the course for 2, then we have some work to do

• we need to fix the bridge axioms be be metazoa-equiv, and make them available in releases such that hierarchies properly link up
• we need some naming solution so people aren't confused by two "duplicates" of "anatomical entity" etc
• we need to check if CARO text definition commitments are truly followed in subclasses, or even followed "on paper"

Either way I think we need to obsolete some classes that are truly equivalent, will make tickets

[cmungall]

Retired in favor of https://github.com/obophenotype/uberon/issues/2349