[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

*To*: zzdev@xxxxxxxxxx, zigzag-list@xxxxxxxxxx*Subject*: ZZ-space and using its dimensions*From*: Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>*Date*: Fri, 7 Jul 2000 17:39:11 +0300 (EEST)*Sender*: tuukka@xxxxxxxxxxxxxxxxxx

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

**Follow-Ups**:**Re: [zzdev] ZZ-space and using its dimensions***From:*Ted Nelson

- Prev by Date:
**Re: [zzdev] :zz,hier,tyrf: Deep overlap in ZigZag (was Re: :gzz: Modules (wuz Re: :zz,tyrf: "Re: [zzdev] Using XML import/export** - Next by Date:
**Re: [zzdev] :gzz,virt: Dim. rotation probs (and modifier keys)** - Previous by thread:
**:zz,spi: Cosmology (was Re: zz(Finland) postponed** - Next by thread:
**Re: [zzdev] ZZ-space and using its dimensions** - Index(es):