IRI gaps in CCO

[michaelrabenberg]

I recently noticed that in the IRI mapping file that was released with v2.0, there are 4 "missing" IRIs. (I put "missing" in scare quotes because there needn't be any problem here, and in fact I assume there isn't. I just wanted to flag the fact to see if there could have been a mistake.) Here's the mapping file:

https://github.com/CommonCoreOntology/CommonCoreOntologies/blob/develop/documentation/mapping-new-iris/iri-mapping-v2.0.csv

In one column are the old, readable IRIs, and in the adjacent column are the new, opaque IRIs that replaced them. IRIs ending in the following four numbers are not present in the opaque IRI column, despite the fact that the numbers appear in ascending order and otherwise always increase by 1:

--1736
--1750
--1751
--1755

So, for example, if you go to lines 1736 and 1737 of the file, you'll notice that the opaque IRIs jump from 1735 to 1737. I also checked the v2.1 merged file and couldn't find any of the four "missing" IRIs in it.

I wanted to flag this in case there was any possibility that four readable IRIs failed to get mapped to opaque IRIs. I assume that's not what happened, that every readable got mapped to some opaque, and that the four "missing" opaques just weren't used. But I thought double-checking would be in order.

[PhiBabs935]

I noticed the IRIs between these are all for ERO annotation properties.

Prior to 1.7, CCO curated the annotation properties:

                     > "definition", "alternative label", "example of usage", and "elucidation". 

Which were replaced by the corresponding skos:core annotation properties (elucidation > ScopeNote) in 1.7

So, this is a guess, but maybe these gaps correspond to those 4 deprecated properties?

This doesn't answer why there is the gap, but it may be relevant...

[APCox]

I think Shane is correct that this is a case of terms being deprecated. That said, we should maintain better records to track this sort of thing. Doing so should help prevent unintentional reuse of deprecated IRIs in the long run.

@michaelrabenberg will it adequately resolve the issue to update the IRI table to include these 4 IRIs and add a "Status" column to mark them as "Deprecated"?

[shanmukhkalasamudram]

@michaelrabenberg — thanks for flagging this. I looked into it, and it appears there's no problem: those four IRIs (ont00001736, 1750, 1751, 1755) were never assigned, so nothing was lost.

What I checked:

IRI registry — in the master registry (iri-registry.csv), those four numbers have no reservations, and they are the only gaps in the entire 1730–1760 range. If a mapping had simply been dropped, the registry would still show the number reserved against a name.
Commit history and releases — they do not appear in any commit, nor in any merged file (current or the archived v1.3–v1.5).

The four gaps correspond to the annotation properties deprecated in v1.7 (as @PhiBabs935 noted). They all fall within the ExtendedRelationOntology annotation-property block, and the timeline is consistent: v1.7 (2024-11-03) deprecated exactly four annotation properties (cco:definition, alternative_label, elucidation, example_of_usage, replaced by their SKOS equivalents); the readable→opaque migration (Full rename) followed on 11/4; and the mapping was created on 11/5 already containing these four gaps. So the deprecated properties were never part of the opaque-ID assignment.

Tagging you to confirm this matches what you observed.

CC: @johnbeve

[michaelrabenberg]

I think Shane is correct that this is a case of terms being deprecated. That said, we should maintain better records to track this sort of thing. Doing so should help prevent unintentional reuse of deprecated IRIs in the long run.

@michaelrabenberg will it adequately resolve the issue to update the IRI table to include these 4 IRIs and add a "Status" column to mark them as "Deprecated"?

If that's what happened, yes, that'd definitely resolve the issue, in my view.

Thanks to you all for looking into this.