research: Wikibase/Wikidata deep dive (entity-statement graph, SPARQL); UC-73-75

SHARD-WP-0003 T2. Structure & native-query far-end: typed knowledge graph (items/properties, statements = claim+qualifiers+references+rank), RDF projection + SPARQL (WDQS/Blazegraph) incl. federated SERVICE, opaque stable Q/P identity (labels-as-annotation), statement-level provenance. UC-73 (typed-graph shard, lossy render), UC-74 (SPARQL + federated query), UC-75 (per-assertion provenance). Enriched UC-34/58/52/24. Marks T2 done. Feeds SHARD-WP-0002 T12/T16. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-14 19:31:08 +02:00
parent ecb7d0154e
commit a6629bdb29
6 changed files with 318 additions and 7 deletions
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -19,9 +19,9 @@ Learnings update both SCOPE and INTENT where necessary.
 |-------|-------|
 | Code | Python package scaffold (`src/shard_wiki/`, smoke tests only) |
 | Intent | `INTENT.md` established; authorization-in-core amendments drafted |
-| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
+| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki + Wikibase deep dives & shard-spectrum synthesis (`research/260614-*/`) |
 | Demand | NetKingdom integration asks captured, not yet negotiated |
-| Spec | Architecture blueprint drafted; UseCaseCatalog 72 UCs from research; PRD/TSD scaffolds |
+| Spec | Architecture blueprint drafted; UseCaseCatalog 75 UCs from research; PRD/TSD scaffolds |
 | Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` active (9 engine dives); `SHARD-WP-0004` active (8 computational-knowledge dives) |

 ## In Scope (today)
--- a/research/260614-wikibase-deep-dive/README.md
+++ b/research/260614-wikibase-deep-dive/README.md
@@ -0,0 +1,16 @@
+# 260614 — Wikibase / Wikidata deep dive
+
+Deep dive on **Wikibase** (the MediaWiki extension behind **Wikidata**) as the
+**entity-statement (RDF) far end** of the structure and native-query spectra: items and
+properties, statements = claim + qualifiers + references + rank, stable opaque IDs, and
+**SPARQL** (Wikidata Query Service / Blazegraph) including **federated** queries.
+
+- `findings.md` — data model, RDF/SPARQL surface, storage & history, capability profile,
+  INTENT mapping, UC seeds (UC-73–UC-75), architecture notes for SHARD-WP-0002, open
+  questions, sources, traceability.
+
+Catalog yield: UC-73 (attach a typed entity-statement / RDF shard, lossy render to a page),
+UC-74 (graph query the union via SPARQL + federated `SERVICE` cross-endpoint query), UC-75
+(statement-level provenance — references + rank per assertion). Enriched UC-34/58/52/24.
+Feeds SHARD-WP-0002 T12 (structured/typed page model) and T16 (stable language-neutral
+identity ≠ label/placement).
--- a/research/260614-wikibase-deep-dive/findings.md
+++ b/research/260614-wikibase-deep-dive/findings.md
@@ -0,0 +1,200 @@
+# Wikibase / Wikidata — deep dive (findings)
+
+**Date:** 2026-06-14 · **Source:** SHARD-WP-0003 T2 · **Subject:** Wikibase (MediaWiki
+extension) and its flagship instance **Wikidata**, incl. the Wikidata Query Service (SPARQL).
+
+## Why this dive
+
+Every structured shard so far tops out at *typed records in a database*: Notion's
+database-pages, XWiki's XObjects/classes, Trilium's typed relations, Roam/Logseq's
+attribute blocks. Wikibase is a *different kind of structure altogether* — a **typed
+knowledge graph of entities and provenance-bearing statements**, queried with **SPARQL**
+over an **RDF** projection. It is the **far end of the structure spectrum** and of the
+**native-query spectrum**, and it pushes **provenance down to the individual assertion**.
+The question for shard-wiki: what does a shard look like when its "page" is *not prose but a
+set of statements*, and what does the page model / adapter contract owe such a shard?
+
+## 1. The data model — entities, statements, snaks
+
+**Entities** are the top-level objects, each on its own MediaWiki page with a **stable
+opaque ID**:
+
+- **Item** — `Q42`. Has multilingual **labels / descriptions / aliases**, a set of
+  **statements**, and **sitelinks** (links to wiki articles). The label is *annotation*,
+  not identity — `Q42` is the identity, "Douglas Adams" is just its English label.
+- **Property** — `P31` ("instance of"). Also has labels/descriptions/aliases, plus a
+  **fixed datatype** constraining its values (item-reference, string, time,
+  globe-coordinate, quantity, monolingual-text, url, external-id, commons-media, …).
+
+**Statement** = the unit of assertion on an item. Structure:
+
+```
+statement = claim + references[] + rank
+claim     = mainSnak + qualifiers[]
+snak      = property + snaktype + (value)        # snaktype ∈ value | somevalue | novalue
+```
+
+- **Main snak** — the core property→value assertion (e.g. `P31` → `Q5` "human").
+- **Qualifiers** — snaks that *contextualize* the claim without being the subject (validity
+  time, "as of", determination method, units). E.g. *population (P1082) = 8.4M, **point in
+  time (P585) = 2020***.
+- **References** — lists of snaks citing **where the claim comes from** (a source item, a
+  URL, a page number). **Provenance attached to the individual statement, not the page.**
+- **Rank** — `preferred` | `normal` | `deprecated`: relative importance among same-property
+  statements (lets multiple, even contradictory, values coexist with a curation signal —
+  the structured analogue of fedwiki's "chorus").
+- Each statement carries a **stable GUID** (`Q42$<uuid>`), so statements are individually
+  addressable.
+
+`somevalue` (known to exist, value unknown) and `novalue` (known *not* to have a value) are
+**first-class** — the model represents *known-unknowns* explicitly, which prose and most
+DBs cannot.
+
+## 2. The RDF / SPARQL surface
+
+Wikibase **projects entities to RDF**; the **Wikidata Query Service (WDQS)** is a
+**Blazegraph** triple store exposing a **SPARQL** endpoint. The projection is deliberately
+multi-layered:
+
+- **Truthy** triples (`wdt:` prefix) — the simple "best" value, for easy queries:
+  `wd:Q42 wdt:P31 wd:Q5`.
+- **Full** statements — reified so qualifiers/references/rank survive: `wd:Q42 p:P31
+  ?stmt . ?stmt ps:P31 wd:Q5 ; pq:P585 ?time ; prov:wasDerivedFrom ?ref`. (`p:`=statement
+  node, `ps:`=statement value, `pq:`=qualifier, `pr:`/`prov:`=reference.)
+- **Federated SPARQL** — the `SERVICE <endpoint> { … }` keyword runs a sub-query against
+  *another* SPARQL endpoint and joins the results. **Query-level federation is built into
+  the query language** — a different federation primitive from fedwiki's fork/neighborhood.
+- **EntitySchemas / ShEx** — schemas (`E`-ids) that *validate* an entity's shape (Shape
+  Expressions). Optional, declarative structure validation over the open graph.
+
+## 3. Storage, identity, history
+
+- **Storage:** each entity is a **JSON blob stored as a MediaWiki page** (`Item:` /
+  `Property:` content model). The RDF/SPARQL store is a **derived index** rebuilt from these
+  canonical JSON entities (an *update stream* feeds WDQS) — exactly shard-wiki's
+  "derived query index over a canonical store" pattern (UC-63), at planet scale.
+- **Identity:** the **opaque Q/P/L IDs are the identity**, fully decoupled from
+  human-readable labels and from language. This is the cleanest real-world instance of
+  **stable, language-neutral identity ≠ label/placement** — a strong reinforcement of our
+  identity model (T16).
+- **History:** because each entity is one MediaWiki page, history is **page-level MediaWiki
+  revisions** — every edit is a full-entity JSON snapshot with author/timestamp/comment.
+  *Coarse* history granularity (whole entity per revision), but the **edit API is
+  fine-grained** (`wbsetclaim`, `wbeditentity` patch individual statements). So: **fine
+  write API over a coarse history unit** — a distinct point on the write/history spectra.
+
+## 4. Capability profile
+
+| Dimension (synthesis spectrum) | Wikibase / Wikidata |
+|--------------------------------|---------------------|
+| Attachment mode | **external-API** (MediaWiki Action API + REST) **and** a derived **SPARQL endpoint**; self-hostable |
+| Addressing granularity | **statement** (each has a GUID) within an **entity** (Q/P id) |
+| Content identity | **stable opaque ID** (Q/P/L); labels are multilingual annotations |
+| Identity vs placement | **fully separated** — identity is language- and label-neutral |
+| Structure | **typed knowledge graph**: entities + statements (claim+qualifiers+refs+rank) |
+| History | **page-level revisions** (whole-entity JSON snapshots); fine-grained edit API |
+| Merge model | MediaWiki last-writer / edit-conflict; rank lets contradictory values coexist |
+| Native query | **SPARQL** (RDF) + **federated `SERVICE`** cross-endpoint join — the far end |
+| Translation | **not Markdown** — content *is* statements; render to prose is a lossy projection |
+| Attachment/write granularity | **statement-level writes** via API; coarse history unit |
+| Operational envelope | huge derived index (Blazegraph), rate-limited public endpoints |
+| Access grant | open read; MediaWiki user/permission model for write; self-host = own ACL |
+| Content opacity | transparent (public JSON + RDF); not encrypted |
+| Provenance | **statement-level** — references + rank per assertion (new far end) |
+
+## 5. INTENT mapping
+
+### Reinforcements
+
+- **Stable identity ≠ placement** (T16): Q/P IDs decoupled from labels/language are the
+  textbook case — adopt the principle that a page's *identity* is an opaque stable handle,
+  display names are annotations.
+- **Derived index over canonical store** (UC-63): WDQS is exactly a SPARQL index rebuilt
+  from canonical JSON entities via an update stream — validates the projection pattern.
+- **Union without erasure / chorus**: **rank** lets multiple (even contradictory) statements
+  coexist with a curation signal rather than forcing one truth — the *structured* analogue
+  of fedwiki's chorus (UC-72) and our "view multiple versions" (UC-27).
+- **Mechanism over policy**: references + rank are *mechanism* for representing disagreement
+  and sourcing; which statement "wins" is left to the consumer/query.
+
+### Divergences (boundaries / design notes)
+
+- **Content is not Markdown.** A Wikibase "page" is a set of statements; there is no prose
+  body. This is the **structure far-end**: shard-wiki must either (a) treat such a shard as
+  a **structured/typed shard** projected to a *lossy* Markdown/table rendering (UC-55/UC-73),
+  or (b) model a page whose payload is typed statements (T12). Forcing it into Markdown-first
+  erases the graph — a design-bug if done silently; render-with-provenance instead.
+- **Provenance granularity is finer than ours.** Our provenance is per-page/per-shard;
+  Wikibase is **per-statement** (references) and even per-value (rank). The page model and
+  coordination journal should *allow* sub-page provenance (UC-75) even if MVP records it per
+  page.
+- **Query is graph, not text/datalog.** SPARQL over RDF (with federated `SERVICE`) is a
+  richer query far-end than Roam/Logseq datalog or Notion filters (UC-52) — and its
+  `SERVICE` federation is a *query-time* cross-shard join, distinct from fedwiki structural
+  federation. Note both as native-query tiers.
+
+### What to keep
+
+1. **Opaque stable identity, labels-as-annotations** as the identity model (T16).
+2. **Statement/assertion-level provenance** (references) and a **coexistence-with-rank**
+   model as the structured form of union-without-erasure (UC-75).
+3. **Derived SPARQL/graph index over a canonical entity store** as a projection pattern
+   (UC-63/UC-74), incl. **federated query** as a first-class federation mode.
+4. A **typed-graph page payload** option in the page model (T12), with **lossy
+   render-to-Markdown** as the projection (never silent flattening).
+
+## 6. UC seeds
+
+| # | Seed | Disposition |
+|---|------|-------------|
+| UC-73 | Attach a **Wikibase** as a **typed entity-statement (RDF) shard** (items/properties/statements w/ qualifiers); project to a rendered page view, lossy to Markdown, preserving the graph | **new** |
+| UC-74 | **Graph-query the union** via **SPARQL** and **federate queries across endpoints** (`SERVICE`) — graph query as a native-query tier + query-time cross-shard join | **new** |
+| UC-75 | Preserve **statement-level provenance** — references + rank attached to each assertion (sub-page provenance granularity) | **new** |
+| — | typed records → typed *graph* entities | enrich **UC-34** |
+| — | inter-record relations → typed graph edges with qualifiers | enrich **UC-58** |
+| — | native query → SPARQL/RDF + federated SERVICE | enrich **UC-52** |
+| — | provenance → statement/assertion granularity | enrich **UC-24** |
+
+## 7. Architecture notes for SHARD-WP-0002
+
+- **T12 (structured/typed page model):** add a **typed-graph payload** tier above
+  typed-records — a page whose content is **entities + statements (claim + qualifiers +
+  references + rank)**, with `somevalue`/`novalue` known-unknowns. Render-to-Markdown is a
+  **lossy projection**, not the canonical form.
+- **T16 (identity / addressing):** adopt **opaque stable identity with labels-as-annotation**
+  (Q/P model); record **statement GUIDs** as an example of *sub-page addressable units*.
+- **Native-query tiering:** SPARQL/RDF + federated `SERVICE` is the **graph far-end** of the
+  query spectrum (above datalog/filters); `SERVICE` is also a **query-time federation**
+  mode to sit beside fedwiki's structural federation.
+- **Provenance model:** allow **per-statement references + rank** (sub-page provenance,
+  coexistence-with-curation) in the union, even if MVP collapses to per-page.
+- **Derived index:** WDQS = canonical JSON entities → update stream → Blazegraph SPARQL
+  index; the reference implementation of UC-63 at scale (per-shard or core-built index, Q16).
+
+## 8. Open questions
+
+1. Does shard-wiki model a **typed-graph page** natively (T12), or always treat Wikibase as
+   a structured shard **projected to a Markdown/table rendering** (UC-55), or both
+   (canonical graph + lossy view)?
+2. Is **SPARQL/graph query** exposed as a union-level capability (translate to a common
+   query layer) or only as a **pass-through** to graph-capable shards? How does federated
+   `SERVICE` relate to shard-wiki's own cross-shard query?
+3. At what granularity does the coordination journal record **provenance** — per page
+   (MVP), per statement (Wikibase-native), or configurable?
+4. Is **rank** (coexisting contradictory values w/ curation) representable in the union as a
+   first-class "chorus of statements," unifying with fedwiki's page-level chorus (UC-72/27)?
+
+## 9. Sources
+
+- Wikibase/DataModel and **DataModel/Primer** — mediawiki.org
+- Help:Qualifiers; Wikidata SPARQL query service + Query Help; SPARQL tutorial — wikidata.org
+- Wikidata Query Service / User Manual — mediawiki.org; Wikitech (Blazegraph, updater)
+- "The wikibase model" — Vanderbilt Libraries Digital Lab (heardlibrary.github.io)
+- RaiseWikibase — Wikibase Data Model functions (ub-mannheim.github.io)
+- WShEx / EntitySchemas (ShEx) — arxiv.org/abs/2208.02697, ceur-ws.org Vol-3262
+
+## 10. Traceability
+
+New UCs **UC-73–UC-75** carry the marker **⬡** in the wikiengines column of
+`spec/UseCaseCatalog.md`. Enriched: UC-34, UC-58, UC-52, UC-24. Architecture cross-refs:
+SHARD-WP-0002 T12, T16, native-query tiering, provenance model, UC-63 derived index.
--- a/research/README.md
+++ b/research/README.md
@@ -28,4 +28,5 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 | 2026-06-14 | `260614-localfirst-workspaces-deep-dive/` | Anytype · AFFiNE · AppFlowy — CRDT local-first workspaces (any-sync/Yjs/Yrs), native merge, P2P/E2EE; UC-64/65 |
 | 2026-06-14 | `260614-trilium-deep-dive/` | Trilium/TriliumNext — note cloning (DAG hierarchy), attribute inheritance/templates, HTML-native, scripting+ETAPI; UC-66/67 |
 | 2026-06-14 | `260614-wikijs-deep-dive/` | Wiki.js — storage-module engine (DB↔Git Markdown), GraphQL API, pluggable modules ≈ adapter-contract prior art; UC-68/69 |
-| 2026-06-14 | `260614-federated-wiki-deep-dive/` | Federated Wiki — fork-with-provenance, per-page semantic-action journal (story=replay), neighborhood/roster + chorus; prior art for our coordination journal / overlay / union pillars; UC-70/71/72 |
+| 2026-06-14 | `260614-federated-wiki-deep-dive/` | Federated Wiki — fork-with-provenance, per-page semantic-action journal (story=replay), neighborhood/roster + chorus; prior art for our coordination journal / overlay / union pillars; UC-70/71/72 |
+| 2026-06-14 | `260614-wikibase-deep-dive/` | Wikibase/Wikidata — typed entity-statement knowledge graph (claim+qualifiers+refs+rank), SPARQL/RDF + federated SERVICE, opaque stable IDs, statement-level provenance; structure & query far-end; UC-73/74/75 |
--- a/spec/UseCaseCatalog.md
+++ b/spec/UseCaseCatalog.md
@@ -12,7 +12,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260614-logseq-deep-dive/`,
 `research/260614-localfirst-workspaces-deep-dive/`,
 `research/260614-trilium-deep-dive/`, `research/260614-wikijs-deep-dive/`, and
