Historical Trends Analysis

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: 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: Combines property presence data from SPARQL queries with the property definitions in property_labels.csv. For each entity type and version, calculates what fraction of expected (non-100%) properties are present, then averages across all entities.

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 ?entity
  (GROUP_CONCAT(DISTINCT ?prop; separator=',') AS ?present_props)
WHERE {
  GRAPH ?graph {
    ?entity a {entity_class} .
    ?entity ?prop [] .
    FILTER(?prop IN ({property_list}))
  }
}
GROUP BY ?graph ?entity

What this measures: Shows the distribution of composite completeness scores for individual AOPs per version. Each AOP's score combines its own property completeness with the average completeness of its linked Key Events and Key Event Relationships, giving a holistic view of how well-documented each AOP network is.

Data source: Pre-computed at startup from SPARQL queries. Retrieves AOP, KE, and KER property presence data, calculates individual completeness scores, then aggregates into composite scores per AOP.

Known limitations: Composite scores weight AOP, KE, and KER completeness equally. Excludes 100%-present properties. Box plots show quartiles (Q1, median, Q3) with whiskers at 1.5x IQR. AOPs with no linked KEs or KERs use only their own completeness. 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
  (GROUP_CONCAT(DISTINCT ?prop; separator=',') AS ?aop_props)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    ?aop ?prop [] .
    FILTER(?prop IN ({aop_property_list}))
  }
}
GROUP 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 ?status
  (GROUP_CONCAT(DISTINCT ?prop; separator=',') AS ?present_props)
WHERE {
  GRAPH ?graph {
    ?aop a aopo:AdverseOutcomePathway .
    ?aop aopo:has_oecd_status ?status .
    ?aop ?prop [] .
    FILTER(?prop IN ({property_list}))
  }
}
GROUP BY ?graph ?aop ?status

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(DISTINCT ?ker) AS ?edges)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ker a aopo:KeyEventRelationship . }
  }
}
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 . }
  }
}
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 . }
  }
}
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 . }
  }
}
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: SPARQL queries count KEs with each component type (aopo:has_biological_process, aopo:has_biological_object, aopo:has_action) per version. Totals represent the number of KE-to-component relationships.

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 ?graph
  (COUNT(DISTINCT ?process) AS ?processes)
  (COUNT(DISTINCT ?object) AS ?objects)
  (COUNT(DISTINCT ?action) AS ?actions)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke aopo:has_biological_process ?process . }
    OPTIONAL { ?ke aopo:has_biological_object ?object . }
    OPTIONAL { ?ke aopo:has_action ?action . }
  }
}
GROUP BY ?graph
ORDER BY ?graph

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 ?graph
  (COUNT(DISTINCT ?ke) AS ?total_kes)
  (COUNT(DISTINCT ?process_ke) AS ?with_process)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke aopo:has_biological_process ?p . BIND(?ke AS ?process_ke) }
  }
}
GROUP BY ?graph
ORDER BY ?graph

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 ?graph
  (COUNT(DISTINCT ?process) AS ?unique_processes)
  (COUNT(DISTINCT ?object) AS ?unique_objects)
  (COUNT(DISTINCT ?action) AS ?unique_actions)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke aopo:has_biological_process ?process . }
    OPTIONAL { ?ke aopo:has_biological_object ?object . }
    OPTIONAL { ?ke aopo:has_action ?action . }
  }
}
GROUP BY ?graph
ORDER BY ?graph

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 ?graph ?process (COUNT(?process) AS ?count)
WHERE {
  GRAPH ?graph {
    ?ke aopo:has_biological_process ?process .
  }
}
GROUP BY ?graph ?process
ORDER BY ?graph

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: For each version, SPARQL queries count the component types per KE, then aggregate KEs by their component count (0 through 3). Results show the distribution shift over time.

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 ?ke
  (COUNT(DISTINCT ?process) AS ?p)
  (COUNT(DISTINCT ?object) AS ?o)
  (COUNT(DISTINCT ?action) AS ?a)
WHERE {
  GRAPH ?graph {
    ?ke a aopo:KeyEvent .
    OPTIONAL { ?ke aopo:has_biological_process ?process . }
    OPTIONAL { ?ke aopo:has_biological_object ?object . }
    OPTIONAL { ?ke aopo:has_action ?action . }
  }
}
GROUP BY ?graph ?ke
ORDER BY ?graph

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 from aopo:has_biological_process and aopo:has_biological_object annotations. 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 <{graph}> {
    { ?s aopo:has_biological_process ?term }
    UNION
    { ?s aopo:has_biological_object ?term }
    FILTER(isIRI(?term))
  }
}