Instability of External Ontology Terms (EFO, OBI, etc.)

[ypriverol]

We have recently observed that widely used ontologies such as Experimental Factor Ontology (EFO) and Ontology for Biomedical Investigations (OBI) are evolving rapidly, with terms being frequently deprecated or replaced.

Examples:

• The EFO term for disease (e.g. EFO_0000408) is now deprecated.
• The OBI term used for organism (e.g. OBI_0100026) has also been marked as obsolete.

Problem

This creates a significant persistence and stability issue for our ecosystem:

• Templates become outdated as referenced terms are deprecated.
• Code and pipelines may break when ontology terms are no longer valid.
• Specifications lose validity quickly, requiring constant updates.
• Maintenance overhead increases, as tracking ontology changes becomes necessary.

In short, relying directly on external ontology identifiers introduces fragility into our data model and infrastructure.

Proposed Solution

To mitigate this, I recommend introducing an abstraction layer via a controlled internal ontology, specifically leveraging PRIDE database ontology terms.

Approach:

Define stable PRIDE ontology terms for all core concepts used in templates/specifications:

• organism
• disease
• phenotype
• organism part

etc.

Map PRIDE terms to external ontologies:

• Maintain links to EFO, OBI, and others.
• Include synonyms and cross-references.

Handle external changes internally:

When an external term is deprecated or replaced, update only the mapping/synonyms in PRIDE.
Avoid modifying templates, specifications, or code.

Summary

Instead of directly depending on frequently changing external ontology terms, we should standardize on PRIDE ontology terms as the canonical layer, using mappings to external ontologies for interoperability. This ensures long-term stability while preserving flexibility.

If you want, I can also turn this into a GitHub issue format with acceptance criteria and implementation steps.

[deeptijk]

This highlights a real and growing stability issue.

Frequent changes in EFO/OBI make direct dependencies fragile — breaking templates, pipelines, and specs. An abstraction layer using PRIDE as the canonical ontology is the right approach to decouple from this volatility.

We should centralize and version mappings, automate detection of deprecated terms, and clearly document cross-references.

Strongly support moving this forward — this is key for long-term stability.

[mobiusklein]

Is the proposed solution to copy a snapshot of all the dependent ontologies into the PRIDE ontology, or only the subset of terms that are currently structurally required? In the former case, it's the same as using a specific version of those ontologies, rather than leaving them always tied to the "latest" version.

If you copy the ontologies in, you do have more control than a pinned dependency, in that you can choose to update only parts of the ontology without having to accept everything, but you also are responsible for ingesting all new terms too. That may be a periodic burden if those new terms become structural for SDRF but my impression is that it's just the root terms that matter, and that most of what should be changing is adding new children.

Does this prevent writers from including terms from other ontologies that have not been copied into the PRIDE ontology?

[ypriverol]

Hi @mobiusklein:

Thanks for your comments; what Im proposing is not importing in PRIDE terms that are in other ontologies because that will replicate the problem; as soon as the term is obsolete, it will also be in PRIDE. My recommendation is to create a new term like:

PRIDE:00000X 
name: .....
synonym: .... 

Example:

[Term]
id: PRIDE:0000955
name: cell line authentication
def: "Method used to authenticate the identity of a cell line, such as STR (Short Tandem Repeat) profiling, SNP analysis, karyotyping, or isoenzyme analysis." [PRIDE:PRIDE]
synonym: "cell line authentication method" EXACT []
synonym: "authentication method" EXACT []
is_a: PRIDE:0000017 ! Sample description additional parameter

The idea is that we can store some of the definitions in PRIDE ontology independently of what could happen in the "external" ontologies; Im proposing this only for the terms that are in characteristics[term] and comment[term]. The values remain from the given ontologies, supported mainly by the names. This is because by definition, those terms are the ones that has to be supported by ontologies, while the values, even if we lose the ontology term, could be free text and the remapping is easy.

Im mainly talking about: organism; organism part; disease; phenotype; cell type...

For the users that wants to extend the specification, templates we can help them to create the ontology terms in PRIDE, or discuss how stable are the ontology they are selecting.

BTW; this is a massive problem if we start having more data annotated with obsolete terms; using PRIDE, PSI-MS; PSI-MOD are ontologies we actively maintain.

