Query a Knowledge Graph with SPARQL

Build a SQLite knowledge graph and query it with SPARQL.

Introduction

30 Second Summary

Some questions only make sense after you follow several connections. A rigid grid can make that trail hard to express.

In this project, you will turn a local SQLite database into a queryable knowledge graph with the experimental sparqlite extension. You will use SPARQL to ask graph questions about linked data.

What You'll Build

Your terminal returns a clear table of linked answers from data stored in one local SQLite database.

By the end of this project, you'll have:

A compiled SQLite extension that loads into the SQLite command line without errors.
A working local graph database that reports its row counts after the tutorial data loads.
A side-by-side query comparison showing how SPARQL and plain SQL express the same question.
An optional Secret Mission to push your skills further.

Are there any prerequisites?

You need the Rust toolchain installed before the hands-on steps begin. You also need the SQLite CLI.

Basic terminal confidence helps with the local build.

Before We Start

This project asks your computer to compile an experimental SQLite extension from source. Missing build tools or a shell that blocks extensions can stop the work before your first query.

In this step, you will prepare Rust, Cargo, Git, and an extension-capable SQLite shell. You will also place the sparqlite source on your Desktop.

In this step, get ready to:

Verify that Git and an extension-capable SQLite shell are available.
Download the experimental sparqlite source checkout.
Prepare the pinned Rust compiler and Cargo.

Check the command-line prerequisites

Git downloads the source repository. The SQLite command-line shell loads the compiled extension later in the project.

Apple's built-in SQLite shell cannot load extensions. The macOS check therefore targets the Homebrew version described by the sparqlite tutorial.

Press Cmd+Space on macOS or the Windows key on Windows to open the search bar.
Type Terminal on macOS or Linux. Type PowerShell on Windows.
Press Enter to open the terminal.

macOS

Check Git and the Homebrew SQLite shell by running these commands:

git --version
$(brew --prefix sqlite)/bin/sqlite3 --version

What does this check prove?

The first line confirms that Git can download the repository. The second line targets the SQLite shell that supports extension loading on macOS.

Windows

Check Git and the SQLite shell by running these commands:

git --version
sqlite3 --version

What does this check prove?

Each command should print version information. That output confirms that PowerShell can find both programs.

Linux

Check Git and the SQLite shell by running these commands:

git --version
sqlite3 --version

What does this check prove?

Each command should print version information. That output confirms that your shell can find both programs.

✔️ Both commands show versions

Good. Git can fetch the source code, while your SQLite shell is available for the database work ahead.

ⓧ One or both commands are unavailable

Install the missing tools using the instructions for your operating system.

macOS

Install Apple's command-line tools by running this command. macOS may open a system installer:

xcode-select --install

What does this install?

The command-line tools provide Git. They also provide the linker that Rust needs when it compiles native code.

Install Homebrew by running the official installer below. Read its summary when it pauses for confirmation:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

What does this install?

Homebrew manages command-line packages on macOS. Follow the post-installation shell instructions printed by the installer.

Install the extension-capable SQLite shell by running:

brew install sqlite

Why use this SQLite shell?

Homebrew installs SQLite separately because macOS already provides its own copy. The sparqlite tutorial uses the Homebrew binary so extension loading works.

Confirm that Git and the Homebrew SQLite shell are ready by running:

git --version
$(brew --prefix sqlite)/bin/sqlite3 --version

What should you see?

Both commands should print version information. This confirms that the required macOS tools are available.

Windows

Download Git from the official Git installation page.
Run the Git installer with its default command-line options.
Download the Windows command-line tools zip from the official SQLite download page.
Extract the SQLite tools into C:\sqlite.

Why extract SQLite to a permanent folder?

Windows runs the SQLite shell from the extracted folder. A permanent location prevents the command from disappearing when you clear your Downloads folder.

Windows hides the PATH editor inside a system dialog, so this part can feel fiddly.

Press the Windows key to open search.
Type Environment Variables.
Select Edit the system environment variables.
Click Environment Variables.
Select Path under User variables.
Click Edit.
Click New.
Enter C:\sqlite.

What does PATH control?

PATH lists the folders Windows searches for commands. Adding C:\sqlite lets you run the SQLite shell from any project folder.

Click OK until every environment window closes.
Close PowerShell so it releases the old PATH value.
Open a new PowerShell window through Windows search.
Confirm that Git and SQLite are ready by running:

git --version
sqlite3 --version

What should you see?

Both commands should print version information. This confirms that Windows can find Git and the extracted SQLite shell.

