divorce/gzz-mirror
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

created mirror

Browse Source
This commit is contained in:
whatever
2026-09-14 20:19:29 -04:00
commit 6764738d92
600 changed files with 87187 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/Gentle_Introduction/Makefile Normal file
View File

@@ -0,0 +1,19 @@
all: gi.html gi-ns4.html
# zzgentle.tex
zzgentle.dvi: zzgentle.tex
pic -t <$*.tex >$*.tex
latex $*
cat $*.dvi >$*.dvi
ps: zzgentle.ps
# DIAGRAMS=linkorder.png beamorder.png
DIAGRAMS=../wmlinc/article.wml
gi.html: gi.wml $(DIAGRAMS)
gi-ns4.html: gi.wml $(DIAGRAMS)
include ../lib.mk

1
Documentation/Gentle_Introduction/README Normal file
View File

@@ -0,0 +1 @@
Requires latex and the xypic package for latex.

586
Documentation/Gentle_Introduction/gi.wml Normal file
View File

@@ -0,0 +1,586 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!--
NOTE! This file uses WML 2.0.1
PLEASE PLEASE PLEASE don't edit .HTML. Edit .WML!!!! Actually,
it's more important for you since your changes will be LOST FOREVER
if you edit the .HTML files.
-->
<html>
<head>
<title>A Gentle Introduction to Ted Nelson's ZigZag Structure</title>
#include '../wmlinc/article.wml'
</head>
<body>
{: [[s/(?<!>)\b(d\.+\w+)/<code>\1<\/code>/g]]
<H1>A Gentle Introduction to Ted Nelson's ZigZag Structure</H1>
<pre>$Id: gi.wml,v 1.4 2000/10/21 13:45:30 tjl Exp $</pre>
<grid layout=3x3 spacing=20>
<cell> <b>Tuomas Lukka</b> <br>
<code>lukka@iki.fi</code><br>
</cell>
</grid>
<toc>
<p>
This document provides a short introduction to the abstract ZigZag
structure and gives some pointers for designing structures for various
applitudes. Unlike most of the other documentation related to GZigZag,
this document is more about the abstract structure, not this one particular
implementation.
<p>
This introduction, even though it is short, is still
rather technical and detailed
and therefore the even gentler manuscript "GZigZag: a platform for
Cybertext Experiments" is recommended to be read before this document.
<p>
This is work-in-progress: if there are any unclear parts, feel
free to ask me to clarify things.
<warn>
<h2>Introduction</h2>
<p>
The best words I've heard to describe the ZigZag structure
are "hyperstructure kit". It is a set of tools or primitives for
building hyperstructures.
ZigZag was invented by Ted Nelson and is currently being implemented
as a prototype at the University of Jyväskylä under the direction of
the author.
The purpose of this document is to introduce
the reader to the ZigZag structure and some example applications of
it.
<p>
This document was written using material and ideas from
documents by and discussions with Ted Nelson,
but also contains original ideas and material.
<p>
See also the glossary of ZigZag terminology in XXX.
<h2>Basics</h2>
<p>
To arrive at ZigZag from a general perspective, consider the problem
of storing and visualizing information in a structure.
Now, we naturally need some kind of ``atoms'', i.e.~indivisible
pieces of information --- let's make an atom connected to a piece of text
as the information it carries. Now, atoms should be connected to each other.
Consider the two principles: 1) all connections must be two-directional
and 2) to preserve visualizability, no cell should have an enormous number
of connections. There are of course several different ways of realizing
these principles but ZigZag is a particularly simple one.
<p>
ZigZag is a paradigm for manipulating data and devices, a platform
if you may, in some way like UNIX. In UNIX (at least originally), everything
is a file. Whether it is really a printer or the console or a network
connection doesn't matter: the same basic operations (or at least
a subset of
them) is available. ZigZag is quite similar: everything is a cell and
connections between the cells. However, the structure set up by ZigZag is
far richer than a hierarchical file system, allowing more interconnectivity
between related information.
<p>
All data in ZigZag consists of <dfn>cells</dfn>.
A cell can contain e.g. text, an image
or something like that --- basically, a unit of data.
It does not matter how the content is stored; simply
think of a cell as a little
bit of data that has no significant internal structure (except of course the
sequence for text, the places of the pixels for an image etc).
FIGURE
<figure img="" width="">
</figure>
<p>
The cells are the primitives of the structure and the structure is formed
by connecting cells to each other through <dfn>dimensions</dfn>.
In each dimension, each cell can have one positive and one negative
neighbour. This means that all connections between cells are
two-directional: we speak of being neighbour to, or connected to,
not of linking to since linking nowadays means one-directional HTML-like
links.
The different dimensions are denoted by names, such as d.1 or d.clone.
<p>
Now, if we have two dimensions and the cells are connected in a regular
lattice, then this corresponds to a normal spreadsheet. However, no
restriction is placed on which positive and negative ends are connected
together - this is why this is called the ZigZag <em>structure</em>. All kinds
of structures are possible: loops, M\oe bius strips, spheres etc.
The kind of structure to choose for your application is up to your
imagination.
<p>
However, locally, from the perspective of one or two cells, this will
still look like the spreadsheet: each cell has its neighbours and
you go from it to one direction and then turn around and come back in
the opposite direction, you end up in the same cell. So locally this
structure is logical and simple --- like a spreadsheet --- but globally
it is paradoxical: you can just keep going into one direction and
arrive back where
you came from, for example, or you can go left, down, right and up,
and
{\em not} come back where you started from in the end.
This property gives more <em>room</em> in ZigZag for putting things
in than a spreadsheet has, for instance.
<p>
One good way of visualizing this kind of structure is to think a
device commonly found in science fiction books and films: a hallway
with several doors. One door leads to a desert, and another to the
antarctic. When you go through the door, you are in a different place
but you can still walk back through the door, open the other door and
walk through it. At each moment separately, you are operating under
the rules of three-dimensional space known to us but when you pass the
door and realize that you don't see the other door from the other side,
you know that you are in a paradoxical environment.
<p>
Another place to look for good, related visualizations, is the work
of M.C.Escher, who has created many paradoxical spaces that would fit
well with ZigZag. However, not all of his paintings work this way: in ZigZag,
directions are global: up is the same ``up'' everywhere, unlike in some
of Escher's work, so care has to be taken with this analogy.
<p>
A slightly different way of looking at the structure that may sometimes
help thinking about it is to consider dimensions
as {\em labeled lists} of cells.
That is, instead of considering cells and connections, consider lists (each
list labeled with a string) of
cells where the same cell may be on several lists (but only one
with any given label).
It is not difficult to see that this is exactly the same
structure as above but viewed from a different angle: emphasizing the ranks
instead of the single cell and its connections.
<p>
As an example of such a structure, consider a list of people and their
birth years. It'd be quite natural to have first names, last names and
birth years in their own columns, each row being one person.
If done e.g.~on a spreadsheet, you would have to settle
for the global rectangular structure. However, with ZigZag you can
do more interesting things such as have the first names in alphabetical
order, the last names in alphabetical order and finally even the birth
years in numerical order in their own colums. This is because the columns
are independent of each other, bound together simply by having the rows
going across them. Displaying such a structure can be done in several
different ways.
Also, it would then be easy to select subsets of the people on other dimensions,
for example for people who are currently in the same class or whatever.
<p>
It is useful to be able to see the structure from both perspectives
since this will both help to overcome the feeling of paradoxicality
from the spreadsheet-like connective picture but also remember that
the cells are important objects in the list picture.
<h2>Comparing ZigZag with existing computer structures.</h2>
<p>
To put it coarsely, outside ZigZag there are three different kinds of
structures in computers today: linear lists (and grids i.e.~lists of lists),
hierarchical trees and messes. That is really messes, not meshes. By
a mess, I mean any complicated data structure, usually with one-directional
links to make things even more unmanageable.
<p>
The first two are inflexible, even with one-directional
hierarchy-crossing links
such as symlinks in filesystems or XML IDs.
The third always requires much
programming and debugging to do and is often hard to visualize.
<p>
ZigZag offers a fundamental new kind of <em>structure</em> where encoding
new structures is simple because the coherence of the underlying
simple flexible structure is guaranteed.
At first it may seem strange that a structure that restricts the
number of connections from each cell can be generic but this simple
restriction is what brings about the coherence of ZigZag.
In the sections below you'll see how this restriction does not prevent
any structure from being represented using ZigZag but it enables several
clever visualizations.
<p>
Among other things,
ZigZag guarantees that there are no dangling pointers: all links are
two-directional. You can always find which cells refer to a given cell.
<p>
One interesting thing to note
about ZigZag and existing structures,
the importance of which I really only realized while doing a demo at Nokia
is simply that by using different dimensions, ZigZag allows you to
arrange the <em>same</em> things into <em>different</em> traditional
structures. So you can have the same cells in a tree along two
dimensions (as you'll see below, trees are easiest done using two
dimensions, one to go from the parent to the first child and the other
to move along siblings), a list along another dimension and a table
along two other dimensions. And possibly another tree in yet two more
dimensions, if desired.
If you use relcells (see below)
you can even put the same things (this time, not cells: you do have to do a step of indirection)
into different structures along the
<em>same</em> dimensions.
<h2>Viewing</h2>
<p>
Now that the structure is defined, we have to be able to view and edit
it on the computer somehow. Of course, we <em>could</em> just put this
structure in a text file and edit it by naming cells with numbers and
links by naming the cell numbers but this would lose the visuality
inherent in the design.
<p>
There are <strong>many</strong> variations to the theme of viewing
ZigZag structures. Views range from generic to specific views.
Generic views are designed to be useful with a wide range of structures
and usually therefore show only a small number of dimensions
or a small number of steps along each dimension.
Specific views on the other hand are free to do anything that
suits the application at hand.
<p>
Specific views are related to <dfn>applitudes</dfn>, explained below
in more detail.
<p>
In this section, we look at the structure of several generic views.
Before going to the views themselves, let us first define some terms:
the <dfn>raster</dfn> and the <dfn>view</dfn>.
A raster is a way of selecting cells from the structure.
A view is a way of placing the selected cells on the screen.
<p>
In order to look clear to the human observer, visual cues about the
structure are vital. All neighbouring cells that lie next to each other
should be connected with a line, and all cells that have neighbours
that were not displayed because of the raster should have e.g. half of a
connecting line, disappearing underneath the other cell in some visual
fashion to show this. Also, when moving in the structure so that the
part of
<h3>2D rectangular views</h3>
<p>
The 2D rectangular views are characterized by placing the
cells in a spreadsheet-like rectangular grid on the screen.
Even here, there are many different possible
rasters for choosing which cells to place where, since
a general ZigZag structure will not fit a rectangular grid
and parts have to be clipped out.
Note that the 2D here refers to the two-dimensionality of the
rectangular grid, not that there need to be only two dimensions
of the ZigZag structure showing. Usually we only have two
in these views but as we see below, this is not a requirement.
<p>
The two simplest rasters useful for the rectangular views
are the row and column rasters, which are actually
the same raster but placed on the screen rotated 90 degrees
from each other.
These rasters are genuinely two-dimensional: they only
use two dimensions in the ZigZag structure to find cells
to display.
<p>
The row/column raster
starts from the cursor and moves along one ZigZag dimension
and place cells on the center column/row of the grid.
After that column/row is full, the raster starts from
the cells placed and from each, moves along the other
dimension and places the cells found along the other
dimension there.
<p>
These rasters are called <dfn>hard rasters</dfn>:
the arrangement of cells is fixed so that there is
only one possible path from the cursor to a cell to be
placed in a given position on the screen. If there is no
cell in the structure along such a path, then that
location is left empty.
<p>
The converse of hard rasters are the <dfn>soft rasters</dfn>
where there can be several different paths for
each cell of the on-screen grid.
The point of soft rasters is that since ZigZag structures are
often relatively sparse in terms of connections, the
hard row and column rasters may show relatively few cells at
a time. Soft rasters are able to show more of the structure
at the same time.
<p>
There are many different ways to define soft rasters for
the rectangular grid. One fairly useful way is to specify
the soft raster so that all the cells that a certain hard
raster would show are shown, but additionally, if there
is space left, more cells are shown along the dimensions.
<h3>Vanishing view</h3>
<p>
The vanishing view looks a little like the hard row/column
raster above but is in fact a completely different beast.
The raster for a vanishing view consists of all the cells
within a given 2- or 3-dimensional Manhattan distance
from the cursor (a Manhattan distance simply means the number
of connections in any direction to get from one cell to another).
<p>
These cells are then placed on screen starting with the center
cell and reducing the cell size as the distance from the cursor
grows. This causes cells that would be in the same slot
in the rectangular grid to be plotted apart from each other.
<p>
This could easily be generalized to more than three dimensions.
<h3>Compass view</h3>
<p>
The previous views have dealt with a few dimensions but several
steps along those dimensions. The compass
<h3>Multicentric views</h3>
<p>
XXX
<h3>Text view</h3>
<p>
One simple view that can be easily overlooked is to simply
take a rank of cells and show their texts appended to each other.
<h2>Applitudes</h2>
<p>
To distinguish itself from the traditional, monolithic applications,
ZigZag uses the term <em>applitude</em> for a "zone of functionality".
The difference between applications and applitudes is the interconnectivity:
whereas conventional, monolithic applications are used to having all data
in their own files, applitudes can easily share cells and simply use
their own, orthogonal dimensions to connect cells.
<p>
The differences caused by this simple shift are enormous: instead
of a selection of monolithic blocks, the contents of the computer can
become an interconnected, organic whole.
Everything connected to a particular person, for example, is
connected to the same cell, whether in the email applitude, the calendar,
the collection of documents or anything.
<h2>Designing structures</h2>
<p>
In this section, we'll go through some commonly occurring
structural patterns in ZigZag. These can be thought of as being
analogous to Design Patterns in Object-Oriented Programming.
The patterns here are not formalized as far as OO design patterns
but carrying out such a treatment would not be difficult.
<p>
As you will see, there are several different ways of encoding
the same conceptual structure in ZigZag. The choice between
using a different dimension or a rank of clones, for example.
These alternative codings resemble in some way one of XML's
similar ambiguities: for example whether to code something as an attribute
or as a contained text-only element.
<p>
It is important to understand the difference
between the low-level structure and the implied, higher-level
structure. Single cells and single connections are building
blocks, not necessarily complete entities by themselves.
<h3>Cloning</h3>
<p>
One of the basic structural mechanisms in ZigZag is
cloning, i.e. connecting cells on d.clone to imply that
they are somehow the same as the root clone, i.e. negend
of d.clone.
<p>
This mechanism is coupled with the cell content:
the contents of all clones is the same as the contents
of the root clone, and editing a clone edits the root clone.
<p>
XXX
<p>
There are alternatives to cloning, and in many cases they
may be preferable.
For instance, in a calendar applitude it would be possible
to clone the cells for persons into the structures
representing meetings but a possibly preferable approach
would be to use an applitude-specific dimension for this.
The reason is that then this dimension would always lead
to predictable structure and the applitude could
easily give interesting visualizations of the meetings
a person participated or will participate in.
<p>
This is a fairly unsettled question. With more experience
in designing different applitudes we will be able to tell easier when
clones are appropriate and when special dimensions are better.
<h3>Arrangement along a dimension</h3>
<p>
Sometimes, there is a good, unique way of arranging cells along a
dimension, e.g. alphabetical order. However, sometimes there is not,
or there are two different orders you'd like to have.
<p>
This may seem like a difficult problem but actually, if all
but one of the desired orders are easy to determine from the
neighbours of the cells, then there is no problem at all: instead
of expressing it directly in the structure, those orderings that
are easy to construct algorithmically should be delegated to
the view (as of yet, there are no viewers capable of this but
they are under construction).
<p>
Another alternative (that does not currently work) will be
to thread the cells through several dimensions, most of which
are implicit: for example, an implicit d.1-alphabetic could
have the same ranks as d.1 but alphabetized. The implicit
dimensions would be read-only and be updated automatically
when the corresponding real dimensions changed.
<p>
If there is more than one order that is not easily determinable,
then using two dimensions or cloning becomes a thing to
consider.
<h3>Many to one reference</h3>
<p>
Even though the structure only allows only
two connections along each dimension, it
is possible for
many cells to refer to one in ZigZag.
This works by the way outlined above, by building
a higher-level
structure from the low-level building blocks of the cells
and connections.
<p>
There are of course
different ways for creating many to one reference,
but two main ones distinguish themselves.
<p>
If the cell referred is very different from the
cells referring to it, then a single rank, where
the referred-to cell is the headcell is a good choice.
Clones, for example, work this way (see above).
<p>
If the referents can be of the same "type", then
it becomes necessary to allow the cell referred to to
refer to another cell. In such case, a construction called
a <dfn>corner list</dfn> is used.
A corner list works by using two dimensions:
the first one connects all the cells referring to a given
cell and the second one connects the referred-to cell
to the headcell of that rank.
There are two main variants: the empty-headed
one where the headcell is
empty and the solid one where the headcell is one of the referring
cells. The insert and delete referring cells operations are
simpler for the empty-headed list since all referring
cells are in the same position but that configuration wastes
one cell.
<h3>Hierarchies</h3>
<p>
A hierarchy can be understood as a many-to-one reference
relation, with the children of a given cell being the
cells referring to it.
<p>
This would make a tree mapped as in the figure XXX.
<p>
It is good to remember that the same cells can be in
several different trees using different dimensions.
<h3>Relation cells</h3>
<p>
Relation cells (relcells) are a commonly occurring construct
in ZigZag. Fundamentally, relcells exist to declare a relationship
between two cells or two groups of cells.
<p>
One example of a relcell would be the empty headcell in the
empty-headed version of the corner list above.
However, this is a fairly untypical example.
<p>
Typically, a relcell is on two or more ranks and implies
a relationship between the headcells of those ranks.
This way, each cell can have the same relationship to
several other cells at the same time.
<p>
A good example of the use of a relation cell is
the genealogy applitude (pardon the obvious puns).
The idea is to connect all the siblings on one rank in the family
tree and married couples on another, but this leaves
open the question of representing the children born in the marriage.
This is solved by placing a relcell <em>between</em> the parents,
and hanging the sibling rank off that cell as the headcell.
This relcell then implies a parent-child relationship between
the cells connected to it..
<h2>Example applitudes</h2>
XXX
<h2>The Cousin Problem</h2>
<p>
There is one important problem when dealing with data
that has relations, which the author calls the "Cousin" problem.
Consider the genealogy applitude.
Now, insert a new person, A, and then his cousin, B.
A moment's reflection will show that this is impossible
in the data structure explained above.
<p>
This is because in the human representation of concepts,
there is no hierarchy between mother, father, son, daughter and
cousin. There is no good way to pick just one way to represent
the information since the idea "B is A's cousin" is perfectly
valid, even without knowing whether it is on the mother's or
father's side.
:}
</body>
</html>
<!--
vim: set syntax=html :
-->

1280
Documentation/Gentle_Introduction/zzgentle.tex Normal file
View File

File diff suppressed because it is too large Load Diff