[Top]

Draft OHS Project Plan 0
by Doug Engelbart
Bootstrap Institute
23-Oct-2000 (BI,2120,)

Introduction 1

Large-scale challenges are best served if there are appropriately scaled strategic principles to guide their pursuit. And special value results if the launch plan of a long-term and large-scale strategy produces significant payoff accrual early in the pursuit. 1A

We are addressing the large-scale, pervasive challenge of improving the collective development and application of knowledge. Many years of focussed experience and conceptual development underly the strategic framework guiding this proposal. 1B

Phase-1: OHS Launch Project: HyperScope enhancement of Legacy Systems 2

Special Note: Implementation of the HyperScope and all of the later stages of the OHS are committed to being done as Open-Source development. There are clear and compelling reasons for this, stemming from the scale and rate of evolution which needs be accommodated, and from the number of collaborative communities which need to be involved, PRO-ACTIVELY. 2A

The HyperScope will be a lightly modified web browser supported by an "Intermediary Processor" (IP) which operates between the browser and the files or data bases holding existing working knowledge of a collaborative community. The HyperScope is not an editor. 2B

A Hyperscope user will be able to follow links into and between these "legacy" files in a manner similar to using a browser with web-based HTML files. And more, there will be numerous new capabilities and features which will give a HyperScope user considerable more flexibility and working power than users limited to standard browsers and "legacy" editors. 2B1

Brief Functional Description of Phase-1 HyperScope 2C

   New capabilities provided to HyperScope users operating within legacy environments:

1. In response to what may be an ordinary HTTP link, the targeted file will be (a) retrieved from its server and (b) dynamically "translated" into an Intermediary file (I-File) with special structure and format implemented with XML+. 2C1

For any community seriously interested in applying HyperScope (and the follow-on, full OHS), it is assumed that appropriate "translator modules" will be developed for every file/db type of significance to their collaborative efforts. It is expected that an increasing list of customized translators will be developed as different application communities extend the range of legacy files to be brought into integrated HyperScope use. 2C1A

2. High-Resolution Addressability: Translation into the I-File's special structure and format creates, among other things, new label tags attached to many objects (e.g. each paragraph), so that links serviced by the HyperScope can explicitly target many objects in the file which were not addressable in their "legacy" form. Ideally, every object in a file should be targetable by a link whose author wants to comment specifically about that object. 2C2

E.g., here "http://xxx.xxx.xxx#aaa" targets a specific object, assumedly not labelled in the legacy file, but given the "aaa" label by the Translator any time that it translates that targeted file into the I-File format. 2C2A

3. View-Specifications: The HyperScope will offer a set of "transcoded viewing options" which a user can selectively employ to examine that file. Simple example: just show me the first line of each paragraph. 2C3

From past experience it is expected that users will invent many variations of the ways they would like to view portions of their files, under different circumstances, often shifting rapidly between views just as one might rotate a physical object, or shift its distance, to get a better understanding of what is there. 2C3A

It is planned to enable the option of incorporating a "view specification" (viewspec) to a link so that a subsequent user will not only have execution of that link take him to the desired specific file location, but will also show the contents there with the specified view. 2C3B

Considerable evolution is expected to take place here. In the "open-source" mode, many groups would be experimenting and tuning, contributing to the evolution. 2C3C

4. Expanded set of HyperScope accessable "Legacy File Types:" In principle, this manner of HyperScope access can be implemented for any standard type of file or data base. The Project will establish the basic implementation conventions, and proceed to develop the translation and special I-File properties appropriate for a selected sequence of file/db types – planning tentatively for those to be used by: 2C4


1. the OHS-dev community (including open-source participants); 2C4A
2. the Software Productivity Consortium's member community: 2C4B
3. communities selected with NIH (and possibly cooperatively with DARPA) for strategic progression of co-evolving tool- and community-development processes. 2C4C

