diff --git a/SCOPE.md b/SCOPE.md index a99b8d8..6594480 100644 --- 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) diff --git a/research/260614-wikibase-deep-dive/README.md b/research/260614-wikibase-deep-dive/README.md new file mode 100644 index 0000000..362e5b3 --- /dev/null +++ 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). diff --git a/research/260614-wikibase-deep-dive/findings.md b/research/260614-wikibase-deep-dive/findings.md new file mode 100644 index 0000000..6769465 --- /dev/null +++ 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$`), 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 { … }` 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. diff --git a/research/README.md b/research/README.md index 9b5ca7a..1311a81 100644 --- 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 | \ No newline at end of file +| 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 | \ No newline at end of file diff --git a/spec/UseCaseCatalog.md b/spec/UseCaseCatalog.md index c879f36..0fb1415 100644 --- 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.) \ No newline at end of file diff --git a/workplans/SHARD-WP-0003-engine-dives-batch.md b/workplans/SHARD-WP-0003-engine-dives-batch.md index b372a54..d65ad8a 100644 --- 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" ```