Re: [unrev-II] Towards a summary of documents. Longish. Going for Eric's record ;-)

From: Jack Park (jackpark@verticalnet.com)
Date: Thu Nov 30 2000 - 10:49:05 PST

  • Next message: scann@prodigy.net: "[unrev-II] Re: Alliance and Partners"

    Rod,
    Interesting that you should land on a paper about HyTime. HyTime, not
    presently standardized in XML (but nevertheless do-able in XML with a bit of
    fudging), is the answer to our prayers, me thinks. Linking, and Time.
    Together in one package; a most useful package, that.

    Your question hits the target I have been painting for some time now. This
    might be longish. Sorry.

    Consider this:
    What SDS does:
        provide a home for source information
        provide a linkage pool with commentary that connects various ideas,
    themes, temporal coincidence, and so forth together
    What SDS should do:
        all of the above, plus:
            provide a navigation engine

    Hah! You thought I'd list more than that under "should do". Well, there is
    more. It needs to develop on ontology for itself by which users can do the
    navigating. Doing that will allow SDS to link up with other SDS engines to
    form a web-based collaboratory. Then, you add, per Eric's suggestion, IBIS.
    This allows for a mechanism by which collaborative SDS implementations can
    communicate with each other. Of course, there are humans doing all this,
    but the engines can, and should automate some of the "backoffice"
    bookeeping. By automating that, we get uniformity in the ontology
    generation. Thus, we get (or, at least, strive for) semantic
    interoperability.

    When you have done that, you have, in fact, constructed the three-layer
    architecture I have been harping about for some time now. I do not claim
    that the three-layer architecture is complete; rather, I suspect that it
    represents a kind of minimalist architecture for performing the OHS/DKR
    functionality. By way of brief review: at the upper level, topic maps and
    IBIS interface, plus import/edit facilities for generation of major "papers"
    to submit. In the middle, the vast array of ontology nodes and links. At
    the bottom, all the raw information, which includes: papers, scanned in
    books, email, personal commentary, IBIS argumentation records, and, well,
    perhaps the kitchen sink as well <gg>. Key concept: everything in the
    bottom layer is an instance of an "addressable thing" according to the OHS
    ontology that Howard is developing. Being an "addressable thing" means that
    all elements of the documents in the bottom layer are somehow addressable.

    It turns out that the Grove architecture (an SGML notion, now doable in XML)
    makes everything into an "addressable thing". In fact, a Grove gives you a
    uniform API for addressing a heterogenious pool of things, each of which
    might have a different API requirement (e.g. Word documents, XML documents,
    RDF documents, LaTex documents, Excel spreadsheets, etc). This all suggests
    that a part of the middle layer "engine" will be something akin to a Grove
    engine.

    Yet another part of the middle layer is an engine that maintains "knowledge
    structures" (KS). Think of KS as nodes and arcs. Well, it's not going to
    be all that simple in the long run, but that's a place to start. KS must be
    capable of existing in an evolutionary environment, one which evolves as
    knowledge representation (KR) needs change. The engine must be, itself,
    evolvable. This implies extensibility, a plug-in architecture, and so
    forth. There are many other specifications I could list for the middle
    layer, but I'll hold that for later.

    With respect to the bottom layer, SDS as it is presently implemented,
    appears to duplicate all its raw data rather than link to original sources.
    This, to me, makes perfect sense if you exist, or plan to exist in an
    environment that should remain isolated and unreliant on the availability of
    source information. In some OHS applications, particularly those where,
    say, a large enterprise hosts a private OHS with lots of OHSettes scattered
    about its intranet, then a central repository makes some sense. For a major
    web-based OHS community, perhaps a central&mirrored repository makes sense.

    Now, to the notion of "daily working activity." There are two parts to
    this. One is the real-time automatic aspect, and the other is the
    individual contributions (e.g. Rod's summaries). Let's think about these
    two, one at a time, starting with individual contributions.

    Reading any of Rod's links shows that his contributions are comprised of two
    parts:
        temporal and conceptual coupling -- links with summary statements
        personal commentary -- thoughts, extensional/projective,
    stream-of-conscious

    Given an evolving ontology, it becomes possible to perform some of the
    temporal and conceptual coupling automatically, and, even notification to
    subscribers of the links found such that those users now can come in and add
    their personal commentary -- perhaps through an IBIS interface.

    Automatic action should be real-time, always active. This means that, as new
    information is deposited into a repository (bottom layer), it is
    automatically scanned, reduced to its ontological elements (some will exist,
    others may be new to the system <note>this is the hard part</note>), and a
    linking engine started. <note>doing the ontology thing is saved for another
    post</note>. None of this exists in SDS at this time, so far as I can tell.
    My comments to Rod have always been that SDS needs this capability, but it
    cannot exist, IMHO, until some commitment to an ontology engine is made.
    When linking is done, subscribers are notified (e.g. by email), complete
    with appropriate response URLs which, presumably open an IBIS interface
    ready with the new information to which a response is solicited.

    I have just described a system that enables the collaborative construction
    of knowledge. Let me recite the underlying assumptions:
        knowledge, itself, is a human-centric notion and cannot be "contained"
    anywhere else but in meat-space.
        knowledge can be *represented* in the form of statements, icons, links,
    whatever, which evoke responses when meat-space is exposed to those
    representations.
        knowledge representations are never the *territory*, they are only the
    *maps* to the territory.
        constructing a concensus ontology is:
            very hard (some would say, impossible)
            worth doing if semantic interoperability is desired
        concensus ontologies are most useful in specific (often called
    *vertical*) domains
        a common *upper* ontology to which all vertical domains are anchored
    allows for eventual discovery of links between domains (analogies, etc).

    <note>a favorite illustration of analogical links between domains, as often
    used in the AI community, is that of the mapping of the *divide and conquer*
    military notion into the radio therapy domain</note>

    In the very long run, the notion of hanging domains on a common *upper*
    ontology enables a background discovery process to run on a continuous
    basis.

    And, IMHO, all of this supports the concept of Knowledge Management (KM).
    And, what is KM? Who knows? What I have stated here wants to surround
    Doug's notion of CODIAK ( http://www.bootstrap.org/augment-132811.htm ).
    Doug speaks of:
        Intelligence Collection (IC)
        Dialog Records (DR)
        Knowledge Product (KP)

    My three-layer architecture provides an archive and interface for
    information flowing in from some environment (IC). That environment
    includes users manipulating the archive (solely) by adding new commentary
    and participating in IBIS-based dialogs (DR). Finally, there is the KP.
    What is that, or what are those? Those, as Doug says, are the proposals,
    plans, budgets, contracts, and so forth as constructed by the participants
    and users of a particular OHS. KM is a process that enables KP.

    Can we contrast this view of an OHS to Rod's SDS? I think so, but my
    version will necessarily be incomplete given that I only have read-only
    access to the web product of SDS with no navigational aids except Rod's
    occasional references in this list.

    SDS clearly handles IC as evidenced in his links to *original* records. SDS
    also handles DR, as evidenced in the links he supplies us as entry points
    into his records. Is there KP in SDS? I believe so, but the only evidence
    we have for that lies in the enthusiastic way in which Rod smears this list
    with profound reminders of what we have said before, complete with his take
    on things. SDS has shown us one particularly important aspect of KM --
    keeping track and making sense of the record. Until SDS has a navigation
    tool, and until it provides us with an opportunity to interact with it, then
    it is not complete as a KM tool in so far as I am describing an OHS. SDS
    appears to be comprised of the elements Time, and Subject, and Records which
    are a cross-product of Time and Subject. That, it seems to me, represents
    the underlying structure necessary for KM. A user interface Rod uses must
    turn that structure into a useful KM tool. My proposals, here, add an
    Ontology as a central core that ties concepts to other concepts to time and
    to records.

    Should we perform a summary of documents as I originally suggested? Or,
    should we toss our energies at development of the navigational tools
    necessary to get a better handle on what we have been saying? We should
    probably do both.

    Jack

    From: Rod Welch <rowelch@attglobal.net>
    >
    > I tried your suggestion and wound up at...
    >
    > http://www.infoloom.com/gcaconfs/WEB/barcelona97/angerst7.HTM
    >
    > This location and the path that led to it seems like it could be very
    useful.
    > How are you thinking of applying this to KM, as Doug lays out in his 1972
    paper,
    > reviewed most recently on 000327....
    >
    > http://www.welchco.com/sd/08/00101/02/00/03/27/094001.HTM#L391402
    >
    > ...and evidently applied in his paper on 980128 for the "Technology
    Template
    > Project," that led to the DKR objective...
    >
    > http://www.bootstrap.org/alliance-980.htm#0436
    >
    > Is the idea to process daily working information with the engine discussed
    in
    > your letter on 000623...,
    >
    > http://www.welchco.com/sd/08/00101/02/00/06/23/114155.HTM#L441903
    >
    > Sounds like a strong track, which might lead to putting the Subject Index
    on the
    > web in some form that would add a new dimension to finding stuff when
    needed,
    > similar to SDS.
    >
    > Rod

    ============================================================================
    This message is intended only for the use of the Addressee(s) and may
    contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
    the intended recipient, dissemination of this communication is prohibited.
    If you have received this communication in error, please erase all copies
    of the message and its attachments and notify postmaster@verticalnet.com
    immediately.
    ============================================================================

    -------------------------- eGroups Sponsor -------------------------~-~>
    eGroups eLerts
    It's Easy. It's Fun. Best of All, it's Free!
    http://click.egroups.com/1/9698/0/_/444287/_/975610212/
    ---------------------------------------------------------------------_->

    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 : Thu Nov 30 2000 - 11:00:36 PST