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