Biomedical Knowledge Composition: A Software Engineering Perspective

Biomedical Knowledge Composition: A Software Engineering Perspective Natallia Kokasha,1 , Adam S.Z. Bellouma,2 , Paola Grossoa,3 a Institute of Informatics, University of Amsterdam, The Netherlands

arXiv:2608.08927v1 [cs.SE] 9 Aug 2026

Abstract Biomedical research has accumulated extraordinary molecular, clinical, and population data, yet translating this wealth into actionable knowledge remains severely constrained by technical and organizational difficulties. This article presents a unified treatment of two complementary perspectives on biomedical knowledge infrastructure. The first perspective introduces the biomedical domain to software engineers: it explains why knowledge graphs (KGs) are the central integrative data structure in modern biomedicine, characterizes five core data harmonization challenges (identifier mapping, entity resolution, schema alignment, evidence integration, and provenance tracking), surveys principal application domains from drug discovery to digital twins, and profiles six representative KG systems with contrasting design choices. The second perspective asks why engineering biomedical knowledge infrastructure remains so difficult. We argue that a contributing root cause is limited adoption of software tooling and practices that make development in other mature domains—particularly web engineering—reliably composable and reproducible: package management, typed namespaces, canonical interchange formats, service composition protocols, reproducible pipelines, and lifecycle governance. Against this backdrop, eight open engineering challenges for biomedical data integration are catalogued, each with partial solutions but no universally adopted stack yet assembled. Crucially, the article shifts emphasis from describing deployed KG instances toward the reproducible process of assembling them: reusable build pipelines, versioned dependencies, and engineering practices that let others compile and customize a KG from source rather than consuming a static artifact. Together, the two perspectives provide domain grounding for newcomers and a research agenda for software engineers seeking to make transformative contributions to biomedical knowledge infrastructure. Keywords: biomedical knowledge graphs, data harmonization, software engineering, reproducibility, FAIR data, knowledge infrastructure

1 ORCID:0000-0003-3639-1245 2 ORCID:0000-0001-6306-6937 3 ORCID:0000-0003-4600-9812

Preprint submitted to Data Intelligence

August 11, 2026

1. Motivation: Why Biomedical Knowledge Graphs? Biomedicine has undergone an irreversible transition into a data-intensive science. Large-scale initiatives—the Cancer Genome Atlas (TCGA) [1], the UK Biobank, the Human Cell Atlas (HCA) [2], and the Clinical Proteomic Tumor Analysis Consortium (CPTAC)—have produced datasets of extraordinary depth. Simultaneously, decades of curation have produced thousands of specialized databases: gene function repositories (Gene Ontology [3], UniProt [4]), pathway databases (KEGG [5], Reactome [6]), drug–target catalogues (DrugBank [7], ChEMBL [8]), variant archives (ClinVar [9], COSMIC [10]), and phenotype ontologies (HPO [11], MONDO [12]). The biomedical knowledge base is vast; the problem is that it is fragmented. Each database was built independently, optimized for a specific domain, and operates under its own data model, identifier namespace, evidence standard, and update cycle. A researcher asking “which genes mutated in this patient’s tumor are known drug targets, and which drugs are currently in clinical trials?” must query at least five separate databases, resolve synonyms, map between incompatible identifiers, and adjudicate conflicting evidence—a process that is slow, error-prone, and not reproducible at scale. Knowledge graphs (KGs) address this fragmentation by representing biological entities and their relationships in a single, traversable graph structure where: nodes represent biological entities (genes, proteins, drugs, diseases, pathways, cell types); edges represent typed, directed relationships (causes, treats, interacts with, expressed in); and properties on nodes and edges carry quantitative attributes and provenance metadata. Once integrated, a KG enables multi-hop graph traversals crossing biological layers, graph-based machine learning over heterogeneous types, and automated reasoning over curated ontological relationships [13]. These capabilities underpin applications from drug repurposing and clinical decision support to mechanistic process modeling and digital twins. However, realizing this potential depends on solving a difficult upstream problem: data harmonization. Before heterogeneous biomedical data can be loaded into a KG, it must be cleaned, standardized, deduplicated, and semantically aligned. 2. The Scope of Biomedical Data Harmonization Data harmonization in biomedicine operates across multiple dimensions simultaneously (Figure 1): • Batch effects arise from technical variability in data generation—differences in laboratory protocols, sequencing platforms, or imaging scanners—that introduce systematic biases unrelated to the biological signal. Statistical correction methods (ComBat, Harmony, scVI) address platform variability, but require careful design to avoid removing biological variation alongside technical artifacts. • Modality heterogeneity refers to the challenge of integrating fundamentally different data types—omics measurements, medical images, physiological signals, and clinical records— that differ in dimensionality, scale, and statistical properties. • Semantic heterogeneity covers inconsistencies in metadata, terminology, and data representation across datasets and institutions. Different ontologies and coding standards (ICD10, SNOMED CT, HPO, OMIM) prevent datasets from being directly combined. 2

Figure 1: Taxonomy of biomedical data harmonization challenges spanning four orthogonal problem categories: batch effects, modality heterogeneity, semantic heterogeneity, and cross-study integration.

• Cross-study integration is required when datasets come from multiple cohorts and institutions with different patient populations, experimental designs, and sampling strategies. Figure 2 illustrates how these challenges manifest across two related but distinct engineering workflows: KG construction and management (left) and model assembly from knowledge graphs (right). While both workflows involve data integration, harmonization, validation, and versioning, they differ substantially in scope, objectives, maintenance practices, and tooling requirements. KG construction focuses on building and maintaining a broad knowledge infrastructure intended to capture as much relevant domain knowledge as possible from heterogeneous sources such as hospitals, laboratories, publications, and repositories. The resulting graph is designed to support multiple downstream applications rather than a single targeted use case. This process typically requires a major initial community effort involving ontology mapping, schema design, normalization, storage infrastructure, APIs, and user-facing services. However, long-term maintenance often becomes problematic: resources may lose active support over time, or remain curated only by closed expert groups with limited mechanisms for community feedback, collaborative editing, bug reporting, or external contributions comparable to open-source software ecosystems. As a result, the produced KG may not be optimized for the requirements of specific downstream modeling tasks despite its broad coverage. In contrast, model assembly targets a specific scientific or analytical objective and therefore relies on selective extraction and integration of only the data relevant to that purpose. Instead of constructing a comprehensive graph, developers repeatedly investigate multiple KGs, datasets, and measurement repositories to curate smaller task-specific subsets. Although harmonization occurs at a smaller scale, it becomes a recurring and labor-intensive activity because each new model may require different combinations of sources, dependencies, and annotations. This workflow is characterized by rapid iteration and frequent generation of model variants. Unlike large KG initiatives, model developers often lack centralized coordination, common annotation standards, documentation guidelines, or dedicated data stewardship expertise. Consequently, many assembled models remain insufficiently documented and difficult to make fully FAIR and reusable. 3

Figure 2: Engineering pipelines for KG-based biomedical knowledge infrastructure. Left: KG construction and management pipeline. Right: Model assembly pipeline selecting and integrating data from multiple KGs and omics sources.

3. Core Challenges in Biomedical Data Harmonization Data harmonization encompasses five interdependent challenges: identifier mapping, entity resolution, schema alignment, evidence integration, and provenance tracking. Table 1 provides an overview; the following subsections describe each challenge with standard mitigations and remaining open issues. Table 1: Five core biomedical data harmonization challenges. Challenge

Core Problem

Current Mitigation

Identifier Mapping

Same entity, multiple namespaces

HGNC, BioMart, Ensembl REST, Bioregistry CURIEs

Entity Resolution

Same concept, no shared ID

MONDO, ChEBI, EFO, embedding-based fuzzy matching

Schema Alignment

Heterogeneous data models

Biolink Model, RO, OWL ontologies

Evidence Integration

Contradictory / multi-source claims

OpenTargets scoring, confidence weights, retraction tracking

Provenance Tracking

Untraceable node/edge origin

PROV-O, Biolink knowledge source properties

3.1. Identifier Mapping The most pervasive harmonization problem is identifier heterogeneity. Every major database assigns its own identifier to each biological entity. A single human gene— TP53—carries at least six common identifiers simultaneously: HGNC:11998, ENSG00000141510 (Ensembl), 7157 (NCBI Entrez), P04637 (UniProt), NM 000546 (RefSeq), and 191170 (OMIM). When TCGA mutation 4

