dbparser - Paper Simplified

# dbparser - Paper Simplified dbparser is an open-source R package. It turns drug databases in different formats into one standard R object, then joins them through DrugBank IDs. It is the engine under [[Drugverse]] DB Parser. Source: Mohammed Ali and Ali Ezzat, "dbparser: An R Package for Parsing and Integrating Pharmacological Databases", *Journal of Open Source Software* 11(118), 9950, Feb 2026.^[Source: [JOSS paper](https://joss.theoj.org/papers/10.21105/joss.09950)] ## The problem in one picture Each database ships in a different shape. Each team writes its own scripts to read and join them. ```mermaid graph LR D[DrugBank deeply nested XML] --> S1[custom script] O[OnSIDES many relational CSVs] --> S2[custom script] T[TWOSIDES compressed flat files, other ID system] --> S3[custom script] S1 --> M{{manual ID matching}} S2 --> M S3 --> M M --> A[analysis slow, error-prone, not reproducible] ``` - Data preparation takes 60–80% of analysis time (paper cites Wickham, 2014). - Commercial integrated platforms (Clarivate Cortellis, Certara D360) cost ~$10k–$50k+ per year. - Other tools cover one database only (drugbankr, pydrugbank) or call live APIs (bioservices). Live APIs change, so results do not repeat. ## The three databases | Database | What it holds | Input format | Parse time* | |---|---|---|---| | **DrugBank** | Drugs, targets, pathways, interactions | XML, ~2.5 GB | 3–5 min | | **OnSIDES** | Side effects from FDA labels, with ML confidence scores | Relational CSVs, ~500 MB | <30 s | | **TWOSIDES** | Adverse events from drug–drug combinations | Compressed CSV, ~1.2 GB | ~1 min | *8-core CPU, 16 GB RAM. > [!note] Name check > These are the "OnSIDES" and "TWOSIDES" from the [[Drugverse]] call transcript. Open Targets and HGNC are not in this paper. They are likely newer Drugverse work. ## How it works ```mermaid graph LR R1[DrugBank XML] -->|parseDrugBank| V1[dvobject] R2[OnSIDES CSVs] -->|parseOnSIDES| V2[dvobject] R3[TWOSIDES CSV] -->|parseTWOSIDES| V3[dvobject] V1 --> J1[merge_drugbank_onsides] V2 --> J1 J1 --> J2[merge_drugbank_twosides] V3 --> J2 J2 --> I[Integrated dvobject ready for analysis] ``` Three steps: 1. **Parse.** One function per database. Fast readers: streaming XML (xml2) and `data.table::fread` for CSVs. 2. **Standardise.** Each output is a **dvobject**. Same shape for every source. 3. **Merge.** Chain merge functions with the R pipe (`%>%`). Each merge adds one database. ## Idea 1 · The dvobject One standard container. The same analysis code works on any source. ```mermaid graph TD V[dvobject] --> T[Tidy tables drugs, targets, categories ...] V --> M[Metadata version, parse time, schema] V --> L[Relationship map which table links to which] ``` - **Tidy tables**: work directly with tidyverse tools. - **Metadata**: records the source version. This is what makes results repeatable. - **Relationship map**: keeps the original links (drug → target → pathway). - Trade-off: it gives up format-specific speed to get one common shape. ## Idea 2 · Hub-and-spoke joins DrugBank is the hub. Every other database joins to DrugBank, not to each other. ```mermaid graph TD subgraph "All-to-all: every pair needs a mapping" a1[DrugBank] --- a2[OnSIDES] a2 --- a3[TWOSIDES] a3 --- a1 a1 --- a4[DB 4] a2 --- a4 a3 --- a4 end subgraph "Hub-and-spoke: one mapping per database" h[DrugBank hub RxCUI, PubChem, ChEMBL, KEGG IDs] --- b2[OnSIDES] h --- b3[TWOSIDES] h --- b4[DB 4] end ``` Why it matters: the number of ID mappings grows much more slowly. | Databases | All-to-all mappings | Hub-and-spoke mappings | |---|---|---| | 3 | 3 | 2 | | 4 | 6 | 3 | | 10 | 45 | 9 | | 20 | 190 | 19 | - All-to-all grows as n(n−1)/2. Hub-and-spoke grows as n−1. - DrugBank already stores IDs from other systems (RxCUI, PubChem, ChEMBL, KEGG). So it is a natural hub. - Trade-off: no DrugBank, no multi-database join. A drug missing from DrugBank cannot link. ## Idea 3 · Drug-centric model Genomics tools (Bioconductor, biomaRt) assume a gene-first chain. Drug work needs a drug-first chain. ```mermaid graph LR subgraph Genomics tools g1[Gene] --> g2[Variant] --> g3[Phenotype] end subgraph dbparser d1[Drug] --> d2[Target] --> d3[Pathway] --> d4[Disease] --> d5[Adverse event] end ``` Forcing drug data into a gene-first model creates mismatch. dbparser is built for the drug-first chain. ## Worked example Question: what are the most common side effects of anticoagulants? 1. Parse DrugBank and OnSIDES. Merge them. 2. Filter DrugBank drugs by category "Anticoagulants". 3. Count their OnSIDES side effects. 4. Top result: haemorrhage. This matches known clinical findings. The merged object then links straight to DrugBank targets or TWOSIDES interactions. ## Proof of traction - First CRAN release Jan 2019. Version 2.2.1 (Jan 2026). MIT licence. - 50,000+ CRAN downloads, ~780 per month. - 98% test coverage. rOpenSci peer review (2020). OpenSSF Best Practices badge. Listed in the CRAN Epidemiology Task View. - Used in 10+ peer-reviewed papers: drug repurposing (Alzheimer's, COVID-19, hearing loss), cancer networks, clinical ML. - Downstream packages: **dbdataset** (pre-parsed DrugBank data) and **covid19dbcand** (COVID-19 drug candidates). ## What this means for Drugverse - **Credibility asset.** Peer-reviewed, cited, widely downloaded. Use it in every pitch. See [[Biotech Neo Labs - Buyer List]]. - **Hub-and-spoke scales.** Each new source costs one mapping, not n. This is how Drugverse can add Open Targets, HGNC and more. - **Versioned metadata = reproducibility.** This is the base for time-split evals. See [[Drugverse RL Environments and Data Play]]. - **Limit to fix.** The hub depends on DrugBank. DrugBank needs a commercial licence for commercial use. A licence-free hub (or a second hub for genes, e.g. HGNC) lowers this risk. - **R-only today.** Postgres plus an API opens it to Python users and agents. See [[Making Drugverse Agent-Accessible]]. ---- tags: #boat #deeptech links: [[Drugverse]] [[TechBio MoC]] [[Drug Discovery]] [[knowledge graphs]] [[ontologies]]