Proposed obsoletion: IAO:0006011 'may be identical to'

[cmungall]

http://purl.obolibrary.org/obo/IAO_0006011

A annotation relationship between two terms in an ontology that may refer to the same (natural) type but where more evidence is required before terms are merged

Looking at this, and also at the original ticket

• New annotation property - 'may be identical to' #40

It looks like this is for a very specific use case of mapping between terms in the same ontology (i.e candidate merge). This is how it has been used in OBO so far (the only user is FBbt, cc @dosumis @gouttegd). IMO an OMO AP used in only one ontology is an antipattern. We want to encourage unification

However, it looks like OEO have been using this as a mapping predicate between ontologies

• Better alignment with ENVO OpenEnergyPlatform/ontology#636 (comment)

cc @jannahastings

I propose one of the following:

Keep

• IAO:0006011 is retained
• the label is changed to clearly indicate intent (e.g may be identical to term in same ontology or has candidate merge term)
• the definition is modified to avoid philosophical terms like "natural type"
• this is made a subAnnotationProperty of skos:closeMatch
  • or until we resolve Add guidelines for use of skos in OMO #65, at least some kind of annotation property. Maybe a self-describing triple IAO:0006011 skos:closeMatch skos:closeMatch
• more guidance notes are added

Obsolete

The term was added in 2018, pre SSSOM. Arguably the original use case has nothing to do with "mapping" per se (but see comments above), and should never appear in a SSSOM file. However, I feel this is really just a FBbt convention of using closeMatch inter-ontology

If we did obsolete we would give both FBbt and OEO as long as they needed to migrate.

Another way to handle this as a candidate merge (discussed with Damien here: INCATools/kgcl#49)

[gouttegd]

If we did obsolete we would give both FBbt and OEO as long as they needed to migrate.

Maybe I missed something, but migrate to what? skos:closeMatch? Either as an annotation directly on the term, or in an intra-ontology mapping set?

I am not sure that would be appropriate. In FBbt we use that annotation to indicate that two terms may refer to the same thing, but maybe not at all – we are not sure.

skos:closeMatch does not convey this incertitude – nor do any of the predicates in the SKOS vocabulary as far as I know. They all assert that the two terms they are applied to are definitively related.

Using an annotation representing a “proposed KGCL merge operation” would also seem inappropriate, for the same reason: it conveys a degree of confidence that we do not have in the cases where we use IAO:0006011.

So I would personally vote to keep. No objection on renaming it and documenting it better. Not sure about making it a sub property of skos:closeMatch.

[gouttegd]

Then again, if we do use, instead of an annotation, a intra-ontology SSSOM mapping set, then we could use skos:closeMatch coupled with a low confidence score to convey the incertitude.

But then we’d need to make sure that our tools (typically the VFB interface, since most of the cases where IAO:0006011 is used are for neurons) can exploit those mappings and display them appropriately.

[joeflack4]

Just an update from the Slack discussion thread for this:

Nico Matentzoglu
I absolutely think it should be possible! Think of noisy semantic spaces like wikidata or big data swamps with person ids. For ZP it would be super useful. Absolute yes!

Chris Mungall
so would existing skos predicates be good enough for this? Do we need separate intra-ontology predicates?

Nico Matentzoglu
I personally dont think so; adding a separate vocabulary introduces churn that outweighs the benefits of conceptual cleanliiness - but I am happy to be convinced otherwise!

Joe Flack
I agree w/ Nico

[gouttegd]

@joeflack4 I am not arguing against using SSSOM for intra-ontology mappings. I have no objection against that (I see no reason why we could not use SSSOM for intra-ontology mappings).

My concern is about the predicate to use. IAO:0006011 has a given meaning (conveying the fact that two terms may, or may not, be redundant) that skos:exactMatch does not have, hence my reluctance to use it as a replacement for IAO:0006011. This is orthogonal to the question of whether we use it as an annotation property directly within the ontology or as a mapping predicate in a SSSOM mapping.

[joeflack4]

Oh, sorry. Chris asked me to add our comments to the issue; but I didn't even look at what the issue was about.

I haven't given thought to that yet (I don't think Nico has either). Will take a look tomorrow.

[jannahastings]

However, it looks like OEO have been using this as a mapping predicate between ontologies

* [Better alignment with ENVO OpenEnergyPlatform/ontology#636 (comment)](https://github.com/OpenEnergyPlatform/ontology/issues/636#issuecomment-2083342497)

cc @jannahastings

Looping in @stap-m for the OEO, as I am not so much involved in OEO at the moment.

[joeflack4]

After finally reading this, I mostly agree with @gouttegd. I lean towards keeping IAO:0006011, 'may be identical to', if it we think it has good current or future potential utility. If not, then I favor obsoletion, though we would lose expressivity if using something like skos:closeMatch instead.

If it is kept, then, along with @gouttegd, I disagree with the suggestion of "IAO:0006011 subAnnotationProperty skos:closeMatch" for reasons he stated.

If it is obsoleted, then I like @gouttegd's suggestion of using skos:closeMatch coupled with a low confidence score when using SSSOM.

Sidebar on "intra ontology":
I don't see the point in denoting "intra ontology" versus not for a mapping predicate that means to express "may be identical to". Indeed I wonder if there is any such predicate where it is useful to have "intra ontology" as a qualification. But, for practical purposes, I'm not about to suggest we introduce a new term that drops "intra ontology" and obsolete IAO:0006011 in favor of such.

[matentzn]

Another quick fix to the documentation issue would be to add some instructions to the terms description to not use it to refer to a term from another ontology. Either way, I think we dont need to be so prescriptive here as to remove it entirely - it is enough to clarify what its intended use is, and imo its intended use is to say: "in the future these terms could be merged". So basically this is like a "consider replacement" before the term has been obsoleted.

[dosumis]

I'm glad this thread reminded me of this AP. I think it will be v.useful in upcoming work on CL. We have an increasing number of cases where we have some evidence that two CL terms identified via different modalities may refer to the same cell type, but there is enough uncertainty/controversy that we don't want to merge, at least until we have more evidence. It is useful for editors and users to be able to track these.

[stap-m]

However, it looks like OEO have been using this as a mapping predicate between ontologies

• Better alignment with ENVO OpenEnergyPlatform/ontology#636 (comment)

Thanks for considering the usage in OEO. Based on this discussion, OEO is planning to replace IAO:0006011 with skos:closeMatch.