Data Model
How PlasticDB structures every degradation claim as traceable evidence.
The evidence spine
PlasticDB does not store “organism X degrades plastic Y” as a flat fact. Every degradation claim is anchored to the evidence that supports it, through a chain of records called the evidence spine:
Reference (paper)└─
Interaction one actor × one plastic, as claimed by this paper├─
Actor a Microorganism, Protein, or Protein Variant├─
Sample Source where the microbe was isolated in this study└─
Experiment one method / assay run under stated conditions├─
Observation one measurement the experiment produced└─
Substrate Composition constituents of a blend/copolymer
A single row of evidence is one Interaction: it names one actor, one plastic, and the paper's overall verdict, then hangs one or more Experiments off it, each holding the Observations (numbers) it produced. An organism tested against three plastics is three interactions; a plastic probed by two methods is two experiments under one interaction.
Papers are never linked directly to an organism or protein — a paper's organisms are derived from the interactions it supports. This is why every fact attaches to an interaction rather than to a standalone organism record.
Actors: what degrades the plastic
Every interaction has exactly one actor, of one of three kinds:
| Actor | What it is | Detail page |
|---|---|---|
| Microorganism | A species-level microbe (bacterium, fungus, archaeon). Identity is species-level; strain and isolation details live on the interaction, because the same species recurs across papers with different isolates. | /microorganisms/{tax_id} |
| Protein | A characterised enzyme, identified by name plus an accession (GenBank / UniProt / PDB). A cell-free enzyme assay is a protein claim — distinct from the source organism degrading plastic. | /proteins/{accession} |
| Protein Variant | An engineered or otherwise modified version of a parent protein (e.g. a stabilised PETase mutant). A first-class record with its own accession — not folded into its parent. | /variants/{id} |
What is stored vs. what is derived
Producers (curators and the extraction pipeline) supply identity and observations. Anything computable from an identifier is filled in automatically by the enrichment pipeline and should never be hand-entered:
| Supplied by the producer | Derived by the server |
|---|---|
| Species name + NCBI tax ID | Full taxonomic lineage (domain → genus) |
| Protein name + accession (GenBank / UniProt / PDB) | Amino-acid sequence, EC number, signal peptide, GO / InterPro / CAZy cross-references, 3D structure |
| Variant name, parent, mutations | Variant accession, and the same enrichment annotations as proteins |
| The plastic's name | The canonical plastic record it resolves to |
This division keeps the database internally consistent: identifiers are the single source of truth, and derived annotations stay current as the reference databases (NCBI, UniProt, PDB) update. The Contributing Data page documents every field a producer supplies, and Reading Results explains how these records surface as badges and counts.