Date: Wed, 26 Apr 2000 09:33:35 -0700
| From: | Jack Park |
|
jackpark@verticalnet.com Reply-To: unrev-II@egroups.com |
| To: | unrev-II@egroups.com |
| Subject: | Jack Park's "10 Step" Program |
Longish, sorry.
Category level IS architecture level.
An architecture delineates categories of components and their interrelationships. Category level can draw from the many studies of design patterns. Class level dives inside each category and fleshes out just how things should actually look and communicate.
In the UML methodology, you would define categories (equivalent to Java packages), then do a sequence diagram on those categories as a means of fleshing out the use cases (scenarios). Once you know that something in category A needs to send some highlevel message to category B, then you begin to visualize the classes and methods inside the categories that will carry out the gestalt of the message. So, you next plan your classes, using class/method-level sequence diagrams to flesh out whole scenarios in detail, inventing messages and methods as you go.
Doug's need to understand WBI does, indeed, jump deeply into implementation issues; it appears to be motivated by the fact that Doug considers Transcoding rather central to the whole system and worthy of "jumping ahead" to mess with. In the end, WBI may not statisfy our needs for open source or cross platform capability; there are other approaches to the Transcoding solution.
The process has no real problem with jumping ahead; in fact it turns out to be rather iterative in nature since you will occasionally (read: always) find reason to go back and reexamine your assumptions, requirements, and so forth.
Remember, everything is supposed to draw from the original narrative. It should read something like the combined works of marketing (what the market thinks it wants), engineering (what folks think can be done), and vision (what folks want to get done).
Thus far, Doug has elucidated a rather vast and huge picture of what needs to be done (his vision), but has not yet drilled down to the bloody details of what that should look like. Right now, we know we want a dynamic knowledge repository.
What the hell is that?
Doug's Augment sets the stage. Rod Welch brings to the table an existence proof of concept for some aspects of a DKR. Visit his web site.
David Gelernter (another visionary) has brought to the table another existence proof of concept (LifeStreams) which has some fundamental similarities to Rod's work. Doug Lenat has demonstrated existence proof of the concept of evolutionary epistemology (Eurisko), and VerticalNet, the company for which I work, is generating proof of the need for and value of ontological engineering (the study of what is) at the bottom of everything. And under that lies knowledge representation (Erics atomic structures). My gosh! Parts of a DKR are already up and running in one form or another out there. It remains for us, as I think Doug has asked, to describe just what goes into a DKR, and go build it.
Thusly, it seems to me that our job should be to revisit the narrative: mine this mailing list for gems and formulate a draft text. Mine Rod's web site, his technology white papers and so forth, mine Gelernter's work, look at Lenat's work, look around, and formulate a final narrative that everyone can agree adequately lays out the vision, the market, and the technology available to us.
Along the way, contributions to the use case and scenario arena will be valuable. Indeed, they contribute something to the marketing narrative, and to the requirements document. Ultimately, the requirements document rules. We damned well better build something that satisfies those requirements. Testing will determine whether the requirements are satisfied.
Yes, there will be some of us who will jump way ahead and hack some code, trying to see what works. Doing so adds spice to the narrative, but always remember that the narrative is NOT ALLOWED to delineate any aspect of implementation, only to discuss technology.
Jack Park
jackpark@verticalnet.com