Building Quantum Functors with SPARQL: When Database Queries Meet Quantum Circuits

How a Graph Query Language Taught Me to Think Like a Category Theorist

AI generated image

Take 3 seemingly unrelated things:

• A simple JavaScript array mapping: [1, 2, 3].map(x => x 2) gives you [2, 4, 6]*. The array stays an array; only the contents change.
• A quantum circuit: a diagram with qubits and gates that looks like abstract art.
• A SPARQL query: something you use to pull data out of a graph database.

They all embody a powerful idea from mathematics called a functor — a way to transform things while preserving structure.

In this article, we’ll explore this connection and propose a translation of quantum circuits into a more analyzable form (ZX-calculus diagrams) using SPARQL. Along the way, we’ll discover what it really means to be a functor, and why a query language might, or might not, qualify.

This is only creative exploration thus not mathematically rigorous. The keen reader with mathematics background might have quite a few things to disagree with.

The Garden Variety Functors

Let’s start with some familiar JavaScript:

const numbers = [1, 2, 3, 4];
const doubled = numbers.map(x => x * 2); // doubled is [2, 4, 6, 8]

That little .map() is an actual functor in action. Here’s how it works:

• A container: the array itself (it contains numbers)
• A regular function: x => x 2* (works on numbers, hence can be applied to array elements)
• A superpower: .map() enables the function to work on the container itself
• A result: a new container with transformed values. The result is just another container with same structure/shape as the original one and items the values of the function applied to each item in the original container.

That’s, pretty much, it. A functor is just a container with a map method that follows two basic rules:

• Identity: If you map a function that does nothing (x => x), you get the same container back.
• Composition: Mapping f then g is the same as mapping g ∘ f (the combined function) in one go.

Continuing on other examples, you most probably have used functor in daily life without much ceremony or second thoughts:

• Promise.then() is a functor for future values. Note: to be accurate, it is actually a monad, but here we are just concerned with mapping.
• Optional chaining (?.) is like a functor for values that might be null
• Or… taking clothes to dry cleaner: you put them in a container, a bag, and ask the guy at the desk to clean them, after which they are returned in another container but each of them has clean() function applied.

A Functor for Quantum Circuits

Now let’s move into the quantum world. No, no physics degree needed. Yet.

A quantum computer is a type of computer that uses the principles of quantum mechanics — the physics of subatomic particles — to solve complex problems faster than traditional computers. Unlike regular computers that use bits (0 or 1), they use qubits, which can represent 0 and 1 simultaneously, allowing them to process vast amounts of data at once.

Superposition: Classic bits are like a light switch (on or off), but qubits are like a dimmer switch, holding multiple states (both 0 and 1) at the same time. Entanglement: Qubits can be linked, i.e. the state of one instantly affects another, no matter the distance, allowing for coordinated processing power. Exponential Speed: Because of these properties, they don’t try solutions one-by-one; they can test many possibilities simultaneously.

Here is what simple circuits look like:

Quantum circuits for Bell states preparation by using quantum gates — image from ResearchGate

• H is a Hadamard gate (puts a qubit into superposition)
• CNOT (the dot and cross) entangles two qubits
• X gate (or Pauli-X gate) acts as a quantum NOT gate, flipping a qubit’s state between |0⟩ and |1⟩

It is basically a collection of quantum logical gates, and measurements, that act on qubits.

These circuits are notoriously hard to reason about. Therefore a visual representation was built: ZX-calculus, which represents the same computation as a diagram of colored spiders and also provides a set of rewrite rules to transform these diagrams while preserving their meaning.

• 🟢 Green, or Z-, spiders for Z-basis operations
• 🔴 Red, or X-, spiders for X-basis operations
• Wires for qubits
• Phases (angles) attached to spiders

The Hadamard gate above becomes a yellow box (or a specific spider pattern). The CNOT becomes a little cluster of one green and one red spider connected. A rotation becomes a green spider with a phase.

First circuit in image above represented in ZX-calculus diagram

And now for the juicy part: there exists a functor from the world of quantum circuits to the world of ZX-diagrams. It maps:

• Objects: qubits → qubits
• Arrows: each gate → a small ZX subgraph
• Composition: if two gates are in sequence, their ZX-calculus diagrams connect in sequence

This functor lets you translate any circuit into a ZX graph, apply graph rewrite rules to simplify it, and then can translate back — potentially getting a more efficient circuit, thus optimizing computation execution.

Simplifying quantum circuits is quite important because, qubits are fragile beasts so quantum computers are quite susceptible to errors caused by noise, decoherence, and environmental interference. Hence the more processing needed, i.e. the more gates in the circuit, the higher the errors probability.

Now this functor is an interesting construction in itself and not necessarily easy to grasp… So what if we could define it using a query language?

Just Because ZX-Diagrams Are Graphs…

ZX-diagrams are, by definition, graphs. Enter an old friend from semantic web hey day: RDF (Resource Description Framework), a standard way for representing graphs. SPARQL is the query language for RDF. Thus if we can represent both circuits and ZX-diagrams as RDF graphs, then SPARQL’s CONSTRUCT queries might just be a natural way to define the translation rules.

Step 1: Represent a Quantum Circuit in RDF

# A circuit with two qubits and two gates
:circuit a qc:QuantumCircuit .