Linux

These commands use the package names documented for Debian and Ubuntu. Use your distribution's official package instructions if your system uses a different package manager.

Install Git, SQLite, and the native build tools by running these commands:

sudo apt install git-all
sudo apt install sqlite3
sudo apt install build-essential

What do these packages provide?

Git downloads the repository. SQLite provides the command-line shell.

The build tools provide the linker that Rust needs for native compilation.

Confirm that Git and SQLite are ready by running:

git --version
sqlite3 --version

What should you see?

Both commands should print version information. This confirms that your Linux shell can find the installed programs.

Still missing Git or SQLite?

Close your current terminal after an installation. Open a new terminal so it receives the updated command search path.

On macOS, keep using the Homebrew SQLite path from the check above. The shorter command can still point to Apple's built-in copy.

On Windows, confirm that sqlite3.exe is directly inside C:\sqlite.

Help me diagnose why Git or SQLite is still unavailable in my terminal.

Download the sparqlite source

sparqlite lives inside the larger simonw/research repository. The tutorial treats sqlite-sparql-rust as the project folder for every later command.

Place the source checkout on your Desktop by running these commands:

cd ~/Desktop
git clone --depth 1 https://github.com/simonw/research
cd research/sqlite-sparql-rust
pwd
ls

What do these commands do?

The first command gives the repository a predictable home on your Desktop.
The clone command downloads the latest repository snapshot without its full history.
The final commands confirm your location and list the source files.

You should now be inside a path ending in research/sqlite-sparql-rust. The listing should include Cargo.toml, ext, and tutorial.md.

Clone did not complete?

Confirm that the Git version check succeeds before retrying the clone. A network restriction can also stop Git from reaching GitHub.

If a research folder already exists on your Desktop, inspect it before deleting anything. It may contain an earlier checkout you want to keep.

Help me fix the sparqlite repository clone.

✔️ Awesome, I've got everything!

Your source checkout is ready. This folder becomes the working directory for the database and query files you create later.

ⓧ I'd like to double check the full code

Local checkout of the experimental sparqlite Rust extension source code, ready to build.

Prepare the pinned Rust toolchain

The repository includes rust-toolchain.toml, which pins the compiler to 1.97. A rustup-managed installation reads that file when you run Rust commands inside the project folder.

The first check may download the pinned toolchain. Your terminal can stay busy during that download.

Check the compiler and Cargo from inside sqlite-sparql-rust by running:

rustc --version
cargo --version

What should this check reveal?

The Rust line should identify compiler version 1.97. The Cargo line should print its installed version.

Together, these outputs confirm that the compiler and build tool are ready for the repository.

✔️ I see the pinned Rust version

That's the toolchain ready. The repository selected its pinned compiler, while Cargo is available to build the extension.

ⓧ I see a different Rust version

A different compiler version means your current Rust installation is not applying the repository's toolchain file. Install Rust through rustup so the project can select its pinned compiler.

On macOS or Linux, install rustup by running the official command below:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

What does rustup install?

rustup installs the Rust compiler and Cargo. It also manages project-specific compiler versions.

On Windows, download the installer from the official Rust installation page.
Run the downloaded rustup installer.
Allow the installer to add any requested Visual Studio C++ Build Tools on Windows.
Close your terminal after rustup finishes.
Open a new terminal through your operating system's search.
Return to the sparqlite folder and repeat the version check by running:

cd ~/Desktop/research/sqlite-sparql-rust
rustc --version
cargo --version

What should change?

The Rust line should now identify version 1.97. Cargo should also print its version.

ⓧ Command not found

Your terminal cannot find a Rust installation yet. rustup installs both the compiler and Cargo.

On macOS or Linux, install rustup by running the official command below:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

What does rustup install?

rustup installs Rust and Cargo in your user account. It configures your command search path during installation.

On Windows, download the installer from the official Rust installation page.
Run the downloaded rustup installer.
Allow the installer to add any requested Visual Studio C++ Build Tools on Windows.
Close your terminal after rustup finishes.
Open a new terminal through your operating system's search.
Return to the sparqlite folder and check the installation by running:

cd ~/Desktop/research/sqlite-sparql-rust
rustc --version
cargo --version

What should you see?

The Rust line should identify version 1.97. Cargo should print its version on the next line.

Rust still unavailable?

Restart the terminal after installing rustup. Existing terminal windows may keep their old command search path.

Confirm that you run the version check from ~/Desktop/research/sqlite-sparql-rust so rustup can read the toolchain file.

