[unrev-II] Maleable Archives

From: Rod Welch (rowelch@attglobal.net)
Date: Tue Jul 24 2001 - 14:32:56 PDT

  • Next message: Henry van Eyken: "Re: [unrev-II] Maleable Archives"


    Good reasoning that belongs in the DKR keeper pile, similar to your planning on


    Eric Armstrong wrote:
    > In the discussion I had with Lee last week, a couple
    > of thoughts came out that I would like to post to a
    > wider audience. (As usual, I'm thinking in email. I'll
    > post as an HTML page later.)
    > The core is this: The concept of an eternal and unchanging
    > archive of exactly what was expressed, when, and by whom,
    > is highly overrated, in my opinion. In my opinion, we think
    > that way because we are only used to two options: full
    > history, and no history. Of the two, we prefer having a
    > history.
    > Let's consider that we have a collaborative email-ish
    > discussion going on, most likely based on an IBIS-style
    > investigation of issues, and that we have our dream data
    > engine (Nodal, in all liklihood) powering it.
    > Now, lets consider a few cases.
    > CASE #1: Wrong audience.
    > I post a message to the group that was intended for an
    > individual. Or I accidentally post to the wrong group.
    > As the author of the message, I have a perfect right to
    > press the "retract" button, as it were, and remvoe the
    > noise from the wires.
    > CASE #2: Wrong assertion.
    > I post a message that says, "A is true", and someone
    > replies, "no it's not", with canonical proof that I
    > am wrong. Well darn it all, I want to remove that
    > hare-brained, addle-pated, wrong-headed, idiotic claim,
    > so I don't look a fool for all eternity. And as its
    > author, I have a right to do that!
    > Now maybe I just have to file the "desire to delete",
    > and when the person responding takes away their
    > contradiction, then the whole thing can disappear.
    > Or maybe I can at least edit the thing to say that
    > "you'd think, on the surface, that A is true, but as
    > Ralph so alerty points out, ..." Or words to that
    > effect. Details to be decided. But you get the idea.
    > CASE #3: Civil Discourse.
    > Here, tempers flare. I say, "you rat-brained son of a
    > skunk". He/she says, "you pig-eating, flaming goose
    > neck", and we're off to the wars. After a while,
    > everyone calms down. I edit my message to read, "I'm
    > not sure you're right about that". He/she edits their
    > message to read "I have to disagree". Later on, reading
    > the archive, the information content is the same. It is
    > only the emotions that have been extracted.
    > The bottom line here is that the overall readability and
    > usability of the archive is improved as a result of the
    > editing. At the moment, an archive is a huge field of
    > wheat, with needles strewn about. You search the field
    > looking for needles, and of course you spend a lot more
    > time "hopeless separating the chaff from the chaff".
    > Message threads begins to organize the wheat into haystacks.
    > But as we all know, often a message that belongs in a
    > thread is posted outside of it. The ability to edit the
    > archive makes it possible to put it where it belongs,
    > which reduces the number of haystacks and makes them a
    > more accurate reflection of the dialog.
    > Similarly, removing material helps to reduce the size of
    > the haystack. Both reorganization and removal help you
    > narrow your search and make it more effective.
    > The alternative -- the unedited archive -- is a mass of
    > detail that no one ever sees. If you can link to it --
    > but you can't find anything in it, and you don't even
    > want to start looking, then the archive loses much of its
    > potential value.
    > The archive, should, over time, become a "narrative
    > history" of the discussion. What options did we consider,
    > which ones did we reject and why. What did we learn. What
    > did we end up with, and why.
    > Like any narrative -- a story told in a novel or over a
    > campfire -- it benefits from revision and editing. Rough
    > drafts are simply not all that much use, except to the
    > historian.
    > That leads to the first of two arguments in favor of fixed
    > archives -- the value of maintaining a complete history.
    > The second argument is over the possibility of broken links.
    > COUNTER ARGUMENT #1: History
    > For the process-gurus, a history is invaluable. How did
    > we get here? How did that group *actually* arrive at
    > those conclusions. For such folks, the fixed archive, IN
    > Tracing the evolution of the archive lets them see when
    > tempers flared, how things were retracted, the deals that
    > were made. "I'll remove my comment if you'll remove yours",
    > etc. Then, when the whole ball of wax disappears, the
    > process folks can dissect the social processes that made it
    > happen.
    > That kind of archeaology can certainly be valuable. And
    > it makes it worth considering retaining the original
    > archive via versioning, as the edited archive is constructed.
    > But it is important to remember that for everyone *except*
    > the process historian, it is the readable version of the
    > archive that is most valuable -- it contains the distilled
    > collection of "knowledge nuggets", with the minimum of
    > excess material.
    > There is a space consideration, though. Since the archiving
    > and versioning consumes additional space, resource constraints
    > may play a role in the deciding whether or not to retain
    > the unedited archive.
    > Then, too, when I accidentally post a note that was intended
    > for my girlfriend, I unequivocally reserve the right to
    > remove it, I care not what!
    > Note:
    > This kind of case happened just the other day.
    > At home, I have the alias "sun" for my work address. At
    > work, I have (HAD) the alias "sunstatus" for the folks who
    > stay abreast of what I'm working on. I was creating an alpha
    > test-list for my learn-by-ear, see-how-its-played tune teaching
    > program, and mailing it back and forth between the two accounts
    > as I thought of additional people to put on the list. At work,
    > I typed "sun" without thinking, and autocompletion expanded it
    > to "sunStatus" and mailed it to the gang of folks I do projects
    > for. Not good! In such cases, "retract" is really necessary.)
    > COUNTER ARGUMENT #1: Broken links
    > The second counter argument concerns broken links. That is
    > of course a serious technical consideration. What if I have
    > a pointer to a node, and that node has disappeared? Given a
    > data engine like Nodal, I believe that the issue is largely
    > moot.
    > First, note that Nodal specifies that the default linking is
    > to the latest version of a node. So when a node is replaced
    > by an edited version, no broken link results.
    > Second, since the back link facility keeps track of who is
    > has pointers to the node, the engine knows when the node can
    > be retired, or when it needs to be kept around.
    > Implementation note:
    > The node would be marked as deleted. If no links exist to
    > the node, it would be targeted as a *candidate* for
    > removal. But there could still be external links who have
    > not "synced" with the system recently. The "ok to eradicate"
    > process would have to work like this:
    > a) For each node, maintain a list of folks to whom
    > he node is potentially visible.
    > b) Maintain a master list of delete candidates.
    > c) As each person syncs up, check the master list. For
    > any node on it they haven't referenced, remove them
    > from the potentiallyVisibleTo list.
    > d) When the potentiallyVisibleTo list is empty, the node
    > can be garbage collected.
    > Summary
    > -------
    > The value of an archive, like the value of a novel, depends on
    > its *readability*. Editable archives allow for discussions
    > that, over time, reflect the best possible reasoning and
    > explication of issues. Whether or not an unedited version is
    > retained underneath, it is the edited version which should be
    > the topmost, publically visible layer.
    > Community email addresses:
    > Post message: unrev-II@onelist.com
    > Subscribe: unrev-II-subscribe@onelist.com
    > Unsubscribe: unrev-II-unsubscribe@onelist.com
    > List owner: unrev-II-owner@onelist.com
    > Shortcut URL to this page:
    > http://www.onelist.com/community/unrev-II
    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
    Secure your servers with 128-bit SSL encryption! Grab your copy of
    VeriSign's FREE Guide "Securing Your Web Site for Business." Get it now!

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

    This archive was generated by hypermail 2b29 : Tue Jul 24 2001 - 14:47:30 PDT