Database Snapshot

What this measures: Breaks down entity counts (AOPs, Key Events, Key Event Relationships) by OECD approval status category. Shows how curation maturity is distributed across entity types.

Data source: Three separate SPARQL queries count AOPs directly by their OECD Status annotation (NCI Thesaurus C25688), and KEs/KERs by the OECD status of their parent AOPs (via aopo:has_key_event and aopo:has_key_event_relationship relationships).

Known limitations: KEs and KERs inherit OECD status from their parent AOPs. A KE belonging to AOPs with different statuses appears in each status group. AOPs without an OECD status annotation appear as 'No Status'. Status categories reflect what is present in the data.

SELECT ?status_label (COUNT(DISTINCT ?aop) AS ?count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL { ?aop <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C25688> ?status_obj . }
    BIND(IF(BOUND(?status_obj), STR(?status_obj), 'No Status') AS ?status_label)
  }
}
GROUP BY ?status_label

What this measures: Same per-AOP hybrid classification as before, but with two toggles. Scope picks which Key Events count toward Signals A, A' and B: all KEs (broadest), Apical KEs only (Tissue/Organ/Individual/Population), or just the Adverse Outcome (regulatory endpoint). Signal C (AOP title regex) is kept regardless of scope. View switches between absolute AOP counts and share of all AOPs in the snapshot. The four legacy panels collapse into this single view; the pie below mirrors the same scope so you read one coherent slice across the section.

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.

Known limitations: The bucket anchors are curated (13 buckets × ~1-4 anchors each). UBERON's own structural decisions drive the rest — e.g. blood is haematopoietic, not cardiovascular, in UBERON; we override that one case. Signal B only classifies 3 GO BPs in the current snapshot because the RO:0002296 axiom is rare in GO — the trade-off vs a hand-curated bridge is conscious. Signal C is regex on free-text titles, shown in grey; not for regulatory claims. The 13 buckets are coarse — sub-organ resolution is collapsed for the headline view but preserved in the CSV download.

Browse full curated mapping (JSON)

SELECT ?aop ?aop_title ?ao ?ke ?organ ?cell ?obj ?proc
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title ;
         aopo:has_key_event ?ke .
    OPTIONAL { ?aop aopo:has_adverse_outcome ?ao . }
    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-01-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-01-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-01-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_") )
  }
}

# Signal C precursor — fetch AOP and AO titles (Signal C runs as regex in
# Python against these literals; the curated patterns are listed at
# /api/organ-system-buckets under "keyword_patterns").
SELECT ?aop ?aop_title ?ao ?ao_title
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title .
    OPTIONAL {
      ?aop aopo:has_adverse_outcome ?ao .
      OPTIONAL { ?ao <http://purl.org/dc/elements/1.1/title> ?ao_title . }
    }
  }
}

What this measures: Pie view of the bucket distribution at the currently selected scope. Each AOP is counted once per bucket it lands in via the hybrid signal pipeline (A / A' / B / C), so slices sum to bucket-memberships, not to total AOPs. The grey 'Unclassified' slice surfaces AOPs that the scope leaves with no signal — useful for spotting false negatives at stricter scopes (e.g. AO-only typically leaves the largest unclassified slice).

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.

Known limitations: Because an AOP can be in multiple buckets, slice percentages describe the share of bucket-memberships, not the share of AOPs. The same caveats as the bar chart apply: curated bucket anchors, UBERON-driven over-classification in some cases (e.g. liver → endocrine via subClassOf), Signal C is regex on free-text titles, etc. See the bar-chart methodology for the full signal queries.

Browse full curated mapping (JSON)

SELECT ?aop ?aop_title ?ao ?ke ?organ ?cell ?obj ?proc
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title ;
         aopo:has_key_event ?ke .
    OPTIONAL { ?aop aopo:has_adverse_outcome ?ao . }
    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-01-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-01-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-01-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_") )
  }
}

# Signal C precursor — fetch AOP and AO titles (Signal C runs as regex in
# Python against these literals; the curated patterns are listed at
# /api/organ-system-buckets under "keyword_patterns").
SELECT ?aop ?aop_title ?ao ?ao_title
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title .
    OPTIONAL {
      ?aop aopo:has_adverse_outcome ?ao .
      OPTIONAL { ?ao <http://purl.org/dc/elements/1.1/title> ?ao_title . }
    }
  }
}

