Drug repurposing lives or dies by its data. With multi-omics datasets scattered across RNA-seq, proteomics, methylation arrays, and metabolomics platforms, the challenge is no longer generating data—it’s making it queryable. That’s why a growing number of research teams are using knowledge graphs to unify multi-omics data for drug repurposing, and doing it without standing up a heavy central data warehouse. Instead of forcing every source into a global relational schema, a knowledge graph preserves the shape of each dataset while connecting it to shared biological identifiers, enabling queries that are both faster to build and closer to the science.
Why the Data Warehouse Is the Wrong Default for Multi-Omics
A multi-omics data warehouse asks an impossible question up front: what does all our data look like together? Transcripts, proteins, metabolites, and clinical notes rarely share a clean join key. In practice, teams spend months designing star schemas for data that changes every experiment. The ETL pipeline becomes a permanent maintenance burden, and every new assay type requires a new round of schema migrations.
In 2026, the smart alternative is a semantic layer that leaves data in its original, versioned objects. The knowledge graph stores only the relationships between biological entities—genes, proteins, pathways, diseases, drugs—along with the provenance of each claim. The heavy files stay in their buckets and repositories. When a new experiment arrives, you map its entities onto existing graph nodes and immediately connect it to everything you already know.
What a Knowledge Graph Actually Changes for Querying
The key shift is from schema-first to relationship-first. A relational warehouse requires you to enumerate tables, primary keys, and foreign keys before you can ask a question. A knowledge graph lets you ask a question—“which approved drugs target proteins downstream of this disease’s gene signature?”—and then model only the minimum graph needed to answer it.
For multi-omics integration, this means each dataset contributes a subgraph with its own provenance. A transcriptomics study maps to HGNC gene identifiers; a metabolomics run maps to ChEBI chemical entities; a drug screen maps to DrugBank or ChEMBL. These canonical identifiers become the glue. You never copy the underlying matrices into the graph, only the assertions made about them.
Minimum Viable Setup for Querying Without a Data Warehouse
You don’t need a large infrastructure investment to make this work. The practical setup for a repurposing project usually includes:
- A graph store that supports SPARQL or Cypher, deployed as a lightweight service or even locally.
- Canonical identifier mappings for genes, proteins, compounds, and diseases (HGNC, UniProt, ChEBI, ChEMBL, DOID).
- A set of named graphs, each representing one source dataset and its provenance metadata.
- Regularly refreshed links to public endpoints—like the EBI’s RDF platform—for cross-species or cross-database expansion.
This setup is intentionally thin. It avoids data duplication, keeps source systems authoritative, and lets you bring in new omics layers as references rather than imports.
Query Patterns That Pull Their Weight in Drug Repurposing
The real payoff comes from query patterns that exploit graph traversal. These three patterns consistently deliver drug repurposing candidates without forcing you to merge everything into one table.
1. Federated SPARQL with Service Clauses
Federated querying is the most direct way to “meet data where it lives.” With SPARQL SERVICE, your local graph can pull results from remote endpoints at execution time. A query over your local disease signature can enrich each gene with pathway annotations from an external RDF resource without ever copying that resource. The syntax is simple:
SELECT ?drug ?pathway
WHERE {
?drug <http://example.org/ontology/targets> ?protein .
?protein <http://example.org/ontology/participatesIn> ?pathway .
SERVICE <https://rdf.example.org/sparql> {
?pathway <http://example.org/ontology/associatedWith> <http://example.org/disease/DOID_8398> .
}
}The result is a list of drug–pathway pairs connected to the target disease, with the remote service handling the heavy annotation lookups.
2. Property Paths for Indirect Repurposing Hops
Most repurposing opportunities are not direct edges. They are two or three hops through intermediary biology. Property paths compress those hops into a single traversal. For example, a drug that targets a protein that participates in a pathway linked to a disease is a classic two-hop repurposing pattern. In Cypher, it looks like this:
MATCH (d:Drug)-[:TARGETS]->(p:Protein)-[:PARTICIPATES_IN]->(pwy:Pathway)-[:LINKED_TO]->(dis:Disease)
WHERE dis.doid = "DOID:8398"
RETURN d.name, pwy.nameTraversing these paths tells you which approved drugs are already positioned—at least biologically—to influence a disease mechanism. You can then rank them by the number and confidence of supporting edges.
3. Hybrid Vector + Graph Ranking
Not all repurposing questions are best answered by deterministic traversals. In 2026, many teams embed disease-specific omics signatures as vectors and combine them with graph topology. The graph supplies the constrained, provenance-backed edges, while the vector layer captures noisy but high-recall similarities. For example, you can embed a patient’s transcriptomic profile, then retrieve nearby disease modules in the graph, then query only drugs connected to those modules. This hybrid pattern reduces false positives without sacrificing sensitivity.
A Practical Anti-ETL Workflow for Repurposing
The pattern below forms a repeatable weekly workflow, no warehouse required.
- Load the latest differential expression table and map genes to HGNC.
- Create a named graph for that experiment, linking each differentially expressed gene to a disease or cell-line context.
- Run a property-path query to find drugs that connect to those genes through any relevant pathway or protein complex.
- Cross-filter the results against drug perturbation signatures from public resources, treating each drug signature as an external graph endpoint.
- Write the shortlist back into the knowledge graph as candidate edges with confidence scores and provenance links.
This workflow keeps raw data untouched, centralizes only the assertions that matter, and lets every step be audited through provenance edges.
Three Traps That Silently Break Graph Queries
Even with a good setup, a few common mistakes can turn your knowledge graph back into a maintenance nightmare.
- Ontology overengineering: Converting every internal vocabulary into a custom graph model creates mapping debt. Reuse established ontologies wherever possible.
- Ignoring provenance: Edges without source confidence are dangerous for drug repurposing. Model provenance as first-class metadata on every edge.
- Over-normalizing: A knowledge graph is not a normalized database. If you split every node into over-specific classes, you lose the traversal speed and biological readability that made you switch in the first place.
Repurposing Is a Graph Problem
Ultimately, drug repurposing is a graph traversal over complex biological relationships. Avoiding the data warehouse doesn’t mean avoiding structure—it means choosing a structure that respects the heterogeneity of multi-omics data. By using a knowledge graph as a semantic layer, teams can query disparate data sources as one connected network, have every result traceable to its source, and stay agile as new experimental data arrives. The future of repurposing discovery belongs to those who can ask the right question across all the data, no matter where it lives.
