A CSV knows what the state charged. It doesn't know what the state violated.

Here is a row from the OVD-Info dataset:

This row tells you four things: who, what charge, when, and current status. Python can count how many people were charged under 207.3. It can compute co-occurrence with other articles. It can test whether the charging structure changed after 2022. All of that is the CSV analysis, and it works.

But the row does not tell you:

Three layers. Each does something the others cannot.

The CSV is the raw material. The SKOS is the legal assessment. The A-Box is the bridge. SPARQL is the query language that crosses all three in one call. Remove any layer and the question "how many people are detained under statutes that violate Article 19?" becomes unanswerable without manual counting.

The state's language and our assessment, separated by construction.

When Russia charges someone under Article 207.3, the charge sheet says "dissemination of knowingly false information about the use of the Armed Forces." That is the state's characterization. Our assessment is that this provision criminalizes protected expression under ICCPR Article 19. These are two different claims, made by two different actors, and the ontology keeps them apart.

The SKOS vocabulary is not a database. It is a controlled vocabulary with editorial provenance. Every annotation records who made the assessment, on what basis, and how confident they are. This is what makes the output citable in a legal proceeding: the tribunal can inspect the reasoning behind each ICCPR mapping, not just the conclusion.

You could add an "iccpr_violation" column to a CSV. But a CSV column is a flat string. It cannot encode the reasoning, the three-tier classification, the provenance, or the relationship between the analyst's assessment and the state's terminology. It cannot be validated by an OWL reasoner. It cannot be merged with another dataset's vocabulary. The SKOS can do all of these.

NetworkX finds the structure. The ontology explains what it means.

The charge co-occurrence graph is a weighted undirected network where nodes are Criminal Code articles and edge weights are the number of people charged under both. NetworkX builds this graph from the CSV. Then Louvain community detection partitions the graph into clusters without being told what to look for. The clusters are not hypothesized. They are discovered.

This is the analytical engine of the pipeline. It produces the findings that make the reports worth reading: three regimes in Russia, four communities collapsing in Belarus, a civilian-military bifurcation in Myanmar. None of these were assumed. All were detected by Louvain and validated by permutation testing.

NetworkX runs on the CSV. It does not need the ontology. But it produces findings that the ontology makes citable. "Louvain found 7 communities with Q=0.47" is a statistical result. "The 7 communities correspond to three regimes, each violating a different ICCPR article" is a legal finding. The first requires NetworkX. The second requires SKOS. You need both.

The query that justifies the entire architecture.

Here is the SPARQL query that returns the number of prosecutions by ICCPR article violated, run against the Myanmar merged graph (386,648 triples):

PREFIX ont: <http://repressions.myanmar/ontology/>
PREFIX iccpr: <http://www.ohchr.org/EN/ProfessionalInterest/Pages/CCPR#>

SELECT ?iccpr_article (COUNT(DISTINCT ?persecution) AS ?n)
WHERE {
    ?persecution a ont:Persecution ;
                 ont:hasCharge ?charge .
    ?charge ont:iccprViolation ?iccpr_article .
}
GROUP BY ?iccpr_article
ORDER BY DESC(?n)

This query does something no Python script running on a CSV can do: it crosses the A-Box (which knows that persecution X has charge Y) with the SKOS (which knows that charge Y violates ICCPR Article Z) and returns the count. The result:

To produce this table from a CSV, you would need to:

One schema. Four countries. The same SPARQL.

The T-Box (class definitions and property axioms) is the same across Cuba, Russia, Belarus, and Myanmar. A Persecution has a Person and one or more ChargeArticle instances, connected by hasPerson and hasCharge relations. Each ChargeArticle links to ICCPR provisions via iccprViolation.

Because the schema is shared, the same SPARQL query runs against any country's graph. "How many people are detained under facially incompatible statutes?" returns 9,029 for Myanmar, 6,298 for Belarus, and a corresponding count for Russia and Cuba. The query does not change. The vocabulary does. That is the point of a formal ontology: the analytical structure is reusable even when the legal substance is different.

A Python script that analyzes the Russian CSV does not generalize to Myanmar without rewriting the column names, the charge parsing logic, the lookup tables, and the output format. An ontology that analyzes the Russian knowledge graph generalizes to Myanmar by swapping the SKOS vocabulary. Everything else (the T-Box, the SPARQL queries, the report generator) works unchanged.

An OWL reasoner catches errors a Python script cannot.

When you build a knowledge graph in OWL, you can run a reasoner (Pellet, HermiT, ELK) that checks logical consistency. If you accidentally classify the same charge as both "facially_incompatible" and "legitimate," the reasoner flags a contradiction. If you assert that a person was prosecuted under Article 207.3 but Article 207.3 doesn't exist in the SKOS vocabulary, the reasoner detects an unresolved reference.

A Python script on a CSV has no equivalent. If your lookup table has a typo ("207.3" vs "207-3"), the join silently fails and the count is wrong. You don't know until someone manually checks. An OWL ontology with SHACL validation catches these errors before the analysis runs.

lookup["207.3"] = "Art. 19"
lookup["207-3"] = "Art. 19"  # typo: dash vs dot
# One of these never matches.
# The count is wrong.
# Nobody knows.

# SHACL validation:
# "Persecution X has charge
#  'art_207_3' which does not
#  exist in the SKOS scheme."
# Build fails. You fix it.

A treaty body will not cite a Python script.

When the UN Working Group on Arbitrary Detention reviews a case, it evaluates evidence. When the Human Rights Committee conducts a periodic review, it considers submissions. When the Special Rapporteur on Myanmar prepares a report, she cites sources.

A Python script that processes a CSV and prints "8,628 prosecutions violate Article 19" is an assertion by an analyst. A SPARQL query that returns 8,628 by crossing a published ontology against a published vocabulary is a reproducible finding. The treaty body can download the ontology, run the query, and verify the count. The reasoning behind each ICCPR mapping is in the SKOS editorial notes. The data provenance is in the A-Box. The schema is in the T-Box. Every component is inspectable, auditable, and citable.

That is the difference between evidence and analysis. Analysis is what you do with a CSV. Evidence is what you produce with an ontology. International legal proceedings require evidence.

CSV vs ontology: what each can and cannot do.

The CSV gets you 30% of the way. NetworkX gets you to 70%. The ontology gets you the last 30%. That last 30% is the part that matters in a courtroom.