data (Entrez IDs), KEGG pathway data (Ensembl IDs), and DrugBank drug–target data (UniProt accessions) are loaded into the same KG without resolution, TP53 appears as three separate, unconnected nodes—and all multi-database graph queries through this gene will fail silently. Identifier spaces also evolve: Ensembl retires gene IDs on annotation updates; HGNC symbols change; RefSeq accession version numbers increment. A KG built from data downloaded at different times may contain phantom duplicates. Liftover tools handle genomic coordinate versioning, but no equivalent automated tool exists for all identifier types, requiring explicit version-pinning in KG construction pipelines. Current solutions. HGNC symbols [14] are recommended as human-readable node labels with HGNC IDs as stable primary keys. BioMart, the Ensembl REST API, and the UniProt ID Mapping service provide cross-reference tables. The Bioregistry and Identifiers.org maintain canonical CURIE prefix registries (e.g., hgnc:11998) [15] enabling namespace-aware deduplication. 3.2. Entity Resolution Entity resolution handles the harder case: determining whether two records refer to the same real-world entity when no shared identifier is available. This problem is most severe for disease and chemical entities. A single disease concept may appear as breast carcinoma (NCIt:C4872), breast cancer (OMIM:114480), malignant neoplasm of breast (ICD-10:C50), and Breast Neoplasms (MeSH:D001943). Without resolution, these become four disease nodes, and queries connecting drugs to “breast cancer” will miss edges from all other representations. Entity resolution errors are asymmetric in consequence: false splits produce redundant nodes and incomplete subgraphs; false merges introduce factually incorrect edges that propagate throughout downstream queries and ML models. The Mondo Disease Ontology (MONDO) [12] was designed to address this, merging terms from OMIM, Orphanet, NCIt, DOID, and MeSH into a unified hierarchy. Ontology-grounded resolution using MONDO, EFO [16], and HPO [11] substantially reduces false merge rates compared to string-similarity heuristics alone. Modern semantic mapping methods [17, 18] further assist dataset entity resolution. Despite the availability of ontologies, the community currently lacks a scalable collective mechanism for propagating discovered errors back into canonical resources. Ontologies are maintained by small curatorial teams on grant cycles; AI-assisted agents capable of continuously inspecting entity resolution quality and proposing corrections at scale represent a promising direction, but require community governance frameworks not yet broadly established. 3.3. Schema Alignment Even after identifiers are resolved, source databases model the same biological reality using heterogeneous schemas. A drug–protein relationship may be a directed edge in DrugBank, a TSV row in ChEMBL, or a linked-data triple elsewhere. Beyond structural differences, sources differ in the granularity at which they model the same concept: KEGG [5] pathway annotations operate at the gene level; Reactome [6] at the protein isoform level; STRING [19] interaction scores aggregate multiple evidence types into a single weight. Granularity mismatches that are not explicitly modeled produce semantic violations invisible to query engines. Current solutions. The Biolink Model [20] is the most widely adopted standard for biomedical KGs, defining 60+ node types and a controlled predicate vocabulary. In practice, most large KGs define bespoke extensions that diverge from any single standard, and no schema has achieved 5

universal adoption. AI-assisted schema mapping agents [21, 22] represent an emerging path to reducing manual overhead. 3.4. Evidence Integration and Conflict Resolution Biomedical knowledge is probabilistic and evolves. ClinVar may classify a variant as “Pathogenic” while a newer study reclassifies it as “Likely Benign.” Evidence integration formalizes the combination of multiple evidence streams into confidence-weighted edges. The OpenTargets Platform [23] exemplifies this, computing association scores for gene–disease pairs by integrating genetic, somatic, molecular, pathway, and text-mining evidence—each with a calibrated weight. A KG built by ingesting sources at different times will contain temporally inconsistent information. Without versioned provenance recording the source database version and download timestamp for every edge, it is impossible to audit or reproduce query results, and stale edges silently corrupt downstream analyses. 3.5. Provenance Tracking Provenance records the full lineage of every node and edge: source database, version used, download timestamp, transformation pipeline, and supporting evidence. Provenance is a functional requirement for reproducibility, auditability, update management, and confidence weighting. The W3C PROV-O ontology [24] and the Biolink primary knowledge source property pattern [20] provide standard frameworks. In practice, many published biomedical KGs omit fine-grained provenance due to engineering complexity, which limits their utility in clinical and regulatory settings. 4. Applications of Biomedical Knowledge Graphs Biomedical KGs are infrastructure for downstream applications. Understanding the intended application is essential for correct KG design: which node types to include, which evidence thresholds to apply, how to model uncertainty, and what query patterns to optimize. Drug Discovery and Target Identification. The pipeline from target identification to approved drug takes 10–15 years at costs upwards of $2 billion [25], with a clinical trial failure rate exceeding 90% [26]. KGs enable multi-evidence target scoring integrating genetic, functional genomic, molecular, and clinical evidence into ranked candidate targets [23]. Drug repurposing [27] identifies new indications for approved drugs by finding graph paths connecting a known drug, via shared mechanism, to a new disease. Precision Oncology and Patient Stratification. KGs support patient stratification by aggregating somatic mutation data [10, 1], drug sensitivity profiles, and clinical outcome data into a unified structure. Tools such as OncoKB [28] serve as knowledge backbones for Molecular Tumor Board platforms. Biomedical Digital Twins. A biomedical digital twin is a computational model of an individual patient updated with clinical measurements and used to simulate disease progression in silico [29, 30]. KGs serve as the biological knowledge substrate: patient-specific omics measurements are overlaid onto the KG’s relational structure, and mechanistic simulation engines use KG topology to define model structure. 6

Mechanistic Process Modelling. KG-derived pathway structures serve as the basis for mathematical models of biological processes: ODE systems, Boolean network models of cell-fate decisions [31], and flux balance analysis of metabolic networks. Integrating context-specific omics data to condition pathway topology on cell-type context is an active research area. Clinical Decision Support and Translational Research. KG-powered clinical tools can flag sequenced tumor variants as clinically actionable, suggest targeted therapy, and retrieve relevant clinical trial numbers. The EMBL-EBI Open Targets Platform [23] and the NCATS Translator [32] are leading public implementations. Epidemiology and Population Genomics. KGs integrate GWAS results [33, 34] with EHR data and environmental exposure measurements to model complex diseases. KG infrastructure enables automated phenome-wide association studies (PheWAS) by providing a pre-integrated graph of variant–phenotype association edges. 5. Representative Biomedical Knowledge Graphs This section profiles six representative KGs to illuminate design trade-offs in their construction pipelines. The key question is: how was each assembled, and can that process be reproduced and adapted? Table 2 summarizes the six systems across four dimensions. Table 2: Six representative biomedical knowledge graphs: scale, primary identifier namespaces, pipeline reproducibility, and key limitations. KG

Purpose and scale

Identifier namespaces

Pipeline reproducibility

Key limitations

Hetionet [35]

Drug repurposing; ≈47K nodes (11 types), 2.25M edges (24 types); Neo4j + TSV/JSON

HGNC (genes), DrugBank (compounds), DOID (diseases)

29 source-specific Python ETL scripts are publicly versioned; pipeline can be re-run against pinned source versions

Static snapshot; no update mechanism; no fine-grained edge provenance; disease taxonomy predates MONDO

NCATS Translator KG2 [32]

Translational research reasoning; >6M nodes, >100M edges from ≈70 databases; served via ARAX/TRAPI

Biolink-compliant CURIEs throughout; cross-source merging via SRI Node Normalizer

Fully automated, publicly available build pipeline (JSON-Lines ETL modules); designed for periodic re-runs with updated sources

Full-graph ML training computationally expensive; quality varies across 70+ automated sources

Open Targets [23] Evidence-scored gene–disease–drug associations for drug discovery; ≈61K genes, 23K diseases, 16K drugs

Ensembl (genes), EFO (diseases), ChEMBL/DrugBank (drugs)

Open-source Apache Spark pipeline regenerates data each release; Parquet files and GraphQL API publicly downloadable

Schema specialised to target–disease–drug triangle; non-human biology excluded

Monarch Cross-species MONDO (diseases), Initiative [36, 37] phenotype–genotype integration HPO/MPO/ZP for disease gene discovery; (phenotypes), Biolink millions of gene–phenotype edges predicates from >30 sources

KGX interchange format; cross-species similarity edges computed by OBO ontological reasoning; build process publicly documented

Variable completeness of model-organism phenotype annotations; cross-species mappings are approximate

Reactome [6]

Manually curated biochemical UniProt (proteins), pathways; ≈14K proteins in ChEBI (small 2,600+ pathways, ≈13K reactions molecules); publication-level provenance per reaction

Curated Neo4j + RDF/OWL export; graph topology (PhysicalEntity→Reaction →Pathway) directly usable as mechanistic model wiring

Coverage limited to reactions with published experimental evidence; slower update cycle than automated databases

PrimeKG [38]

