Re: [unrev-II] ThemeScape: Augment + categories = OHS v0.1

From: John J. Deneen (
Date: Sun Jun 25 2000 - 13:16:31 PDT

  • Next message: John J. Deneen: "Re: [unrev-II] Item #2 ThemeScape: Augment + categories = OHS v0.1"

    Jack Park wrote:

    > Painfully longish. Sorry.
    > From: Gil Regev
    > The problem with categories is that they tend to rigidify
    > the knowledge repository, in which case I wonder how dynamic
    > it will be. I was in a conference on trans-disciplinarity a
    > few months ago and one of the presenters said that the the
    > real threat to trans-disciplinarity was the hardening of
    > categories. I a collaborative software (not Knoware) we did
    > in our lab we moved from relying on categories to find
    > information to using a good search tool. We figured that
    > whatever categorization scheme we could come up with, it
    > would be obsolete pretty fast. Having said that, I totally
    > agree that categories are essential but they should be
    > implemented in a way that preserves the dynamics of the
    > system.In Knoware, relationships have no meaning for the
    > software but they do have meaning to the users. The search
    > tool searches for text in relationships as well as in
    > concepts.Gil
    > Gil has a good point here. In fact, George Lakoff wrote a whole book
    > on this (_Women, Fire, and Dangerous Things_). Gil's point, combined
    > with the meeting yesterday, lead me to ponder a couple of issues,
    > which I shall do outloud, even as I type... My take on the meeting
    > yesterday was this: a lot of back-and-forth without a clearly defined
    > ontology on which the banter was founded. Ultimately, even the
    > definition of "document" was up for grabs, not to mention "node." I
    > believe that we waste an enormous amount of human intellectual energy
    > doing battle while not even on the same page. If that sounds like a
    > criticism of one aspect of yesterday's meeting, it is meant to be so.
    > OTOH, the meeting was, indeed, valuable largely since Eugene did a
    > masterful job of summarizing the Use Case issue and presenting it --
    > something that needed (and continues to be needed) to be done. I
    > respectuflly submit that all discussions be preceeded by the
    > development of a concensus ontology. <side note>achievement of a
    > concensus ontology should be a goal of this list</side note> Gil
    > points out what Lakoff and others have been saying: once you get to
    > the ontological level of "category", concensus begins to fall apart.
    > Gil uses the term "rigidify." That works for me, but there are other
    > points of view as well. At issue is the fact that we all categorize
    > the world in our own way. Production-line education tends to enforce
    > standardization in that arena, but we are still individuals with our
    > own non-linearities and so forth. So, just what IS a mother to do? An
    > OHS/DKR is, at root, a vision of a universal tool for collaborative
    > evolutionary epistemology (that's my take on it, your mileage may
    > vary). To be universal, the implication is that everybody has the
    > chance to contribute (both give and take) with the "appearance" of
    > being on the same page as everyone else. Nice trick, if you can do
    > it. As it turns out, Adam, I, Howard, and Peter Yim all work for a
    > company that is working to render this very capability in the B2B
    > space. VerticalNet uses a carefully crafted ontology (on which Howard
    > works) to serve as an "interlingua" or, shall I say, "page renderer",
    > so that enterprises that have their own individual ontology can be
    > mapped onto the playing field. When Mary Keeler and I spoke at one of
    > the meetings recently, we sketched on the board a 3-layered
    > architecture, all of which comprised the DKR and its gateway to the
    > OHS (which I define here as a desktop, palmtop, whatever, window into
    > the DKR). Let me now sketch (in words) that 3 layer architecture and
    > try to show how it has the opportunity to do precisely what Doug asks
    > for, and allows us to build an ontology that serves as an interlingua
    > to all possible users no matter what they make of women, fire, and/or
    > dangerous things. Peirce's theory of categories has it that there are,
    > fundamentally, three categories: Possibilities -- all the "noise"
    > out there, raw data, written/spoken discourse Actualities -- a
    > mapping of the possibilities; Mary calls this layer a "lens."
    > Probabilities -- what you and I do with the actualities. Possibilities
    > resides at the bottom layer of the architecture. This layer is nothing
    > more or less than a database (archive) of human discourse, recorded
    > experience.<side note>if up-down imagery doesn't work for you,
    > substitute left-right, or whatever</side note> Actualities resides in
    > the middle. This layer serves as a lens, mapping the possibilities
    > into structures (an ontology) that can be viewed, inferenced, debated,
    > and so forth. This layer, IMHO, is the crucial one. To get it right,
    > it must consist of a kind of structure that, at once, serves as a
    > universal ontology (tongue ensconsed firmly in cheek on that one), a
    > platform for reasoning and debate, and a permanent record of the
    > evolving human knowledge base. Whoever builds this layer
    > wins. Probabilities is the top layer in the architecture. It, in fact,
    > is the gateway to the users "out there." Users will have their own
    > mapping tools, perhaps what Doug calls the transcoder. Transcoding
    > can, of course, be accomplished anywhere in the world; at the server
    > (good for wireless), somewhere else in the network, or at the user's
    > client computer. The purpose of transcoding is to allow the user to
    > get or otherwise construct a view that suits his/her
    > tastes/needs/desires. The user should have the ability to directly
    > query actualities, and, through that layer, ask a question like "where
    > did you get that?" and have read-only access directly to the
    > possibilities layer. This capability suggests that each "node" (don't
    > go there, we shall define it eventually) contains pointers into the
    > "document(s)"(hey!, I said don't go there) from which it (the node)
    > was derived. <side note>I believe that transcoding now takes on a
    > larger role; originally it was conceived as a view generation tool.
    > Now, I suspect it also takes the role of ontological mapping</side
    > note> How is this architecture used? Here's a sketch of the
    > appropriate scenario that traces document origination, actualities
    > generation, and user experience. 1- Documents (e.g. articles, news
    > items, books, papers, speaches, etc) are entered into the archive.
    > 2- An engine is turned loose on the archive to perform the task of
    > mapping everything into the actualities layer. (as I said, whoever
    > does this wins).
    > In regards to item 2, ThemeScape 2.0 targeted at enterprise portals
    > and business intelligence that is based on Cartia's proprietary
    > Relational Topic Mapping (RTM) technology
    > ( may be an example of this
    > capability?
    > ThemeScape automatically reads large numbers of documents, recognizes
    > the informational content, and organizes the collection by topic onto
    > a visual map. Version 2 makes the technology accessible via the web.
    > The underlying technology of ThemeScape has been in development for
    > more than four years, beginning at the Department of Energy's Pacific
    > Northwest National Laboratory operated by Battelle. With roots in
    > highly classified covert operations, early development was directed by
    > the United States federal government to help discover patterns and
    > trends within hundreds of thousands of intelligence documents. Among
    > other operations, the technology played an instrumental role in
    > analyzing Iraqi troop movements after the Gulf War. In 1996, Cartia
    > secured exclusive rights to the technology and has since redesigned
    > both the mapping engine and user interface for use in commercial
    > applications.
    > "ThemeScape helps you rise above individual documents to see the big
    > picture," said Mark Goros, CEO of Cartia. "The system is designed to
    > rapidly convey information with very little reading. In less than 30
    > seconds, it can show you what's inside thousands of documents
    > and that's just the beginning. When you search, the results are
    > visually organized by topic, right on the map. You can zoom in for
    > greater detail, flag interesting documents and forward them to others.
    > It's a new way to work with information."...
    > This Relational Topic Mapping (RTM) technology is provided a a free
    > service by ..." can show you in 15 seconds
    > what could take hours of reading," said Mark Goros, CEO of Cartia.
    > "Everything is graphically organized by topic. You can look at a
    > NewsMap of 500 news articles and pick out the hot spots with almost no
    > reading. You can see a discussion forum of 10,000 postings and
    > immediately know what people are talking about. NewsMaps are fully
    > interactive so you can search, zoom in, read individual documents, and
    > even respond to newsgroup postings."...
    > .... Because documents are simply points on the map, it is possible
    > for ThemeScape to show thousands of documents at once without
    > overwhelming the user. Zooming into the map reveals greater detail.
    > For any region on the map, a click of the mouse pops up a list of
    > documents with related content. Pointing to any document title
    > displays a short text summary. A mouse click links the user directly
    > to the original document.....
    > ThemeScape is composed of three primary components:
    > * ThemeServer is the underlying engine that provides content
    > aggregation, map generation, and information distribution to end
    > users. Each ThemeServer can support multiple ThemePublishers and
    > ThemeReaders.
    > * ThemePublisher is the control center for ThemeScape.
    > ThemePublisher users can harvest information from local
    > directories, Intranet servers, or Internet web sites. They can
    > customize map appearance, create time-sliced maps based on
    > document dates, and even personalize the application with
    > graphics, user controls, and text specific to their business.
    > * ThemePublisher also includes all of the capabilities of
    > ThemeReader. ThemeReader is a desktop client that allows users to
    > view and interact with maps created using ThemePublisher. Users
    > can work with the entire information landscape in context,
    > progressively disclose greater detail, search for topics and
    > themes, and view summaries or individual documents.
    > 3- User constructs a view into actualities, perhaps as a query,
    > perhaps as a simple mapping of the knowledge structures contained in
    > actualities to a topic map, for which templates may be available. It
    > doesn't really stop there. Let's pretend user takes exception with
    > something discovered in actualities. 4- User opens a "debate" view
    > after selecting a particular actuality item (node?) 5- DKR creates
    > a new document in possibilities to record the nature of the
    > criticism. 6- DKR alerts subscribers to the debate. 7- DKR maps
    > new document into actuality. From that, we can see that user does NOT
    > have write access to actuality. Only the system does -- and that, of
    > course, is the big issue here. Hesse's Glass Bead Game suggested that
    > there is a Bead Master, one individual that has the ability to do such
    > mappings and control the flow of the epistemological evolution within
    > the system. I tend to think that will not happen, at least in my
    > lifetime. There needs to be a "machine" that does this work, and
    > there is an enormous body of scholarly work being generated that hints
    > of the emergence of this capability. But, given that this capability
    > remains the great "anal sphincter" in our project, the entire
    > architecture I have sketched cannot, by definition, be our Version
    > 1.0. So, we must re-sketch it as something we can do today. Largely,
    > the overall architecture remains the same. We simply do not set out to
    > construct the universal ontology as a middle layer. Rather, we scale
    > it back to some kind of human-generated (perhaps with machine
    > augmentation as that evolves) middle layer, one that represents a
    > concensus ontology for today, but one that is mutible as the concensus
    > evolves (conceptual drift). By constructing the software as a
    > pluggable architecture, we simply plug in software modules as they
    > emerge to enhance the system. <side note>I have a hunch that some
    > activity of the UN, say, the UN/SPSC, will ultimately become the basis
    > for the "universal mapping engine"</side note> Which brings me back
    > (yes, Marth, non-linear types can find their way back) to the original
    > space on which this diatribe is based. The fundamental architecture
    > being espoused within the meeting was that of an engine that mutates
    > original documents by adding links to them. The fundamental approach
    > taken in the architecture I present here is one in which absolutely no
    > modifications are ever performed on original documents. All linkages
    > are formed "above" the permanent record of human discourse and
    > experience. I strongly believe that the extra effort required to avoid
    > building a system that simply plays with original documents will prove
    > to be of enormous value in the larger picture. Thus ends the diatribe.
    > The non-linear one is now leaving the building. While leaving, he
    > wishes to acknowledge that the architecture sketched here has been
    > strongly influenced by Doug (for the big picture), Mary Keeler (for
    > the Peircian vision), Kathleen Fisher (for the knowledge mapping
    > structures, along with John Sowa and others), Eric (for his
    > introduction to IBIS), and Rod (for his web site that tries to keep
    > all this together).
    > -----------------------------------------------------------------------
    > -----------------------------------------------------------------------
    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Sun Jun 25 2000 - 13:24:14 PDT