[unrev-II] Email question

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Fri Dec 22 2000 - 13:32:42 PST

  • Next message: Eric Armstrong: "Re: [unrev-II] Refactoring and information annealing"

    I don't get it. You can intersperse your answers to the original
    message. Why can't I intersperse my replies with yours?

    "Garold L. Johnson" wrote:

    > -----Original Message-----
    >
    > From: Paul Fernhout [mailto:pdfernhout@kurtz-fernhout.com]
    >
    > Gary-
    >
    > I like this and your other summarizes. I especially like the way you
    > are
    > referring to a debate on issues to create a set of requirements.
    >
    > I have a thought related to this and other subsequent posts by people,
    >
    > which is that since email is really the most widely used application
    > on
    > the internet, we need a clearer statement with details and use cases
    > of
    > how much better an OHS/DKR will be to solve any specific issues than
    > email in a threaded email viewer.
    >
    > I like your list. What might make it even more useful is tying each
    > point to a qualitative statement of how much this issue cannot be
    > handled by email (the difficulty it entails for example, and how
    > frequently it comes up). Perhaps we could start by refining the list,
    > characterizing how one might address each issue with regular email
    > (even
    > if it required a certain disciplined use)?
    >
    > [Garold L. Johnson] The major problems with email all relate to
    > linking, at least to a first approximation. Since emails have no
    > unique identifiers, tying even a reply to a specific email much less a
    > specific reference is difficult since there is nothing unique to which
    > an email can refer. Hence we end up doing a lot of quoting because we
    > can’t refer to an email uniquely much less in a fine grained way, and
    > there is no way of knowing how much of the email traffic any new
    > viewer has.
    >
    > Egroups assigns a message number to every message it receives, but
    > that number is not reflected in the email that is sent to the list.
    > The originator doesn’t know it since it isn’t assigned until it is
    > received by egroup.
    >
    > To give some idea of how little it would take, the egroup messages are
    > available as URLs of the form
    > http://www.egroups.com/message/unrev-II/1787 where the final number is
    > the message number within the group. This means that the email
    > repository can be referenced by links to the global emails. Thus if
    > there were just a little more information in the emails – the egroup
    > sent the message number in some field, and the in-reply-to field was
    > set to the message number, we could get threading directly, and we
    > would solve the problem of access to the repository.
    >
    > Add a fine grain linking mechanism, and suddenly an email list manager
    > begins to be a lot more useful.
    >
    > Add the ability to split a message reply or to reply to a message
    > section, and we suddenly have a hyperlinked information base.
    >
    > Notice that this is little more than a WikiWeb generated by email.
    >
    > To carry that further, by using the Wiki formatting rules in email, we
    > could send text that could be appropriately formatted into HTML.
    >
    > The implication of this is that if the OHS were to start here, it
    > should be possible to pick an mail list server with existing code and
    > link it to a WikiWeb, also existing code, and have a system that would
    > allow us to organize this discussion in far more effective ways than
    > an email list alone.
    >
    > Since the entire content would be available as text files on the Wiki
    > server, could be added to by email,and updated directly by Wiki, such
    > a system should allow us to experiment with features easily.
    >
    > Depending on the Wiki base, there is support for version control of
    > the nodes, allowing access to a history.
    >
    > Features can be added by adding buttons to the Wiki pages to allow new
    > operations. If templates can vary based on the page, which is true of
    > Wikis that support locked pages, we could experiment with nearly any
    > option that we wanted at the expense of a rather small piece of CGI
    > code.
    >
    > While most Wikis operate on text files, this is by no means a
    > requirement. The page source could be held in any sort of database
    > desired.
    >
    > Any post-processing schemes could be applied to the system at will
    > since it would all be available. It might be necessary to add sections
    > to the page source, much like the .ini files used in Windows. This
    > would allow the addition of frame based attributes to a Wiki system.
    > The impact of the various sections would depend on the code for the
    > Wiki operations.
    >
    > Now we have a scheme that would allow us to simulate any sort of
    > system that we might wish, or as many as we might wish, within the
    > same base.
    >
    > Want to try out an IBIS style structured communication? Add options
    > for classifying an email response to the email list server that saves
    > the pages in the Wiki, add a section to the pages indicating that it
    > is an IBIS system, have the page renderer add the links to the Wiki
    > page for the various allowed sorts of linked responses, and you have
    > an IBIS system with email input.
    >
    > It seems to be a very fast way to achieve a system on which all sorts
    > of usage experiments can be loaded, each in their own sandbox if
    > necessary, and post-analysis would allow for all sorts of tests on
    > knowledge organizations.
    >
    > <SNIP>
    >
    > Obviously there have been discussions on this list on how to do such a
    >
    > fine grained linking in regards to the specifications and the purple
    > numbers (acting like chapter and verse numbers in the Christian bible)
    >
    > accomplish the same thing.
    >
    > However, as an alternative, perhaps a more disciplined use of email
    > subjects in a threaded discussion (including splitting replied into
    > multiple smaller emails) would immediately address this issue with
    > conventional technology? [Although that has it's own difficulties as
    > it
    > eliminates the notion of connected "essay" from the system.] For
    > example
    > Rod and SDS exemplify disciplined KM, but it takes effort and
    > developing
    > certain work habits. Or, perhaps something as tiny as a modified
    > version
    > of an email client to be able to link to those references already
    > given
    > email would then go a long way towards this? Or perhaps, this would
    > not
    > be so essential if we had a standard way of referring to messages not
    > being directly replied to?
    >
    > [Garold L. Johnson] if you go to the egroup site the URL can be
    > determined. If a few changes were made to the egroups email system, we
    > could do all sorts of things. (see above).
    >
    >
    > <SNIP>
    >
    > Obviously the international space station, the Boeing 747, the Taj
    > Mahal, and the city of New York have all been built without OHS/DKR.
    > (What tools did people use?) So we are not saying you can't make
    > complex
    > things without OHS/DKR.
    >
    > [Garold L. Johnson] Since I worked on many of these projects, I can
    > tell you that they are tool averse. The majority of the work is done
    > with paper documents done in word processors. These documents are now
    > (sometimes) available on local networks, but there is not even so much
    > as an index to them or a way to determine the latest version or
    > release status of a given document. All document references are done
    > by document title and in a few instances, by paragraph numbers, which
    > may change in later revisions. With requirements, there are often
    > unique identifiers and there are a few tools being used at times.
    >
    > There is little or not way to track discussions of topics until they
    > end up in a published document, and then there is only the result of
    > the discussions, not the discussions themselves.
    >
    > There is no way to revisit decision processes. There is no way to find
    > out that a rejected alternative was held to be the best except for
    > some impediments, and now that the impediments have been removed,
    > there is a better alternative than the current one.
    >
    > Collaboration is mostly by direct meeting with viewgraphs and,
    > sometimes, documents. Email is playing an increasingly large part,
    > with all of the problems we have noted. When a discussion gets long
    > enough or important enough, somebody captures a portion of it in a
    > document describing a proposal. This document may or may not address
    > any issues raised during the discussion. Then discussion starts on the
    > new document.
    >
    > This is not unique to the projects you mention, it appears to be the
    > state of the art for all projects.
    >
    > We talk about adding formalisms to our systems to aid in organization
    > – most of these documents are produces without any use of even simple
    > word processing features such as paragraph styles. There is no use of
    > hyperlinking because there is no central place for a link to refer.
    > Document copies get passed around in much the same way as we quote
    > email. Trying to get the idea of a common document template across is
    > nearly impossible. Going beyond that is hopeless. This is from
    > engineering professionals trying to build products where any failure
    > in precision can mean failures in the billions of dollars, and
    > possibly numerous human lives.
    >
    > If the cultures in which these people operate cannot support KM
    > formalisms at eve a low level, how are they ever going to support any
    > real KM interaction? If we can’t get professionals who have a real
    > need for better KM to do even the little bit needed to make things
    > better, how are we ever going to get groups of essentially casual
    > users to do anything like it.
    >
    > We have to be more making statements about cost
    > or speed. Then implicitly the reason for OHS/DKR becomes that lower
    > cost
    > or quicker speed may make developing a solution more politically
    > feasible given limited resources. Or, another reasons is that
    > technically, it may now be feasible to address problems that would
    > otherwise morph faster than the solution could be devised. Again,
    > though
    > the issue is which problems have this requirement, as opposed to just
    > using plain old text email to resolve?
    >
    > -Paul Fernhout
    > Kurtz-Fernhout Software
    >
    > [Garold L. Johnson] I think that the combination of a (slightly)
    > enhanced email system and a Wiki as I described could produce an
    > extremely powerful platform for experimentation.
    >
    > By adding a publish option to an attached document. For example, we
    > could generate an uneditable document with the famous purple numbers
    > of other equivalent. We could autogenerate the section links as the
    > emails were processed or the Wiki pages were saved depending on the
    > source.
    >
    > Such a system should be relatively easy to build from existing code
    > bases and could be exported to the rest of the internet.
    >
    > Now, if we talk about ways to edit Wiki pages with an intelligent
    > editor / browser, we begin to get the possibility of greater formalism
    > during the creation of emails and Wiki pages, for those who want to
    > use them. By using some of the linking provisions in XML it should be
    > possible to refer to individual elements of a document, which results
    > in the fine grain links we believe are really needed for good KM
    > representations.
    >
    > Thanks,
    >
    > Garold (Gary) L. Johnson
    >
    >
    > eGroups Sponsor
      [Click Here!]
    >
    > 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

    -------------------------- eGroups Sponsor -------------------------~-~>
    eLerts
    It's Easy. It's Fun. Best of All, it's Free!
    http://click.egroups.com/1/9699/0/_/444287/_/977520753/
    ---------------------------------------------------------------------_->

    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



    This archive was generated by hypermail 2b29 : Fri Dec 22 2000 - 13:43:18 PST