:h1 a qc:HadamardGate ;
    qc:onQubit :q0 ;
    qc:position 1 .

:cx1 a qc:CNOTGate ;
     qc:control :q0 ;
     qc:target :q1 ;
     qc:position 2 .

:q0 a qc:Qubit .
:q1 a qc:Qubit .

Step2: Represent a ZX-Diagram in RDF

:zx a zx:ZXDiagram .

:s1 a zx:ZSpider ;
    zx:phase "0" ;
    zx:connectedTo :s2 .

:s2 a zx:XSpider ;
    zx:phase "0" .

Step 3: Write SPARQL CONSTRUCT Rules for Each Gate

Here is a rule for the Hadamard gate:

PREFIX qc: <http://example.org/quantum-circuit#>
PREFIX zx: <http://example.org/zx#>

CONSTRUCT {
  ?hadamardNode a zx:HadamardNode ;
                zx:onQubit ?qubit .
}
WHERE {
  ?gate a qc:HadamardGate ;
        qc:onQubit ?qubit .
  BIND(IRI(CONCAT(STR(?gate), "-zx")) AS ?hadamardNode)
}

And a CNOT gate:

CONSTRUCT {
  ?controlSpider a zx:ZSpider ; zx:phase "0" .
  ?targetSpider a zx:XSpider ; zx:phase "0" .
  ?controlSpider zx:connectedTo ?targetSpider .
}
WHERE {
  ?gate a qc:CNOTGate ;
        qc:control ?c ;
        qc:target ?t .
  BIND(IRI(CONCAT(STR(?gate), "-control")) AS ?controlSpider)
  BIND(IRI(CONCAT(STR(?gate), "-target")) AS ?targetSpider)
}

We have to ensure that gates are connected in the right order — that the output of one gate feeds into the input of the next. For this we can use the qc:position property to order them and connect the corresponding ZX nodes.

Step 4: Execute the Queries

Running all these CONSTRUCT queries against the circuit RDF yields a new RDF graph representing the ZX-diagram. Here’s our functor applied!

Is This a Real Thing?

Of course there is this annoying question: “Does this SPARQL-based transformation satisfy the functor laws?” i.e. does it preserve identity and composition in the mathematical sense?

TLDR: Not out of the box

SPARQL CONSTRUCT gives a way to specify graph transformations, but it doesn’t come with any guarantees about that being a functor. You could write rules that violate composition, and SPARQL couldn’t care less. The composition we hacked together using position numbers is something that we will have to carefully maintain, explicitly. The identity law — mapping an identity gate (a no-op) to an identity ZX structure (a straight wire) — is also something we must explicitly code and verify.

Therefore, in this naive implementation, what we have is functor-like behaviour. It is a useful construct that approximates the idea, but it doesn’t come with a mathematical proof.

However there is recent research from better people showing that SPARQL CONSTRUCT can be given a formal semantics that makes it a genuine categorical functor. By carefully defining categories of RDF graphs and using algebraic graph transformation techniques, like POIM (Pushout with Image Factorization), researchers have shown that CONSTRUCT queries can be interpreted as functors between these categories. In such a framework, the mathematical laws hold. By construction.

So, while our everyday SPARQL might not be a functor per se, the idea of using SPARQL for structure-preserving transformations is not too shaby — and with the right mathematical underpinnings, it might get elevated to the real thing.

Qui Prodest?

Even if we’re not doing formal category theory, there are some practical benefits of thinking in functor terms:

• Declarative rules: You describe what maps to what, not how to traverse graphs.
• Extensibility: Add a new gate by adding a new CONSTRUCT rule. Existing rules are maintained.
• Queryable results: Once you have the ZX graph in RDF, you can query it for patterns, like:

# Find all red spiders with phase > 0 
SELECT ?spider ?phase 
 WHERE { 
   ?spider a zx:XSpider ; 
   zx:phase ?phase . 
   FILTER(?phase > 0) 
 }

• Analogy power: Thinking of SPARQL transformations as “functors” helps you design them to preserve structure — basically you ask: “Does my mapping respect composition? Does it handle identity correctly?”

To Infinity And Beyond

As expected, this approach isn’t limited to quantum circuits. Anytime you need to transform one graph-based representation into another while preserving relationships, SPARQL can be your friend:

• Database schema migrations: Map old schema to new schema
• Data integration: Transform data from one company’s format to another’s
• Ontology alignment: Bridge different knowledge graphs
• Code generation: Translate abstract syntax trees to target code

In each case, you can think of the transformation as a functor between categories of data structures. The SPARQL rules become mapping definitions, and the query engine executes them.

The Functor Mindset

So we started from a simple JavaScript map and ended up with quantum spiders and SPARQL queries.

Our SPARQL-based circuit-to-ZX translator is a functor in spirit. It may not satisfy the mathematicians’ definition out of the box, but it presents the same idea: transform contents while preserving container shape. And with advanced categorical semantics, it might even become a true functor.

Maybe next time you write a SPARQL CONSTRUCT query, ask yourself: “Am I building a functor? Does my mapping respect composition?” or even “Would category theorists approve?” Even if they would nitpick, you’ll be designing better, more principled transformations with a maths flair.

And who knows? Maybe, just maybe, sometime your database queries will help optimize a real quantum computer.