-----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
This archive was generated by hypermail 2b29 : Fri Dec 22 2000 - 08:21:16 PST