Note: Here again, it is planned to facilitate Open-Source development so that many individuals and application communities can pursue specialty application needs and possibilities. (Facilitating this evolution is planned.) 2C4D

5. Copying-Pasting HyperScope Links: When viewing a legacy file via his HyperScope, a user will easily be able to install a HyperScope link (HS-Link) in any legacy file, targeting an explicit location in the file being viewed on his HyperScope. Clicking on the desired target object in a HyperScope "Copy mode," he can subsequently turn to the "legacy editor" and "Paste" the appropriate link into the legacy file. Later execution of that link will take any subsequent HyperScope user to the desired, specific location and with the specified view. 2C5


6. Back-Link Management: Provision will be made to capture information about links pointing through the HyperScopes into a specified collection of files, to establish a "Back-Link Data Base" (BLDB). For each such link, information to be captured would be such as: 2C6


1. Explicit target object being cited; 2C6A
2. The "foreign" location of the link; 2C6B

NOTE: both 6a and 6b being very much more usefully explicit if exercised via HyperScope use. 2C6B1

3. The author of that other-file citation link. 2C6C
4. The "Type" of link citation, as per the vocabulary of "link typing" adopted by the usage community, and provided for inclusion in "link syntax" by appropriate standardization processes. 2C6D

NOTE: Link Typing has been advocated and discused for many years. With the above HyperScope-facilitated LDB, link-type utilization within appropriately developed community conventions and practices, would offer very important enhanced capability for collective knowledge development. 2C6D1

AND, in a larger sense, it would enable a practical way to improve on the established academic convention of only publishing AFTER appropriate peer review (with attendant time delays in the cycle of knowedge evolution). 2C6D2

HERE, a promising alternative is offered: Publish now, let Peer Review and "evolving attribution" take place after. I.e., much more than just counting citations can here provide effectively attributed peer evaluation: explicit back-link assessment of trails can operate in many complex knowledge-evolution environments to isolate the key contributions (and also the key misleading entries). 2C6D3

7. Extended addressing conventions to improve linking power: 2C7


1. Relative Addressing: A conventional URL with a "#label" extension can position the HyperScope at a given object in the target file. Extended conventions will enable the link to point to subordinate objects – e.g., to a word in a paragraph, to an expressiion in an equation, ... 2C7A
2. Indirect Linking: A very powerful extension to the relative addressing is a convention which directs the HyperScope to go to a specific location and then follow the link at that position – and perhaps at the link's destination to do further relative positioning and "link following." This indirect linking provides very powerful functionality when users learn to harness it. 2C7B
3. Implicit Linking: Example – every word is implicitly linked to its definition in a dictionary; every special term is implicitly linked to its definition in that discipline's glossary; every instance of an object's name in a source-code file is implicitly linked to its imlementation code; ...; every pronoun is implicitly linked to its antecedent. Special "jump" commands can be provided which can operate as though the term in question is explicitly linked to the "implicitly linked" object. (Jump to Definition, ...) 2C7C


8. Same file in multiple windows – no real limit there – simultaneously allowing different positioning and differnet viewing portrayals of a given file. 2C8

Later, when editing of the Intermediary File will be offered, any legal edit operation executed in one window is reflected accurately and immediately in all other of that file's portrayal windows. 2C8A

This flexibility in utilizing multiple windows has surprising value when users learn to make effective use of it. 2C8B

9. Non-Link Jumps: Options offered via simple selection means – E.g.: 2C9

A click in a given paragraph, not on an embedded link, would hoist that paragraph to the top of the window. 2C9A

Click-select a given paragraph, then Jump Next, Last, First, Origin, ... 2C9B

10. Double-click Jumps offer surprisingly flexible options: 2C10

First click indicates what jump is desired; second click can be in any other window, indicating where the jump-result view is to be portrayed. Whatever viewing spec already established in the target window will also prevail when the jumped-to file/location is portrayed there. 2C10A

