[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
:zz: GENEALOGY (was: User semantics for dimensions / sug'd guidelines
- To: zzdev@xxxxxxxxxx
- Subject: :zz: GENEALOGY (was: User semantics for dimensions / sug'd guidelines
- From: Ted Nelson <ted@xxxxxxxxxx>
- Date: Wed, 28 Oct 1998 17:54:50 +0900
- Cc: ted@xxxxxxxxxxxxxx
- In-reply-to: <19981026160131.26504.qmail@xxxxxxxxxx>
- References: <Your message of "Mon, 26 Oct 1998 14:52:22 EST." <3.0.6.32.19981026145222.007e2db0@xxxxxxxxxxxxxxxxxxx>
- Reply-to: zzdev@xxxxxxxxxx
WOW!
Brief reply on genealogy--
I tried genealogy for an hour in a medical waiting room,
with amazing results. I put in all my relatives (to the best
of my knowledge, which petered out quickly) as follows--
d.1 => name segments (first, middle, last)
d.2 => names (first, middle-- each list in alphabetical order in d.2. Note
that
some people use their first initial like a middle name (eg A.Schuyler
Dunning, L.Joseph Stone), so in those cases I alphabetized the "A" and "L"
in the middle-name rank.
d.3 marriage (firstname.female, sign (+ for issue, - for no children),
firstname.male)
d.4 chronology (successive marriages of one person are a rank of cloned
first names, succssive children are in order-- again by first names)
I found this astonishingly successful. It results immediately in
two interesting views:
1/2 (1 across, 2 down)-- table of names
3/4 -- explorable tree of marriages and children.
SURPRISE VIEWS - - - - -
But then, I thought, what about the OTHER views that
I hadn't considered when I laid it out? Let's see--
**1/3 Marriages showing first and last names (maiden name
if female)
*1/4 Full name / Whether married more than once & siblings
*2/3 First names alphabetized, showing marriages (except the
clones aren't alphabetized. Suggestion: make sure the first marriage
is the original in the clone list)
2/4 Alphabetical listing of everybody, showing (it seems)
whether they were married more than once, and whether
they have parents in the listing.
These seem to be useful in diminishing order (number of
asterisks is my rough evaluation).
But the payoff is: THEY WEREN'T DESIGNED! Rather,
they expressed relations also contained in the data in ways
that are varyingly useful.
It's a slight downer that the usefulnesses have to be looked at,
aren't quite predictable.
Haven't tried choosing a third dimension for travel forward
or backward; that might hold interesting uses & surprises.
The benefit of these depends in part on where you start
looking. If you start at a dud cell it goes nowhere, and you
might not notice that it's a useful view.
POSSIBLE VARIANTS - - - - -
One variant I would consider would be putting the relation (marriage)
first, children in a second column.
Reason for putting relation first: Polish notation. more
generalized, in some ways more readable and parsable.
When we start exploring lots of other relations this way,
the prefix notation could be more and more helpful.
Best, Ted
At 11:01 AM 10/26/98 -0500, you wrote:
>
>> Hi Mark-Jason--
>>
>> >If the existing contents system is going to work at all, users must be
>> >able to provide their own semantics for dimensions.
>>
>> Definitely!
>>
>> My intention (and I'm way behind) has been to provide
>> about sixteen predefined dimensions, and suggested guidelines
>> for how to extend.
>
>I hope you won't mind if I expand on my ideas a little.
>
>Your plan is for d.inside and d.contents to be closely related to each
>other, so that neither one has a real meaning without the other.
>
>Suppose I am using ZigZag, and I want to create my own pair of
>dimensions that are related int the same way that d.inside and
>d.contents are, to serve an analogous but separate purpose. For
>example, suppose I am doing a geneological chart, and I want to
>capture the idea of `ancestry'. I will have two dimensions, d.parent
>and d.sibling:
>
>
> A-B-C +--> d.parent
> | | |
> D E v d.sibling
>
>A is the parent of B, who is the sibling of D and the parent of C and E.
>
>As far as `ancestry' goes, this is almost exactly the way d.contents
>and d.inside work:
>
> A-B-C +--> d.inside
> | | |
> D E v d.contents
>
>A holds B and D, and B holds C and E, so that C and E are also
>considered to be inside of A.
>
>If I want ZigZag to be able to do appropriate computations with
>ancestor charts, I will need to be able to tell ZigZag that d.parent
>and d.sibling are associated dimensions, that they go together in the
>way that d.inside and d.contents do. In my notes I called this kind
>of association a `conjoinment'. (I think `conjoinment' is as
>absolutely awful name.) d.inside and d.contents are conjoined.
>
>Conjoinment is one of the kit items I was thinking about. When I
>create a new dimension, I should be able to say whether it is
>conjoined to other dimensions.
>
>Similarly, the chart above has exactly the same *meaning* as if I had
>built it this way:
>
> A-D +--> d.parent
> | |
> B-C v d.sibling
> |
> E
>
>I would like ZigZag to understand that. So when I create d.sibling, I
>would like a way to say `The order of the cells in a group doesn't
>matter, and positive and negative directions are the same.'
>
>This `disorderment' property is closely related to conjoinment, but I
>haven't figured out the details yet. `Disordered' is another item in
>the kit. When I create a new dimension, I should be able to say that
>in this dimension, the order of cells in a group is unimportant as
>long as they are all linked in a line. (I called a line of linked
>cells in one dimension a `pier', but maybe you have a different name
>for it.)
>
>> Interesting point. Except users might want to add some
>> meaning to the direction of a dimension whose general
>> meaning is predefined without direction.
>
>Just so. Dimensions express relations between things. In forming
>relations, they might have any, all, or none of the following properties:
>
> 1. Symmetric (positive and negative are the same, as you said)
> 2. Conjoined to other dimensions
> 3. Reflexive (A cell is considered to be related to itself)
> 4. Transitive (If A-B and B-C, then A is considered to be
> related to C even though there is no explicit link)
> 5. Disordered (I think this turns out to be the same as
> symmetric + transitive.)
>
>There were a couple of others I thought of, but my notebook is
>downstairs.
>
>
>
>
____________________________________________________
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.10.28:
"The most incomprehensible thing about the universe is that it is
comprehensible." Albert Einstein