ML-ready precision medicine KG; ≈129K nodes, 4.05M edges (30 relation types); designed for GNN training [39]

Flat CSV edge lists + node feature Static 2022 snapshot; limited tables; reproducible from public provenance metadata; not sources; includes train/val/test validated for clinical splits and pre-computed node deployment features

MONDO (diseases), DrugBank (drugs), NCBI Entrez (genes)

7

The profiles collectively illustrate a spectrum of pipeline reproducibility. Hetionet and NCATS KG2 publish full ETL pipelines under open licences; Open Targets operationalises this further through a versioned build system re-executed from scratch each release cycle. PrimeKG occupies a middle position: distributed as static CSV files, it is nonetheless reconstructible because every upstream source is publicly accessible. Reactome and Monarch publish curated exports without an automated reconstruction path, reflecting the irreducible cost of expert curation. From these examples we draw a general observation: pipeline transparency is as consequential as data availability. A fully reproducible build makes schema changes, source updates, and provenance queries tractable engineering tasks; an opaque export shifts that burden entirely onto the downstream consumer. We treat pipeline reproducibility as a first-class design criterion and draw design principles elaborated below. 6. Design Principles for Harmonization-First KG Construction Several cross-cutting principles emerge for engineering teams building new biomedical KGs: 1. Choose canonical identifier namespaces before writing any ETL code. Retrospective identifier normalisation is expensive and error-prone. Establish the primary key namespace for each node type (HGNC for human genes, MONDO for diseases, DrugBank for drugs, UniProt for proteins) before ingesting any source. 2. Use a standardized data model as your schema contract. A stable, community-maintained schema provides a shared vocabulary enabling interoperability with minimal integration effort. The Biolink Model [20] is one such approach; the principle applies to any welldocumented, recognized data model. 3. Treat provenance as a first-class data requirement. Every element must be linkable to the source and source version properties. This is hardly optional metadata; it is the foundation of reproducibility and auditability. 4. Design for update, not for snapshot. Build ETL pipelines that are idempotent and sourceversion-aware so that incremental updates can be re-ingested without full graph reconstruction. 5. Prioritize the assembly pipeline over the deployed artifact. A versioned, documented build pipeline that others can run to assemble a comparable KG from source provides far more scientific value than a static deployed instance that cannot be reproduced, customized, or updated. The dominant trend in large-scale KG development is a shift toward virtualization and federated access, driven by the practical difficulty of centralizing the volumes of data involved. iKraph processes over 34M PubMed abstracts across 40 public databases, yielding more than 10M unique entities and 30M relations [40]. PrimeKG integrates 20 resources characterizing over 17,000 diseases via more than 4M relationships [38]. The Louisiana Tumor Registry KG spans 25 billion RDF triples (∼4 TB) [41, 42]. At this scale, strict schema enforcement becomes computationally prohibitive, and best-effort semantics replace strict correctness [42]. Federated querying across heterogeneous KGs is a key composition mechanism. QLever [43] provides a high-performance SPARQL engine for very large RDF datasets; the dblp KG demonstrates cross-graph composition via QLever-powered federated SERVICE clauses [44]. The Data 8

Distillery KG harmonizes over 180 ontologies into a unified, queryable environment [45], and the Petagraph framework scales this vision further, unifying billions of biomedical entity relationships [46]. However, large-scale harmonization efforts often suffer from reproducibility limitations. As a concrete illustration from our own experience attempting to reuse the Data Distillery KG, we encountered three recurring obstacles: • Redeployment: The KG is distributed as a Docker container running a fixed-version Neo4j image. Academic HPC centres often prohibit standard Docker deployments due to rootprivilege requirements. We were forced to manually extract KG files from the container—a non-trivial process due to format changes between Neo4j versions. • Poor discoverability: The schema consisted of a single node label Concept with around 1600 distinct relationship types, with data provenance encoded as a node property. Absent indexes made many queries run excessively long or not complete. • Incomplete coverage: In attempting to reproduce a multi-hop query connecting disease phenotypes to compounds via gene regulation, we found that the harmonization effort covers only portions of the underlying datasets. The dozens of integration scripts are not consolidated into a reusable build pipeline [47]. These obstacles are not unique to Data Distillery; similar friction has been reported across largescale biomedical KG projects [48, 49, 50], suggesting they reflect structural properties of the problem rather than implementation deficiencies of any single system. One architectural response is the federated, ontology-based data access (OBDA) paradigm, which creates a unified query layer over disparate sources without physical data centralization. The NCATS Translator, Monarch Initiative, and Biolink Model exemplify this approach at scale [51, 20]. However, federation shifts rather than eliminates the harmonization burden. In practice, these projects rely on heterogeneous harmonization mechanisms with distinct reproducibility profiles: manually curated mappings and crosswalks that require sustained maintenance; statistical batch-correction methods that are deterministic under fixed inputs but sensitive to parameters and reference cohorts; bespoke transformation scripts that are rarely reusable; and increasingly, LLM- and AI-agent-based approaches for entity resolution and schema mapping [22, 21]. The latter introduces additional methodological concerns. LLM outputs are stochastic, model weights evolve on vendor-controlled schedules, inference behavior changes across versions, and the provenance of harmonization decisions is difficult to audit or reproduce independently. Consequently, the harmonization layer of large biomedical KGs is not a fixed artifact but a living, partially opaque process, with direct implications for reproducibility and long-term maintainability. 7. The Engineering Maturity Gap A software engineer joining a new web project in 2026 will typically encounter a highly standardized development workflow. Dependency specifications are commonly maintained in files such as package.json or pyproject.toml, enabling automated installation of versioned software 9

packages. Continuous integration pipelines routinely execute test suites, while documentation can often be generated directly from source code annotations and typed interfaces. In contrast, constructing a knowledge graph (KG) for a precision oncology application requires the integration of data from multiple independently maintained biomedical resources. Relevant datasets may include protein structure predictions from AlphaFold, bioactivity measurements from ChEMBL, gene dependency data from DepMap, somatic mutation profiles from TCGA, and pathway information from Reactome. These resources are distributed across separate platforms and frequently differ in access methods, file formats, identifier systems, metadata conventions, and release schedules (Table 3). As a result, data integration typically relies on substantial manual effort to harmonize identifiers, reconcile schema differences, track provenance, and accommodate changes introduced by upstream data providers. Unlike software package ecosystems, there is generally no unified mechanism for dependency management, semantic versioning, or automated detection of schema-level changes across the collection of resources used in a KG construction pipeline. This contrast reflects a genuine difference in tooling maturity. Web development accumulated its infrastructure over decades of incremental investment by practitioners sharing common problems on public platforms. Biomedical data engineering is a younger and more fragmented discipline in which large consortia tend to build bespoke pipelines rarely abstracted into reusable tooling [50]. The consequence is that significant scientific value is locked behind brittle and largely irreproducible data engineering work [52]. The analogy is imperfect—biomedical data curation involves domain expertise and curatorial judgment that generalizes less readily than software logic—but the engineering infrastructure gap is real. Table 3: Representative data sources for a targeted cancer KG, illustrating format and access heterogeneity. Data Source

Description

Formats

Access

Size

Metabolomics WB

Metabolite concentrations across studies

mwTab, .csv, .json

Download / API

1 GB

DepMap / Achilles

CRISPR essentiality, CNV, expression

.csv, .hdf5

Download / API

10 GB

Human Protein Atlas

Protein/RNA expression by tissue and cell

.tsv.zip, .csv

Download

5 GB

STRING / BioGRID

Protein–protein interactions

.tsv, .mitab, .xml

Download / API

30 GB

ChEMBL

Bioactive molecules, assay activities

.sdf.gz, .tsv, MySQL

FTP / API

35 GB

GTEx

eQTL data, RNA-seq matrices per tissue

.txt.gz, .gct, .vcf

Download / API

50 GB

AlphaFold Proteome

Predicted 3D protein structures

.pdb, .cif, .tar

FTP

25 TB

TCGA / GDC

Tumour multi-omics: MAF, RNA-seq, methylation

.tsv, .maf, .bam

Gated API

2.5 PB

8. SE Challenges in Biomedical Knowledge Infrastructure Software engineering practices have a critical yet under-appreciated role in biomedical research; below we list challenges which, if addressed, could make building and consuming biomedical KGs a less daunting engineering task. 8.1. SE Challenge 1: No Package Manager for Biomedical Data Sources In a typical Web engineering project, a Node.js developer writes npm install react@18.2.0 and receives a versioned, dependency-resolved, integrity-hash-verified module tree in seconds. 10

