Standardize how we indicate the relationship between a core class and its matching OBO one

[beckyjackson]

From @cmungall

Currently we have been making notes as rdfs:comments but we should do this in a better way

If we believe they are truly equivalent then equivalentClasses is appropriate - however, this is a pain to work with in protege (since you induce a class declaration). I would vote for editing as a skos:exactMatch (we can avoid declaring a class). It could be converted to equivalence during release

For close matches, skos:closeMatch, otherwise rdfs:seeAlso?

Or we could make our own vocabulary for this?

[beckyjackson]

Currently, there is a mix of skos:exactMatch and skos:closeMatch in core to link to external terms. See https://github.com/rctauber/Experimental-OBO-Core/pull/6

We will use skos:exactMatch for any external terms that are equivalent terms so that we can later add the equivalence axioms.

[beckyjackson]

@cmungall Looking at the matches in the current core-edit.owl file, I see:

Core Term	Exact Match	Exact Match Label
organism	MeSH:D009938	Organizations
organism	biotop:Organ	Organ
organism	CCO:Organization	Organization
organism	SIO:000012	organization
organization	OBI:0100026	organism

I think these are incorrect and should be removed. Maybe Organ can be moved as a skos:closeMatch for 'gross anatomical part'...

Additionally, 'cell' has exactMatch http://purl.obolibrary.org/obo/CL_0000000 - should this be skos:closeMatch instead? The GO cell IRI is not included in the matches, perhaps this should be a close match as well?

[cmungall]

I can redo without the stemming to avoid the junk.

Let's discuss how best to manage this moving forward next week

[bpeters42]

I thought we would be doing this manually? There are a bunch of ontologies that I don't even want to link to / consider in this. I guess a question is what the link is intended to mean: I was thinking it goes to existing terms that we have taken into account when writing definitions.

On Thu, Jul 25, 2019 at 6:33 AM Chris Mungall notifications@github.com wrote:

I can redo without the stemming to avoid the junk.

Let's discuss how best to manage this moving forward next week

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/Experimental-OBO-Core/issues/23?email_source=notifications&email_token=ADJX2IV33PZHJ5INKIDPAATQBGTQ7A5CNFSM4IBVKBO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2ZPMOI#issuecomment-515044921, or mute the thread https://github.com/notifications/unsubscribe-auth/ADJX2IQ2Y6CRQZX3OCIJE5DQBGTQ7ANCNFSM4IBVKBOQ .

-- Bjoern Peters Professor La Jolla Institute for Allergy and Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[cmungall]

Restating some of what was in the archived repo: https://github.com/rctauber/Experimental-OBO-Core/pull/6

There are at least three distinct use cases here, highest priority first:

1. We want to be able to state (using logical axioms if possible) the relationship between a CORE class and an OBO class. Ideally these will eventually be equivalent based on discussions between particular OBO ontologies and core, but in the meantime there will be some that will not be equivalent, so we want to know the logical relationship, reason about implications, etc
2. Similarly, we would like to know the relationship between CORE classes and non-OBO upper ontology classes, e.g biotop, SIO, wikidata, and also schemas like biolink. While this may be lower priority, I would argue this is easy to do, highly informative (we are not the first to make an upper bio ontology) and also potentially useful for buy-in from a larger community
3. We would like to know where we have terminological clashes, where we use a label where another community uses it differently. I strongly think we should avoid the trap many philosophical OBOs fall into of choosing a label which has one meaning for a community, and then applying it to a class that has a more restricted or different meaning.

For 1, these should obviously be manually curated. Becky has done a first pass in #28, and she lists some outstanding questions in that PR

For 2, I am happy to take on this. These should also be manually curated, and will go in a separate file. Not clear if logical axioms or skos is the most appropriate here.

For 3, this was merged in https://github.com/rctauber/Experimental-OBO-Core/pull/6. This is automatic since the whole point is to see where we have clashes. skos is an appropriate vocabulary for this.