# 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).