Is the proposed solution to copy a snapshot of all the dependent ontologies into the PRIDE ontology, or only the subset of terms that are currently structurally required? In the former case, it's the same as using a specific version of those ontologies, rather than leaving them always tied to the "latest" version.

If you copy the ontologies in, you do have more control than a pinned dependency, in that you can choose to update only parts of the ontology without having to accept everything, but you also are responsible for ingesting all new terms too. That may be a periodic burden if those new terms become structural for SDRF but my impression is that it's just the root terms that matter, and that most of what should be changing is adding new children.

Does this prevent writers from including terms from other ontologies that have not been copied into the PRIDE ontology?

[nithujohn]

This looks like a good solution to handle frequent ontology changes. Using PRIDE terms as a stable layer should improve consistency.
Maybe we should also think about how to track updates from external ontologies automatically.

[veitveit]

Isn't one of the reasons that EFO is used that proteomics data can be made more compatible with e.g. transcriptomics data? How do they handle this?

Maintaining an ontology that is sufficiently detailed with respect to all categories mentioned above will be hard and I fear the results will be too coarse-grained.

When looking that the EFO release page (https://github.com/EBISPOT/efo/releases), the number of deprecated terms is very small. A larger issue will be changed terms. And these might then just be taken over. With these numbers in front of me, I do not understand the issue.

[ypriverol]

Totally agree @veitveit ; this is not a problem for terms that are values because, for example, if we have a term like cancer, our pipelines/validators can go and pick the term somewhere. The main problem is when we have a template/specification term; we are expecting to be in a given ontology and a link is in place for the user to read what the terms mean. When that happens, if those terms get obsolete, our specification/documentation is also affected in some way.

My proposal is to anchor only those terms in PRIDE ontology; making sure they don't change quite often and responding only to the SDRF specification. They change (if needed) only if the specification change. All those terms will link to the corresponding terms in other ontologies.

[ypriverol]

PR for now to fix; temporarily fix this issue: bigbio/sdrf-templates#23

[magnuspalmblad]

This may not add anything everyone here doesn't already know, but the "best practice" in general is to link to the source ontologies with the version and term IRIs, not copy terms from other ontologies. However, this can cause the problems mentioned above down the road. Maybe this is a bit too cheeky, but if we always keep track of the version of the source ontology that was used in every annotation in every SDRF file, we kick the bucket down the road, or pass the problem on to whomever or whatever AI agent wants to search or integrate the data, including what deprecated terms to include in the search and how to deal with them. We would only allow current terms to be used for new annotations, but would not automatically deal with old annotations with changed or deprecated terms. At least nothing breaks catastrophically this way, but at some point there may be so many terms for the same thing that it becomes difficult to find all the data one wants, at least for a human...

[ypriverol]

I think what we want to anchor is the specification term; like when I'm running a validation on an SDRF; for cell type and the validator says not cell type defined with this accession in EFO; the pipeline/validator doesn't break (real time); the submissions in PRIDE or other tools, just because unannounced we have a term getting obsolete.

If we keep it in the current way, we may need to improve the logic for checking ontology terms to validate for obsolete terms; get a warning until we fixed in the next release, but that will demand extra work. I'm also not in favor of replicating terms; but I think as SDRF proteomics becomes more important and relevant, and we have more projects around, we may need to anchor some of the terms to have control over them.

[noatgnu]

Should we move the validator to use the internal cache as default? We can also add the custom validator only ontology terms in the internal cache.

Since the validator is expected to be able to work offline using its internal cache. There should always been a possibility of deviation to the online lookup service. When using its internal cache, the user will need to record the date of validation for the sdrf document and the version of the pipeline to look back for the correct database. We do provide this as part of the validation hash json or just the version of the release.

It is possible for each new build of the pipeline to automatically create an errata database or txt document with machine readable migration details on removed/obsolete/changed from one version to the next for its internal cache. Knowing which version, we can add a function to the validator to look back through github release document of the version to track the correct term definition on that date and recommend the user to update the document with the more up to date term if the definition had changed to mean something else.

If we are to move to this, we are also expected to release new minor version more frequent to keep a mostly close to the ols. Or decouple the internal cache to be downloaded separately by the user through the api.

[ypriverol]

The problem is that we removed the cache files from the build meaning they are outside; and one of the points from @jpfeuffer which I agree to is that adding all these files inside made the entire container/package really big for no reason.