Open Biomedical Knowledge Graphs at Scale: Construction, Federation, and AI Agent Access with Samyama Graph Database

This paper presents two open-source biomedical knowledge graphs built on the high-performance Samyama database, introducing a reproducible ETL pipeline, cross-dataset federation capabilities, and schema-driven MCP server generation to enable efficient, natural-language access for AI agents to complex biomedical queries.

The Gist

Imagine the world of medical research as a massive library, but instead of books on shelves, the information is scattered across thousands of different, locked rooms.

• One room has a list of all the drugs being tested.
• Another room has a map of how proteins talk to each other inside your cells.
• A third room lists clinical trials for breast cancer.
• A fourth room details biological pathways (like the assembly lines in a factory).

The Problem:
Right now, if a researcher wants to answer a complex question like, "Which biological assembly lines are being broken by the new breast cancer drugs currently in Phase 3 trials?", they have to run to five different rooms, grab a stack of papers from each, and try to manually cross-reference them with a pen and paper. It's slow, messy, and prone to errors.

The Solution: The "Samyama" Graph Database
The authors of this paper built a super-fast, open-source system called Samyama (think of it as a high-speed, intelligent librarian) and used it to create two massive "Knowledge Graphs."

Think of a Knowledge Graph not as a spreadsheet, but as a giant, glowing web of connections.

• Nodes are the dots (Drugs, Genes, Diseases, Trials).
• Edges are the strings connecting them (e.g., "Drug A treats Disease B" or "Protein X is part of Pathway Y").

They built two specific webs:

1. The Pathways Web: A map of how your body works at a molecular level (118,000 dots).
2. The Clinical Trials Web: A massive map of every drug trial happening right now (7.7 million dots!).

The Three Big Magic Tricks

The paper highlights three main ways this system changes the game:

1. The "Snap-and-Load" Construction (The LEGO Analogy)

Usually, building these graphs is like trying to glue wet clay together; it's fragile and hard to fix.
The authors created a reproducible recipe. They download data, clean it, and package it into a "snapshot" (like a saved game file or a LEGO set in a box).

• Why it's cool: You can take this "box," drop it onto any computer, and instantly have the entire graph ready to use. It takes less than a minute to load a graph with 7.8 million connections on a standard home computer (like a Mac Mini).

2. The "Federation" (The Bridge Analogy)

This is the most exciting part. Imagine you have two separate LEGO cities: one is "The Body City" and the other is "The Hospital City."

• Old way: You can't ask a question that involves both cities because they aren't connected.
• New way: The authors built a bridge between the two cities. They didn't smash the cities together; they just laid down a bridge using shared names (like "UniProt IDs" for proteins or "DrugBank IDs" for drugs).
• The Result: You can now ask, "Show me the path from a Breast Cancer Trial -> to the Drug -> to the Protein it targets -> to the Biological Pathway it disrupts." The system instantly jumps across the bridge and gives you the answer in 2.1 seconds.

3. The "AI Agent" (The Translator Analogy)

Usually, to ask the database a question, you need to speak its language (a complex coding language called Cypher).
The authors added a Model Context Protocol (MCP) server. Think of this as a universal translator or a smart concierge.

• How it works: You can talk to an AI (like a chatbot) in plain English: "What pathways are affected by breast cancer drugs?"
• The AI doesn't need to know how to code. It looks at the "menu" (the schema) the system automatically generated, picks the right tool, asks the database, and reads the answer back to you. No manual coding required.

Why Does This Matter?

• Speed: What used to take days of manual research now happens in seconds.
• Discovery: It allows researchers to spot hidden connections. For example, they found that drugs in breast cancer trials are hitting specific "assembly lines" like Signal Transduction and Cell Cycle, confirming known biology and suggesting new research angles.
• Accessibility: Because everything is open-source and runs on cheap hardware, any researcher with a laptop can do this kind of high-level analysis, not just big tech companies with supercomputers.

In a Nutshell

The authors took a chaotic library of medical data, organized it into two massive, interconnected webs, built a bridge between them, and gave us a voice-activated remote control to explore it. They proved that we can now ask complex, multi-step questions about how drugs affect our bodies and get instant, accurate answers.

Technical Summary

1. Problem Statement

Biomedical knowledge is currently fragmented across dozens of siloed public databases (e.g., Reactome, ClinicalTrials.gov, STRING, Gene Ontology), each with unique schemas, identifiers, and update cycles. Researchers face significant challenges in integrating this data:

• Fragmentation: Answering complex translational questions (e.g., "Which biological pathways are disrupted by drugs in Phase 3 breast cancer trials?") requires manually downloading flat files and writing bespoke scripts to cross-reference multiple sources.
• Scalability & Reproducibility: Existing large-scale Knowledge Graph (KG) efforts like Bio2RDF or Hetionet often rely on static datasets, complex SPARQL endpoints, or specific database engines (like Neo4j) that lack portable snapshot mechanisms for instant deployment.
• AI Accessibility: Integrating KGs with Large Language Models (LLMs) typically requires manual authoring of tool definitions, creating a bottleneck for natural language access.