-`research/260614-federated-wiki-deep-dive/`.
+`research/260614-federated-wiki-deep-dive/`, and
+`research/260614-wikibase-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.

 ## Conventions
@@ -605,7 +606,10 @@ database **query API** (filters/sorts) — a strong delegation target
 (`research/260614-notion-deep-dive/findings.md` §2, §4). **Logseq** shows the third path:
 Datalog over a **derived** index built from plain files — neither native-DB nor plugin;
 when no engine exists, shard-wiki can build the index itself (UC-63,
-`research/260614-logseq-deep-dive/findings.md` §3).  
+`research/260614-logseq-deep-dive/findings.md` §3). **Wikibase** is the far end:
+**SPARQL** over an RDF projection with **federated `SERVICE`** cross-endpoint joins
+(`research/260614-wikibase-deep-dive/findings.md` §2) — a graph-query tier above
+datalog/filters, and `SERVICE` is itself a query-time federation primitive (UC-74).  
 **Priority:** Later

 ### UC-53 — Attach a local-first Markdown vault with a live concurrent native editor
@@ -965,6 +969,52 @@ chorus compose with shards that assert a canonical? Feeds SHARD-WP-0002 T1–T5;
 UC-05/UC-27 (union/chorus), UC-26 (fork).  
 **Priority:** Later

+### UC-73 — Attach a typed entity-statement (RDF) knowledge-graph shard
+
+**Actor:** Orchestrator / adapter  
+**Goal:** Attach a **Wikibase** instance as a **typed entity-statement shard** — items and
+properties, statements = claim + qualifiers + references + rank — and project entities to a
+rendered page view (lossy to Markdown) **without flattening away the graph**.  
+**Source:** wikiengines, intent  
+**Notes:** The **structure far-end** beyond Notion DB / XWiki XObjects / Trilium relations:
+a true typed knowledge graph with `somevalue`/`novalue` known-unknowns
+(`research/260614-wikibase-deep-dive/findings.md` §1). Content **is not Markdown** — render
+is a lossy projection (UC-55), so attach as a structured shard and either keep the graph as
+the canonical payload (T12) or offer a rendered view, never a silent flatten. Feeds
+SHARD-WP-0002 T12 (typed-graph page payload), T16 (stable opaque identity).  
+**Priority:** Later
+
+### UC-74 — Graph-query the union (SPARQL) and federate queries across endpoints
+
+**Actor:** Reader / analyst  
+**Goal:** Query graph-capable shards with a **graph query language (SPARQL)** and **federate
+queries across endpoints** (`SERVICE`) — a query-time cross-shard join distinct from
+structural (fork/neighborhood) federation.  
+**Source:** wikiengines, intent  
+**Notes:** SPARQL over the RDF projection (Wikidata Query Service / Blazegraph) is the
+**native-query far-end** above Roam/Logseq datalog and Notion filters (UC-52); `SERVICE` is
+a **query-time federation** primitive beside fedwiki's structural federation (UC-72)
+(`research/260614-wikibase-deep-dive/findings.md` §2). Open: union-level common query vs
+pass-through to graph-capable shards. Feeds SHARD-WP-0002 native-query tiering; relates
+UC-63 (derived index — WDQS is one).  
+**Priority:** Later
+
+### UC-75 — Preserve statement-level provenance (references + rank)
+
+**Actor:** Core orchestrator  
+**Goal:** Preserve **provenance at the assertion level** — references and **rank** attached
+to each *statement*, not just per page or per shard — so contradictory values can coexist
+with a curation signal.  
+**Source:** wikiengines, intent  
+**Notes:** Wikibase attaches **references** (sources) and a **rank**
+(`preferred`/`normal`/`deprecated`) to each statement
+(`research/260614-wikibase-deep-dive/findings.md` §1, §5) — provenance granularity **finer**
+than shard-wiki's per-page model, and the *structured* analogue of fedwiki's chorus (UC-72)
+and "view multiple versions" (UC-27). The page model + coordination journal should **allow**
+sub-page/per-assertion provenance even if MVP records per page. Enriches UC-24; feeds
+SHARD-WP-0002 T12 + provenance model.  
+**Priority:** Later
+
 ---

 ## B. Knowledge work and collaboration
@@ -1157,7 +1207,11 @@ edit count, and whether the page has local overlays or diverges elsewhere.
 provenance principle. Xanadu deep dive: provenance is *structural*, not decorative —
 content remembers where it came from and where it is reused (UC-45), built into the
 storage model rather than added after the fact
-(`research/260614-xanadu-deep-dive/findings.md` §4, §8.1).  
+(`research/260614-xanadu-deep-dive/findings.md` §4, §8.1). **Wikibase** pushes provenance
+*finer than the page*: **references + rank per statement** let sourced, even contradictory,
+values coexist with a curation signal (UC-75,
+`research/260614-wikibase-deep-dive/findings.md` §1, §5) — the page model should allow
+sub-page/per-assertion provenance even if MVP records it per page.  
 **Priority:** Later

 ### UC-25 — Collaborative glossary and precise naming
@@ -1230,6 +1284,9 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-70 | | | ✓⊞ | | ✓ |
 | UC-71 | | | ✓⊞ | | ✓ |
 | UC-72 | | | ✓⊞ | | ✓ |
+| UC-73 | | | | ⬡ | ✓ |
+| UC-74 | | | | ⬡ | ✓ |
+| UC-75 | | | | ⬡ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1670,6 +1727,38 @@ above fedwiki's fork-DAG provenance edges. Architecture logged for `SHARD-WP-000
 (T1–T5, T11, T13, T16): journal-as-coordination-journal, story-item write granularity,
 journal-replay as a third merge model, fork entries as identity≠placement provenance edges.

