A Baby-Baby Step: Learning SPARQL Using Wikidata

Before installing a graph database, defining ontologies, or wiring anything into a BI system, it helps to develop intuition for what a knowledge graph actually is and how it is queried. The easiest way to do that—with zero setup—is to use the public SPARQL environment provided by Wikidata.

This step is not about mastery. It’s about recognition.

What you need

Nothing but a browser. Go to: https://query.wikidata.org

You’ll see:

  • a query editor on the left
  • a results panel on the right
  • buttons to switch between table, graph, map, and timeline views

This is a live SPARQL endpoint backed by a very large, real knowledge graph.

Step 1: Run a query without understanding it

Paste the following into the editor and click Run:

SELECT ?item ?itemLabel
WHERE {
?item wdt:P31 wd:Q146 .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 10

You’ll get a small table of results.

Don’t analyze yet. Just notice:

  • results appear instantly
  • each result has a long identifier (an IRI)
  • there is no schema browser, no joins, no tables

Step 2: Translate the query into plain English

Now let’s decode just enough to understand what happened.

?item wdt:P31 wd:Q146 .

This is a triple pattern:

subject – predicate – object

  • ?item → “some thing”
  • wdt:P31 → “instance of”
  • wd:Q146 → “cat”

So the line literally means:

“Find things that are instances of cats.”

The rest of the query:

  • asks for human-readable labels
  • limits the output to 10 rows

That’s it.

If you understand that one sentence, you already understand the core of SPARQL.

Step 3: Look at the graph

Switch the results view from Table to Graph.

This is the “aha” moment for many people.

You will see:

  • nodes representing entities
  • edges representing relationships
  • identifiers that are stable and global

This is the same mental model you already use in BI—just made explicit.

Step 4: Map this to BI thinking

In BI terms:

BI conceptSemantic Web equivalent
Dimension memberIndividual
AttributeProperty
HierarchyExplicit relationship
Surrogate keyInternal identifier
Member unique nameIRI

The important shift is this:

In BI, meaning is implied by schema and convention.
In a knowledge graph, meaning is explicit and queryable.

Step 5: Introduce hierarchy (cat / subcat thinking)

Now let’s look at something closer to product hierarchies.

Paste this query:

SELECT ?child ?childLabel ?parent ?parentLabel
WHERE {
?child wdt:P279 ?parent .
?child wdt:P31 wd:Q2424752 .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 20

What this says:

  • P279 means “subclass of”
  • you’re asking for things that are subclasses of other things
  • constrained to “products”

This is category / subcategory thinking without tables.

Switch to the Graph view again and observe:

  • the hierarchy is not implicit
  • the relationships are the data

Step 6: What SPARQL feels like (important note)

SPARQL does not feel like SQL—and that’s intentional.

SQL:

  • assumes tables
  • joins structure after the fact
  • infers meaning from schema

SPARQL:

  • assumes meaning
  • traverses relationships directly
  • does not require predefined join paths

This is why SPARQL initially feels strange to SQL users—and why it becomes powerful once the model clicks.

Step 7: Why this matters for BI + AI

This exercise isn’t about cats or products. It’s about understanding three foundational ideas:

  1. IRIs are identity
    • not names
    • not surrogate keys
    • stable references that everything agrees on
  2. Relationships are first-class
    • no hidden joins
    • no ambiguous semantics
    • hierarchy is explicit
  3. Queries describe meaning, not structure
    • you ask what something is
    • not how to stitch tables together

This is exactly why a knowledge graph grounds an LLM:

  • the model doesn’t guess what “product” means
  • it is told, explicitly, via IRIs and relationships

And it’s why an LLM helps build a KG:

  • it can draft descriptions
  • propose candidate relationships
  • accelerate metadata creation

Step 8: When to stop (for now)

At this stage, you do not need:

  • OWL
  • reasoning
  • inference
  • ontology design
  • graph databases

If you can:

  • read a SPARQL query
  • explain it in plain English
  • relate it to BI concepts