Historical Trends

What this measures: Tracks the total number of AOPs, Key Events (KEs), Key Event Relationships (KERs), and Stressors across all available database versions. Shows how the knowledge base has grown over time through quarterly RDF releases.

Data source: Four separate SPARQL queries count instances of each entity class (aopo:AdverseOutcomePathway, aopo:KeyEvent, aopo:KeyEventRelationship, nci:C54571) across all named graph versions. Results are merged into a unified time series.

Known limitations: Data reflects the RDF transformation, not the raw AOP-Wiki database. Entity counts include all instances regardless of completeness or quality. Some versions may have data quality variations due to changes in the RDF conversion pipeline. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph (COUNT(?aop) AS ?count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
  }
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Tracks which metadata properties are present in AOPs over time. Shows absolute counts of AOPs containing each property per version. Properties that are always 100% present are excluded to highlight meaningful variation in documentation completeness.

Data source: Properties are defined in property_labels.csv. For each version, SPARQL queries check how many AOPs have each property present. Uses CSV-based property loading and GROUP_CONCAT aggregation for efficiency.

Known limitations: Properties always present (100%) are excluded for clarity. Measures presence only, not quality of property values. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?p (COUNT(DISTINCT ?AOP) AS ?count)
WHERE {
  GRAPH ?graph {
    ?AOP a aopo:AdverseOutcomePathway ;
         ?p ?o .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?p
ORDER BY ?graph ?p

SELECT ?graph (COUNT(DISTINCT ?AOP) AS ?total)
WHERE {
  GRAPH ?graph { ?AOP a aopo:AdverseOutcomePathway . }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Tracks which metadata properties are present in Key Events over time. Identifies completeness patterns and annotation trends. Uses marker shapes for visual distinction between property lines.

Data source: Properties are defined in property_labels.csv filtered for KE entity type. SPARQL queries check property presence across all Key Events in each version using GROUP_CONCAT aggregation.

Known limitations: Properties always present (100%) are excluded for clarity. Measures presence of each property, not quality or accuracy of the values stored. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?p (COUNT(DISTINCT ?ke) AS ?count)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent ;
        ?p ?o .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?p
ORDER BY ?graph ?p

SELECT ?graph (COUNT(DISTINCT ?ke) AS ?total)
WHERE {
  GRAPH ?graph { ?ke a aopo:KeyEvent . }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Tracks which metadata properties are present in Key Event Relationships over time. Monitors evidence and annotation quality across versions. Uses marker shapes for visual distinction between property lines.

Data source: Properties are defined in property_labels.csv filtered for KER entity type. SPARQL queries check property presence across all KERs in each version using GROUP_CONCAT aggregation.

Known limitations: Properties always present (100%) are excluded for clarity. Measures presence of each property, not the strength or quality of evidence recorded. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?p (COUNT(DISTINCT ?ker) AS ?count)
WHERE {
  GRAPH ?graph {
    ?ker a aopo:KeyEventRelationship ;
         ?p ?o .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?p
ORDER BY ?graph ?p

SELECT ?graph (COUNT(DISTINCT ?ker) AS ?total)
WHERE {
  GRAPH ?graph { ?ker a aopo:KeyEventRelationship . }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Tracks which metadata properties are present in Stressors over time. Identifies documentation patterns and completeness trends for stressor entities. Uses marker shapes for visual distinction.

Data source: Properties are defined in property_labels.csv filtered for Stressor entity type. SPARQL queries check property presence across all Stressors in each version using GROUP_CONCAT aggregation.

Known limitations: Properties always present (100%) are excluded for clarity. Stressors are identified by the NCI Thesaurus type (nci:C54571), which may not capture all stressor-related entities in the knowledge base. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?p (COUNT(DISTINCT ?s) AS ?count)
WHERE {
  GRAPH ?graph {
    ?s a nci:C54571 ;
       ?p ?o .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?p
ORDER BY ?graph ?p

SELECT ?graph (COUNT(DISTINCT ?s) AS ?total)
WHERE {
  GRAPH ?graph { ?s a nci:C54571 . }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Shows the average completeness percentage for AOPs, Key Events, Key Event Relationships, and Stressors over time. Completeness is the fraction of non-ubiquitous properties each entity has filled in, averaged across all entities of that type per version.

Data source: For each of AOP, KE, KER, and Stressor, three SPARQL queries run: (1) total entities per version, (2) property-presence counts per version (used to drop properties that hit 100% in any version), (3) per-entity property counts using the filtered URI list. The disclosed queries show the AOP variant; the plot loops over all four entity types in Python, substituting the entity's RDF type and property list from property_labels.csv before each round-trip. Per-entity completeness is computed in Python as prop_count / total_filtered_properties; the chart shows the mean per version, with one line per entity type.

Known limitations: Excludes properties that are 100% present (always filled in) to focus on optional properties reflecting data richness. Averages can mask bimodal distributions where some entities are very complete and others are very sparse. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph (COUNT(DISTINCT ?aop) AS ?total)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

SELECT ?graph ?p (COUNT(DISTINCT ?aop) AS ?count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway ;
         ?p ?o .
    FILTER(?p IN (
      <http://purl.org/dc/elements/1.1/title>,
      <http://purl.org/dc/terms/abstract>,
      <http://aopkb.org/aop_ontology#has_key_event>,
      <http://aopkb.org/aop_ontology#has_adverse_outcome>
    ))
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?p
ORDER BY ?graph ?p

SELECT ?graph ?aop (COUNT(DISTINCT ?p) AS ?prop_count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway ;
         ?p ?o .
    FILTER(?p IN (
      <http://purl.org/dc/elements/1.1/title>,
      <http://purl.org/dc/terms/abstract>,
      <http://aopkb.org/aop_ontology#has_key_event>,
      <http://aopkb.org/aop_ontology#has_adverse_outcome>
    ))
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?aop
ORDER BY ?graph ?aop

What this measures: Tracks the mean completeness percentage per OECD approval status category across database versions. Shows how documentation quality correlates with the approval pipeline stage over time.

Data source: Combines AOP completeness data with OECD status annotations. For each version and status, calculates the average completeness across all AOPs in that status category.

Known limitations: OECD status data is version-specific and may change between releases. Status categories depend on what is present in the data. Some AOPs may lack status annotations and are excluded from this analysis. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?aop (STR(?status_obj) AS ?status)
  (COUNT(DISTINCT ?p) AS ?prop_count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL {
      ?aop <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C25688> ?status_obj .
    }
    ?aop ?p ?o .
    FILTER(?p IN (
      <http://aopkb.org/aop_ontology#AopContext>,
      <http://aopkb.org/aop_ontology#LifeStageContext>,
      <http://aopkb.org/aop_ontology#has_adverse_outcome>,
      <http://aopkb.org/aop_ontology#has_evidence>,
      <http://aopkb.org/aop_ontology#has_key_event>,
      <http://aopkb.org/aop_ontology#has_key_event_relationship>,
      <http://aopkb.org/aop_ontology#has_molecular_initiating_event>,
      <http://edamontology.org/operation_3799>,
      <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C25217>,
      <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C25688>,
      <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C25725>,
      <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C48192>,
      <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571>,
      <http://purl.bioontology.org/ontology/NCBITAXON/131567>,
      <http://purl.obolibrary.org/obo/PATO_0000047>,
      <http://purl.org/dc/elements/1.1/creator>,
      <http://purl.org/dc/elements/1.1/description>,
      <http://purl.org/dc/elements/1.1/identifier>,
      <http://purl.org/dc/elements/1.1/title>,
      <http://purl.org/dc/terms/abstract>,
      <http://purl.org/dc/terms/alternative>,
      <http://purl.org/dc/terms/created>,
      <http://purl.org/dc/terms/isPartOf>,
      <http://purl.org/dc/terms/modified>,
      <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>,
      <http://www.w3.org/2000/01/rdf-schema#label>,
      <http://www.w3.org/2000/01/rdf-schema#seeAlso>,
      <http://xmlns.com/foaf/0.1/page>
    ))
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?aop ?status_obj

What this measures: Per-version count of distinct stressors typed `nci:C54571`. Same numbers as the Stressors trace of the headline AOP Entity Counts plot, isolated so it can be downloaded, methodology-cited, and toggled to a Δ view on its own. Best read alongside the AOPs-per-stressor distribution to distinguish *broadening* (new stressors) from *deepening* (same stressors, more AOPs).

Data source: One COUNT-per-graph aggregation. The Δ view is computed in Python from the absolute counts (pandas diff).

Known limitations: Counts the distinct stressor URIs of class `nci:C54571` regardless of whether they are linked to any AOP. A stressor may exist in the RDF without yet being attached to an AOP. Trend data covers only the published RDF release versions available in the SPARQL endpoint.

SELECT ?graph (COUNT(DISTINCT ?s) AS ?n_stressors)
WHERE {
  GRAPH ?graph { ?s a <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571> . }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph

What this measures: Per snapshot, stressors bucketed by how many AOPs reference them: {1 AOP, 2 AOPs, 3-5, 6-10, 11+}. The stacked-area view reveals whether AOP-Wiki is broadening (most stressors used in 1 AOP each) or deepening (a few popular stressors carry many AOPs). Latest snapshot has ~74% of stressors in just one AOP — coverage is currently broad and shallow.

Data source: One per-version GROUP BY aggregation returning (graph, stressor URI, #AOPs referencing it). Bucketing is applied in Python. The percentage view normalises against the total number of stressors in that snapshot.

Known limitations: Only counts AOP→stressor edges via the `nci:C54571` predicate (the AOP-Wiki RDF uses the same URI for both the class and the linking predicate — unusual modelling but consistent). Stressors not yet attached to any AOP do not appear in this view (use the Stressor Coverage Growth plot for total counts).

SELECT ?graph ?stressor (COUNT(DISTINCT ?aop) AS ?aop_count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571> ?stressor .
    ?stressor a <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571> .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?stressor

What this measures: Per-version share of Key Events that carry an `obo:MMO_0000000` description — the predicate AOP-Wiki uses for free-text measurement-method / assay text. Currently only ~37% of KEs have one; the gap is the largest single completeness signal for NAM-ready AOPs. Companion to the snapshot donut on the Latest page.

Data source: One per-version aggregation. `SUM(IF(BOUND(?mmo), 1, 0))` counts KEs with at least one MMO triple; `COUNT(?ke)` is the denominator. Percentage = with / total × 100.

Known limitations: Measures presence, not quality — a KE with a one-character MMO string and a KE with a full assay paragraph both count as `with MMO`. Trend data covers only the published RDF release versions available in the SPARQL endpoint.

SELECT ?graph
       (SUM(IF(BOUND(?mmo), 1, 0)) AS ?with_mmo)
       (COUNT(?ke) AS ?total)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke <http://purl.obolibrary.org/obo/MMO_0000000> ?mmo }
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph

What this measures: Number of AOPs classified into each of 13 organ-system buckets at every quarterly snapshot. Toggle 'Show Percentage' to switch to a per-snapshot normalised view. Combines structured-anatomy signals A and A' (UBERON / CL) with Signal B (Process / phenotype — GO BP via RO:0002296, plus HP and MP via UPHENO:0000001). Signal C (keywords) is excluded from the longitudinal view because keyword behaviour tracks title-editing more than coverage growth.

Data source: One SPARQL query per snapshot pulls all AOPs, their member KEs, OrganContext / CellTypeContext / hasObject / hasProcess IRIs, and AOP titles. The UBERON / CL / GO term-to-bucket map is built offline by scripts/build_organ_system_cache.py — it queries Ubergraph (an integrated UBERON+CL+GO+RO ontology endpoint) and writes static/data/organ_system_cache.json. The dashboard loads that cache at startup. Click 'Browse full curated mapping (JSON)' to see the resolved term-to-bucket map, the bucket anchors, and the override layer.

How the mapping works:

1. Step 1 — SPARQL pull. One query per snapshot collects every AOP, its member Key Events, and any IRIs in the four annotation predicates: aopo:OrganContext, aopo:CellTypeContext, aopo:hasObject (inside aopo:hasBiologicalEvent), and aopo:hasProcess. AOP titles are pulled too — Signal C runs on them.
2. Step 2 — UBERON / CL → bucket via Ubergraph (Signals A and A'). Anatomical IRIs are resolved by transitive (part_of | subClassOf)* closure to a small set of anchor IRIs per bucket — e.g. Nervous = UBERON_0001016 (nervous system); Hepatobiliary = liver + gallbladder + bile duct. Anchor-specificity pruning then drops reached anchors that are themselves ancestors of other reached anchors — so liver (UBERON:0002107) classifies only as Hepatobiliary even though UBERON places it under both digestive and endocrine systems. The lookup runs offline against https://ubergraph.apps.renci.org/sparql and is cached at static/data/organ_system_cache.json. Intentional dual-anchors are preserved: pancreas (UBERON_0001264) is its own anchor for both Digestive and Endocrine because it is both an exocrine digestive organ and an endocrine gland — so pancreas-derived terms classify to both.
3. Step 3 — Process / Phenotype signal (Signal B). Three resolution paths into the same 13 buckets: (a) GO biological-process via RO:0002296 (results_in_development_of) → UBERON anchor (~3 terms); (b) HP and MP phenotypes via their rdfs:label matched against the Signal-C bucket regex — this replaces the previous UPHENO:0000001 approach, which Ubergraph materialises as an over-broad anatomy closure (hepatic-steatosis and microvesicular-hepatic-steatosis return the same 35 UBERON targets including endocrine and digestive system). Label-regex gives mono-organ classification when the phenotype name names an organ system. Phenotypes whose label contains no organ keyword (e.g. behavioural HP/MP terms) are NOT classified.
4. Step 4 — Keyword regex on AOP titles (Signal C, exploratory). Each AOP title is scanned with a bucket-specific regex set, e.g. Nervous = \bneuro, \bsynap, \bmyelin, …; Hepatobiliary = \bhepat, \bliver\b, \bsteatosis\b, …; Cardiovascular = \bcardio, \bheart\b, …. Lowest-confidence signal, shown in grey throughout.
5. Step 5 — Editorial override layer. A small project-owned override layer is applied after the ontology resolution to handle terms where the project's framing diverges from UBERON. Currently a single entry: blood (UBERON_0000178) is reported under both Cardiovascular and Immune/Haematopoietic — UBERON places it structurally under haematopoietic only, but toxicology practice frames blood-borne effects as cardiovascular too.
6. Step 6 — Aggregate per AOP. An AOP is counted in a bucket if any of its member KEs (Signals A/A'/B) or its own title (Signal C) classifies into it. The bar segment colour shows the highest-confidence signal that classified the AOP–bucket pair (A > A' > B > C). AOPs can belong to multiple buckets — see the Multi-organ AOPs plot.
7. Step 7 — Source code. Full classifier (~300 LOC, covering classify_anatomy, classify_process, classify_text, the SIGNAL_ORDER reducer, the apical-level filter, and AO-only filter): see plots/organ_systems.py on GitHub. The ontology cache builder is at scripts/build_organ_system_cache.py.

Known limitations: Same caveats as the snapshot views, applied per snapshot. Pre-2020 snapshots have very sparse OrganContext / CellTypeContext annotations — early values should not be read as 'zero biological coverage', only as 'zero structured anatomy coverage at that time'. The percentage view normalises by total AOPs per snapshot, so growth that lags AOP count growth shows as a flat or declining line even when the absolute number rises.

Browse full curated mapping (JSON)

SELECT ?aop ?organ ?cell ?obj ?proc
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke .
    OPTIONAL { ?ke aopo:OrganContext ?organ . }
    OPTIONAL { ?ke aopo:CellTypeContext ?cell . }
    OPTIONAL {
      ?ke aopo:hasBiologicalEvent ?be .
      OPTIONAL { ?be aopo:hasObject ?obj . }
      OPTIONAL { ?be aopo:hasProcess ?proc . }
    }
  }
}

# Signal A only — curated anatomy directly on Key Events
SELECT ?aop ?ke ?organ_or_cell
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke .
    { ?ke aopo:OrganContext   ?organ_or_cell . }
    UNION
    { ?ke aopo:CellTypeContext ?organ_or_cell . }
  }
}

# Signal A' only — UBERON / CL appearing as hasObject inside a biological event
SELECT ?aop ?ke ?obj
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke .
    ?ke  aopo:hasBiologicalEvent ?be .
    ?be  aopo:hasObject ?obj .
    FILTER( STRSTARTS(STR(?obj), "http://purl.obolibrary.org/obo/UBERON_")
         || STRSTARTS(STR(?obj), "http://purl.obolibrary.org/obo/CL_") )
  }
}

# Signal B only — GO biological-process terms (bridged to buckets in Python)
SELECT ?aop ?ke ?proc
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke .
    ?ke  aopo:hasBiologicalEvent ?be .
    ?be  aopo:hasProcess ?proc .
    FILTER( STRSTARTS(STR(?proc), "http://purl.obolibrary.org/obo/GO_") )
  }
}

What this measures: Tracks how densely connected each AOP is on average over time, measured by the number of Key Events and Key Event Relationships per AOP in each version. Indicates whether newer AOPs tend to be more or less complex.

Data source: SPARQL queries count total AOP, KE-to-AOP, and KER-to-AOP relationships across all versions, then compute the ratio per version.

Known limitations: Averages can be dominated by a few very large or very small AOPs. Does not distinguish between well-developed and stub AOPs. Only counts explicitly declared relationships. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph
  (COUNT(DISTINCT ?aop) AS ?aop_count)
  (COUNT(?ke) AS ?ke_count)
  (COUNT(?ker) AS ?ker_count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL { ?aop aopo:has_key_event ?ke . }
    OPTIONAL { ?aop aopo:has_key_event_relationship ?ker . }
  }
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Measures how densely connected the KE-KER graph is over time. Network density is the ratio of actual edges (KERs) to the maximum possible edges between KE nodes, showing whether the knowledge base is becoming more interconnected.

Data source: SPARQL queries count unique Key Events (nodes) and Key Event Relationships (edges) per version. Density = edges / (nodes * (nodes - 1) / 2) for an undirected graph interpretation.

Known limitations: Network density depends on explicitly declared KE-KER relationships in the RDF data. Adding many new KEs without corresponding KERs will decrease density. The metric is sensitive to the number of isolated or poorly connected nodes. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph (COUNT(DISTINCT ?ke) AS ?nodes) (COUNT(?ker) AS ?edges)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke ;
         aopo:has_key_event_relationship ?ker .
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Tracks the number of unique authors contributing to AOPs over time. Shows how the contributor base has grown across database versions.

Data source: SPARQL queries count distinct dc:creator URIs across all AOPs per version. Each unique creator URI is counted once per version.

Known limitations: Author counts are based on unique dc:creator URIs and may not match AOP-Wiki user accounts exactly. Co-authorship is counted per unique URI. Authors who contribute to non-AOP entities are not included. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph (COUNT(DISTINCT ?author) AS ?count)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    ?aop dc:creator ?author .
  }
}
GROUP BY ?graph
ORDER BY ?graph

What this measures: Visualizes temporal patterns of AOP creation and modification. Includes three views: (1) number of AOPs created per year, (2) number of AOPs last modified per year, and (3) a scatter plot of creation date vs. last modification date for each AOP.

Data source: SPARQL queries retrieve dc:date (creation) and dcterms:modified (last modification) timestamps for all AOPs in the latest version. Dates are parsed and grouped by year for the histogram views.

Known limitations: Creation and modification dates reflect what is stored in the RDF data, which may differ from the AOP-Wiki web interface timestamps. Some AOPs may have missing or malformed date values. Only the latest version's date information is used. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?aop ?created ?modified
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL { ?aop dc:date ?created . }
    OPTIONAL { ?aop dcterms:modified ?modified . }
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
ORDER BY DESC(?graph)

What this measures: Visualizes temporal patterns of AOP creation and modification. Includes three views: (1) number of AOPs created per year, (2) number of AOPs last modified per year, and (3) a scatter plot of creation date vs. last modification date for each AOP.

Data source: SPARQL queries retrieve dc:date (creation) and dcterms:modified (last modification) timestamps for all AOPs in the latest version. Dates are parsed and grouped by year for the histogram views.

Known limitations: Creation and modification dates reflect what is stored in the RDF data, which may differ from the AOP-Wiki web interface timestamps. Some AOPs may have missing or malformed date values. Only the latest version's date information is used. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?aop ?created ?modified
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL { ?aop dc:date ?created . }
    OPTIONAL { ?aop dcterms:modified ?modified . }
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
ORDER BY DESC(?graph)

What this measures: Tracks how many Key Event annotations include Process, Object, and Action elements over time. Shows the absolute number of each component type across database versions.

Data source: Per-version parallel SPARQL queries count Key Events that reach process, object, and action annotations via the aopo:hasBiologicalEvent hop (?ke aopo:hasBiologicalEvent ?ev . ?ev aopo:hasProcess|hasObject|hasAction ?term). Totals represent the number of KE-to-component relationships per version graph.

Known limitations: Counts the number of annotations, not unique terms. A KE with multiple process annotations contributes multiple counts. Growth in annotations may reflect both new KEs and enrichment of existing ones. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT
  (COUNT(?process) AS ?process_count)
  (COUNT(?object) AS ?object_count)
  (COUNT(?action) AS ?action_count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?bioevent .
    OPTIONAL { ?bioevent aopo:hasProcess ?process . }
    OPTIONAL { ?bioevent aopo:hasObject ?object . }
    OPTIONAL { ?bioevent aopo:hasAction ?action . }
  }
}

What this measures: Shows how many Key Events have Process, Object, and Action annotations as a percentage of all KEs per version. Normalizes for growth in total KE count to reveal annotation coverage trends.

Data source: Uses the same SPARQL query as KE Component Annotations, but divides each component count by the total KE count per version to produce percentages.

Known limitations: Percentage calculations assume consistent definition of what constitutes a KE across versions. Changes in RDF conversion methodology could affect comparability between versions. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT
  (COUNT(?process) AS ?process_count)
  (COUNT(?object) AS ?object_count)
  (COUNT(?action) AS ?action_count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?bioevent .
    OPTIONAL { ?bioevent aopo:hasProcess ?process . }
    OPTIONAL { ?bioevent aopo:hasObject ?object . }
    OPTIONAL { ?bioevent aopo:hasAction ?action . }
  }
}

What this measures: Tracks the total number of unique (distinct) Process, Object, and Action annotations used in Key Events over time. Unlike the component count, this measures the vocabulary diversity of annotations.

Data source: SPARQL queries count distinct URIs for each component type (biological processes, objects, actions) across all KEs per version.

Known limitations: Unique counts are based on distinct URIs, so the same biological concept referenced by different ontology URIs would be counted separately. Does not measure the frequency of use for each unique term. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT
  (COUNT(DISTINCT ?process) AS ?process_count)
  (COUNT(DISTINCT ?object) AS ?object_count)
  (COUNT(DISTINCT ?action) AS ?action_count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?bioevent .
    OPTIONAL { ?bioevent aopo:hasProcess ?process . }
    OPTIONAL { ?bioevent aopo:hasObject ?object . }
    OPTIONAL { ?bioevent aopo:hasAction ?action . }
  }
}

What this measures: Tracks KE annotations with biological processes and objects grouped by ontology source. Shows which ontologies (GO, MESH, NCIT, etc.) are most commonly used for annotating Key Events over time.

Data source: SPARQL queries retrieve all biological process and object URIs from KE annotations, classify them by ontology namespace prefix, and count occurrences per version.

Known limitations: Ontology classification is based on URI prefix pattern matching. Some URIs may not match known prefixes and would be classified as 'Other'. Does not measure the quality or specificity of ontology term usage. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?process (COUNT(?process) AS ?count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?bioevent .
    ?bioevent aopo:hasProcess ?process .
  }
}
GROUP BY ?process

What this measures: Tracks KE annotations with biological processes and objects grouped by ontology source. Shows which ontologies (GO, MESH, NCIT, etc.) are most commonly used for annotating Key Events over time.

Data source: SPARQL queries retrieve all biological process and object URIs from KE annotations, classify them by ontology namespace prefix, and count occurrences per version.

Known limitations: Ontology classification is based on URI prefix pattern matching. Some URIs may not match known prefixes and would be classified as 'Other'. Does not measure the quality or specificity of ontology term usage. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?process (COUNT(?process) AS ?count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?bioevent .
    ?bioevent aopo:hasProcess ?process .
  }
}
GROUP BY ?process

What this measures: Tracks how many Key Events contain a specific number of Key Event Components (0, 1, 2, or 3) over time. Reveals annotation completeness trends and whether the community is enriching existing KEs or primarily creating new ones.

Data source: A SPARQL query counts biological-event annotations per Key Event (?ke aopo:hasBiologicalEvent ?bioevent) using an inner subquery, then buckets KEs into groups by their bioevent count (0, 1, 2, 3, 4, 5, 6+) per version graph.

Known limitations: Only counts distinct component types (max 3: Process, Object, Action), not total annotations. A KE with multiple processes but no objects or actions would count as 1. Does not measure annotation quality. Trend data covers only the published RDF release versions available in the SPARQL endpoint; the AOP-Wiki knowledge base predates the earliest RDF release, so earlier activity is not captured.

SELECT ?graph ?bioevent_count_group
  (COUNT(DISTINCT ?ke) AS ?total_kes)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke aopo:hasBiologicalEvent ?bioevent . }
    {
      SELECT ?ke (COUNT(DISTINCT ?bioevent2) AS ?bioevent_count)
      WHERE {
        ?ke a aopo:KeyEvent .
        OPTIONAL { ?ke aopo:hasBiologicalEvent ?bioevent2 . }
      }
      GROUP BY ?ke
    }
    BIND(
      IF(?bioevent_count = 0, "0",
        IF(?bioevent_count = 1, "1",
          IF(?bioevent_count = 2, "2",
            IF(?bioevent_count = 3, "3",
              IF(?bioevent_count = 4, "4",
                IF(?bioevent_count = 5, "5",
                  IF(?bioevent_count >= 6, "6+", ">1"))))))) AS ?bioevent_count_group
    )
  }
  FILTER(STRSTARTS(STR(?graph), "http://aopwiki.org/graph/"))
}
GROUP BY ?graph ?bioevent_count_group
ORDER BY ?graph xsd:integer(?bioevent_count_group)

What this measures: Tracks the number of unique ontology terms used in biological process and object annotations across database versions. Growth indicates expanding annotation vocabulary and richer biological characterization.

Data source: Per-version parallel SPARQL queries count distinct IRI-valued terms reached from Key Events via the aopo:hasBiologicalEvent hop, taking the union of aopo:hasProcess and aopo:hasObject paths. Results are plotted as line chart (absolute) and bar chart (delta per version).

Known limitations: Counts unique term IRIs, not unique biological concepts (different IRIs may reference the same concept across ontologies). Only covers process and object annotations. Trend data covers only the published RDF release versions available in the SPARQL endpoint.

SELECT (COUNT(DISTINCT ?term) AS ?unique_terms)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-04-01> {
    ?ke a aopo:KeyEvent ;
        aopo:hasBiologicalEvent ?be .
    { ?be aopo:hasProcess ?term . }
    UNION
    { ?be aopo:hasObject ?term . }
    FILTER(isIRI(?term))
  }
}