From c1424e8863c4de668098730159a26fa0180eb2d0 Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 14 Jun 2026 02:14:04 +0200 Subject: [PATCH] research: ZigZag/zzstructure deep dive (information space as orthogonal dimensions); UC-47/48/49 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Evaluated modelling a wiki information space as a zzstructure: a page is a cell at the intersection of many co-equal dimensions (namespace tree, created-from genealogy, version, shard, equivalence, links). Recommendation: adopt zzstructure as a navigation/visualization/indexing LENS (a derived dimensional projection over the union), not as the storage substrate — Git and sovereign shards stay canonical, and the many-to-many link graph does not fit the one-neighbour-per-dimension rank rule. Clone <-> transclusion convergence with the Xanadu dive. Added UC-47/48/49; enriched UC-05/22/26/29; dimensional projection layer + genealogy-edges-in-journal logged as architecture for SHARD-WP-0002. Co-Authored-By: Claude Opus 4.8 --- SCOPE.md | 4 +- research/260614-zigzag-deep-dive/README.md | 43 +++ research/260614-zigzag-deep-dive/findings.md | 294 +++++++++++++++++++ research/README.md | 3 +- spec/UseCaseCatalog.md | 98 ++++++- 5 files changed, 432 insertions(+), 10 deletions(-) create mode 100644 research/260614-zigzag-deep-dive/README.md create mode 100644 research/260614-zigzag-deep-dive/findings.md diff --git a/SCOPE.md b/SCOPE.md index 89ca392..a26a6fc 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-*/`); Project Xanadu deep dive (`research/260614-xanadu-deep-dive/`) | +| Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag deep dives (`research/260614-*/`) | | Demand | NetKingdom integration asks captured, not yet negotiated | -| Spec | Architecture blueprint drafted; UseCaseCatalog 46 UCs from research; PRD/TSD scaffolds | +| Spec | Architecture blueprint drafted; UseCaseCatalog 49 UCs from research; PRD/TSD scaffolds | | Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (10 tasks) | ## In Scope (today) diff --git a/research/260614-zigzag-deep-dive/README.md b/research/260614-zigzag-deep-dive/README.md new file mode 100644 index 0000000..f1f85f2 --- /dev/null +++ b/research/260614-zigzag-deep-dive/README.md @@ -0,0 +1,43 @@ +# 260614 — ZigZag / zzstructure deep dive (an information space as orthogonal dimensions) + +Date: 2026-06-14 + +## What this is + +A focused study of **Ted Nelson's ZigZag** and its data model **zzstructure**, asked +through a specific shard-wiki question: a wiki page is linked in many independent ways +at once — a **namespace** tree, a **created-from / genealogy** lineage, **hyperlinks**, +plus shard-wiki's own **shard / overlay / version / transclusion / equivalence** +relations. Could the information space be modelled as a zzstructure, where each +relationship is a first-class **dimension** and none is privileged? + +Distinctive material: +- the zzstructure model — **cells**, **dimensions** (edge colours), **ranks**, + **posward/negward**, and the one rule that defines it: *at most one posward and one + negward neighbour per dimension per cell* (a directed coloured multigraph) +- **views** — I-view (one dimension), **H-view** (pivot two dimensions into a cross), + raster-vs-view +- trees/lists/tables as *spent dimensions*; many-to-many graphs as the hard case + (handled by **clones**) +- **clone ↔ transclusion** convergence with the Xanadu dive + +## Contents + +| Path | Role | +|------|------| +| `findings.md` | zzstructure model, views, fit analysis, a proposed dimension map for a shard-wiki space, recommendation (lens not store), INTENT mapping, UC seeds, architecture notes, sources | + +## Status + +Initial deep dive complete. Three new use cases promoted to `spec/UseCaseCatalog.md` +(UC-47 navigate-by-dimension, UC-48 H-view pivot/cross-tab, UC-49 genealogy +dimension); UC-05/17–22/26/29 enriched. A **dimensional projection layer** is logged +as architecture for `workplans/SHARD-WP-0002-federation-architecture.md`. + +**Recommendation recorded:** adopt zzstructure as a **navigation / visualization / +indexing lens** (a derived dimensional projection over the union), **not** as the +storage substrate — Git and sovereign shards remain canonical (INTENT Stability Note). +The many-to-many hyperlink graph does not fit zzstructure's rank constraint and stays a +separate graph index. Pairs with `research/260614-xanadu-deep-dive/` (clone ↔ +transclusion). + diff --git a/research/260614-zigzag-deep-dive/findings.md b/research/260614-zigzag-deep-dive/findings.md new file mode 100644 index 0000000..861b4ce --- /dev/null +++ b/research/260614-zigzag-deep-dive/findings.md @@ -0,0 +1,294 @@ +# Findings — ZigZag / zzstructure: an information space as orthogonal dimensions + +Date: 2026-06-14 +Source kind: **conceptual / data-model prior art** (a data model + visualization +paradigm, not a deployable wiki engine, not a candidate shard backend) +Lens: shard-wiki — modelling a wiki information space where a page participates in +*many* relationship structures at once (namespace, genealogy, links, versions, shards) + +> Motivating question (from the user). A wiki page is linked in several independent +> ways at once: a **primary namespace** association giving a tree-like hierarchy; a +> **created-from / genealogy** association (fork/derivation lineage); **hyperlinks** +> to other pages; and — in shard-wiki — *which shard* it lives in, its **overlays**, +> its **versions**, its **transclusions**, and its **equivalents** elsewhere. Could +> the information space be modelled as Ted Nelson's **ZigZag / zzstructure**, where +> each kind of relationship is a separate, first-class **dimension** and no single +> relationship is privileged as *the* structure? +> +> Short answer: **yes as a navigation / visualization / indexing lens; no as the +> storage substrate.** zzstructure is an unusually good *conceptual* match for +> shard-wiki's "union without erasure" thesis — it makes every relationship +> co-equal and separately navigable — but its one-neighbour-per-direction +> constraint makes it a poor *direct* encoding of the many-to-many hyperlink graph, +> and Git/heterogeneous shards must remain the canonical store. Details below. + +Companion to the Xanadu dive (`research/260614-xanadu-deep-dive/`): ZigZag is +Nelson's *other* lifelong project, the structural/visual counterpart to Xanadu's +literary/addressing one. Where Xanadu gives shard-wiki **reference-not-copy**, ZigZag +gives it **many co-equal structures over the same cells**. + +--- + +## 1. What ZigZag / zzstructure is + +ZigZag (Ted Nelson, conceived 1981 at Datapoint; first Perl prototype by Andrew Pam, +1997; the **GZigZag / Gzz** Java project 2000–2003; US patent 6,262,736, expired +2019) is **"a data model that deconstructs the spreadsheet to allow irregular +relations, generalizing the idea to multiple dimensions."** The generic, vendor-free +name for the data model is **zzstructure**. + +Core vocabulary: + +- **Cell (zzcell)** — an atom of data (a value, a record, a page). Cells are the only + content; everything else is connection. +- **Dimension** — a *named kind of connection* (an edge colour). Dimensions are + **first-class** — in ZigZag, dimensions are themselves cells. +- **Link (zzlink)** — a connection between two cells *along one dimension*, with a + **posward** (positive) and **negward** (negative) direction. +- **Rank** — the maximal chain of cells along one dimension (a path, or a cycle). A + rank is ZigZag's equivalent of "a row" / "a list" — but it exists only along one + named dimension. +- **Cursor** — the current focus cell from which views are drawn. +- **Clone** — a copy of a cell that shares identity with its head cell (along a + special clone dimension), used to let one logical item appear in several places / + participate in many-to-one relations. + +--- + +## 2. The one rule that defines everything + +Formally (McGuffin & schraefel, HT2004; McGuffin's graph-theoretic intro), a +zzstructure is: + +> a **directed multigraph whose edges are coloured (typed)**, subject to the +> restriction that **each node has at most one incoming edge of each colour and at +> most one outgoing edge of each colour.** + +Equivalently: **along any single dimension, a cell has at most one posward and one +negward neighbour.** That single constraint is the whole design: + +- Each dimension decomposes the cell set into disjoint **ranks** (paths and cycles) — + never a branching tree, never a fan-out, *within one dimension*. +- Many dimensions coexist over the **same** cells, each imposing its own independent + rank structure. A cell sits at the intersection of as many dimensions as it + participates in. +- There is **no inherent hierarchy.** A tree is not the substrate; it is *one + possible dimension* (encoded left-child/right-sibling — see §4). + +This is the property that matters for shard-wiki: **the same set of pages can carry +many orthogonal structures simultaneously, with none privileged.** + +--- + +## 3. Views — how multiple dimensions are seen + +Because no screen can show all dimensions, ZigZag *rotates* two into view at a time: + +- **I-view** — cells along **one** dimension from the cursor, drawn as a line. +- **H-view** — a 2-D cross: **two** dimensions through the cursor, one drawn + horizontally and one vertically; only cells actually connected to the cursor along + those two dimensions appear (empty spreadsheet cells simply do not exist). +- **I+/H+ (augmented) views** — fill remaining space with further neighbours. +- **Raster vs. view (terminology)** — a *raster* selects which cells to take from the + structure; a *view* places them on screen. "Pivoting" rotates a different dimension + into the horizontal or vertical slot. + +The H-view "pivot" is the genuinely interesting UX idea for a *federated* wiki: put +**pages of a namespace** on one axis and **shards** (or **versions across shards**) +on the other, then rotate to re-cross-tabulate the same union by a different pair of +relationships. + +--- + +## 4. Trees, lists, tables, graphs — what fits and what does not + +zzstructure subsumes simpler structures by spending dimensions: + +- **List** = one rank along one dimension. +- **Table** = two dimensions (rows / columns), shown as an H-view. +- **Tree** = encoded as a zzstructure "analogous to the left-child, right-sibling + pointer implementation" — i.e. a *parent→firstchild* dimension plus a + *sibling→sibling* dimension. So a hierarchy is **two dimensions**, not a primitive. +- **Many-to-one / many-to-many** = NOT directly expressible (the one-edge-per-colour + rule forbids fan-out). It is simulated with **clones**: the head cell links to many + clone cells along the clone dimension, and each clone participates in a different + rank. + +**This is the critical caveat for wikis.** A namespace hierarchy (each page has *one* +parent) and a created-from genealogy (each page has *one* origin) fit zzstructure +*natively* and beautifully. But a wiki's **hyperlink graph is many-to-many** (a page +links to many pages and is linked from many) — it is *not* a rank and cannot be one +dimension. Representing links/backlinks in zzstructure requires cloning or treating +the link set as data, which is awkward. zzstructure is excellent for the +**functional/sequential/hierarchical** relationships and weak for the **arbitrary +graph** ones. + +--- + +## 5. Mapping a shard-wiki information space onto dimensions + +Taking the user's framing literally — model the union of pages as cells, and each +relationship as a dimension: + +| Dimension (proposed) | Rank meaning | Fits zzstructure? | shard-wiki source | +|----------------------|--------------|-------------------|-------------------| +| `d.namespace-child` + `d.namespace-sibling` | namespace tree (left-child/right-sibling) | **Yes** (2 dims) | UC-22, yawex topics | +| `d.genealogy` | created-from / fork lineage (each page one origin) | **Yes** (functional) | UC-26 fork, UC-29 remix | +| `d.version` | revision order of a page | **Yes** (a rank = a history) | coordination journal | +| `d.shard` | pages grouped by owning shard | **Yes** | shard sovereignty | +| `d.overlay` | page → its overlays | **Yes** (or clones) | overlay model | +| `d.equivalence` | parallel versions of the same topic across shards | **Yes** (a rank of equivalents) | UC-27, UC-46 | +| `d.recent` | temporal order of changes | **Yes** | UC-17 RecentChanges | +| `d.alphabetical` | AllPages ordering | **Yes** | UC-19 | +| `d.links` / `d.backlinks` | hyperlink graph | **No** (many-to-many) — needs clones / stays a graph index | UC-05, UC-18 | +| `d.transclusion` | content reused in many places | **No** as rank — but maps to **clones** (= "same content in many places") | UC-32, UC-44/45 | + +Observation: shard-wiki's existing **derived views** (UC-05, UC-17–UC-20) are, in +zzstructure terms, *dimensions + rasters*: RecentChanges is a raster along `d.recent`, +AllPages along `d.alphabetical`, SiteMap is an H-view over the two namespace +dimensions. zzstructure offers a **single unifying vocabulary** for what shard-wiki +currently treats as a grab-bag of separate derived views. + +Observation 2: ZigZag **clones** are conceptually the same move as Xanadu +transclusion ("the same content knowably in more than one place") — the two Nelson +projects converge here. A transcluded span / equivalent page is a clone that +participates in multiple ranks. + +--- + +## 6. Is zzstructure the right model for shard-wiki? (recommendation) + +**Adopt as a lens, not a substrate.** + +- **As a navigation & visualization model: promising.** Letting a reader pick which + *dimension* to traverse (namespace vs. genealogy vs. version vs. shard) and pivot + two dimensions into an H-view is a real, differentiated UX for a federated, + provenance-preserving wiki. It operationalizes "union without erasure": every + relationship is co-equal and visible, none hidden. (UC-47, UC-48.) +- **As a conceptual model for the page graph: useful and clarifying.** Reframing the + scattered derived views as *dimensions over one cell set* is a clean mental model + and a candidate internal index/API shape. It also de-privileges the namespace tree + (UC-49) — consistent with **mechanism over policy** (the hierarchy is one + configurable dimension, not the canonical structure). +- **As the storage substrate: reject.** Git and heterogeneous sovereign shards remain + canonical (per INTENT Stability Note — Git's role is architectural). A zzstructure + is a **derived, projected index** computed over the union, like BackLinks today — + not a database that replaces the shards. The many-to-many hyperlink graph does not + fit the rank constraint, and forcing the wiki into a zz-DB would violate shard + sovereignty and the orchestrator-not-engine boundary. + +Net: zzstructure is a strong answer to *"how do we present a page's many +simultaneous relationships without picking a winner?"* — a **dimensional projection** +layer over the existing union, not a new store. + +--- + +## 7. Mapping to shard-wiki INTENT (compare, do not equate) + +### 7.1 Reinforcements + +- **Union without erasure ↔ co-equal dimensions.** zzstructure's refusal to privilege + any one structure is the data-model expression of shard-wiki's refusal to hide + provenance, conflicts, or alternative arrangements. +- **Mechanism over policy ↔ hierarchy-as-just-a-dimension.** The namespace tree being + one dimension among many is exactly "do not hard-code one canonical structure." +- **Provenance ↔ genealogy dimension.** Created-from lineage as a navigable rank makes + provenance a first-class traversal, not metadata buried in a footer. + +### 7.2 Deliberate divergences (design bugs if conflated) + +1. **zzstructure as store.** Replacing Git/shards with a zz-database would break the + Stability-Note boundary on Git's role and on orchestrator-vs-engine. zzstructure is + a projection, full stop. +2. **Forcing the hyperlink graph into ranks.** The link/backlink graph is many-to-many + and must stay a graph index; do not contort it into a single dimension. Use clones + or keep it as a separate graph projection. +3. **One global zz-space.** Like Xanadu's docuverse, a single universal zz-space would + fight shard sovereignty. Each information space gets its *own* dimensional + projection over *its* attached shards. + +### 7.3 What ZigZag teaches that shard-wiki should keep + +- A page is best understood as **a cell at the intersection of many independent + relationships**, not as a node in one tree. Build the page model and the navigation + API so *adding a new relationship is adding a dimension*, not special-casing a view. +- **Pivoting two relationships** (H-view) is a powerful, under-used exploration + primitive for federation (namespace × shard, page × version, topic × equivalent). + +--- + +## 8. Use-case seeds → catalog (promoted 2026-06-14) + +Last existing UC is **UC-46**. New UCs **UC-47–UC-49** added; existing UCs enriched. + +| Seed | Catalog action | +|------|----------------| +| **Navigate along a chosen relationship dimension** — pick namespace / genealogy / links / version / shard as the active traversal axis | **UC-47 (new)** | +| **Pivot two dimensions as a cross-tab (H-view)** — e.g. namespace × shard, page × version-across-shards | **UC-48 (new)** | +| **First-class created-from / fork genealogy dimension** — navigate derivation lineage as a rank | **UC-49 (new)** | +| Namespace hierarchy is *one dimension among many*, not the privileged structure | **enriches UC-22** | +| Derived views (RecentChanges, AllPages, SiteMap, BackLinks) reframed as dimensions + rasters | **enriches UC-05** (anchor for the UC-17–UC-20 view reframing) | +| Fork/remix produce a genealogy edge consumed by UC-49 | **enriches UC-26, UC-29** | +| Clone = "same content in many places" = transclusion convergence | links UC-32, UC-44/45 | + +--- + +## 9. Architecture notes for SHARD-WP-0002 (no UC) + +- A **dimensional projection layer** over the union is a candidate internal model: + pages = cells; relationships (namespace, genealogy, version, shard, equivalence, + overlay, recent, alphabetical) = dimensions; existing derived views = rasters over + them. It is **derived/lazy**, never canonical store. +- The **link/backlink graph stays a separate many-to-many index**; do not model it as + a rank. Reconcile with the dimensional model via clones or by keeping graph and + dimensional projections side by side. +- **Genealogy** (created-from) should be recorded as an edge when fork/remix/import + happens (UC-26, UC-29) so the `d.genealogy` rank can be reconstructed — ties to the + coordination journal. +- Whether the dimensional model is exposed in a **public navigation API** or stays an + internal organizing concept is open (see §10). + +--- + +## 10. Open questions (for spec / workplans) + +1. Is the dimensional/zzstructure model a **public navigation API** and UI paradigm, + or only an *internal* organizing concept for the existing derived views? +2. How is the **many-to-many link graph** reconciled with the rank-based dimensional + model — clones, a parallel graph index, or both? +3. Which dimensions are **core** (namespace, version, shard, genealogy, recent) vs. + **adapter-provided** vs. **computed on demand** (equivalence, backlinks)? +4. Is **H-view pivoting** worth a reference-UI investment, or is it research-only? +5. Does the **clone = transclusion** convergence justify a single internal primitive + shared by UC-44/45 (transclusion) and UC-47/48 (dimensional navigation)? + +--- + +## 11. Sources + +| Source | Used for | +|--------|----------| +| Wikipedia — ZigZag (software) (https://en.wikipedia.org/wiki/ZigZag_(software)) | History, spreadsheet-deconstruction framing, one-connection-per-dimension rule, pivoting | +| Wikipedia — Zzstructure (https://en.wikipedia.org/wiki/Zzstructure) | Directed-coloured-multigraph definition, dimensions-are-cells, raster vs. view | +| McGuffin & schraefel, "A Comparison of Hyperstructures: Zzstructures, mSpaces, and Polyarchies," ACM Hypertext 2004 (https://www.dgp.toronto.edu/papers/mmcguffin_HT2004.pdf) | Graph-theoretic formal definition; taxonomy vs. mSpaces/polyarchies | +| McGuffin, "A Graph-Theoretic Introduction to Ted Nelson's Zzstructures" (https://www.dgp.toronto.edu/~mjmcguff/research/zigzag/) | Ranks, I-view/H-view/augmented views, clones, tree-as-left-child/right-sibling, "multiple arrangements coexist via dimensions" | +| Moore & Brailsford, "Unified Hyperstructures for Bioinformatics," JoDI (https://jodi-ojs-tdl.tdl.org/jodi/article/download/jodi-138/127) | Applied zzstructure as a unifying model over heterogeneous structures | +| Nelson, "A Cosmology for a Different Computer Universe" (zzstructure context) | Nelson's own framing of cells/dimensions/visualization | +| Gzz — "A Gentle Introduction to Ted Nelson's ZigZag Structure" (https://www.nongnu.org/gzz/gi/gi.html) | Practical cell/dimension/rank examples (rate-limited; corroborated by above) | + +Cross-references: `research/260614-xanadu-deep-dive/findings.md` (clone↔transclusion +convergence), `spec/UseCaseCatalog.md` (UC-05, UC-17–UC-22, UC-26, UC-27, UC-29, +UC-32, UC-44/45/46), `workplans/SHARD-WP-0002-federation-architecture.md`. + +--- + +## 12. Traceability + +- New UCs: **UC-47, UC-48, UC-49** → `spec/UseCaseCatalog.md`. +- Enriched UCs: **UC-05** (anchors the UC-17–UC-20 derived-view reframing), **UC-22, + UC-26, UC-29**. +- Architecture (no UC): dimensional projection layer; link-graph-stays-graph; + genealogy edges in the journal; clone↔transclusion primitive → `SHARD-WP-0002`. +- Decision boundary recorded: zzstructure is a **derived lens, not the store**; + Git/shards remain canonical (INTENT Stability Note). + diff --git a/research/README.md b/research/README.md index 6b48664..cb40c6a 100644 --- a/research/README.md +++ b/research/README.md @@ -17,4 +17,5 @@ when multiple files or sources are involved. Findings here inform `spec/` and | 2026-06-13 | `260613-xwiki-deep-dive/` | XWiki impl, extension interfaces, ecosystem; UC-38/39 | | 2026-06-13 | `260613-twiki-deep-dive/` | TWiki impl, plugin API, ecosystem; UC-40/41 | | 2026-06-13 | `260613-foswiki-deep-dive/` | Foswiki store abstraction, extension API; UC-42/43 | -| 2026-06-14 | `260614-xanadu-deep-dive/` | Project Xanadu — EDL/reference-not-copy, transclusion, addressing; UC-44/45/46 | \ No newline at end of file +| 2026-06-14 | `260614-xanadu-deep-dive/` | Project Xanadu — EDL/reference-not-copy, transclusion, addressing; UC-44/45/46 | +| 2026-06-14 | `260614-zigzag-deep-dive/` | ZigZag/zzstructure — information space as orthogonal dimensions; UC-47/48/49 | \ No newline at end of file diff --git a/spec/UseCaseCatalog.md b/spec/UseCaseCatalog.md index 780bcce..8a352cf 100644 --- a/spec/UseCaseCatalog.md +++ b/spec/UseCaseCatalog.md @@ -5,8 +5,8 @@ Status: **draft** · Date: 2026-06-08 · Updated: 2026-06-14 Promoted from `research/260608-c2-wiki-origins/`, `research/260608-yawex-prior-art/`, `research/260608-federation-concepts/`, `research/260608-wikiengines-overview/`, `research/260613-xwiki-deep-dive/`, -`research/260613-twiki-deep-dive/`, `research/260613-foswiki-deep-dive/`, and -`research/260614-xanadu-deep-dive/`. +`research/260613-twiki-deep-dive/`, `research/260613-foswiki-deep-dive/`, +`research/260614-xanadu-deep-dive/`, and `research/260614-zigzag-deep-dive/`. See InfoTechPrimers on coulomb.social for use-case catalog conventions. ## Conventions @@ -72,7 +72,11 @@ all attached shards as a federated graph. **Source:** intent, c2, yawex **Notes:** Present on both c2 (community nerve center) and yawex core pages. BackLinks over the union link-graph is the strongest core candidate; per-shard -vs union scope remains open (see UC-19–UC-21). +vs union scope remains open (see UC-19–UC-21). ZigZag deep dive reframes these views +under one vocabulary: each is a **dimension + raster** (RecentChanges along `d.recent`, +AllPages along `d.alphabetical`, SiteMap as an H-view over the namespace dimensions), +navigable via UC-47 (`research/260614-zigzag-deep-dive/findings.md` §5). Note: the +many-to-many link/backlink graph stays a **separate graph index**, not a zz-rank. **Priority:** Later ### UC-06 — Authenticated team wiki (L2+) @@ -107,7 +111,9 @@ shard for independent editing, with provenance preserved. **Notes:** Fedwiki fork primitive. shard-wiki may realize as import, overlay seed, or writable copy per policy — distinct from UC-04 (overlay without copy) and UC-03 (projection only). Fork vs overlay vs import decided in -`SHARD-WP-0002`. +`SHARD-WP-0002`. Should record a **created-from genealogy edge** in the coordination +journal so the lineage is navigable as a dimension (UC-49, +`research/260614-zigzag-deep-dive/findings.md` §9). **Priority:** Later ### UC-27 — View multiple versions of equivalent page @@ -144,7 +150,8 @@ per-shard history. Frictionless reuse principle (~15s not ~15min). Xanadu **transcopyright**: a reference carries provenance *and reuse terms* with it, so attribution/permission travel with the span — but reuse policy stays configurable, not baked into the substrate (`research/260614-xanadu-deep-dive/findings.md` §6); links the -authz-in-core L0→L4 ladder decision. +authz-in-core L0→L4 ladder decision. Remix should also record a **genealogy edge** +(UC-49) so reuse lineage is navigable, not just attributed. **Priority:** Later ### UC-30 — Time-bounded collaboration space @@ -397,6 +404,45 @@ normalized-text hash, none). Open: core vs. adapter-index; cost at wiki scale wi enfilades (findings §11 Q3). **Priority:** Later +### UC-47 — Navigate the information space along a chosen relationship dimension + +**Actor:** Reader +**Goal:** Traverse pages along a *selected* relationship axis — namespace, created-from +genealogy, version history, owning shard, equivalence, or recent-change order — rather +than a single fixed hierarchy. +**Source:** zigzag, intent +**Notes:** ZigZag/zzstructure treats each relationship as a first-class **dimension**; +a page is a cell at the intersection of many independent ranks +(`research/260614-zigzag-deep-dive/findings.md` §2, §5). Reframes the existing derived +views (UC-05, UC-17–UC-20) as *dimensions + rasters* under one vocabulary. Embodies +union-without-erasure: every relationship co-equal, none privileged. Open: public +navigation API vs. internal model (findings §10 Q1). +**Priority:** Later + +### UC-48 — Pivot two relationships into a cross-tab view (H-view) + +**Actor:** Reader +**Goal:** Cross-tabulate the union by two dimensions at once — e.g. namespace × shard, +or page × versions-across-shards — and pivot to re-cross by a different pair. +**Source:** zigzag +**Notes:** ZigZag **H-view** shows two dimensions through a cursor, one horizontal one +vertical, with only existing cells present (`research/260614-zigzag-deep-dive/findings.md` +§3). A differentiated exploration primitive for federation/provenance. Open: reference-UI +investment vs. research-only (findings §10 Q4). +**Priority:** Later + +### UC-49 — Navigate created-from / fork genealogy as a first-class dimension + +**Actor:** Reader or maintainer +**Goal:** Follow a page's derivation lineage — what it was forked/remixed/imported +from, and what was derived from it — as a navigable rank. +**Source:** zigzag, federation, intent +**Notes:** Genealogy is a *functional* relation (one origin) that fits a zzstructure +dimension natively (`research/260614-zigzag-deep-dive/findings.md` §4, §5). Requires a +genealogy edge recorded at fork/remix/import time (UC-26, UC-29) in the coordination +journal. Makes provenance a traversal, not a buried footer (complements UC-24). +**Priority:** Later + --- ## B. Knowledge work and collaboration @@ -550,7 +596,11 @@ adapter-provided indexing TBD. normalized paths within a topic hierarchy. **Source:** yawex **Notes:** yawex topics-as-directories; page-resolution state space is -inspiration only for federation design (not inherited as API). +inspiration only for federation design (not inherited as API). ZigZag deep dive: treat +the namespace hierarchy as **one dimension among many** (encoded left-child/right-sibling +as two zz-dimensions), not the privileged structure — consistent with mechanism over +policy; navigate it as one axis via UC-47 (`research/260614-zigzag-deep-dive/findings.md` +§4, §7.1). **Priority:** Later ### UC-23 — Soft topic creation via red link @@ -625,6 +675,9 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD. | UC-44 | | | ✓† | | ✓ | | UC-45 | | | ✓† | | ✓ | | UC-46 | | | ✓† | | ✓ | +| UC-47 | | | ‡ | | ✓ | +| UC-48 | | | ‡ | | | +| UC-49 | | | ‡ | | ✓ | | UC-08 | ✓ | | | | UC-09 | ✓ | | | | UC-10 | ✓ | | | @@ -743,6 +796,33 @@ single-global-docuverse premise, single-canonical-instance model, and baked-in e policy (findings §8.2), as these violate shard sovereignty, parallel-version support (UC-27), and mechanism-over-policy. +### zigzag mapping + +(‡ UC-47–UC-49 are placed in the **federation** matrix column as the nearest existing +source; their true lineage is the **ZigZag deep dive**, +`research/260614-zigzag-deep-dive/findings.md`.) + +| ZigZag / zzstructure mechanism (findings §) | Catalog UC | +|---------------------------------------------|------------| +| Each relationship is a first-class **dimension**; a page is a cell at many ranks (§2, §5) | UC-47 | +| **H-view** — pivot two dimensions into a cross-tab (§3) | UC-48 | +| **Genealogy** as a functional dimension fitting a zz-rank (§4, §5) | UC-49 | +| Hierarchy is **one dimension among many** (left-child/right-sibling) (§4, §7.1) | UC-22 (enriched) | +| Derived views = **dimensions + rasters** under one vocabulary (§5) | UC-05 (enriched; anchors UC-17–UC-20) | +| Fork/remix records a navigable genealogy edge (§9) | UC-26, UC-29 (enriched) | +| **Clone** = "same content in many places" — converges with transclusion (§5) | links UC-32, UC-44/45 | + +Note: ZigZag is **a data model + visualization paradigm, not a candidate shard +backend.** Recommendation recorded in the dive: adopt zzstructure as a **navigation / +visualization / indexing lens** — a *derived dimensional projection* over the union, +like BackLinks today — and **reject it as the storage substrate** +(`research/260614-zigzag-deep-dive/findings.md` §6, §7.2). Git and sovereign shards +remain canonical (INTENT Stability Note). The many-to-many hyperlink graph does **not** +fit zzstructure's one-neighbour-per-dimension rule and stays a separate graph index. +Architecture logged for `SHARD-WP-0002`: a dimensional projection layer; genealogy +edges in the coordination journal; clone↔transclusion as a possible shared primitive +(findings §9). Pairs with the Xanadu dive (clone ↔ transclusion convergence). + --- ## Open questions @@ -756,4 +836,8 @@ policy (findings §8.2), as these violate shard sovereignty, parallel-version su `ProductRequirementsDocument.md` as explicit product identity? 5. Which federation UCs (UC-26–UC-33) are **MVP** vs deferred until `SHARD-WP-0002` architecture decisions land? -6. Does UC-32 (transclusion) belong in core orchestrator or adapter/UI layer? \ No newline at end of file +6. Does UC-32 (transclusion) belong in core orchestrator or adapter/UI layer? +7. Is the **dimensional/zzstructure model** (UC-47/48) a public navigation API and UI + paradigm, or only an internal organizing concept for the derived views? +8. How is the **many-to-many link graph** reconciled with the rank-based dimensional + model — clones, a parallel graph index, or both? (ZigZag dive §10.) \ No newline at end of file