2. Methodology

The authors propose a solution built on Samyama, a high-performance, Rust-native graph database. The methodology consists of three core pillars:

A. Reproducible ETL Pattern

The authors developed a standardized five-phase ETL pipeline for constructing KGs from heterogeneous open-license sources:

1. Download: Automated fetching of source files (TSV, XML, JSON, OBO) with resume support.
2. Parse & Filter: Source-specific parsers extract entities, applying human-only filters (Organism ID 9606).
3. Deduplicate: A shared registry tracks entities across phases to prevent re-creation (e.g., ensuring a protein from Reactome isn't duplicated if found in STRING).
4. Batch Load: Nodes and edges are ingested via batched OpenCypher CREATE statements (50–100 entities/batch) through Samyama's HTTP API.
5. Snapshot Export: The final graph is exported as a portable, gzip-compressed .sgsnap file (JSON-lines), enabling instant restoration on any Samyama instance.

B. Cross-KG Federation (Property-Based Joins)

Instead of merging datasets during ETL, the authors demonstrate federation by loading multiple snapshots into a single graph tenant.

• Mechanism: Entities from different snapshots (e.g., a Protein in the Clinical Trials KG and a Protein in the Pathways KG) remain as separate nodes but share common properties (e.g., uniprot_id, drugbank_id, gene_id).
• Querying: Cross-KG queries use property-based joins (e.g., WHERE prot1.uniprot_id = prot2.uniprot_id) to traverse edges across the logical boundaries of the original datasets without complex ETL-time merging.

C. Schema-Driven AI Agent Access

The system introduces Model Context Protocol (MCP) server generation:

• The MCP server automatically discovers the graph schema from the running Samyama instance.
• It auto-generates typed tools (functions) for every node label and edge type.
• LLM agents can query the graph using natural language, invoking these generated tools without manual coding of Cypher queries or tool definitions.

3. Key Contributions & Results

Two Large-Scale Open-Source KGs

The paper presents two distinct, open-license KGs:

1. Pathways KG:
   • Sources: Reactome, STRING, Gene Ontology, WikiPathways, UniProt.
   • Scale: 118,686 nodes, 834,785 edges.
   • Schema: 5 node labels (e.g., Protein, Pathway), 9 edge types (e.g., INTERACTS_WITH, PARTICIPATES_IN).
2. Clinical Trials KG:
   • Sources: ClinicalTrials.gov, MeSH, RxNorm, OpenFDA, PubMed.
   • Scale: 7,774,446 nodes, 26,973,997 edges.
   • Schema: 15 node labels (e.g., ClinicalTrial, Drug, AdverseEvent), 25 edge types.

Performance Metrics (Mac Mini M4, 16GB RAM)

• Ingestion Speed: The combined federated graph (7.89M nodes, 27.8M edges) loads in 76 seconds (Pathways: 1s; Clinical Trials: 72s).
• Query Latency:
  • Standard single-KG queries: < 1.5 seconds.
  • Signature Federated Query: "Pathways disrupted by Phase 3 breast cancer drugs" (a 6-hop traversal across both KGs) returns validated results in 2.1 seconds.
• Federation Correctness: The system successfully identified 10 biological pathways (including Signal Transduction, Immune System, and Cell Cycle) disrupted by breast cancer drugs, aligning with known biology (e.g., HER2 signaling, CDK4/6 control).

AI Integration

The schema-driven approach allows LLM agents to access complex graph data via natural language. For example, an agent can ask "What pathways does TP53 participate in?" and automatically invoke the pathway_members tool, receiving structured results without human intervention.

4. Significance and Impact

• Democratization of Biomedical Data: By providing open-source snapshots and ETL code, the authors enable researchers to reproduce complex federated queries in under 2 minutes on commodity hardware, removing the need for massive infrastructure.
• Bridging Translational Gaps: The federation model effectively bridges molecular biology (Pathways KG) and clinical medicine (Clinical Trials KG), enabling queries that were previously impossible without manual data integration.
• AI-Ready Infrastructure: The integration of MCP servers represents a significant step toward making Knowledge Graphs "LLM-native," allowing agents to reason over structured biomedical data without manual tool engineering.
• Generalizability: The authors note that this pattern (independent KGs + snapshot federation + property joins) is applicable to other domains, having already been tested on sports (Cricket KG) and industrial operations.

5. Limitations

• Snapshot Currency: Data is point-in-time; continuous updates require periodic re-exporting.
• Identifier Coverage: Join efficiency depends on the normalization quality of identifiers (e.g., some proteins in clinical trials lack UniProt IDs).
• Storage Overhead: Property-based joins result in duplicate nodes for shared entities, increasing storage compared to a fully merged graph.
• Memory: The full federated graph requires ~8GB RAM, though smaller subsets are accessible on lower-spec machines.

In conclusion, this paper demonstrates a scalable, reproducible, and AI-accessible framework for integrating fragmented biomedical data, proving that high-performance graph federation is achievable on standard hardware with immediate utility for translational research.