coulomb/shard-wiki
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

research: ZigZag/zzstructure deep dive (information space as orthogonal dimensions); UC-47/48/49

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Bernd Worsch
2026-06-14 02:14:04 +02:00
parent 0a335eca8b
commit c1424e8863
5 changed files with 432 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
SCOPE.md
View File

@@ -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)

43
research/260614-zigzag-deep-dive/README.md Normal file
View File

@@ -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).
</content>

294
research/260614-zigzag-deep-dive/findings.md Normal file
View File

@@ -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).
</content>

3
research/README.md
View File

@@ -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 |
| 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 |

98
spec/UseCaseCatalog.md
View File

@@ -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?
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.)