Re: Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...

[Rauli Ruohonen <rruohone@xxxxxxxxx>]

On Sun, 6 Oct 2002, Benja Fallenstein wrote:

> Let me first summarize the problem:
>
> We want to have the paragraphs available as cells, for linking. The idea
> is that whenever an applitude has an item X, it tries to assign exactly
> one cell to it, and doesn't delete or change that cell for the whole
> lifetime of item X, so that other applitudes can make connections to it
> and have them stay.

Yes, as a general idea that is obviously essential for ZZ structures. But
here.. I think you're trying to assign an identity to something that
doesn't always stay the same.

What is a lifetime of a paragraph? In my opinion, a paragraph is a textual
unit that tries to concisely bring a point across. Given this, a paragraph
ceases to be the same when the point changes too substantially.  "Too
substantially?" How much is that, then? Is there an automatic heuristic?

From the point of view of someone who wishes to quote a paragraph, refer
to it, ideally the paragraph should not change at all. At least when I'm
commenting on a paragraph someone has written, I'm certainly not implying
that what I say applies after N revisions to the paragraph, with less than
70% of the original text left. What's more, I don't want to let anyone
else decide whether what I've said applies to any modified version,
especially not the original writer. An AI that isn't capable of writing an
essay justifying its decision is out of the question.

Satisfying this simple requirement in ZZ should be trivial; just refer to
the permanent piece of text in a certain version. If somebody wants to see
what has happened to that piece of text in later versions, showing that
should also be trivial -- when it involves only rearrangement and
transcopying. Determining the relevance of anything else, except as a
really wild guess, is a task for an intellect that shouldn't be doing such
grunt work in the first place, at least without getting paid.. (but I'm
not against showing wild guesses, as long as they are acknowledged as
such. They are often good enough to be useful.)

None of this is really paragraph-specific, either.. It's spans of text
that seem to be the focus of interest, be they paragraphs or not.

> With paragraphs, the problem is that two paragraphs may be joined into
> one, without the second paragraph really disappearing-- its text just
> became part of the first. If we try to separate the paragraphs again, by
> hitting "Enter" where we separated them, the second paragraph may come
> back as it was-- but without the links to it, since to the applitude,
> it's still a 'new' paragraph.

Giving paragraphs an identity (cell) that's not really dependent on its
content (spans) seems odd to me. They are just a way of organizing ideas
anyway, the sentences in them are far more important than the way they
have been split. Besides, if I change every second word of a paragraph,
even if the meaning stays the same I don't think it's the same paragraph
anymore..

In my opinion, old links should be shown when the text near the endpoint
the user is looking at is reasonably intact (meaning: not so intact => not
so relevant => lesser priority, probably not shown if there are many
links. The other endpoint is always the original anyway). If the links are
connected to spans, finding the links shouldn't be a problem?

This has been mostly about links that point to the document in question
(that's being made new versions of). In such cases, letting the links fade
as the text is removed/scattered is the proper behavior. In the case of
links that the document writer has made himself (referring to others),
heavy modification still lessens their relevance, but they should probably
be renewed automatically, because the user sees what he modifies and can
be assumed to drop the link if it's no longer relevant.

Am I thinking too much from the user's point of view? :-/ Based on the
direction the project was taking the last time I looked at it properly,
all of this should be rather simple to implement by the time of the
release of 0.8.  Perhaps there have been changes..

> The point is that because of the hierarchical containment, we never need
> to split or join a cell. When there were two paragraphs, P and Q, with
> their own cells along d..contain-set, and the user joins the two
> paragraphs, cell Q never disappears: only its "paragraph start" mark is
> removed. When the user inserts a paragraph break into P, the cell isn't
> really split; we just split what's *inside* it into multiple cells
> *contained* in P, and one of these cells has a paragraph start mark. P
> therefore now contains two paragraphs-- If we now make the links mean,
> "the paragraph (the beginning of) P/Q is in," our semantics work mostly
> fine.

Eeeettoo.. :-& <paku><paku> ...don't tell me that you've gotten rid of
spans/scrolls and that there's no longer any way of referring to arbitrary
sequence of text without splitting cells? Also, this seems to be too
concerned with paragraphs. What about referring to sentences? Or sections?
Or three sequential paragraphs in a 6-paragraph subsection? Or more
scattered sentences, nevertheless related?

I still feel like it's the text that's being referred to, no matter how
the division to paragraphs (or whatever) changes. Retaining old ghost
paragraphs seems a bit odd, except as version history.

> Still, I *want* to be able to see and connect paragraphs as cells. It's
> part of the fun. :)

That would be nice, as long as it means connecting those paragraphs as
they are, not unpredictable future versions.

Hmm. Seems like a "open/closed document" distinction would be useful..
"This is connected here, but not as it is now, it's unfinished! Instead,
forge the connection when I say this version is done." (say, you're
editing a bunch of interconnected documents at once, and want to make
links to places that still say "XXX to be written" :-)

  -- Rauli, just a bit confused by the hardness of "simple" text editing