A bioinformatician ingesting TCGA RNA-seq data must write custom FTP download scripts, manually track which GDC data release was used, and rely on informal documentation to detect schema changes. Modern package ecosystems (npm, pip, Cargo) provide four capabilities largely absent from the biomedical data landscape: semantic versioning contracts (MAJOR.MINOR.PATCH with welldefined compatibility guarantees); dependency resolution; integrity verification (cryptographic hashes); and centralised registries. Biomedical databases publish releases rather than packages. A TCGA data release has no semantic version number, no changelog, no formal contract specifying which schema parts were updated, and no mechanism to alert downstream consumers when a field has been renamed or deprecated. Partial solutions. The Bioregistry [15] maintains a controlled vocabulary of identifier namespaces. The NCATS Translator’s SRI Node Normalizer provides cross-namespace entity resolution for a subset of entity types. The BioCypher framework [53] moves toward structured adapter-based KG construction, but stops short of full version-locked dependency management. Open problem: biomedical data package manager

A complete biomedical data package manager requires: (1) a canonical versioning scheme for database releases; (2) a manifest format for declaring data dependencies with version constraints; (3) a registry of published data packages with integrity hashes; and (4) a resolver that satisfies dependency declarations while enforcing identifier namespace compatibility. 8.2. SE Challenge 2: Identifier Namespaces Without Type Enforcement In a typical Java project, com.google.guava.collect.ImmutableList is unambiguous regardless of what other libraries define a class called ImmutableList: the fully qualified name is the contract. In biomedical KGs, TP53 may simultaneously appear as an HGNC gene symbol, an NCBI Gene label, a UniProt gene name, and a COSMIC cancer gene reference within the same graph, often without fully reliable automatic namespace disambiguation. The Biolink Model [20] addresses identifier heterogeneity via CURIEs (e.g., hgnc:11998, uniprot:P04637): the prefix identifies the namespace, and the local part identifies the entity within it. The SRI Node Normalizer maps equivalent CURIEs to a single canonical identifier. For human genes, proteins, and a growing subset of diseases, CURIE-based resolution is functional. For the long tail— metabolites, imaging features, cell lines—coverage is patchy. Critically, there is no equivalent of a linker error: a pipeline that joins tables on mismatched identifier namespaces fails silently, producing a KG that looks syntactically correct but would come semantically corrupt. Open problem: namespace type safety

A system in which namespace types are first-class objects in the pipeline language, so that joining ensembl:ENSG* with ncbigene:* identifiers produces a compile-time type error rather than a silent semantic failure. The OMOP CDM enforces coding system constraints at the schema level, but no general-purpose biomedical pipeline framework en11

forces namespace type safety end-to-end. 8.3. SE Challenge 3: Format Heterogeneity and the Absent Canonical Intermediate Representation A targeted cancer KG assembly project may need to integrate a dozen structurally incompatible formats, including FASTA, VCF, MAF, mzML, HDF5, .mcool, mwTab, PSI-MI XML, OBO, and plain TSV—each encoding different assumptions regarding coordinate systems, measurement units, reference genome versions, metadata conventions, and identifier namespaces. This situation resembles pre-standardization phases in other engineering disciplines, although biomedical data formats additionally encode domain-specific semantics that resist purely syntactic normalization. A canonical intermediate representation (CIR)—a unified internal schema or exchange model into which ingestion adaptors transform heterogeneous inputs—is standard in compiler engineering (LLVM IR) and ETL systems. Candidate solutions exist at multiple layers of the stack: the Biolink Model at the semantic schema layer; RDF/Turtle and JSON-LD [54] at the representation layer; and SHACL [55] at the validation layer. The KGX format provides a TSV-based serialization for Biolink-typed nodes and edges, while BioCypher [53] formalises source adaptors as reusable typed components. Open problem: validated graph interchange specification

A specification combining: (1) a Biolink-typed node and edge schema; (2) a SHACL constraint layer expressing biological integrity rules; (3) a PROV-O provenance subgraph; and (4) an identifier namespace declaration per node type. This could enable automated KG assembly pipeline validation and compliance checking in CI/CD. 8.4. SE Challenge 4: Model Format Proliferation Biomedical mechanistic models are described in a proliferation of domain-specific languages designed for expressiveness within their domain but not for interoperability with each other or with KGs (Table 4). A researcher assembling a digital twin of a cancer cell needs pathway topology from Reactome (Neo4j/RDF), kinetic parameters from BioModels (SBML), protein– protein interaction evidence from STRING (TSV/MITAB), and gene expression context from GTEx (HDF5 matrices)—incompatible data models, identifier namespaces, and computational frameworks. The COMBINE archive coordinates across SBML/CellML/SED-ML/BioPAX, and the OMEGA framework [56] provides semantic harmonization across model DSLs, but no universal modelling language spanning relational KG and dynamic model behaviour has achieved consensus. 8.5. SE Challenge 5: Service Composition Beyond REST APIs Biomedical data access is fragmented across REST APIs, FTP archives, SPARQL endpoints, Cypher-queryable Neo4j instances, GraphQL APIs, and gated secure enclaves. The NCATS Translator’s TRAPI protocol provides a standardized JSON message format for multi-hop biomedical queries [32]; Listing 1 illustrates a two-hop TRAPI query. The Open Targets GraphQL API demonstrates that introspective, typed schemas enable programmatic service discovery at KG scale [23]. 12

Model / DSL

Description

SBML

Widely used standard for ODE and reaction-network models.

BioPAX

OWL-based pathway knowledge representation.

PSI-MI XML / MITAB

HUPO Proteomics Standards Initiative formats for protein interaction evidence.

CellML

XML-based mathematical models of cell biology.

BNGL / BioNetGen

Rule-based language for combinatorially complex signalling networks.

Table 4: Examples of biomedical DSLs and their domain focus.

Even with consistent APIs, a query engine must still resolve that the target id field from ChEMBL and the ensembl id field from Open Targets refer to the same biological entity. Semantic service composition—services that declare inputs and outputs in terms of shared ontological types—would enable automated composition analogous to typed function signatures. Emerging work in this direction remains largely at the prototype stage.

Listing 1: Two-hop TRAPI query: small molecules targeting genes associated with type 2 diabetes. { " message " : { " query_graph " : { " nodes " : { " n0 " : { " ids " : [ " MONDO :0005148 " ] , " categories " : [ " biolink : Disease " ] } , " n1 " : { " categories " : [ " biolink : Gene " ] } , " n2 " : { " categories " : [ " biolink : SmallMolecule " ] } }, " edges " : { " e0 " : { " subject " : " n1 " , " object " : " n0 " , " predicates " : [ " biolink : g e n e _ a s s o c i a t e d _ w i t h _ c o n d i t i o n " ] } , " e1 " : { " subject " : " n2 " , " object " : " n1 " , " predicates " : [ " biolink : affects " ] } } } } } % --- RESPONSE ( abridged ) --{ " message " : { " kn ow l ed ge _ gr ap h " : { " nodes " : { " MONDO :0005148 " : { " name " : " type 2 diabetes mellitus " } , " NCBIGene :3643 " : { " name " : " INSR " } , " DRUGBANK : DB01252 " : { " name " : " Insulin glargine " } }, " edges " : { " e_result_0 " : { " subject " : " NCBIGene :3643 " , " object " : " MONDO :0005148 " , " predicate " : " biolink : g e n e _ a s s o c i a t e d _ w i t h _ c o n d i t i o n " , " attributes " : [{ " a t t r i b u t e _ t y p e _ i d " : " biolink : score " , " value " : 0.94 }] } } } } }

13

8.6. SE Challenge 6: Reproducible Pipelines and the Data Versioning Gap The reproducibility crisis in computational biology is well documented [50]. Its primary engineering causes are: (1) implicit software environment dependencies not captured in pipeline specifications; (2) mutable input data (database releases that update without version bumps); (3) non-deterministic tools; and (4) incomplete provenance recording. Despite the proliferation of academic and industrial workflow management systems, they are rarely adopted in KG assembly pipelines. Nextflow [57] and Snakemake [58] have made significant progress on causes (1) and (3), providing workflow execution models, containerized task environments, and provenance graphs. Nextflow’s dataflow model enables natural parallelization across many samples, and its integration with containers and HPC environments aligns well with reproducible biomedical workflows [52, 59]. Listing 2 illustrates a Nextflow process normalizing GTEx RNA-seq matrices in parallel. Listing 2: Nextflow process normalising GTEx RNA-seq matrices in parallel. 1 2 3 4 5 6 7 8 9 10

process NORMALISE { input : path gct output : path " $ { gct . baseName }. norm " script : """ python normalise_matrix . py " $gct " > " $ { gct . baseName }. norm " """ }

However, a Nextflow process declaring path gct does not verify that the GTEx matrix is the version it was designed for. The analogous infrastructure for data sources—versioned, hashverified packages with well-defined access interfaces—does not yet exist in general-purpose form for biomedical data. Open problem: data dependency management for workflows