Help me fix my Rust and Cargo installation.

Before you run the final check, do you expect all four tools to answer from inside the sparqlite project folder?

macOS

Verify the complete macOS setup by running:

cd ~/Desktop/research/sqlite-sparql-rust
git --version
rustc --version
cargo --version
$(brew --prefix sqlite)/bin/sqlite3 --version
pwd
ls

What should you see?

You should see version information for Git, Rust, Cargo, and SQLite. Your path should end in research/sqlite-sparql-rust.

The final listing should include the source files needed for the build.

Windows

Verify the complete Windows setup by running:

cd ~/Desktop/research/sqlite-sparql-rust
git --version
rustc --version
cargo --version
sqlite3 --version
pwd
ls

What should you see?

You should see version information for Git, Rust, Cargo, and SQLite. Your path should end in research\sqlite-sparql-rust.

The final listing should include the source files needed for the build.

Linux

Verify the complete Linux setup by running:

cd ~/Desktop/research/sqlite-sparql-rust
git --version
rustc --version
cargo --version
sqlite3 --version
pwd
ls

What should you see?

You should see version information for Git, Rust, Cargo, and SQLite. Your path should end in research/sqlite-sparql-rust.

The final listing should include the source files needed for the build.

Your local toolchain and source checkout are ready. Next up, you will compile sparqlite and watch the extension library appear.

Build the sparqlite Extension

Your Rust tools are ready. The sparqlite source must become a shared library that SQLite can load.

Cargo compiles the extension with its release profile. This produces the optimized libsparqlite.so file used by the next step.

In this step, get ready to:

Build the sparqlite source with Cargo's release profile.
Verify the compiled extension at sparqlite/target/release/libsparqlite.so.

Build the release library

The release profile applies optimizations to the compiled library. The first build can take several minutes while Cargo downloads dependencies.

Compile the source checkout in release mode by running this command:

cargo build --release --manifest-path sparqlite/Cargo.toml

What does this command do?

The --manifest-path option points Cargo to sparqlite/Cargo.toml.
The --release option selects Cargo's optimized release profile.
Cargo places the resulting library under sparqlite/target/release.

Wait for Cargo to complete the build.

You should see a completion line for the release profile. Good progress. Cargo has turned the source checkout into a loadable library.

Build did not complete?

Confirm that sparqlite/Cargo.toml exists in the working directory from earlier.
Confirm that the platform linker from your setup is available in the same terminal session.

Ask for help with the first build error.

Confirm the compiled extension

Before you check, where do you expect Cargo to have placed the shared library?

List the expected library path by running this command:

ls sparqlite/target/release/libsparqlite.so

What does this check prove?

The ls command prints the named file when it exists. Seeing the full path proves the release build produced the required SQLite extension library.

You should see sparqlite/target/release/libsparqlite.so printed in the terminal. That file is the compiled extension you can load into SQLite.

Library path missing?

Return to the build output to confirm that Cargo completed successfully.
Check that the build command used sparqlite/Cargo.toml as its manifest path.

Ask for help locating the compiled library.

Your compiled sparqlite library is ready. Next, you'll load it into the SQLite command-line shell.

Load the Extension in SQLite

The release build turned sparqlite into the loadable extension at sparqlite/target/release/libsparqlite.so. SQLite still needs to attach that library to the current connection before its graph functions exist.

The SQLite command-line shell enables extension loading for each session. A version query then proves that the extension registered its SPARQL functions.

In this step, get ready to:

Enter a temporary SQLite session from the working directory.
Load the compiled sparqlite extension into the active connection.
Confirm that SQLite can call a function registered by sparqlite.

Prepare a clean extension check

An in-memory database gives you a clean connection for checking the extension. The database disappears when the shell closes.

Start the SQLite shell from the working directory by running this command:

sqlite3

What does this command do?

The sqlite3 command launches the interactive SQLite shell.
Starting the shell without a database filename creates a temporary in-memory database.

You'll see SQLite's startup message followed by its input prompt.

No SQLite prompt?

Confirm that you typed sqlite3 in your system terminal.
Use the same SQLite command-line installation that you verified earlier.

Help me diagnose why the SQLite shell does not start.

Add sparqlite to the connection

Loadable extensions belong to individual database connections. The shell has already enabled extension loading for the session you just opened.

Load the compiled library at the SQLite prompt by entering this dot-command:

.load sparqlite/target/release/libsparqlite.so

How does the extension load?

