Gil Regev wrote:
> This discussion reminds me of the paper by Shipman and Marshall called
> "Formality Considered harmful". They show how and why people don't
> take this extra step of documenting code, structuring their
> discussions with IBIS (which the explicitly name) etc. It's not a long
> paper and is easy to read. You can get it at:
> http://www.csdl.tamu.edu/~shipman/formality-paper/harmful.html
THANK YOU for a highly relevant and provocative paper. The authors
describe
5 kinds of systems aimed at improving analysis and design -- and we have
discussed or been aimed at developing each of the 5, at different times:
* hyperlink systems
* argument/discussion systems (IBIS)
* knowledge-based systems
* groupware systems
* software development environments
In effect, this paper categorizes each of the approaches that we have
separately and collectively envisioned as a way to approach "systems
that support intellectual work", as Shipman and Marshall call them.
Specific comments below.
On general hypertext:
---------------------
"Some beginning users would write hierarchical outlines and full pages
of text which they would connect by a single link to the next page of
text..."
--the issue here is that the medium was not *inherently* granular.
Hypermedia systems, as currently constructed, are by default
single monolithic blocks of text that only has the appearance of
structure. It takes a specific act to make any segment addressable,
and even then, the lack of real structure makes the target of the
address indeterminate (was the target intended to be a bit of text
or a subtree?)
--The systems we have been envisioning, on the other hand, are
*inherently* granular. The result of editing *is* a structure, not
a monolith, and all elements of the structure are addressable,
without any extra work.
--So the problems the author see with this approach appear to me
to inherent in the tools, rather than in the formalisms. The issue
is that the tools used (KMS, VNS, NoteCards, and hypertext
in general) do not support the *required* formalism -- the one
that is really needed for productivity and reuse.
On structured argumentation systems:
-------------------------------------
"...argumentation and design rationale systems force their users to
chunk and categorize information according to its role....
First, people aren't always able to chunk intertwined ideas; we have
observed, for example, positions with arguments embedded in them.
Second, people seldom agree on how information can be classified
and related in this general scheme; what one person thinks is an
argument may be an issue to someone else..."
--The first issue is one of usability. Yes. Most of these systems
forced users to pre-select their category. And that is not good.
The structure needs to be imposed AFTER THE FACT. A
facilitator does that in real time, as the arguments progress. A
"candidate summary" option in a maleable archive is another way
to achieve that goal, I think. That lets people who are expert in
information-structuring apply their experience to the factoids
offered up by domain experts.
--The second issue is that of determining how a thing should be
classified. Here, I think that patience is a virtue. These systems
are entirely new, and they reflect an emerging paradigm -- an
epistemology for how knowledge is acquired. So two answers
suggest themselves:
a) The ability to apply multiple categories, and reuse the
information
in different contexts. The same text may *indeed* be both an
issue and an argument. Why not allow it to fill both roles
simultaneously? Or replaced by factored versions, if and when
that makes sense?
b) The understanding that information-structure experts gain in
the process of categorizing such things will eventually lead to
greater understanding of the issues, better semantic nets, and
a whole specialty with conferences and classes, in how to
model such discussions.
On knowledge-based systems:
------------------------------
(Summarizing) The real issue seems to be that until you add "knowledge
tags" to the system, the information content can't be used as knoweldge
in any meaningful way. (Section 2.3 doesn't really say much about this
issue. But it was intimated in the introductory sections.)
--I have to agree with this assessment. The only reasonable solution I
can see is to add knowledge tags in order to answer questions. I
envision an eFAQ system that starts out answering very few questions.
Instead of answering questions directly, I empower the FAQ to
answer the questions by a combination of:
a) Making it aware of existing documents, or by authoring
documents
expressly for the purpose
b) Adding "knowledge tags" to the document, so that it can be
found.
c) Adding "semantic equivalence" information to the ontology
translation mechanisms, so that the person's original query
can
be translated by the system into a form that it knows how to
answer.
A pointer to the (newly generated) FAQ is then returned to the person
who made the query. Over time, such a system gains more and more
expertise, as a result of the human-mediated queries. If successful,
more
and more old queries should be handled automatically, with only new
and
interesting queries going to the mediators.
On groupware systems:
-----------------------
"users have proven to be unwilling to describe their normal decision
methods for whether and when to schedule a meeting with other people.
The same rules of scheduling that apply to your boss do not apply to a
stranger, but
making such differences explicit is not only difficult, but also
socially undesirable."
--Here, the case is convincingly made for independent workstations, and
NOT
a central server. Difficulty aside, the decision-heuristics I use
should not exist
anywhere other than on my system.
"Coordination oriented systems have the additional burden of formalizing
social practices which are largely left implicit in normal human-human
interactions..."
--Yup. Have to agree. And that requirement can be a killer -- UNLESS the
formalization can be introduced in a 2nd pass, by folks who are adept
at it.
"systems without the ability to handle exceptions to the formalized
procedure cannot support the large number of cases when exceptional
procedures are required.
Arguably, almost all office procedures turn out to be exceptions to the
prescribed form"
--Yup. Got to agree with this. A system that anticipates all the
possible cases is
too difficult to use. One that doesn't is too braindead. The middle
ground is an
email-like system where formalism is easily imposed.
--For example, when reporting a bug, who wants to fill out some long
form??
How about I describe the problem, and someone who is familiar with
the
possible choices highlights parts and applies categories to "fill out
the form".
Then, things like "what system am I using" can rightly be identified
as irrelevant
when I am reporting a functional deficiency in version 2.5 of the
software.
When additional information *is* required, the request for it should
be generated
automatically. When it comes in, the same categorizing can take
place...
On Software Development systems:
-----------------------------------
"When such introspection becomes necessary to produce and apply a formal
representation during a task it necessarily interrupts the task,
structures and
changes it....An example of this interference is McCall's observation
that design students have difficulty producing IBIS-style argumentation
even though videotapes of their
design sessions show that their naturally occurring discussions follow
this structure [Fischer et al. 91]."
--This is a key observation, and makes all the more clear why formal
structure
should be developed ad hoc (after the fact), rather than "in vivo",
as it were.
As users become familiar with the ontology, they may well add labels
as they
go, but it should be not be a requirement for using the system.
--For example, an initial user writes, "I don't think that's true,
because ....".
A later summary changes that to "[-] ..." (omitting the introductory
clause)
so it becomes an "argument against". Or maybe it becomes "[?] ..."
(Are
you sure?). The idiom becomes entrenched through use, and users who
are familiar with the system start writing "[-] ....", thereby saving
themselves
the time of writing the introductory clause.
--The important point here is that the new user need know nothing of the
ontology to interact with the system. They don't have to know or care
whether we use "idea", "alternative", or "option" to represent a
possible
answer to a question.
"argument representations are often derived from analyzing naturally
occurring argumentative discourse .... (but) post hoc analysis is very
different from generation. When (these) descriptive models are given to
users, they find it very difficult to formalize knowledge as they are
generating or producing it..."
--can't argue with that. But it was stated well enough to be worth
reproducing here.
The answer is to add formalism, not insist on it at the outset.
"one of the subjects in Malone's study said of a pile of papers waiting
to be filed
(said) "You don't want to put it away because that way you'll never come
across it again. ... Leaving them out means that I defer for now having
to decide--either having to make use of, decide how to use them, or
decide where to put them." [Malone 83] (page 107)"
--In other words, it must not be necessary o categorize information to
put it into the system. Must not. Must not. Must not.
"An analogy can be drawn between collaborative formalization and writing
a legal document for multiple parties who have different goals. The best
one can hope for in either case is a result sufficiently vague that it
can be interpreted in an acceptable way to all the participants"
--This, I'm afraid, is just plain wrong. It is perhaps the outstanding
exception to the
generally well-stated and astute observations in the remainder of the
paper. Having
been a party to a few negotiations, I can tell you that the major
issue is to *resolve*
the ambiguities, to express clearly what is intended and what is not
implied. The
result, otherwise is bound to end up in court. The very ambiguity
described as the
"aim" of negotiations is in fact, largely responsible for the
"justifications" nations have
to go to war -- because according to nation A's interpretation,
nation B clearly
reneged on their promise which, according to nation B, they never
made.
--An example came up recently, when the U.S. said, "we're sorry the
Chinese pilot
lost his life". In English, "sorry" means either "expression of
sympathy" or "apology".
The Chinese translated it as apology, so they "got" the apology they
demanded.
Meanwhile, the U.S. said with a straight face "we never yielded to
their demand for
an apology." Was that confusion a good thing? It depends on whether
or not your
goal was clarity. In this case, the confusion was relatively benign.
But had the
confusion been over some expected future action, then the conflicting
interpretation
could have been at the root of escalating tensions.
--In a design setting, in particular, one has to assume that the goal is
clarity. If
adding formalism brings to light differences in interpretation, then
the formalism
is doing its job. The correct response is to clear up the
confusion(s), not to
dispense with the formalism.
"For different people to agree on a formalization they must agree on the
chunking, the labelling, and the linking of the information. ....the
prospects of negotiating how information is encoded in a fixed
representation is at best difficult."
--difficult, yes. Impossible no. And the result is rewarding.
--Note, too, that the premise "for different people to AGREE on a
formalization".
Using the idea of independent clients and ontology translation, it
may be less
important for us to agree on an ontology than to be able to translate
between
useful ontologies. If our ontologies differ, but are still
interoperable, then perhaps
we can collaborate effectively even with very different world-models.
"A system which attempts to impose a particular structure on
communication will likely not match the appropriate communication
structure for any given group."
--actually, we've seen this even with informal structures in our own
group!!
It's true, darn it. And when I summarize stuff with my ontology, it's
likely to be
look different than the ontology you would use. But if we combine the
idea of
ratings with the idea of competing summaries, then the analysis that
is found to
be most useful will have the highest ratings, and the ontological
framework that
underlies the analysis will probably come to be regarded as the most
useful,
using the analytical equivalent of Occam's Razor.
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Secure all your Web servers now: Get your FREE Guide and learn to: DEPLOY THE LATEST ENCRYPTION,
DELIVER TRANSPARENT PROTECTION, and More!
http://us.click.yahoo.com/k0k.gC/nT7CAA/yigFAA/IHFolB/TM
---------------------------------------------------------------------~->
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 http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Wed Sep 12 2001 - 21:36:31 PDT