Also, in the interval between window clicks, icon or menu clicks, or character input, can indicate the new viewing spec if the user desires something different from what is currently set for the target window. 2C10B

For instance: Window 1 could be relatively narrow, with view spec set for small font and only first line of each paragraph portrayed; Window 2 wider, with larger, more-readable font and full-paragraph portrayal. 2C10C

We assume that the above capabilities would be useful to almost any collaborative community, essentially as soon as adequate HyperScope-application support services could be provided. (NOTE that a qualified SRI group is explicitly set now to establish and operate such servics. Optional whether arrangements for this are pre-established at outset of the "OHS-dev Project", or later when support of a particular community choose to become involved. In any event, suitable lead time needs be allowed.) 2C11

Phase-2: Maturing/Evolving the Hyperscope into full-feature OHS 3

Evolution of the Intermediary File format will be given careful attention since it is destined to become the format for the full Open Hyperdocument System (which will continue its evolution). 3A

An OHS "User Interface System" (UIS) will be developed to provide a basic range of functions for moving, viewing and editing. 3B

Provision for archiving, version control, etc. will be developed so that it becomes possible to develop and maintain an evolving knowledge base soley within an OHS environment – with integrated flexibility and power accumulated from the best that was accomplished via HyperScope usage among the legacy files. 3C

Now the VERY important feature of this approach to OHS development comes into play: task by task, or person by person, in almost any order and rate, users can start to keep their files entirely within the OHS environment. All the working material is still interlinkable, whether in OHS or legacy files. 3D

And the critical community-development processes will become VERY important here – to start the active "co-evolution" of the "Human System" and the OHS "Tool System" (as discussed at length in the "Bootstrap Publications"). 3E

For the scale of utilization that will be necessary, in number of inter-operating groups, in the diversity of inter-operable knowledge domains, and in the continuing changes in tools and skills, processes, etc. – it will be absolutely critical that 3F

1. the Tool System be as open to continuing evolution as can be managed, and 3F1
2. the application communities be specifically organized to participate pro-actively in the Human-Tool co-evolution. 3F2

It is sincerely hoped that organizations investing in the Stage-1 HyperScope development and use will do so with clear intent to be simultaneously readying their targeted application communities for becoming pro-active, "evolutionary participants." 3G

Phase-3: Special Evolutionary Provision: Multi-class UIS Architecture and High-Performance Teams 4

The OHS Interface Architecture will be set up explicitly to provide for multiple UIS options, with a common, full-feature Application Program Interface (API). To support extensive capability evolution, it will be necesary to provide for a range of UIS options, varying in complexity, potential competency level, difficulty to learn, types of interface devices and modalities, etc. 4A

Being able effectively to support web-connected mobile phones is one example. 4A1

But a VERY IMPORTANT purpose here is to enable individuals, or special-role support teams, to experiment with interface equipment, functionality, and control options, together with optional special attributes of the standard Intermediary File, to pursue especially high performance at important parts of their knowledge processes. 4B

Having this kind of exploration in any event will be necessary. Doing it with special extensions to the widely used OHS will be very important in enabling feasible migration of these tools and skills out into the rest of the communities. Moreover, doing this exploratory high-performance activity over the SAME WORKING domains amplifies that benefit immensely; motivated individuals can optionally acquire special interface equipment, take some special training, and move up to a "new class of user proficiency" (e.g. becoming a certified Class-4B Knowledge Integrator). 4C

There are support roles anticipated in developing and maintaining a community's Dynamic Knowledge Repository (DKR) which could very well be taken on by specially trained High-Performance Support Teams. Such a team could for instance be fielded in a university (as a research project into High-Performance Collective Knowledge Work), and take on the "Knowledge Integrator" role for a professional society's DKR. And competetive exercises could be conducted among teams from different universities – or companies, or agencies, or countries – as part of an explicit processes to facilitate improvement in "Collective IQ." 4D