OHS Project ,
the unfinished revolution

July 6, 2000
previous meeting, next meeting. 1

Agenda: 2

  1. Approval of last week's minutes and this week's agenda. 
  2. Announcements and New Business. 
    1. Doug's talks at Cadence and SourceForge. 
    2. Guest: Daniel Austin of AskJeeves 
  3. Licensing. 
  4. NASA proposal. 2A

Present: 3

Grant Bowman 
Mary Coppernoll 
Bill Daul 
Meghan DeClerck 
John Deneen 
Doug Engelbart 
Norm Hardy 
Frode Heglund 
Jim Hurd 
Lee Iverson 
Eugene Kim 
Howard Liu 
Jack Park 
Joe Williams. 3A

Minutes: 4

1) Agenda:

  • Welcome Bill Daul, Norm Hardy, Frode Heglund, and Meghan DeClerck 
  • Basics for launch plan for the OHS project. 4A
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. 4B

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: 4B1

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,... 4B1A

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. 4B2

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

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. 4B4

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. 4B5

Consider SourceForge. See how proactive user communities can be. Consider the languages Python and Java. 4B6

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. 4B7

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: 4B8

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.4B8A

We need to translate all this into software jargon. 4B9

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. 4B10

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

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

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. 4C1

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

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

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. 4C4

We're interested in the API that enable mappings from lens to viewer. 4C5

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. 4C6




Above space serves to put hyperlinked targets at the top of the window
Copyright 2000 Bootstrap Institute. All rights reserved.