shard-wiki/research/260614-zigzag-deep-dive/findings.md

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