Re: [unrev-II] Semantic Community Web Portal

From: Eric Armstrong (
Date: Wed Sep 12 2001 - 16:42:04 PDT

  • Next message: Jack Park: "Re: [unrev-II] Semantic Community Web Portal"

    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:

    THANK YOU for a highly relevant and provocative paper. The authors
    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

      --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
              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
              expressly for the purpose
          b) Adding "knowledge tags" to the document, so that it can be
          c) Adding "semantic equivalence" information to the ontology
              translation mechanisms, so that the person's original query
              be translated by the system into a form that it knows how to
       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,

        and more old queries should be handled automatically, with only new
        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
       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
    --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
       How about I describe the problem, and someone who is familiar with
       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
       When additional information *is* required, the request for it should

    be generated
       automatically. When it comes in, the same categorizing can take

    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
       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
       so it becomes an "argument against". Or maybe it becomes "[?] ..."
       you sure?). The idiom becomes entrenched through use, and users who
       are familiar with the system start writing "[-] ....", thereby saving

       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
       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

    --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
       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

       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
       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

       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
       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
       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,

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to

    This archive was generated by hypermail 2.0.0 : Wed Sep 12 2001 - 21:36:31 PDT