Add superclass mapping from COB characteristic to ChEBI role

[cthoyt]

Closes #169

This PR adds an explicit equivalence mapping between COB and ChEBI:

• COB:0000502 (characteristic) sssom:superClassOf CHEBI:50906 (role)
• COB:0000088 (drug product) rdfs:seeAlso CHEBI:23888 (drug)

This one seems pretty straightforward, so maybe there's a reason these were difficult to align before, so feedback or changes (e.g., different relationship) are welcome.

Note: I tried running the make command but got an error (see #174). I'm curious if there are tools built in to the make command that can automatically check that adding an equivalence like this doesn't cause any problems

[cmungall]

You would think this would be straightforward, right?

TL;DR - I think CHEBI:role should be up a level, a subclassof "characteristic"

COB follows BFO in forcing you to make a distinction between "role" and "disposition".

(aside: I think some of these are processes)

After years of working with upper ontologies I am now convinced this is like forcing you to choose whether your database is painted the color of angel's wings or demon's fur.

We could go through the CHEBI role hierarchy and look at the individual terms and analyze using a BFO approach whether those terms are "dispositions" "qualities" or "roles". It would be a mix. And there would be many that would be on the edge. We could spend the next decade arguing about these at various meetings, and leave a giant trail of unclosed github tickets in our wake.

So in fact we had a similar issue with PATO, at one point we considered splitting the ontology into qualities vs dispositions:

pato-ontology/pato#112

But we discovered we would be having angels-on-pinhead discussions about whether mass, color, etc were dispositions or qualities. The fact is, the concepts as used by scientists have aspects of both, and no user cares about the distinction

we have in fact made the decision over here in COB that we would formally uncommit PATO and just put it's root at the parent class of 'characteristic'

subject_id	subject_label	predicate_id	object_id	object_label	notes
COB:0000502	characteristic	owl:equivalentClass	PATO:0000001	quality	#124

See also #27 and #124

This leaves open the possibility that in future PATO commits individual sub-branches to subclasses - but realistically, our time is limited, no one has resources to do this kind of pointless work

I recommend we do the same with CHEBI - make chebi role a subclass of characteristic, and CHEBI can choose to make individual commitments about sub-branches later on.

Another view of the CHEBI role branch is as shortcuts for more direct statements pertaining to more concrete classes, as we describe here: https://doi.org/10.26434/chemrxiv.12591221.v1

[cmungall]

Talking about drug product separately:

the proposed equivalence doesn't work since COB drug product is a material entity, and chebi:drug is a role, these are disjoint in COB. See #140 for our drug issues

[cthoyt]

Thanks for the detailed explanation, Chris. If I had to guess, I would probably call ChEBI roles dispositions.

We could spend the next decade arguing about these at various meetings, and leave a giant trail of unclosed github tickets in our wake.

^ Such wisdom :)

I recommend we do the same with CHEBI - make chebi role a subclass of characteristic, and CHEBI can choose to make individual commitments about sub-branches later on.

Will do

Another view of the CHEBI role branch is as shortcuts for more direct statements pertaining to more concrete classes, as we describe here: https://doi.org/10.26434/chemrxiv.12591221.v1

One day, somebody will help me write a script to turn this all into nice OWL that can be integrated with everything else in OBO, then we can finally submit this paper. @matentzn looking at you!

the proposed equivalence doesn't work since COB drug product is a material entity, and chebi:drug is a role, these are disjoint in COB. See #140 for our drug issues

I'll also take this out. Sorry I didn't see that issue before. However, maybe I can just change it to rdfs:seeAlso in case someone reads this later and also has the same idea that I did

[cthoyt]

@cmungall should I run some of the build functions before merging this PR?

[cmungall]

I approved github actions for you, I trust you not to mine bitcoin, so now PR QC checks should automatically run for you. No need to do anything else

[cmungall]

I like this. closeMatch is also not wrong, but I think seeAlso is good as it's even weaker. We should systematize this a bit more