+### wikibase mapping
+
+(⬡ UC-73–UC-75 are placed in the **wikiengines** matrix column; lineage = the **Wikibase
+deep dive**, `research/260614-wikibase-deep-dive/findings.md`.)
+
+| Wikibase mechanism (findings §) | Catalog UC |
+|---------------------------------|------------|
+| Items/properties + statements (claim+qualifiers+refs+rank); not-Markdown graph (§1) | UC-73 (new) |
+| RDF projection + SPARQL (WDQS/Blazegraph) + federated `SERVICE` (§2) | UC-74 (new) |
+| References + rank per statement = assertion-level provenance + coexistence (§1, §5) | UC-75 (new) |
+| Typed records → typed *graph* entities (§1) | UC-34 (enriched) |
+| Inter-record relations → typed graph edges with qualifiers (§1, §2) | UC-58 (enriched) |
+| Native query → SPARQL/RDF + federated SERVICE (§2) | UC-52 (enriched) |
+| Provenance → statement/value granularity (§1, §5) | UC-24 (enriched) |
+| Opaque stable Q/P IDs; labels = annotations; identity ≠ label/placement (§3) | links UC-51 / T16 |
+| WDQS = derived SPARQL index over canonical JSON entities via update stream (§3) | links UC-63 |
+| Rank: contradictory values coexist with a curation signal (§1, §5) | links UC-27 / UC-72 |
+
+Note: Wikibase (the engine behind **Wikidata**) is the **structure and native-query
+far-end** of the studied set — a **typed knowledge graph** where a "page" is a set of
+**statements** (claim + qualifiers + **references** + **rank**), not prose, queried with
+**SPARQL** over an **RDF** projection (incl. **federated `SERVICE`** cross-endpoint joins).
+Three things transfer cleanly: **opaque stable identity with labels-as-annotation** (the
+cleanest real instance of identity ≠ placement, T16); **assertion-level provenance** —
+references + rank let contradictory values coexist with curation (the *structured* chorus,
+UC-75/UC-27); and **a derived graph index over a canonical entity store** (WDQS = UC-63 at
+scale). **Boundary recorded:** content is **not Markdown** — attach as a structured shard
+and render lossily (UC-55/UC-73), never silent-flatten the graph; expose SPARQL as a
+graph-query tier (UC-74), not the union default. Architecture logged for `SHARD-WP-0002`
+(T12/T16): typed-graph page payload, opaque identity, native-query tiering (SPARQL +
+federated SERVICE), sub-page provenance model.
+
 ---

 ## Open questions