What this measures: Distribution of AOPs by the number of distinct organ systems they classify into across Signals A, A', B, and C (excluding the No-annotation sentinel). Answers 'how many AOPs are single-organ vs multi-organ?'. The raw-data toggle lists every multi-organ AOP with its full bucket set, so you can inspect which pathways span e.g. Endocrine + Reproductive + Nervous.

Data source: Reuses the same SPARQL pull and ontology resolution as the AOP Coverage plot. For each AOP we count the number of distinct organ-system buckets it lands in via any of the four signals.

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.

Known limitations: An AOP appearing in multiple buckets does not necessarily mean it is biologically multi-system — it can also mean Signal C (keywords) added an extra bucket on top of Signal A's curated anatomy. The CSV preserves which signal(s) contributed each bucket so this is auditable.

Browse full curated mapping (JSON)

SELECT ?aop ?aop_title ?ao ?ke ?organ ?cell ?obj ?proc
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title ;
         aopo:has_key_event ?ke .
    OPTIONAL { ?aop aopo:has_adverse_outcome ?ao . }
    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-01-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-01-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-01-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_") )
  }
}

# Signal C precursor — fetch AOP and AO titles (Signal C runs as regex in
# Python against these literals; the curated patterns are listed at
# /api/organ-system-buckets under "keyword_patterns").
SELECT ?aop ?aop_title ?ao ?ao_title
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         <http://purl.org/dc/elements/1.1/title> ?aop_title .
    OPTIONAL {
      ?aop aopo:has_adverse_outcome ?ao .
      OPTIONAL { ?ao <http://purl.org/dc/elements/1.1/title> ?ao_title . }
    }
  }
}

What this measures: Counts how many AOPs declare each life-stage applicability label (Adult, Juvenile, Embryo, All life stages, etc.) via aopo:LifeStageContext. An AOP with no LifeStageContext literal at all is reported as Not specified. AOPs with multiple life-stage labels contribute once per label.

Data source: Single SPARQL query selecting every aopo:AdverseOutcomePathway and OPTIONAL aopo:LifeStageContext literal in the selected snapshot. Aggregation happens in Python after deduplicating per AOP.

Known limitations: aopo:LifeStageContext values are free-text literals chosen by curators — there is no fixed controlled vocabulary, so spelling variants (e.g. "Adult" vs "Adults") appear as distinct bars. Sex applicability is NOT exposed as a structured RDF predicate; it is only described inside free-text aopo:AopContext literals and cannot be machine-aggregated reliably. The dashboard surfaces this gap rather than guessing.

SELECT ?aop ?life_stage
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway .
    OPTIONAL { ?aop aopo:LifeStageContext ?life_stage . }
  }
}

What this measures: Shows the top 30 Key Events that appear in the most AOPs, revealing shared biology across adverse outcome pathways. Clicking a bar opens the corresponding KE page on AOP-Wiki.

Data source: SPARQL query counts distinct AOPs per Key Event via aopo:has_key_event relationships. Only KEs appearing in more than one AOP are shown. KE titles are retrieved via dc:title.

Known limitations: Limited to the top 30 most reused KEs. KE titles may be truncated for readability. The count reflects explicit aopo:has_key_event declarations in the RDF data. Entity links open https://aopwiki.org/events/{id} in a new tab.

SELECT ?ke (SAMPLE(?title_val) AS ?title) (COUNT(DISTINCT ?aop) AS ?aop_count)
WHERE {
  GRAPH <http://aopwiki.org/graph/2026-01-01> {
    ?aop a aopo:AdverseOutcomePathway ;
         aopo:has_key_event ?ke .
    OPTIONAL { ?ke dc:title ?title_val . }
  }
}
GROUP BY ?ke
HAVING (COUNT(DISTINCT ?aop) > 1)
ORDER BY DESC(?aop_count)
LIMIT 30

What this measures: Analyzes how completely AOPs are documented by measuring the presence of key metadata properties. Shows the distribution of completeness scores across all AOPs, where completeness is the fraction of non-ubiquitous properties that are filled in.

Data source: Properties are loaded from property_labels.csv which defines expected properties per entity type. For each AOP, SPARQL queries check presence of each property. Properties that are 100% present (always filled) are excluded to focus on informative variation.

