Minutes: July 6, 2000    (01)

4-6pm, SRI Engineering Building, EK255
By Howard Liu <hliu@verticalnet.com>    (02)

Present    (03)

• Grant Bowman    (04)
• Mary Coppernoll    (05)
• Bill Daul    (06)
• Meghan DeClerck    (07)
• John Deneen    (08)
• Doug Engelbart    (09)
• Norm Hardy    (010)
• Frode Heglund    (011)
• Jim Hurd    (012)
• Lee Iverson    (013)
• Eugene Kim    (014)
• Howard Liu    (015)
• Jack Park    (016)
• Joe Williams    (017)

1) Agenda:    (018)

• Welcome Bill Daul, Norm Hardy, Frode Heglund, and Meghan DeClerck    (019)
• Basics for launch plan for the OHS project    (020)

2) Launch plan for the OHS project. Doug presented some slides for his launch plan for the OHS project. We want a sequence of prototypes, and a sequence of active user communities. We've zeroed in on software communities.    (021)

Addressability is an essential feature of the system. For example, every paragraph should have a reference, addressable by a URL from the browser. Doug shows a slide with a diagram, whose text content is shown below. The bracket pairs stand in for the colored boxes displayed:    (022)

Stage-1 OHS Browsing
Every object addressable; flexible viewing options.

[Browser] <-- [ [Families of Transcoders] <-- [X-Files] <-- [Translation] ] <-- [Web servers]

[Link db]

Also, high-resolution linking to audio, video,...    (023)

Another essential feature of the system is that it provides a range of user views. Like the program Augment, the OHS/DKR offers the user multiple views of the original document. For example, one view show the user only the first line of a text document. One view may display the document's location number on left, and another may display it on the right side. One view may show a text document with lines single-spaced, while another shows it without.    (024)

The ideas of the OHS/DKR we're building is based on Augment. We'll start with hypermail.    (025)

The OHS/DKR itself coevolves with its user communities. We want to cultivate communities of proactive users. In order to do so, we must find ways for our OHS/DKR to demonstrate superior capabilities.    (026)

Glossaries, descriptions, current states of design, evolving descriptions of things: we'll find a standard form for how each of those is to be translated. Aside: We need to consider what language to use to build the translator.    (027)

Consider SourceForge. See how proactive user communities can be. Consider the languages Python and Java.    (028)

We need conventions for link types. IBIS provides a standard system. We need a database to keep track of them. Database activities tell who's pointing at the link types. Whoever has raised relevant issues can be tracked. We need to get attribution working well.    (029)

Doug shows another slide with a diagram, whose text content is shown below. Again, bracket pairs stand in for the colored boxes displayed. Identically named terms, e.g. [UIS], represent the same object on the actual diagram:    (030)

Stage-2x, Integrated Editing/Browsing

[Browser] [UIS]; Multiple UID Classes, Integrating Agents... 
<-- [ [Families of Transcoders] <-- [Evolving, Standard "OHS-File"] <-- [Families of Translators] [Link db] [Caching]] 
<-- [Target servers]

[UIS] --> [Editing] --> [OHS-File]

And then, gradual phasing of all work into this OHS.    (031)

We need to translate all this into software jargon.    (032)

We need to find the way software people are doing things. We can provide a way for communities to define their own concepts. Tools like conceptual maps come to mind.    (033)

Joe presented his diagram of the DKR on the board. Doug asked Jack to explain OHS/DKR and reconcile with Joe's picture.    (034)

3) Jack presented his OHS/DKR architecture diagram. There's no such thing as knowledge other than what's in the human mind.    (035)

The record is permanent in the DKR. Cache is a design detail. It is a copy of record, only it's structured. The cache is merely a design expedient. It is part of the design picture, but not the conceptual picture.    (036)

Mozilla has an XML/HTML editor built-in. It uses what it calls the XUL to make the user experience tailored to the user.    (037)

The user view manages the mapping from the lens (ontology) to the browser.    (038)

We need to enabled constrained dialogue in order that all intelligent, concerned humans can together work on and solve the world's problems. The ontology is not for machines to reason and solve the world's problems, but for humans to do so. Humans entering a new domain must learn the vocabulary, or jargon, of that domain.    (039)

We're interested in the API that enable mappings from lens to viewer.    (040)

Doug asked, what's the first stage in this project? Jack responded, we should look at what's already available. Consider JEXT, java version emacs-like tool, with lots of templates. Ozone might serve as the database system to hold the immutable records.    (041)