The .load dot-command attaches a compiled library to the active connection.
The path points to the .so file produced by your release build.
The SQLite shell enables extension loading during startup, so the dot-command needs no extra switch.

A successful load returns you directly to the SQLite prompt without error text. That clean return is your first confirmation that the library registered.

Does SQLite report a loading problem?

Confirm that the library path is exactly sparqlite/target/release/libsparqlite.so.
Confirm that you launched SQLite from the working directory that contains sparqlite.

Help me diagnose why SQLite cannot load my sparqlite library.

Test the registered function

The load command proves that SQLite accepted the library. Calling a function provided by sparqlite proves that registration completed.

What do you expect the registered function to return? Your prediction becomes the test.

Ask the extension for its version by running this SQL statement:

SELECT sparql_version();

What does this query prove?

The sparql_version() function exists only after sparqlite registers it on the active SQLite connection.
The returned text identifies the sparqlite version plus the host SQLite version.

You'll see sparqlite with version 0.1.0. Your SQLite version appears in parentheses.

That's the connection verified: SQLite can now call sparqlite's functions.

Keep the SQLite shell open for the tutorial data step.

Version function unavailable?

Return to the previous .load command to check whether SQLite printed a loading problem.
Check that the library path still matches sparqlite/target/release/libsparqlite.so.

Help me find out why SQLite cannot call sparql_version().

sparqlite is live inside SQLite. Next, you'll run the tutorial script. Its row counts will confirm that the graph store is ready.

Populate the Tutorial Database

Your sparqlite extension is now loaded in the SQLite command-line shell. That gives the database a SPARQL query engine.

This step uses the tutorial population script to create tutorial.db. The script fills it with linked records that later queries can follow.

In this step, get ready to:

Run the tutorial population script to create tutorial.db.
Check row counts to confirm the linked data was inserted.

Populate the tutorial database

A knowledge graph becomes useful when its nodes contain real examples. The tutorial script generates those examples before loading them into a new database file.

Run the tutorial population script from the SQLite shell by entering:

.shell python3 sparqlite/tutorial/make_tutorial_data.py --db tutorial.db --ext sparqlite/target/release/libsparqlite.so

What does this command do?

The .shell command runs an operating-system command without closing your current SQLite session.
Python runs the tutorial's data generator.
The --db tutorial.db option selects the database file to create.
The --ext sparqlite/target/release/libsparqlite.so option points the script to your compiled extension.

Confirm the final summary includes 2413 quads.
Confirm the last line says wrote tutorial.db.

That is the data layer in place. Your local tutorial.db now contains the tutorial dataset.

Database file not created?

Check that sparqlite/tutorial/make_tutorial_data.py exists inside the source checkout.
Confirm the compiled extension still exists at sparqlite/target/release/libsparqlite.so.

Help me diagnose why the tutorial population script did not create tutorial.db.

Verify the inserted row counts

Row counts provide direct evidence that the database contains records. The first count covers graph quads. The second covers relational job postings.

Predict which row count is larger before you run the check.
Run both row-count queries without leaving the SQLite shell by entering:

.shell sqlite3 tutorial.db "SELECT count(*) AS quads FROM rdf_quad; SELECT count(*) AS job_postings FROM job_postings;"

What does this check?

The first statement counts every stored quad in rdf_quad.
The second statement counts every relational record in job_postings.

Confirm the first result is 2413.
Confirm the second result is 300.

You have now proved that both parts of the tutorial dataset are present. The database is ready for graph questions.

Counts missing or incorrect?

Check that the command points to tutorial.db in your current working directory.
Rerun the population script if either table is missing.

Help me troubleshoot unexpected row counts in tutorial.db.

Your tutorial database is populated. Next up, you will ask your first graph question with SPARQL.

Query the Graph with SPARQL

Your populated tutorial database already proves that linked data is present. Row counts still cannot show how one record connects to another.

Now you will ask the graph which records are query languages. The sparqlite extension passes a SPARQL 1.1 pattern through SQLite. The answer comes back as a familiar table.

In this step, get ready to:

Trace the triple pattern behind a graph question.
Save the SPARQL 1.1 query in queries.sql.
Return the matching languages as a SQLite table.

Map the graph question

An RDF graph stores each fact as a subject, predicate, and object. A SPARQL triple pattern replaces unknown parts with variables that begin with ?.

Keep the SQLite shell from earlier focused on tutorial.db.
Read ?lang a ex:QueryLanguage as a request for records whose type is ex:QueryLanguage.
Read rdfs:label ?language as a request for each matching record's label.

