zz,tx,crel: FIX: Parting of the Versions again (was Re: *Still further Clarif. re inside/contents (was: Re: Surplus meaning & anthills (was: Re: FURTHER Clarif. re inside/contents

[Ted Nelson <ted@xxxxxxxxxx>]

Hi, Mark-Jason--

1.  Semantics of the containment structure.

>If the user wants `additional extraneous links',  why don't they make
>them in an additional extraneous dimension, instead of making them in
>d.contents, which has a system-imposed semantics?  

Because the system semantics ALSO includes ending interpretation
 of d.contents at a negward link on d.inside.  

I can see where you want the semantics to be a little simpler
 for elegance' sake.  (Back to that later.)

2.  Is the cutoff rule extraneous?
>Then
>you don't need a rule about how a negward connection in a totally
>different dmiension somehow nullifies the effect of a link.

But I believe that "stopping the interpretation of a list before a negward
 link" is a general pattern we'll need for other conjoined dimension pairs,
 e.g. d.mark/d.marklist (allowing some mark-sets to be joined together).

This is a termination feature of what I call a "corner list"-- which
 in the case of containment consists of one cell connected on d.inside
 to a list on d.contents, but which I see as a general zigzagular structure.

Cutoff rule stated more fully and generally: "Stopping the interpretation
 of a list along the second dimension of a dimension-pair when a
 negward link is found on the first dimension of the pair".

Who will want to do such things, making gratuitous connections
 between well-defined corner lists?  I for one.  It will have
 useful visualization properties.  

Eg (frankly, I'd forgotten this important example):
\/d.contents  <=d.inside (reversed to use the margin of this e-mail)
January - 1998
February
March
April
May
June
July
August
September
October
November
December 
January - 1999

where 1998 - 1999.

Try it and see.  Great for chronological listings.
 (I had an excellent time dataset on which I worked
 many hours last December, but it won't open.
 I suppose I better redo it ...

3.  Overlapping categories.

>> >I said that you were mistaken, because the user made the
>> >C-D link on purpose and ZigZag has no right to disregard that.
>> 
>> Then the user has to disconnect B-D, because it ends the list.
>
>And what if they want D to be in B as well as in A?

For this, the clone.

4.  Clearly you understand the structure !-)

* * * The problem is really cosmological / aesthetic.  (Not joking:
 this is really important in the field, because it deeply affects people's
 deep religious(-like) loyalties to different systems and languages.) * * *

You want the semantics to be a little simpler for elegance' sake.
 I respect that very much.   But as Einstein says, "a thing
 should be as simple as possible, but no more so."  

I really love conceptual cleanliness myself.   * * * But ZigZag
 is intrinsically a compromise between elegance and ragged edges
 of ad hoc usability.  This design has to seek a balance between
 diamond-simplicity (like the fundamental connective structure)
 and ad hokery that plays at the corners, finding the usable
 visualizations (for instance) and discarding the non-useful ones. * * *  

(In this mix ZigZag strongly resembles Perl, which nobody thinks is
 elegant, but which sure has functionality.)

Other parts of the balance I'm striving for here are A) to make ZigZag
 as flexible as possible for free-floating and wacky new uses and
 connections, and B) not to constrain it any more than absolutely
 necessary in the early and Director's Cut versions.   

The Director's Cut version is to work the way I describe.
 Where we take later versions will depend in part on public
 reaction to this one, and partly my own feelings after protracted
 use of it.  

5.  I think here we may have come to another parting of the versions. 
 If you would like to carry out parallel development of the
 alternative you're thinking of, I'll be interested to try it.  

All best, Ted


At 09:47 AM 11/4/98 -0500, you wrote:
>
>> Hi.  Sorry, I impulsively sent without proofing again.
>> 
>> >I am not talking about d.2.  I am talking about d.contents.
>> >d.2 was not anywhere in your picture.
>> 
>> Right.  That's what I meant.
>> 
>
>OK.
>
>> With this note I am sending again as attachments
>>  my crummy sketches to explain this.
>> 
>> Study the pix and see if it becomes clear why.
>
>I've seen them before, and it's still not clear why.
>
>> - Picture 1:  THE FUNDAMENTAL CONCEPT
>> - Picture 2:  WITH ADDITIONAL EXTRANEOUS CONNECTIONS,
>>   IGNORED BY THE SYSTEM
>
>If the user wants `additional extraneous links',  why don't they make
>them in an additional extraneous dimension, instead of making them in
>d.contents, which has a system-imposed semantics?  That seems to me
>like the simplest way to make sure that the system ignores them.  Then
>you don't need a rule about how a negward connection in a totally
>different dmiension somehow nullifies the effect of a link.
>
>> >I thought that you said that d was not part of the contents of A, even
>> >though c-d.  
>> 
>> Correct.  The negward connection B-d on d.inside
>>  ends downward interpretation of the contents list.
>
>Yes, I understand that you said that.  My reply says that I think that
>you're making a mistake.
>
>Here's Figure 1:
>
>  >>> d.inside  vvv d.contents
>
>  A - C
>
>
>
>  B - D
>
>
>Figure 2:
>
>  A - C             
>      |
>  B - D
>
>
>In figure 1, C is in A and D is in B.
>
>In figure 2, C is in A and D is in B.
>
>You say that in figure 2, D is *not* in A.
>
>I said, ``Why not?  The user made C-D for a reason.  Your rule tells
>ZigZag to ignore the link from C-D in figure 2.  You want ZZ to behave
>the same way whether the C-D link is present or not.  But this
>disables the user by ignoring the links that they have made.''
>
>> >I said that you were mistaken, because the user made the
>> >C-D link on purpose and ZigZag has no right to disregard that.
>> 
>> Then the user has to disconnect B-D, because it ends the list.
>
>And what if they want D to be in B as well as in A?
>
>> * * * The idea is to be as permissive as possible.  Users can
>>  do what they like, as long as they understand what the rules are.
>
>There has to be a collaboration between ZZ and the user, because ZZ
>provides the basic interpretation and meaning of the structure that
>the user builds.  
>
>>  Woe betide the cleverness of the partially informed!  (And I
>>  ought to know.) * * * 
>
>I've done the best I can can to inform myself.  If you'd like to
>inform me further, please do.
>
>
>
____________________________________________________
Theodor Holm Nelson, Visiting Professor of Environmental Information
 Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
 Home Fax from USA: 011-81-466-46-7368  (If in Japan, 0466-46-7368)
Professorial home page http://www.sfc.keio.ac.jp/~ted/ 
_____________________________________________________
Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
 Tel. 415/ 331-4422, fax 415/332-0136  
http://www.xanadu.net
PERMANENT E-MAIL: ted@xxxxxxxxxx
_____________________________________________________
Quotation of the day, 98.11.05:
Last words of Ludwig Wittgenstein: "Tell them I had a wonderful life."