A layer for workflow systems that: (1) declares upstream data sources with pinned version identifiers in the workflow manifest; (2) verifies integrity of downloaded data via published checksums; (3) logs data source versions into the provenance record alongside compute environment hashes; and (4) alerts when upstream data is updated by checking registered release feeds. 8.7. SE Challenge 7: KG Lifecycle Management: Schema Evolution and Sustainability Biomedical databases suffer a cluster of lifecycle failures well understood in software engineering but not systematically addressed in the biomedical context: Silent schema evolution. Database releases may rename or remove columns without a machinereadable changelog. Downstream pipelines that hard-code field names break silently—not with an error, but with missing or misaligned data detectable only months later. 14

Identifier retirement without forwarding. Gene identifiers, protein accessions, and compound IDs are periodically retired or merged without automated forwarding—the biological equivalent of HTTP 301 redirects—leaving dangling references in KG nodes. Funding discontinuity. Multiple scientifically important databases have experienced funding gaps resulting in API outages or stale data. There is no uptime SLA or graceful deprecation standard for public biomedical data services. BioCypher [53] represents the most structured current approach, making schema changes visible as code diffs in versioned adapter code. The broader sustainability problem is structural: unlike software packages maintainable by a single developer at near-zero marginal distribution cost, biomedical KGs require ongoing consortium-scale curation investment. 8.8. SE Challenge 8: Scaling from Experimental Pipeline to Production The transition from an experimental pipeline to full-cohort production deployment is one of the most consistently underestimated engineering challenges in biomedical data integration— documented in the literature yet responsible for significant development time lost [52, 50]. The scale gap is not merely quantitative. Edge cases—corrupt VCF records, ambiguous gene identifiers, race conditions in shared output directories—appear reliably at scale. Pipeline steps well-studied for one-shot execution have received little systematic attention for incremental updates [48], and graphs pursuing similar goals display substantial variation in source integration and terminology [49]. Testing infrastructure is immature or absent. Standard software engineering prescribes three test layers: unit tests for individual processing steps; integration tests verifying that chained steps produce correct outputs; and end-to-end smoke tests on representative data slices that can run in CI/CD within an hour. Two partial solutions emerged in 2024: nf-test [60] and NFTest [61], addressing unit and snapshot testing of Nextflow processes. Both cover only Nextflow pipelines; test-driven development remains limited compared to software engineering norms. Failure observability. When a full-cohort pipeline fails after consuming 200 CPU-hours, the developer typically receives only a non-zero exit code—never the precise input record or pipeline state at the moment of failure. Integration of EHR data adds further complexity, as standardized graph representations for clinical data sources remain underdeveloped [62]. Multi-hop retrieval over large biomedical KGs has itself become a major computational bottleneck [63]. Open problem: production-readiness engineering for biomedical pipelines

Concretely absent are: (1) a staging environment specification—a miniaturised but structurally faithful replica enabling full pipeline runs in under two hours; (2) a structured failure logging contract—a standard schema for recording failure context to a queryable store; (3) a within-task checkpoint API for partial recovery; (4) a data contract validation layer—automated schema checks at each stage boundary. The nf-core community [64] has begun institutionalising some of these practices, but a coherent framework applicable across workflow systems and biomedical data modalities remains unbuilt [62, 48]. 15

9. Toward a Unified Engineering Stack for Biomedical Knowledge The aforementioned challenges share a common pattern: robust solutions exist in general software engineering, and partial biomedical counterparts have emerged, yet most projects still implement these capabilities in ad hoc and incompatible ways. The community has not yet converged on a coherent, general-purpose engineering stack capable of unifying and simplifying KG construction, maintenance, and model assembly lifecycles (Table 5). Table 5: The engineering maturity gap in biomedical knowledge infrastructure across eight challenge areas. SE Concept

Partial Biomedical Equivalent

What Is Missing

Package manager

Bioregistry, BioCypher adapters

Semantic versioning, dependency resolution, integrity hashes for data releases

Namespace / type system

Biolink CURIEs, SRI Node Normalizer

Namespace type enforcement at pipeline compile time

Canonical IR

KGX format, Biolink Model

Full SHACL constraint layer; biological integrity rules; provenance subgraph spec

Universal modelling language SBML / BioPAX / COMBINE standards

Unified language spanning relational KG and dynamic model behaviour

Typed service contract

TRAPI protocol, Open Targets GraphQL

Semantic input/output types; automated composition from ontological type signatures

CI/CD + immutable envs

Nextflow / Snakemake + containers

Data source version pinning and integrity verification in workflow manifests

Schema migration

BioCypher adapter versioning

Machine-readable schema changelogs; automated downstream breakage detection

Staging / prod parity

nf-core CI/CD standards, nf-test

Staging environment spec; structured failure logging; within-task checkpoint API

The convergence trajectory is emerging: the Biolink Model provides the namespace contract; the NCATS Translator ecosystem provides a composition protocol; BioCypher and KGX provide structured ETL abstractions; Nextflow provides reproducible compute environments; JSON-LD and SHACL provide web-native semantic data exchange. What is missing is not individual components but their integration into a coherent, documented stack—and the engineering culture shift toward shipping pipelines rather than snapshots. The goal is a workflow that lets a researcher reproduce or customize a KG in a few commands from version-pinned sources, the way a developer runs npm install to reconstitute a web application. 10. Visualization as a First-Class Concern One aspect of the biomedical data engineering stack that receives comparatively little investment is visualization as infrastructure—rather than as a downstream reporting step. Most KG platforms provide only rudimentary reactive graph views, typically force-directed layouts where nodes and edges are distinguished primarily through colour and shape. The highly informative diagrams found in scientific publications—illustrating pathways, anatomical hierarchies, or multi-scale biological organization—are typically created manually and cannot be reproduced or automatically updated when the underlying data change. The visualization literature provides many diagram types suited to structured knowledge representation: trees, treemaps, directed acyclic graphs, heatmaps, and visualizations combining graphs with quantitative plots. Modern reactive frameworks (D3.js, Vega/Vega-Lite, Observable 16

Plot, Apache ECharts) make it possible to generate such diagrams programmatically, but the required data transformation pipelines are rarely standardized or integrated into KG infrastructures. An emerging opportunity lies in LLM-assisted visualization: a language model could interpret a domain scientist’s natural language query, decompose it into a structured retrieval and transformation plan, and dispatch sub-tasks to specialized microservices via the Model Context Protocol (MCP) [65]—a standardized interface enabling AI agents to invoke external tools in a composable, auditable manner. Realizing this vision requires visualization pipelines to be registered as FAIR resources with explicit semantic descriptions of their input–output contracts. A semantic visualization layer—where node and relation types are mapped to visual encodings through declarative rules derived from domain ontologies such as Biolink—would make visualizations reproducible, queryable, and automatically updatable. Approaches such as constraintbased layouts and structural-signature anomaly detection illustrate how visualization could evolve into a systematic tool for knowledge validation and quality assurance.

(a) KG without visualization effort.

(b) KG visualization with node and edge classification.

(c) Reactive KG visualization.

(d) KG analytics via visual exploration with transformation pipelines.

(e) KG semantic- and context-aware layout generation.

(f) Relationships between concepts providing visualization constraints.

Figure 3: Levels of graph-based biomedical data visualization, from no effort (a) through node-edge classification (b), reactive exploration (c), transformative analytics (d), to full semantic context-aware layout (e, f).

17