Known limitations: Completeness is based on property presence, not quality or accuracy of the data. Properties always present (100%) are excluded from the calculation. The property list is defined externally and may not capture all relevant metadata.

SELECT ?graph ?aop
  (GROUP_CONCAT(DISTINCT ?prop; separator=',') AS ?present_props)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    ?aop ?prop [] .
    FILTER(?prop IN (<http://aopkb.org/aop_ontology#has_key_event>, <http://aopkb.org/aop_ontology#has_key_event_relationship>, <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571>, <http://aopkb.org/aop_ontology#has_molecular_initiating_event>, <http://aopkb.org/aop_ontology#has_adverse_outcome>, <http://purl.org/dc/elements/1.1/title>, <http://purl.org/dc/terms/abstract>, <http://xmlns.com/foaf/0.1/page>, <http://purl.org/dc/elements/1.1/creator>, <http://purl.org/dc/terms/created>, <http://purl.org/dc/terms/modified>, <http://www.w3.org/2000/01/rdf-schema#label>, <http://www.w3.org/2000/01/rdf-schema#seeAlso>, <http://purl.org/dc/elements/1.1/identifier>, <http://purl.org/dc/elements/1.1/description>, <http://aopkb.org/aop_ontology#AopContext>, <http://aopkb.org/aop_ontology#LifeStageContext>, <http://aopkb.org/aop_ontology#has_evidence>, <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://purl.obolibrary.org/obo/PATO_0000047>, <http://purl.org/dc/terms/alternative>, <http://edamontology.org/operation_3799>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://purl.org/dc/terms/isPartOf>, <http://purl.bioontology.org/ontology/NCBITAXON/131567>))
  }
}
GROUP BY ?graph ?aop
ORDER BY DESC(?graph)

What this measures: Compares AOP completeness scores across OECD approval status categories (e.g., Endorsed, Under Review, Under Development). Reveals whether more mature AOPs tend to be better documented. Properties are grouped into categories: Essential, Content, Context, Assessment, and Metadata.

Data source: Combines AOP completeness data with OECD status information. SPARQL queries retrieve both property presence counts and the OECD status for each AOP. Status is determined via the aopo:has_oecd_status predicate.

Known limitations: OECD status data is version-specific and may change between releases. Some AOPs may lack a status annotation. Properties always present (100%) are excluded from completeness calculation. Status categories reflect the OECD approval pipeline stages present in the data.

SELECT ?graph ?aop ?status
  (GROUP_CONCAT(DISTINCT ?prop; separator=',') AS ?present_props)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    ?aop ?prop [] .
    OPTIONAL { ?aop aopo:has_oecd_status ?status . }
    FILTER(?prop IN (<http://aopkb.org/aop_ontology#has_key_event>, <http://aopkb.org/aop_ontology#has_key_event_relationship>, <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571>, <http://aopkb.org/aop_ontology#has_molecular_initiating_event>, <http://aopkb.org/aop_ontology#has_adverse_outcome>, <http://purl.org/dc/elements/1.1/title>, <http://purl.org/dc/terms/abstract>, <http://xmlns.com/foaf/0.1/page>, <http://purl.org/dc/elements/1.1/creator>, <http://purl.org/dc/terms/created>, <http://purl.org/dc/terms/modified>, <http://www.w3.org/2000/01/rdf-schema#label>, <http://www.w3.org/2000/01/rdf-schema#seeAlso>, <http://purl.org/dc/elements/1.1/identifier>, <http://purl.org/dc/elements/1.1/description>, <http://aopkb.org/aop_ontology#AopContext>, <http://aopkb.org/aop_ontology#LifeStageContext>, <http://aopkb.org/aop_ontology#has_evidence>, <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://purl.obolibrary.org/obo/PATO_0000047>, <http://purl.org/dc/terms/alternative>, <http://edamontology.org/operation_3799>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://purl.org/dc/terms/isPartOf>, <http://purl.bioontology.org/ontology/NCBITAXON/131567>))
  }
}
GROUP BY ?graph ?aop ?status

What this measures: Measures completeness of Key Events based on the OECD status of the AOPs they belong to. KEs linked to multiple AOPs with different statuses are counted for each status. Property categories include Essential (Title, Description), Content (Biological components), Context (Applicability), Assessment (Evidence), and Metadata.

