Humans are engaged "out there" doing cycle A, in which some problem is being solved. Along the way, humans are also engaged at Context making public statements which enter an IBIS discussion. Eventually, some concensus is reached, new artifacts generated, and humans experience the feedback of cycle C, folding it into their own B cycles.

Let us assume that my view of the improvement cycles somehow coincides with those already expressed by Douglas Engelbart. On that assumption, I shall take this a bit further.

In the conduct of design of an OHS -- any rendition of an OHS, for that matter -- my view is that the important issues to resolve up front are those associated with the API that allows Context to talk to DKR. When such an API is created -- itself a part of bootstrap cycles, then becomes possible to implement all sorts of variants along the OHS theme. So long as they all implement the API, they all are intended (by design) to be interoperable.

The Context package includes Human Computer Interface (HCI) systems that enable a variety of OHS features, such as Topic Map navigation, email, forums, conferences, chat, document manipulation, IBIS, SDS, and so forth, each of which is supported by way of the infrastructure constructed within DKR and exposed by way of the API.

In summary, I am illustrating three specific kinds of bootstraping here. The A cycles are those in which society plays out its roles bootstrapping solutions to the complex, urgent problems that Doug and others describe. The B cycles represent individual growth and learning, and the C cycles, enabled by way of OHS, represent societal growth and learning. At the same time, I am making the claim that job one lies in the evolution (bootstraping) of an API that allows OHS implementations to emerge.

Sincerely,

Jack

Jack Park
jackpark@thinkalong.com
jackpark@verticalnet.com