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