Skip to content

Advanced Knowledge Graph Techniques in Iolanta
Assignment for MC-3 Fall 2025 © Anatoly Scherbakov

This document extends the Iolanta knowledge graph design presented in MC-1 and MC-2, demonstrating advanced constructs and techniques from MC-3 "Build with Nuance".

Wikidata as a part of Knowledge Commons Advanced Topic

Wikidata is a part of Knowledge Commons. As a huge repository of machine readable knowledge, Wikidata is a very interesting target for data visualization.

iolanta http://www.wikidata.org/entity/Q204606

Most elements here are interactive. For instance, if you click cybersecurity then you should see something like this:

iolanta http://www.wikidata.org/entity/statement/Q204606-fd8d7c8a-431b-1444-80ef-bb3c0cb139a9

Why does the URL say statement? What does it mean? It is a hint that Wikidata extensively uses reification.

Reification in Wikidata Main Topic

The basis for reification is a specialized Statement class in Wikidata ontology.

Info

This illustrates that rdf:Statement is not the only possible basis for reification.

The Statement class itself doesn't reveal much about its structure.

iolanta http://wikiba.se/ontology#Statement

The fragment of knowledge we are interested in is that Cyberspace is associated with the field of work which is cybersecurity.

Instead of expressing this as one triple, Wikidata uses a much more complicated structure. The diagram below visualizes how the simple fact that Cyberspace has the field of work cybersecurity is represented through reification:

Through reification, Wikidata is able to attach rank and other meta properties to statements, but the structure of the graph becomes more complicated, and the Statement instance has no attached human readable representation.

Reasoning to the Rescue Main Topic

We have a few potential solutions to this.

SPARQL inference uses CONSTRUCT queries to generate new triples that simplify the reified structure.

Pro

  • Explicit control over inference rules
  • Does not require a reasoner

Contra

  • Requires writing and maintaining SPARQL queries
  • May need multiple rules for different patterns
  • Performance depends on query optimization
  • Might be verbose

OWL inference leverages ontology reasoning to automatically infer relationships and labels.

Pro

Declarative and standards-based

Contra

  • Requires an OWL reasoner (additional dependency)
  • OWL does not easily support property transfer: copying a property with its object from one subject to another

Custom facet logic implements domain-specific handling within Iolanta's facet system.

Pro

  • Tight integration with Iolanta's rendering system
  • Can leverage existing facet infrastructure
  • Domain-specific optimizations possible

Contra

  • Requires Python code changes
  • Less reusable across different domains

So, we go with SPARQL reasoning. Let's examine the specific inference queries we use:

Querying Graphs Main Topic

Iolanta has several built-in inference SPARQL queries, each of these implements a CONSTRUCT statement. One of them is this:

wikidata-statement-label.sparql
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX prov: <http://www.w3.org/ns/prov#>

CONSTRUCT {
  ?statement rdfs:label ?label .
}
WHERE {
  ?statement a wikibase:Statement .

  # Find predicates from statement to values (excluding metadata predicates)
  ?statement ?statementProp ?value .

  FILTER(?statementProp != wikibase:rank)
  FILTER(?statementProp != rdf:type)
  FILTER(?statementProp != prov:wasDerivedFrom)
  FILTER(?statementProp != iolanta:last-loaded-time)

  # Handle entity values: get their label
  {
    ?value rdfs:label ?label .
  } UNION {
    # Handle literal values: use the literal directly
    ?statement ?statementProp ?label .
    FILTER(isLiteral(?label))
  }
}

This query finds an rdfs:label for each Statement by traversing its related nodes in the graph.

For properties, we use this inference query:

wikidata-prop-label.sparql
PREFIX wikibase: <http://wikiba.se/ontology#>

CONSTRUCT {
  ?thing rdfs:label ?label .
}
WHERE {
  ?entity
    (wikibase:claim | wikibase:qualifier | wikibase:statementProperty | wikibase:statementValueNormalized) ?thing ;
    rdfs:label ?label .
}

This query transfers labels from property entities (like http://www.wikidata.org/entity/P101) to their corresponding property URLs (like http://www.wikidata.org/prop/P101) by following the wikibase:claim, wikibase:qualifier, wikibase:statementProperty, or wikibase:statementValueNormalized relationships.

Together, these two inference queries enable readable labels for both statements and properties. Here's how they work in practice:

iolanta http://www.wikidata.org/prop/P101 --as title

The inference rules automatically flatten the reified structure by inferring rdfs:label triples directly on property and statement URLs. This allows Iolanta's facets to work with simple label queries rather than navigating the complex Wikibase ontology structure.

Conclusion

I haven't found an application of reification, OWL punning, probabilities, or RDF-Star in Iolanta ontology itself. In this document, I tried to demonstrate:

  • How Iolanta implements inference with advanced SPARQL queries,
  • And by that, we are able to untangle complex reification schemes, — and thus get the visualization we need.