Figure 3 illustrates how visualization effort transforms the usability of the same underlying data. The higher levels require derivation of trees from graphs, clustering within graph structure, and shared filters across reactive components— pipelines that are rarely integrated with KG schemata. The apinatomy panels (e, f) show an approach where each KG element knows how it must be drawn: “part-of” relationships place an entity node within boundaries of its hosting entity, and other relationship types constrain position, size, shape, and color within the forcedirected layout. 11. Scope and Limitations This article has an intentionally engineering-centric and translational focus. Several important dimensions of biomedical knowledge infrastructure are addressed only briefly or not at all. Scope. The article focuses on the software engineering infrastructure required to assemble, version, and maintain biomedical knowledge graphs—the pipeline layer rather than the algorithms that operate over them. Machine learning methods for KG completion, graph neural network architectures, and clinical prediction tasks are referenced as motivating applications but not surveyed in depth. The article emphasizes translational infrastructure (the path from raw data sources to queryable, reproducible, FAIR-compliant knowledge structures) over biostatistical methodology, clinical validation, or regulatory compliance. Empirical limitations. Several claims in this article are directionally supported by the literature and our own engineering experience but should be interpreted cautiously. The comparison between biomedical data engineering and web development reflects a qualitative observation rather than a systematic empirical study. Claims about ecosystem immaturity—such as the absence of broadly adopted package management for biomedical data—are accurate as of writing but characterize a field in active development rather than permanent constraints. The Data Distillery case study (Section 6) reflects one team’s experience with one version of one system; other users may have had different experiences, and the project may have evolved since our evaluation. Non-exhaustive challenge catalogue. The eight SE challenges described in Section 8 represent a curated, not exhaustive, selection. Challenges in privacy-preserving computation over biomedical data, federated learning governance, real-time streaming integration, and natural language interfaces to KGs are acknowledged but not treated in depth. KG selection. The six KGs profiled in Section 5 were selected to illustrate design diversity and pipeline reproducibility patterns, not to rank systems or comprehensively survey the field. Many important biomedical KGs—including BioKG, CKG, SPOKE, and others—are not profiled here. AI and agent speculation. Claims about the potential of LLM-based agents to navigate and automate biomedical knowledge infrastructure (Sections 9 and 12) are forward-looking and rest on capabilities that, while demonstrated at smaller scale, have not yet been adopted in production biomedical settings. 12. Conclusion This article has examined biomedical knowledge infrastructure from two complementary perspectives: the integration and harmonization of biological knowledge derived from heterogeneous sources, and the engineering and lifecycle management practices required to support the construction, maintenance, and evolution of biomedical KGs. 18

From an integration perspective, biomedical knowledge is distributed across a large number of specialized databases, ontologies, and experimental resources. Knowledge graphs provide a flexible representation for combining these heterogeneous data sources, but their construction requires addressing challenges related to identifier harmonization, ontological alignment, semantic interoperability, provenance representation, and data quality management. From an engineering perspective, the assembly and maintenance of KGs remain labor-intensive processes that rely on custom integration pipelines and substantial domain expertise. Compared with the mature tooling available in modern software development ecosystems, biomedical data integration lacks broadly adopted mechanisms for dependency management, versioning, reproducible builds, and automated validation. A recurring theme throughout this article is the distinction between deployed KG instances and reproducible KG construction processes. While deployed portals provide access to integrated knowledge resources, reproducible build pipelines enable reconstruction, customization, verification, and extension of those resources from their original data sources. Explicit specification of data dependencies, versioned releases, transformation steps, and validation procedures supports reproducibility and facilitates long-term maintenance and community participation. Consequently, documenting and standardizing KG assembly workflows may be as important as publishing the resulting knowledge graph itself. The analysis presented in this article suggests several directions for future software and knowledge engineering research. These include formal models for biological data package management, standardized approaches to identifier and namespace management, interoperable graph exchange formats, machine-verifiable integrity constraints, and tooling that supports reproducible end-to-end data integration workflows. Such developments could help reduce the engineering overhead associated with KG construction and improve the reproducibility of biomedical data integration efforts. The emergence of LLM-based agents and agentic workflows introduces additional requirements for well-defined interfaces and reproducible infrastructure. Standards such as TRAPI and MCP provide mechanisms for structured interaction with knowledge resources, while knowledge graphs offer a foundation for grounding agent behavior in curated biomedical data. Beyond information retrieval, agents may support tasks such as monitoring upstream resource updates, assisting with schema and namespace alignment, and coordinating re-execution of data integration pipelines. The reliability of such capabilities, however, depends on the availability of transparent, versioned, and interoperable knowledge infrastructure. Taken together, these observations suggest that progress in biomedical knowledge engineering depends not only on the availability of high-quality biological data, but also on the development of software engineering practices, standards, and tools that make data integration workflows reproducible, maintainable, and interoperable. Addressing these challenges will require continued collaboration among software engineers, knowledge engineers, data providers, and biomedical researchers. References [1] K. Tomczak, P. Czerwińska, M. Wiznerowicz, The Cancer Genome Atlas (TCGA): an immeasurable source of knowledge, Contemporary Oncology 19 (1A) (2015) A68–A77. doi:10.5114/wo.2014.47136. [2] A. Regev, S. A. Teichmann, E. S. Lander, I. Amit, C. Benoist, E. Birney, et al., The Human Cell Atlas, eLife 6 (2017) e27041. doi:10.7554/eLife.27041.

19

[3] Gene Ontology Consortium, The Gene Ontology Resource: 20 years and still GOing strong, Nucleic Acids Research 47 (D1) (2019) D330–D338. doi:10.1093/nar/gky1055. [4] UniProt Consortium, UniProt: the Universal Protein Knowledgebase in 2023, Nucleic Acids Research 51 (D1) (2023) D523–D531. doi:10.1093/nar/gkac1052. [5] M. Kanehisa, M. Furumichi, Y. Sato, M. Kawashima, M. Ishiguro-Watanabe, KEGG for taxonomy-based analysis of pathways and genomes, Nucleic Acids Research 51 (D1) (2023) D587–D592. doi:10.1093/nar/gkac963. [6] B. Jassal, L. Matthews, G. Viteri, C. Gong, P. Lorente, A. Fabregat, K. Sidiropoulos, J. Cook, M. Gillespie, R. Haw, et al., The Reactome pathway knowledgebase, Nucleic Acids Research 48 (D1) (2020) D498–D503. doi:10. 1093/nar/gkz1031. [7] D. S. Wishart, Y. D. Feunang, A. C. Guo, E. J. Lo, A. Marcu, J. R. Grant, T. Sajed, D. Johnson, C. Li, Z. Sayeeda, et al., DrugBank 5.0: a major update to the DrugBank database for 2018, Nucleic Acids Research 46 (D1) (2018) D1074–D1082. doi:10.1093/nar/gkx1037. [8] D. Mendez, A. Gaulton, A. P. Bento, J. Chambers, M. De Veij, E. Félix, M. P. Magariños, J. F. Mosquera, P. Mutowo, M. Nowotka, et al., ChEMBL: towards direct deposition of bioassay data, Nucleic Acids Research 47 (D1) (2019) D930–D940. doi:10.1093/nar/gky1075. [9] M. J. Landrum, J. M. Lee, M. Benson, G. R. Brown, C. Chao, S. Chitipiralla, B. Gu, J. Hart, D. Hoffman, W. Jang, et al., ClinVar: improving access to variant interpretations and supporting evidence, Nucleic Acids Research 46 (D1) (2018) D1062–D1067. doi:10.1093/nar/gkx1153. [10] J. G. Tate, S. Bamford, H. C. Jubb, Z. Sondka, D. M. Beare, N. Bindal, H. Boutselakis, C. G. Cole, C. Creatore, E. Dawson, et al., COSMIC: the catalogue of somatic mutations in cancer, Nucleic Acids Research 47 (D1) (2019) D941–D947. doi:10.1093/nar/gky1015. [11] S. Köhler, M. Gargano, N. Matentzoglu, L. C. Carmody, D. Lewis-Smith, N. A. Vasilevsky, D. Danis, G. Balagura, G. Baynam, A. M. Brower, et al., The Human Phenotype Ontology in 2021, Nucleic Acids Research 49 (D1) (2021) D1207–D1217. doi:10.1093/nar/gkaa1043. [12] N. A. Vasilevsky, N. A. Matentzoglu, S. Toro, J. E. Flack, H. Hegde, D. R. Unni, E. M. Spiegel, S. A. Loomı́s, N. L. Harris, M. A. Haendel, C. J. Mungall, Mondo: Unifying diseases for the world, by the world, medRxiv (2022). doi:10.1101/2022.04.13.22273750. [13] M. D. Wilkinson, M. Dumontier, I. J. Aalbersberg, G. Appleton, M. Axton, A. Baak, N. Blomberg, J.-W. Boiten, L. B. da Silva Santos, P. E. Bourne, et al., The FAIR guiding principles for scientific data management and stewardship, Scientific Data 3 (1) (2016) 160018. doi:10.1038/sdata.2016.18. [14] R. L. Seal, B. Braschi, K. Gray, T. E. M. Jones, S. Tweedie, L. Haim-Vilmovsky, E. A. Bruford, HGNC: the HUGO Gene Nomenclature Committee in 2023, Nucleic Acids Research 51 (D1) (2023) D1003–D1009. doi: 10.1093/nar/gkac888. [15] J. A. McMurry, N. Juty, N. Blomberg, T. Burdett, T. Conlin, N. Conte, M. Courtot, J. Deck, M. Dumontier, D. K. Fellows, et al., Identifiers for the 21st century: how to design, provision, and reuse persistent identifiers to maximize utility and impact of life science data, PLOS Biology 15 (6) (2017) e2001595. doi:10.1371/journal.pbio. 2001595. [16] J. Malone, E. Holloway, T. Adamusiak, M. Kapushesky, J. Zheng, N. Kolesnikov, A. Zhukova, A. Brazma, H. Parkinson, Modelling sample variables with an Experimental Factor Ontology, Bioinformatics 26 (8) (2010) 1112–1118. doi:10.1093/bioinformatics/btq099. [17] N. F. Noy, N. H. Shah, P. L. Whetzel, B. Dai, M. Dorf, N. Griffith, C. Jonquet, D. L. Rubin, M.-A. Storey, C. G. Chute, M. A. Musen, BioPortal: ontologies and integrated data resources at the click of a button, Nucleic Acids Research 37 (Web Server issue) (2009) W170–W173. doi:10.1093/nar/gkp440. [18] N. Kokash, L. Wang, T. H. Gillespie, A. Belloum, P. Grosso, S. Quinney, L. Li, B. de Bono, Ontology- and LLMbased data harmonization for federated learning in healthcare, Frontiers in Digital Health 8, health Informatics section (2026). doi:10.3389/fdgth.2026.1756555. [19] D. Szklarczyk, A. L. Gable, K. C. Nastou, D. Lyon, R. Kirsch, S. Pyysalo, N. T. Doncheva, M. Leeb, F. Juhl, L. J. Jensen, P. Bork, C. von Mering, The STRING database in 2021: customizable protein-protein networks and functional characterization of user-uploaded gene/measurement sets, Nucleic Acids Research 49 (D1) (2021) D605–D612. doi:10.1093/nar/gkaa1074. [20] D. R. Unni, S. A. T. Moxon, M. Bada, M. Brush, R. Bruskiewich, J. H. Caufield, P. A. Clemons, V. Dancik, M. Dumontier, K. Fecho, G. Glusman, J. J. Hadlock, N. L. Harris, A. Joshi, T. Putman, G. Qin, S. A. Ramsey, K. A. Shefchek, H. Solbrig, K. Soman, A. E. Thessen, M. A. Haendel, C. Bizon, C. J. Mungall, The Biomedical Data Translator Consortium, Biolink Model: A universal schema for knowledge graphs in clinical, biomedical, and translational science, Clinical and Translational Science 15 (8) (2022) 1848–1855. doi:10.1111/cts.13302. [21] M. Parciak, B. Vandevoort, F. Neven, L. M. Peeters, S. Vansummeren, Schema matching with large language models: an experimental study, in: VLDB 2024 Workshop: Tabular Data Analysis Workshop (TaDA), 2024. URL https://vldb.org/workshops/2024/proceedings/TaDA/TaDA.8.pdf [22] P.-L. Mouchel, et al., Interactive data harmonization with LLM agents, arXiv preprint arXiv:2502.07132 (2025).

