Re: [unrev-II] Re: "self-healing" systems / cyc / personal ontologies/ teaching

From: Eric Armstrong (
Date: Wed Nov 07 2001 - 12:34:38 PST

  • Next message: "Re: Can IBIS be useful for individual/asynchronous collaboration? (was Re: [unrev-II] Visual stimuli & IBIS methodology)"

    Eugene Eric Kim wrote:

    > On Fri, 2 Nov 2001, Eric Armstrong wrote:
    > > Basically, the answer to "how do we structure terabytes of
    > information" is ... with meta-information that builds
    > > a network of interrelationships
    > I don't dispute this. My question is, who does the structuring, and
    > how?

    I really do see the rise of "ontology" as a profession. I see library
    sciences transitioning into that role, joining a merge of web services
    and technical support departments to deliver truly useful eFAQ systems.
    Each company will start out as an ontological "island", but part of the
    ontologists' role will be to build translation mechanisms for other
    queries. Eventually, the existence of the translation mechanisms will
    make it possible to search other islands for information, and begin to
    build bridges. I continue to see the man-machine combination as the most
    powerful ontology producer. Ontologists will have editing systems and
    development environments. Tools will be built to automate some tasks,
    but the majority of the effort will more of a writing process than a
    factory-automation process. (Although there is reason to hope that Cyc's
    "common sense" knowledge base will allow for a lot of automation that is
    difficult to foresee.)

    > Is it realistic to try to have hundreds, even thousands of people
    > constructing topic maps from the terabytes of digital information that
    > currently exists?

    I think so. And I think it will happen. The ontologist/librarians who
    are hired by the companies to make their solve-it and fix-it data
    accessible to inquiries will give them the charter to do just that.
    Businesses spend fortunes on this kind of stuff. In many ways, it's part
    of the "organizational capital" of a serious enterprise. (Note: I
    *don't* see John Q. Anybody doing this task.) The Nodal/Groves capacity
    to "tack on" meta data to existing information will be pivotal in this

    Also, I see the process happening organically. I see the ontologist as a
    supporting member of the technical support team, with the process going
    something like this:
      * customer asks question of eFAQ, gets useless response
      * customer support rep gets into the picture, translates the problem,
         finds information
      * the top time-wasting queries are collected, and given to the
    ontologist, along
         with the question, "why can't we find this"
      * ontologist maps existing data in ways that makes it accessible
      * eFAQ developer tests the new mapping(s) while figuring out how to
         the system respond to common queries in the most useful way.

    > Keep in mind that the structuring has to happen as the
    > information is created; otherwise, the information is always
    > out-of-date.

    That is truly ideal. "Real time" eFAQ generation would be awesome. But
    in reality
    there is always a time delay. Right now, the choice is between expensive
    and useless FAQs. The focus in the new systems will be to minimize the
    delay for human interpreters of the information and maximize the number
    of satisfactory automated responses to common queries.

    > In order for the Semantic Web to scale, you need to make implicit
    > structure explicit automatically. There are a number of ways to do
    > it. The science fiction scenario has intelligent agents reading
    > documents and spitting out RDF metadata or Topic Maps.

    That would be cool. I am impressed enough with Cyc to think that in the
    15-20 year range it may well become possible. (Barring a comet, I am now
    convinced that we *will* survive that long. The incredible response to
    the energy crisis in California impressed me with the society's ability
    to adapt quickly to problems. I even saw a PBS special on
    energy-positive 3-story office buildings using solar power! And
    California just passed a bill to start using solar power on government
    buildings. Time to invest in those people!)

    > On the opposite end of the spectrum, there are a number of more
    > plausible scenarios. The example I throw out most often is e-mail.
    > Quoting e-mail in responses produces implicit structure that could
    > easily and automatically be made explicit with the right tools.

    Yes. I think building a GUI tree-widget capable of displaying multiple
    lines in each item is absolutely the key to the kingdom, on this front.
    We have very few hierarchy-editors, solely due to the lack of that
    widget. (There are dozens of attempts at XML editors, all of which have
    different atrocious mechanisms to compensate for that lack.)

    Give me a structured email tool in which I respond to your paragraphs by
    position the curser and pressing Enter. It would look like the above,
    only my comments would be indented under your paragraphs. Only my
    comments would be transmitted in the reply, along with pointers to the
    nodes they refer to. When you get it, the "review response" mode would
    eliminate anything I haven't responded to. The paragraphs I *have*
    responded to be flush left, with my replies indented underneath.

    When you reply to my comments, they would be indented under mine.
    you could modify the original node, or add new nodes as part of the
    original message.
    When I get it back, the "review response" mode would show me things in
    context --
    your replies along with my comments, and your new and modified nodes.

    Sure would love to see that happen. One difficult question to answer,
    though, is
    whether the hierarchical structure exists independently of type
    information. In
    other words, is "hierarchical structure" a special relationship in its
    own right?

    If it is a special relationship, then A1 is under A, and that's always
    true, no matter
    what. I might then categorize A as a proposition, and A1 as an
    argument:for, but
    the hierarchical relationship is unchanged by the categorization.

    On the other hand, hierarchical structure might *derive* from
    relationships. That
    strikes me as more powerful, though perhaps less easy to implement, and
    more confusing to use.

    In that scenario, A1 is under A *because* it has been categorized as
    Without that category -- or some other structuring relationship -- there
    is no way to
    put A1 under A. That means that when write, you create A and B. Later,
    when you
    categorize B as Argument:For, it becomes A1.

    Personally, I think there has to be a simple, constant notion of
    "structure" that is
    independent of categories, in order to have something you would call a
    document. Otherwise, there really is nothing but "node soup", and all
    document-views are
    produced as the result of queries -- but that means having to set up
    dozens of
    relationships in order to produce something you want to think of as a

    Setting up lots of relationships to construct a "document" strikes me as
    a lot
    of extra work that no one will want to do. So I suspect that there must
    some form of hierachical structure that is "atomic". Other document
    views may
    well be constructed as a result of queries, but I don't think we can
    entirely get
    away from the concept of a more-or-less fixed "document".

    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 Nov 07 2001 - 12:22:09 PST