How does the pattern work?

The variable ?lang represents each matching graph node. The keyword a checks the node's type.

The same ?lang variable appears beside rdfs:label. This shared variable connects each query-language node to its readable name.

Save the SPARQL query

A saved query file makes the graph question repeatable. The SQLite shell can write literal lines into queries.sql while your database session stays open.

Create queries.sql from the SQLite shell by running these dot commands:

.output queries.sql
.print "-- Ask which graph records are query languages."
.print "SELECT v0 AS language FROM sparql_rows('"
.print "  PREFIX ex:   <http://example.org/pl/>"
.print "  PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>"
.print "  SELECT ?language"
.print "  WHERE { ?lang a ex:QueryLanguage ; rdfs:label ?language }"
.print "  ORDER BY ?language"
.print "');"
.output

What do these commands do?

The first .output command sends subsequent shell output into queries.sql.
Each .print command writes one line of the saved query.
The final .output command restores output to the terminal.
The outer SQL query gives the first SPARQL result variable the table heading language.

Wait for the SQLite prompt to return after the final .output command.

The returning prompt confirms that later output is heading back to your terminal. Your graph question now lives in queries.sql.

File not created?

Make sure .output queries.sql appears before the first .print command. Check that the final .output command is on its own line.

Why is my saved SQLite query file not being created?

Run the saved query

The saved file wraps the SPARQL pattern inside a SQL query. The sparql_rows function turns each SPARQL solution into a SQLite row.

Before you run it, which language names do you expect the graph to classify as query languages?

Execute queries.sql against tutorial.db by running this SQLite shell command:

.read queries.sql

What happens when the query runs?

The .read command executes the SQL stored in queries.sql.
The PREFIX declarations shorten the graph's full identifiers.
The SPARQL pattern finds nodes classified as ex:QueryLanguage.
The outer SQL query displays each matching label in the language column.

You will see a boxed table containing SPARQL, SQL, and XQuery in alphabetical order.

That worked. Your first graph question now returns structured rows through the SQLite shell.

Query file not found?

Confirm that the filename is exactly queries.sql. Make sure you stayed in the same working directory after creating it.

Why can the SQLite shell not read my queries.sql file?

✔️ Awesome, I've got everything!

Your query returned the three matching language names. Keep queries.sql beside tutorial.db for the comparison in the next step.

ⓧ I'd like to double check the full code

