bigbio/proteomics-sample-metadata

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

Open

#814 opened on Mar 20, 2026

View on GitHub
 (13 comments) (1 reaction) (0 assignees)HTML (115 forks)auto 404
Specificationenhancementhelp wantedquestion

Repository metrics

Stars
 (113 stars)
PR merge metrics
 (PR metrics pending)

Description

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.

Contributor guide