20

URL https://arxiv.org/abs/2502.07132 [23] D. Ochoa, A. Hercules, M. Carmona, D. Suveges, A. Gonzalez-Uriarte, C. Malangone, A. Miranda, L. Fumis, D. Carvalho-Silva, M. Spitzer, et al., Open Targets Platform: supporting systematic drug–target identification and prioritisation, Nucleic Acids Research 49 (D1) (2021) D1302–D1310. doi:10.1093/nar/gkaa1027. [24] L. Moreau, P. Missier, PROV-O: The PROV ontology, W3c recommendation, W3C (2013). URL https://www.w3.org/TR/prov-o/ [25] O. J. Wouters, M. McKee, J. Luyten, Estimated research and development investment needed to bring a new medicine to market, 2009–2018, JAMA 323 (9) (2020) 844–853. doi:10.1001/jama.2020.1166. [26] C. H. Wong, K. W. Siah, A. W. Lo, Estimation of clinical trial success rates and related parameters, Biostatistics 20 (2) (2019) 273–286. doi:10.1093/biostatistics/kxx069. [27] S. Pushpakom, F. Iorio, P. A. Eyers, K. J. Escott, S. Hopper, A. Wells, A. Doig, T. Guilliams, J. Latimer, C. McNamee, et al., Drug repurposing: progress, challenges and recommendations, Nature Reviews Drug Discovery 18 (1) (2019) 41–58. doi:10.1038/nrd.2018.168. [28] D. Chakravarty, J. Gao, S. M. Phillips, R. Kundra, H. Zhang, J. Wang, J. E. Rudolph, R. Yaeger, T. Soumerai, M. H. Nissan, et al., OncoKB: A precision oncology knowledge base, JCO Precision Oncology 1 (2017) 1–16. doi:10.1200/PO.17.00011. [29] K. P. Venkatesh, M. M. Raza, J. C. Kvedar, Health digital twins as tools for precision medicine: considerations for computation, implementation, and regulation, npj Digital Medicine 5 (1) (2022) 150. doi:10.1038/ s41746-022-00694-7. [30] R. Laubenbacher, A. Niarakis, T. Helikar, G. Lee, R. Srivastava, M. Blinov, M. Birtwistle, S. Finley, A. Luo, H. R. Chamberlin, et al., Building digital twins of the human immune system: toward a roadmap, npj Digital Medicine 5 (1) (2022) 64. doi:10.1038/s41746-022-00610-z. [31] G. Karlebach, R. Shamir, Modelling and analysis of gene regulatory networks, Nature Reviews Molecular Cell Biology 9 (10) (2008) 770–780. doi:10.1038/nrm2503. [32] E. C. Wood, A. K. Glen, L. G. Kvarfordt, F. Womack, L. Acevedo, T. S. Yoon, C. Ma, V. Flores, M. Sinha, Y. Chodpathumwan, A. Termehchy, J. C. Roach, L. Mendoza, A. S. Hoffman, E. W. Deutsch, D. Koslicki, S. A. Ramsey, RTX-KG2: a system for building a semantically standardized knowledge graph for translational biomedicine, BMC Bioinformatics 23 (1) (2022) 400. doi:10.1186/s12859-022-04932-3. [33] P. M. Visscher, N. R. Wray, Q. Zhang, P. Sklar, M. I. McCarthy, M. A. Brown, J. Yang, 10 years of GWAS discovery: biology, function, and translation, American Journal of Human Genetics 101 (1) (2017) 5–22. doi: 10.1016/j.ajhg.2017.06.005. [34] A. Buniello, J. A. L. MacArthur, M. Cerezo, L. W. Harris, J. Hayhurst, C. Malangone, A. McMahon, J. Morales, E. Mountjoy, E. Sollis, et al., The NHGRI-EBI GWAS Catalog of published genome-wide association studies, targeted arrays and summary statistics 2019, Nucleic Acids Research 47 (D1) (2019) D1005–D1012. doi:10. 1093/nar/gky1120. [35] D. S. Himmelstein, A. Lizee, C. Hessler, L. Brueggeman, S. L. Chen, D. Hadley, A. Green, P. Khankhanian, S. E. Baranzini, Systematic integration of biomedical knowledge prioritizes drugs for repurposing, eLife 6 (2017) e26726. doi:10.7554/eLife.26726. [36] C. J. Mungall, J. A. McMurry, S. Köhler, J. P. Balhoff, C. Borromeo, M. Brush, S. Carbon, T. Conlin, N. Dunn, M. Engelstad, et al., The Monarch Initiative: an integrative data and analytic platform connecting phenotypes to genotypes across species, Nucleic Acids Research 45 (D1) (2017) D712–D722. doi:10.1093/nar/gkw1128. [37] K. A. Shefchek, N. L. Harris, M. Gargano, N. Matentzoglu, D. Unni, M. Brush, D. Keith, T. Conlin, N. Vasilevsky, X. A. Zhang, et al., The Monarch Initiative in 2019: an integrative data and analytic platform connecting phenotypes to genotypes across species, Nucleic Acids Research 48 (D1) (2020) D704–D715. doi:10.1093/nar/gkz997. [38] P. Chandak, K. Huang, M. Zitnik, Building a knowledge graph to enable precision medicine, Scientific Data 10 (2023) 67. doi:10.1038/s41597-023-01960-3. URL https://www.nature.com/articles/s41597-023-01960-3 [39] M. Zitnik, M. Agrawal, J. Leskovec, Modeling polypharmacy side effects with graph convolutional networks, Bioinformatics 34 (13) (2018) i457–i466. doi:10.1093/bioinformatics/bty294. [40] J. Zhang, et al., A comprehensive large-scale biomedical knowledge graph for AI-powered data-driven biomedical research, Nature Machine IntelligenceAlso available as bioRxiv preprint: https://doi.org/10.1101/2023. 10.13.562216 (2025). doi:10.1038/s42256-025-01014-w. URL https://www.nature.com/articles/s42256-025-01014-w [41] M. R. Hossain, et al., A knowledge graph approach for the secondary use of cancer registry data, in: Proceedings of the IEEE International Conference on Big Data, 2019, oSTI.GOV report; describes the Louisiana Tumor Registry KG with 25+ billion triples and ∼4 TB storage. URL https://www.osti.gov/biblio/1558464 [42] M. R. Hossain, et al., Knowledge graph-enabled cancer data analytics, IEEE Journal of Biomedical and Health Informatics (2021). doi:10.1109/JBHI.2021.3077810.

