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 ?itemLabelWHERE { ?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 concept | Semantic Web equivalent |
|---|---|
| Dimension member | Individual |
| Attribute | Property |
| Hierarchy | Explicit relationship |
| Surrogate key | Internal identifier |
| Member unique name | IRI |
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 ?parentLabelWHERE { ?child wdt:P279 ?parent . ?child wdt:P31 wd:Q2424752 . SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }}LIMIT 20
What this says:
P279means “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:
- IRIs are identity
- not names
- not surrogate keys
- stable references that everything agrees on
- Relationships are first-class
- no hidden joins
- no ambiguous semantics
- hierarchy is explicit
- 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