coulomb/shard-wiki
Archived
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

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 |