-- Ask which graph records are query languages.
SELECT v0 AS language FROM sparql_rows('
  PREFIX ex:   <http://example.org/pl/>
  PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  SELECT ?language
  WHERE { ?lang a ex:QueryLanguage ; rdfs:label ?language }
  ORDER BY ?language
');

Your SPARQL question is saved and repeatable. Next up, you will ask the same question with plain SQL so you can compare both approaches side by side.

Compare SPARQL and SQL

Your first SPARQL query already returns matching rows from tutorial.db. This final step tests whether plain SQL can express the same graph question.

A fair comparison keeps the question unchanged. Matching results let you focus on how each language expresses the relationships.

In this step, get ready to:

Translate the existing graph question into an equivalent plain SQL query.
Compare how each query represents the linked data.
Run both queries against tutorial.db.

Translate the graph question into SQL

SPARQL follows linked facts by matching graph patterns. SQL reaches the same answer through joins between rows that represent those relationships.

How does the translation work?

Each selected SPARQL variable maps to an output column in SQL.
Each graph pattern maps to the tutorial table rows that store the relationship.
Each repeated variable becomes a join condition between the corresponding columns.
The SQL filters preserve the constraints from the graph question.

Switch back to queries.sql in the text editor from the previous step.
Find the complete SPARQL statement that returned matching rows.
Add an equivalent plain SQL statement directly below it.
Save queries.sql.

Compare the query structures

Both statements now sit together in queries.sql. Their structure reveals how graph patterns replace table mechanics.

What should you compare?

SPARQL groups relationships into graph patterns.
A repeated variable connects one graph pattern to another.
SQL names the tables that hold each part of the relationship.
A join condition connects one SQL row set to another.

Read the SPARQL statement from top to bottom.
Identify every variable that appears in more than one graph pattern.
Read the SQL statement from top to bottom.
Match each repeated SPARQL variable to its SQL join condition.
Compare how much structure each version needs to ask the same question.

You should now be able to point from every shared graph variable to the SQL condition that represents the same relationship.

Run both versions and confirm the match

The loaded extension lets the existing SQLite shell execute the SPARQL version beside native SQL. Running both statements gives you a direct result comparison.

Before you rerun the SPARQL version, what columns and rows do you expect from the graph question?

Select only the complete SPARQL statement in queries.sql.
Copy the selected statement.
Return to the SQLite command-line shell from earlier.
Paste the copied statement into the shell.
Execute the statement.

You'll see the matching result table from the previous step. Keep that output visible in the terminal scrollback.

Before you run the SQL version, do you think every heading, row value, and row order will match?

Return to queries.sql.
Select only the complete plain SQL statement.
Copy the selected statement.
Switch back to the SQLite command-line shell.
Paste the copied statement into the shell.
Execute the statement.

You should see the same column headings in the same order. You should also see the same row values in the same order.

Do the results differ?

If the headings differ, compare the selected SQL columns with the variables returned by SPARQL.

If the rows differ, check the SQL filters and join conditions. A missing join can produce duplicate rows.

Help me compare my two queries.

Strong finish. queries.sql now preserves both ways to ask the graph question.

The matching result tables prove that both versions reach the same answer.

Secret mission

Defend Your Query Design

Turn your side-by-side queries into a design recommendation. Trace their relationship hops, test how each style handles a future change, and confirm that both versions preserve the same result.

Clean Up Your Resources

Everything in this project runs locally, so keeping the files creates no ongoing service charges. Decide whether to keep the database and query file, close the active SQLite session, or remove the local project files.

Resources you used:

The local sparqlite source checkout, including its Rust source, tutorial population script, and compiled sparqlite/target/release/libsparqlite.so library.
The populated tutorial.db database containing the tutorial's linked-data records.
The queries.sql file containing the SPARQL graph question and its plain SQL equivalent.

Keep everything running

No action needed. Choose this if you want to rerun the queries, change the graph question, or compare more SPARQL and SQL examples later.

Keep tutorial.db so you can query the populated graph again.
Keep queries.sql as a record of your side-by-side query comparison.
Keep the sparqlite checkout if you want to rebuild the extension or inspect its source.

Keep It Experimental

Sparqlite is an experimental extension. Keep it for local learning and avoid treating it as a production dependency.

Pause - I'll come back to this later

Pausing means ending the active SQLite session while preserving every project file. Your local files remain available without ongoing costs.

Close the terminal window that contains the active SQLite shell.
Leave sparqlite, tutorial.db, and queries.sql in their current folder.

The SQLite session stops when the terminal closes. Your database and queries remain ready for your next session.

Delete - I don't want to use this again

Deleting removes the source checkout, database, and query file from your computer. This becomes permanent once you empty your system's deleted-files area.

Copy queries.sql to another folder if you want to preserve your query comparison.
Close the terminal window that contains the active SQLite shell.

macOS

Press Cmd+Space to open the search bar.
Type Finder and press Enter to open it.
Type tutorial.db into the Finder search box.
Control-click tutorial.db in the search results.
Select Show in Enclosing Folder.

You'll see the folder containing sparqlite, queries.sql, and tutorial.db.

Hold Cmd while selecting sparqlite, queries.sql, and tutorial.db.
Press Cmd+Delete to move the selected items to Trash.
Control-click Trash in the Dock.
Select Empty Trash to remove the project files permanently.

The source checkout, compiled extension, tutorial data, and query file are now removed from your Mac.

Windows

Press the Windows key to open search.
Type File Explorer and press Enter to open it.
Type tutorial.db into the File Explorer search box.
Right-click tutorial.db in the search results.
Select Open file location.

You'll see the folder containing sparqlite, queries.sql, and tutorial.db.

Hold Ctrl while selecting sparqlite, queries.sql, and tutorial.db.
Press Delete to move the selected items to the Recycle Bin.
Right-click Recycle Bin on the desktop.
Select Empty Recycle Bin to remove the project files permanently.

The source checkout, compiled extension, tutorial data, and query file are now removed from your Windows computer.

Nice Work!

You made it! Your local SQLite database now answers graph questions through SPARQL.

You've learned how to:

Built the experimental sparqlite extension from source with Rust. Loaded the compiled library into the SQLite command-line shell.
Created a knowledge graph inside tutorial.db. Confirmed the records with row-count queries.
Wrote a SPARQL query in queries.sql. Compared its result with an equivalent SQL query side by side.
Secret Mission: Completed an optional extension that pushed your graph-querying skills further.

Ready to quiz yourself?