Slopnet Architecture: RDF-star, Named Graphs, and Graph-Shape Discovery

The Great RDF-star vs QLever Debate

Today we made a critical architectural decision for Slopnet: Oxigraph + RDF-star over waiting for QLever support.

The Decision Matrix

We considered two heavyweight contenders:

Oxigraph:

• Native RDF-star support (RDF 1.2)
• Optimized for relational graph queries
• Perfect for entity co-occurrence and social graph traversal
• Scales to 500K-1M users at 250 slops each

QLever:

• Blazing fast full-text search
• Wikipedia-scale optimization (billions of triples)
• BUT: No RDF-star support yet (issue #2169)
• Missing quoted triple syntax we need for clean provenance

Why RDF-star Won

The killer feature: quoted triples for provenance

# Old way (verbose blank nodes):
_:prov1 slop:subject :entity123 ;
        slop:predicate schema:name ;
        slop:object "knowledge graphs" ;
        slop:confidence 0.87 .

# RDF-star way (elegant):
<< :entity123 schema:name "knowledge graphs" >> 
    slop:confidence 0.87 ;
    slop:lineStart 42 .

We're not doing full-text search as the primary use case - we're doing relational pattern matching on entity graphs. Oxigraph excels at this.

Per-Slop Named Graphs

Each slop gets its own graph URI:

https://slop.at/graph/{user}/{repo}/{slop-id}

Benefits:

• Atomic CRUD: DROP GRAPH deletes one slop cleanly
• Query flexibility: Search all graphs by default, filter by user/repo pattern
• Provenance boundary: Graph URI = source of truth
• Scalability: Millions of named graphs? No problem (RocksDB FTW)

The Discovery Vision

The real magic: graph-shape-based recommendations

With symmetric local + remote Oxigraph topology, we can:

# Find slops similar to MY entity patterns
SELECT ?slop WHERE {
  # Local: my co-occurrence patterns
  { SELECT ?e1 ?e2 WHERE { ?mySlop slop:mentions ?e1, ?e2 } }
  
  # Remote: public slops with similar structure
  SERVICE <https://slop.at/sparql> {
    ?slop slop:mentions ?e1, ?e2 .
  }
}

Not text similarity - structural graph similarity. What would I find interesting based on how my knowledge connects, not just keyword matching.

Migration Path

If we hit 100K users and need QLever's full-text power:

1. Export N-Quads from Oxigraph
2. Import to QLever (when they add RDF-star)
3. Change one env var: SLOP_GRAPH_SERVER
4. Same queries work (it's all SPARQL)

The Tech Stack

• Storage: Oxigraph (local + remote)
• RDF: RDF 1.2 with RDF-star quoted triples
• Python: pyoxigraph (rdflib doesn't support RDF-star yet)
• Serialization: N-Triples-star format
• Provenance: Quoted triples with confidence, line numbers, source URLs
• Attribution: "familiar" field with full model ID

Scale Targets

• Beta: 10K users
• Growth: 100K users (revisit at this point)
• Theoretical max: 500K-1M users before needing sharding

At 250 slops/user × 100 triples/slop = 25K triples/user:

• 100K users = 2.5B triples (approaching DBpedia scale, still doable)
• 500K users = 12.5B triples (now we're talking Wikidata territory)

What We Unlocked Today

1. ✅ Clean RDF-star provenance (no more blank node spaghetti)
2. ✅ Per-slop atomic graphs (easy management)
3. ✅ LLM attribution ("familiar" field)
4. ✅ Local/remote symmetry (graph-shape discovery ready)
5. ✅ Migration flexibility (can move to QLever later)

The Philosophy

"Why use 47 AWS services when Supabase go brrr?" applies to RDF stores too.

Why wait for QLever when Oxigraph + RDF-star gives us:

• The relational query power we actually need
• Clean provenance semantics
• Future-proof RDF 1.2 compliance
• A clear migration path if we outgrow it

YAGNI meets semantic web. Ship it. 🚀

Slopspiracy theory: What if the real knowledge graph was the architecture decisions we made along the way?