rete · Start here Real-world scenario

A real-world scenario: a queryable SBOM on a URL

A worked end-to-end example: publish a software dependency graph (an SBOM-style slice) as a single .rete file, then answer "what is impacted by this CVE?" — over HTTP, fetching only the bytes the query needs, with no database.

The data (examples/deps.nt) models packages, their kind (rdf:type Application/Library), dependsOn edges, and a vulnerable package:

<http://ex/app>     dependsOn  <http://ex/web>, <http://ex/auth>
<http://ex/web>     dependsOn  <http://ex/logging>
<http://ex/auth>    dependsOn  <http://ex/logging>, <http://ex/safejson>
<http://ex/logging> dependsOn  <http://ex/log4x>
<http://ex/log4x>   hasVulnerability  <http://ex/CVE-2099-0001>

1. Validate, then build

Check the source is well-formed RDF first, then pack it:

rete validate examples/deps.nt
#  valid: 13 statement(s) — 13 in the default graph, 0 named graph(s)

rete build examples/deps.nt -o deps.rete
#  wrote deps.rete: 13 triples, 12 terms, 2 pyramid level(s), 2035 bytes

rete verify deps.rete        # confirm the content hash
#  OK — content hash matches

2. Publish

It's one immutable file — upload it anywhere that serves HTTP Range requests:

aws s3 cp deps.rete s3://my-bucket/deps.rete          # S3
# or commit it to a repo and use the raw URL, or any CDN / static host.

No server, no endpoint, no index to maintain. The file's blake3 content hash doubles as an ETag-like id, so clients can cache byte ranges forever.

3. Query it from the URL

The headline question: what does the CVE impact?

Everything that (transitively) depends on the vulnerable log4x:

rete sparql-url https://my-bucket.s3.amazonaws.com/deps.rete \
  "PREFIX e: <http://ex/> SELECT ?d WHERE { ?d e:dependsOn+ e:log4x }"
#  4 solution(s)
#  (fetched 2035 bytes in 1 range request(s); file is 2035 bytes)
#  ?d=<http://ex/auth>
#  ?d=<http://ex/logging>
#  ?d=<http://ex/web>
#  ?d=<http://ex/app>

safejson is correctly excluded — it doesn't reach the vulnerable package. At this toy size the whole file fits in one bounded range request; on a real graph the same query pulls a handful of small ranges — dictionary chunks and index tiles — from a file thousands of times larger, never scanning linearly.

Just the affected libraries, with the CVE id

rete sparql-url https://my-bucket.s3.amazonaws.com/deps.rete \
  "PREFIX e: <http://ex/>
   SELECT ?lib ?cve WHERE {
     ?lib e:dependsOn+ ?v . ?v e:hasVulnerability ?cve .
     ?lib a e:Library
   }"

A simple point lookup (triple pattern, no SPARQL)

rete query-url https://my-bucket.s3.amazonaws.com/deps.rete \
  --predicate '<http://ex/hasVulnerability>'

Overview first, without downloading the index

The overview-first path: a client makes three byte-range reads — the 1024-byte header at bytes 0 to 1023, then the dictionary, then the pyramid summary — and computes the coarse community graph without ever fetching the permutation indexes. Drawn to scale on the published davidrumsey.rete, 74.8 MB: the three reads total 17.4 MB, 23.3 percent of the file, while the permutation indexes alone are 42.6 MB, 56.9 percent, and are never requested. The share depends on how large the dictionary is relative to the rest of the file.

The overview path: header + dictionary + summary in three range reads — 23.3% of davidrumsey.rete; the triple index stays on the server.

rete summary-url https://my-bucket.s3.amazonaws.com/deps.rete   # community quotient graph
rete schema      deps.rete                                       # classes & relations (local)

4. Querying with plain curl

There is no query endpoint — a .rete query is a set of HTTP Range reads that the rete client (or the WASM engine) performs. You can watch and even drive those reads with curl.

The whole file is tiny here; fetch it and query locally:

curl -s https://my-bucket.s3.amazonaws.com/deps.rete -o deps.rete
rete sparql deps.rete "PREFIX e: <http://ex/> SELECT ?d WHERE { ?d e:dependsOn+ e:log4x }"

See the range mechanics directly — the first 1024 bytes are the header, and a Range request returns 206 Partial Content:

# Fetch just the header (bytes 0–1023); confirm the magic and partial response:
curl -s -r 0-1023 https://my-bucket.s3.amazonaws.com/deps.rete | head -c 4 ; echo
#  RETE
curl -sD - -o /dev/null -r 0-1023 https://my-bucket.s3.amazonaws.com/deps.rete | grep -i '206\|content-range'
#  HTTP/2 206
#  content-range: bytes 0-1023/2035

That 206 is the contract: a host that ignores Range and returns 200 is rejected by the client (it would otherwise read the wrong bytes). For large files, this is the whole point — a point query pulls a handful of kilobytes from a multi-megabyte file instead of the entire thing.

5. In the browser

The same file serves a zero-backend web app: the browser engine range-fetches the overview first, then runs SPARQL client-side. A security dashboard could load deps.rete straight from S3 and let users explore impact with no API to build, deploy, or secure.

What just happened: one static file replaced a graph database + query API. The data is plain RDF, the queries are standard SPARQL, and the transport is ordinary HTTP range requests — so it works on infrastructure you already have.