@@ -1726,5 +1815,10 @@ journal-replay as a third merge model, fork entries as identity≠placement prov
    vocabulary (create/add/edit/move/remove/fork) at item granularity, or an abstract op
    set other shards can also emit — and does a **chorus / no-canonical** union (UC-72)
    compose with shards that assert a canonical? (Federated Wiki dive §9.)
+24. Does shard-wiki model a **typed-graph page** natively (entities + statements, UC-73) or
+    always project Wikibase to a lossy Markdown/table view (UC-55) — and is **SPARQL/graph
+    query** (UC-74) a union-level capability or a pass-through to graph-capable shards? At
+    what granularity is **provenance** recorded — per page (MVP) or per statement (UC-75)?
+    (Wikibase dive §8.)
 23. How does shard-wiki **honor/surface a shard's path-based access rules** (UC-06) in a
    projection without re-implementing its ACL engine? (Wiki.js dive §9.)
--- a/workplans/SHARD-WP-0003-engine-dives-batch.md
+++ b/workplans/SHARD-WP-0003-engine-dives-batch.md
@@ -67,7 +67,7 @@ chorus); feed `SHARD-WP-0002` T1–T5.

 ```task
 id: SHARD-WP-0003-T2
-status: todo
+status: done
 priority: high
 state_hub_task_id: "23272f05-556b-4cc7-93b6-4ac3c7277738"
 ```