Re: [zzdev] ZZ-space and using its dimensions

[Ted Nelson <ted@xxxxxxxxxx>]

Hi Tuukka--

>I've been toying with ZZ and gZZ enough to have quite a long personal
>TODO list :-) Now, before running into doing this stuff, I feel like I
>should have a deeper understanding of the possibilities and limitations
>of the space. I think one of the most important things is to comprehend
>how to use the multidimensionality right. 

An excellent idea!

>I have read mostly the
>gzigzag documentation, 

I suggest you go to the original author!  (I'm told that Newton's
 introduction to the calculus is still the best ...)

See the tutorial at xanadu.com.

And please look especially at the Floating World design specs.

I am not able to reply to your long comments
 at this time.  I hope you can see the unity of
 my design and understand it.

Best, Ted


At 05:39 PM 7/7/00 +0300, you wrote:
>
>Hello!
>
>I've been toying with ZZ and gZZ enough to have quite a long personal
>TODO list :-) Now, before running into doing this stuff, I feel like I
>should have a deeper understanding of the possibilities and limitations
>of the space. I think one of the most important things is to comprehend
>how to use the multidimensionality right. I have read mostly the
>gzigzag documentation, which gives some examples on this subject too. I
>don't know if I could already find this somewhere, but here are my
>thoughts. If this isn't redundant, please read through and comment.
>
>
>
>1 Different dimensions present different kinds of atomic relations
>
>
>You can do _everything_ in one dimension: think of your computers
>one-dimensional RAM. 
>
>You can do _everything_ without dimensions: graphs in CS don't have
>dimensions, still one can describe any structure using only graphs.
>
>You can do _everything_ having one dimension per relation ie. infinite
>number of dimensions: here the dimensions have totally lost their
>meaning, and their number means nothing.
>
>Now, in ZigZag, it seems best to have each dimension contain all
>relations of a single type. We have "d.cursor", "d.handle", 
>"d.cellcreation" etc. all represent one special relationship between the
>cells connected along that dimension. This seems reasonable, as we want
>to describe or find out certain types of relations at a time. The
>(bi)directional structure of ZigZag luckily allows us even to see these
>relations in pairs, "if your my child then I'm your parent".
>
>
>1.1 Splitting relations up
>
>The first problem, encountered when thinking about ZZ by the definition,
>are the limitations. How do we describe one-to-many or many-to-many
>relations? Of course this is possible (we know it right away as we see
>computer RAM as a special case of this), but the question is, how to
>describe these relations meaningfully, so that we get some advance from
>the underlying ZZ-space.
>
>One solution given is to have clone cells, ie. dummy cells pointing to
>the real cell along d.clone. This way we can create any number of
>similar relations, we'll simply extend the rank along d.clone with one
>clone cell per cell's relation. This way has its shortcomings: When we
>get cell data we must /everywhere/ check for d.clone relation and
>possibly run through the rank to get the data cell. 
>
>|Data|
>   |
>|Clone|<-|uses|
>   |
>|Clone|<-|uses|
>   |
>|Clone|<-|uses|
>
>More simple way to represent the relations is actually given here:
>headcell is in one-to-many relation with its clones, witch run down the
>rank along d.clone. One more way could be using d.rel for the relation
>with the first of the set, and then let rest of the set run down the
>rank along d.enumerate.
>
>|uses|-|Item A|
>          |
>       |Item B|
>          |
>       |Item C|
>
>On many-to-many relations, one way is to use conventional adjacency
>matrices, marking cells in table "+" if there's a relation, " " if not.
>         |Cell A| |Cell B| |Cell C|
>|Cell 1| |  +   |-|  +   | |  +   |
>            |        |   |    |
>|Cell 2| |      |-|      |-|  +   |
>            |        |        |
>|Cell 3| |  +   |-|  +   |-|  +   |
>
>This is extremely bad: we need n*m (n^2) dummy cells, we must run
>through the empty cells to find the relations, there are no constraints
>for the relations.
>
>A way better is given: use one-to-many relation to both directions.
>This could look like the adjecency matrix, we just remove the " " cells
>and connect their positive and negative relations. (This thanks to
>local euclidity)
>
>
>The point is, we must break these more complex relations back to
>simpler ones, probably expressing the original relation with two
>dimensions. To me this seems to be a good thing. The bad thing you've
>already felt: there is more than one way to do it. Now the question is,
>is there always an optimal way, so we could write it down somewhere and
>let everyone learn it - or do we have to learn these different ways and
>learn to decide when to use each one. (Current gZZ implementation uses
>several of these.)
>
>
>1.2 Reserving each dimension to one relation type
>
>Think of "d.1" and "d.2" and "d.3". What relations do they represent?
>Now, take this example:
>
>We have a simple applitude (a structure and a way to change and see it)
>for e-mail. We have the contents of a mail in one cell, and the next
>mail can be found poswards on "d.next" of the cell. The user sees one
>message a time in the window, and he can get previous mail pressing "-"
>and next pressing "+". (A _simple_ applitude, as I told you!) It's
>important that the mail is on a rank on "d.next", otherwise the
>applitude can't know what to do when "+" or "-" is pressed.
>
>We have also another simple applitude, kind of a garbage collector.
>When I don't need a cell anymore I can drag cells into its view, and
>the next time I ask it to take the rubbish out, it'll go and
>detach/erase these cells. And, you guessed it, it uses "d.next" to
>get to the next cell to remove. When I try to add some junk mail to the
>list, the best thing the applitude can do is to say it's not possible,
>the cell is already connected along this dimension. 
>
>Note that the clone cells won't help. If it was the content we were
>interested in - like if I list things I must read - then it would
>suffice to clone the e-mail for listing. And even then, the applitude
>would have to know of clone cells. (Should we make these mandatory,
>like I suggested d.cellcreation to be?)
>
>The solution is to make sure each dimension is used for a single task.
>We can make the applitudes configurable, make them able to choose a
>fresh dimension when they're used for the first time, make it possible
>to change/translate dimensions when importing data sets (be it slices or
>something else) etc. If we make sure each applitude can be used with
>several configurations at a time, it's also possible to mix data sets
>of the same type of applitude, eg. have different lists shown by list
>applitude.
>
>
>The problem is, we can't have "default" dimensions - dimensions used 
>for several unrelated tasks - like "d.1", "d.2" and "d.3". OK, let's
>forget them, it's easy to change the places the implementation depends
>on them. Now, how do we define a convenient way to travel in the space?
>At the moment, we can see two or three dimensions at once. If we won't
>have these "default" dimensions, it'll be a lot of turning and trying
>to find one's way further. (On the current visualisations, that is. I'm
>sure many clever ones can be designed.)
>
>(To be continued with parts 2, 3, etc. if you find these useful or if
>I get good comments.)
>
>
>Tuukka
>
>
>
>
_________________________________________
Theodor Holm Nelson              
Project Professor, Keio University SFC Campus, Fujisawa, Japan
Visiting Professor, University of Southampton, England
 ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
 ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
 ? Coordinates in USA      Tel. 415/ 331-4422
  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
_________________________________________