21

URL https://pmc.ncbi.nlm.nih.gov/articles/PMC8324069/ [43] H. Bast, B. Buchhold, QLever: A query engine for efficient SPARQL+text search, in: Proceedings of the 2017 ACM on Conference on Information and Knowledge Management (CIKM’17), ACM, 2017, pp. 647–656. doi: 10.1145/3132847.3132921. URL https://doi.org/10.1145/3132847.3132921 [44] M. R. Ackermann, H. Bast, B. M. Beckermann, J. Kalmbach, P. Neises, S. Ollinger, The dblp knowledge graph and SPARQL endpoint, Transactions on Graph Data and Knowledge (TGDK) 2 (2) (2024) 3:1–3:23. doi:10.4230/ TGDK.2.2.3. URL https://doi.org/10.4230/TGDK.2.2.3 [45] T. Mohseni Ahooyi, B. Stear, J. A. Simmons, V. T. Metzger, P. Kumar, J. E. Evangelista, D. J. Clarke, Z. Xie, H. Kim, S. L. Jenkins, et al., The data distillery: A graph framework for semantic integration and querying of biomedical data, bioRxivAlso published in PMC: https://pmc.ncbi.nlm.nih.gov/articles/ PMC12363844/ (2025). doi:10.1101/2025.08.11.666099. URL https://www.biorxiv.org/content/10.1101/2025.08.11.666099v1 [46] B. J. Stear, T. Mohseni Ahooyi, J. A. Simmons, C. Kollar, L. Hartman, K. Beigel, A. Lahiri, S. Vasisht, T. J. Callahan, C. M. Nemarich, J. C. Silverstein, D. M. Taylor, Petagraph: A large-scale unifying knowledge graph framework for integrating biomolecular and biomedical data, Scientific Data 11 (1) (2024) 1338. doi:10.1038/ s41597-024-04070-w. [47] Taylor Research Lab, CFDE Data Distillery Project, https://github.com/TaylorResearchLab/CFDE_ DataDistillery, accessed: 2026-05-21 (2024). [48] M. Hofer, D. Obraczka, A. Saeedi, H. Köpcke, E. Rahm, Construction of knowledge graphs: Current state and challenges, Information 15 (8) (2024) 509. doi:10.3390/info15080509. URL https://www.mdpi.com/2078-2489/15/8/509 [49] K. G. Cortes, S. Sundar, S. Gehrke, K. Manpearl, J. Lin, D. R. Korn, H. Caufield, K. Schaper, J. Reese, K. Koirala, L. E. Hunter, E. K. Carter, M. DeLuca, A. Krishnan, C. Mungall, M. Haendel, Improving biomedical knowledge graph quality: A community approach, arXiv preprint (2025). arXiv:2508.21774. URL https://arxiv.org/abs/2508.21774 [50] L. Wratten, A. Wilm, J. Göke, Reproducible, scalable, and shareable analysis pipelines with bioinformatics workflow managers, Nature Methods 18 (10) (2021) 1161–1168. doi:10.1038/s41592-021-01254-9. [51] K. Fecho, G. Glusman, S. E. Baranzini, et al., Announcing the biomedical data translator: Initial public release, Clinical and Translational Science 18 (7) (2025) e70284. doi:10.1111/cts.70284. URL https://pmc.ncbi.nlm.nih.gov/articles/PMC12241707/ [52] M. Djaffardjy, G. Marchment, C. Sebe, R. Blanchet, K. Belhajjame, A. Gaignard, F. Lemoine, S. Cohen-Boulakia, Developing and reusing bioinformatics data analysis pipelines using scientific workflow systems, Computational and Structural Biotechnology Journal 21 (2023) 2075–2085. doi:10.1016/j.csbj.2023.03.003. [53] S. Lobentanzer, A. Koleti, P. Brack, J. Baumbach, J. Saez-Rodriguez, P. Anagnostopoulou, et al., BioCypher: a unifying framework for biomedical research knowledge graphs, Nature Biotechnology 41 (9) (2023) 1234–1237. doi:10.1038/s41587-023-01848-y. [54] M. Sporny, D. Longley, G. Kellogg, M. Lanthaler, N. Lindström, JSON-LD 1.1: A JSON-based serialization for linked data, W3c recommendation, W3C (2020). URL https://www.w3.org/TR/json-ld11/ [55] H. Knublauch, D. Kontokostas, Shapes Constraint Language (SHACL), W3c recommendation, W3C (2017). URL https://www.w3.org/TR/shacl/ [56] M. L. Neal, M. König, D. Nickerson, J. Mı́šek, A. Kiričši, I. I. Moraru, C. J. Myers, J. R. Faeder, et al., Harmonizing semantic annotations for computational models in biology, Briefings in Bioinformatics 20 (2) (2019) 540–550. doi:10.1093/bib/bby087. [57] P. Di Tommaso, M. Chatzou, E. W. Floden, P. P. Barja, E. Palumbo, C. Notredame, Nextflow enables reproducible computational workflows, Nature Biotechnology 35 (4) (2017) 316–319. doi:10.1038/nbt.3820. [58] F. Mölder, K. P. Jablonski, B. Letcher, M. B. Hall, C. H. Tomkins-Tinch, V. Sochat, J. Forster, S. Lee, S. O. Twardziok, A. Kanitz, et al., Sustainable data analysis with Snakemake, F1000Research 10 (2021) 33. doi: 10.12688/f1000research.29032.2. [59] A. E. Ahmed, J. M. Allen, T. Bhat, P. Burra, C. E. Fliege, S. N. Hart, J. R. Heldenbrand, M. E. Hudson, D. D. Istanto, M. T. Kalmbach, et al., Design considerations for workflow management systems use in production genomics research and the clinic, Scientific Reports 11 (1) (2021) 21680. doi:10.1038/s41598-021-99288-8. [60] L. Forer, S. Schönherr, Improving the reliability, quality, and maintainability of bioinformatics pipelines with nftest, GigaSciencePreprint posted May 2024 at bioRxiv, doi:10.1101/2024.05.25.595877 (2025). doi:10.1093/ gigascience/giaf130. [61] Y. Patel, C. Zhu, T. N. Yamaguchi, Y. Z. Bugh, M. Tian, A. Holmes, S. T. Fitz-Gibbon, P. C. Boutros, NFTest: automated testing of Nextflow pipelines, Bioinformatics 40 (2) (2024) btae081. doi:10.1093/bioinformatics/

22

btae081. [62] K. Hänsel, S. N. Dudgeon, K.-H. Cheung, T. J. S. Durant, W. L. Schulz, From data to wisdom: Biomedical knowledge graphs for real-world data insights, Journal of Medical Systems 47 (1) (2023) 65. doi:10.1007/ s10916-023-01951-2. URL https://pmc.ncbi.nlm.nih.gov/articles/PMC10191934/ [63] H. Cheng, Y. Wu, S. Khatwani, M. Kruse, D. Dligach, T. A. Miller, M. Afshar, Y. Gao, Scaling biomedical knowledge graph retrieval for interpretable reasoning: Applications to clinical diagnosis prediction, medRxivPreprint (2026). doi:10.64898/2026.01.12.26343957. URL https://www.medrxiv.org/content/10.64898/2026.01.12.26343957v1 [64] P. A. Ewels, A. Peltzer, S. Fillinger, H. Patel, J. Alneberg, A. Wilm, M. U. Garcia, P. Di Tommaso, S. Nahnsen, The nf-core framework for community-curated bioinformatics pipelines, Nature Biotechnology 38 (3) (2020) 276–278. doi:10.1038/s41587-020-0439-x. [65] Anthropic, Model context protocol, Tech. rep., Anthropic, open standard for connecting AI assistants to external data sources and tools. Specification and SDKs available at https://modelcontextprotocol.io (Nov. 2024). URL https://www.anthropic.com/news/model-context-protocol

23

Related documents

• Formal ontology for biomedical knowledge systems integration#733681
• Knowledge Engineering for Open Science: Building and Deploying Knowledge Bases for Metadata Standards.#330745
• Integrating Knowledge: The Power of Ontologies in Psychiatric Research and Clinical Informatics.#221027
• Building Ontologies with Basic Formal Ontology#117418
• Coordinating virus research: The Virus Infectious Disease Ontology#106712