Data source: SPARQL queries join KE property presence data with AOP status information via the aopo:has_key_event relationship. Each KE inherits the status of its parent AOP(s).

Known limitations: A KE belonging to multiple AOPs with different OECD statuses will appear in each status group, potentially inflating counts. KEs not linked to any AOP are excluded. Properties always present are excluded from completeness scores.

SELECT ?graph ?ke ?status
  (COUNT(DISTINCT ?prop) AS ?prop_count)
WHERE {
  GRAPH ?graph {
    ?aop aopo:has_key_event ?ke .
    ?aop aopo:has_oecd_status ?status .
    ?ke ?prop [] .
    FILTER(?prop IN (<http://aopkb.org/aop_ontology#has_key_event>, <http://aopkb.org/aop_ontology#has_key_event_relationship>, <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571>, <http://aopkb.org/aop_ontology#has_molecular_initiating_event>, <http://aopkb.org/aop_ontology#has_adverse_outcome>, <http://purl.org/dc/elements/1.1/title>, <http://purl.org/dc/terms/abstract>, <http://xmlns.com/foaf/0.1/page>, <http://purl.org/dc/elements/1.1/creator>, <http://purl.org/dc/terms/created>, <http://purl.org/dc/terms/modified>, <http://www.w3.org/2000/01/rdf-schema#label>, <http://www.w3.org/2000/01/rdf-schema#seeAlso>, <http://purl.org/dc/elements/1.1/identifier>, <http://purl.org/dc/elements/1.1/description>, <http://aopkb.org/aop_ontology#AopContext>, <http://aopkb.org/aop_ontology#LifeStageContext>, <http://aopkb.org/aop_ontology#has_evidence>, <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://purl.obolibrary.org/obo/PATO_0000047>, <http://purl.org/dc/terms/alternative>, <http://edamontology.org/operation_3799>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://purl.org/dc/terms/isPartOf>, <http://purl.bioontology.org/ontology/NCBITAXON/131567>))
  }
}
GROUP BY ?graph ?ke ?status

What this measures: Measures completeness of Key Event Relationships based on the OECD status of the AOPs they belong to. KERs linked to multiple AOPs with different statuses are counted for each status. Property categories include Essential, Content, Context, and Metadata.

Data source: SPARQL queries join KER property presence data with AOP status information via the aopo:has_key_event_relationship predicate. Each KER inherits the status of its parent AOP(s).

Known limitations: A KER belonging to multiple AOPs with different OECD statuses will appear in each status group. KERs not linked to any AOP are excluded. Properties always present are excluded from completeness scores.

SELECT ?graph ?ker ?status
  (COUNT(DISTINCT ?prop) AS ?prop_count)
WHERE {
  GRAPH ?graph {
    ?aop aopo:has_key_event_relationship ?ker .
    ?aop aopo:has_oecd_status ?status .
    ?ker ?prop [] .
    FILTER(?prop IN (<http://aopkb.org/aop_ontology#has_key_event>, <http://aopkb.org/aop_ontology#has_key_event_relationship>, <http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl#C54571>, <http://aopkb.org/aop_ontology#has_molecular_initiating_event>, <http://aopkb.org/aop_ontology#has_adverse_outcome>, <http://purl.org/dc/elements/1.1/title>, <http://purl.org/dc/terms/abstract>, <http://xmlns.com/foaf/0.1/page>, <http://purl.org/dc/elements/1.1/creator>, <http://purl.org/dc/terms/created>, <http://purl.org/dc/terms/modified>, <http://www.w3.org/2000/01/rdf-schema#label>, <http://www.w3.org/2000/01/rdf-schema#seeAlso>, <http://purl.org/dc/elements/1.1/identifier>, <http://purl.org/dc/elements/1.1/description>, <http://aopkb.org/aop_ontology#AopContext>, <http://aopkb.org/aop_ontology#LifeStageContext>, <http://aopkb.org/aop_ontology#has_evidence>, <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://purl.obolibrary.org/obo/PATO_0000047>, <http://purl.org/dc/terms/alternative>, <http://edamontology.org/operation_3799>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://purl.org/dc/terms/isPartOf>, <http://purl.bioontology.org/ontology/NCBITAXON/131567>))
  }
}
GROUP BY ?graph ?ker ?status