Date: Fri, 23 Feb 2001 10:14:25 -0500
Mr. Rod Welch
rowelch@attglobal.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
415 781 5700
| Subject: | SDS Role in 3-layer Architecture |
|
Planning Meeting on SDS Feb 28, 1100 with Pacific Consultants |
Rod,
[Responding to your letter on February 22, 2001..... ]
Actually, I'm going to TX to give a talk at the Knowledge Technologies conference. You can read my paper at...
There, I will also be meeting with my publisher about the book and about future book plans.
About your meeting, I would like to think that you can think in terms of SDS as two different products, each with precisely the same front end, but each with a different backend. That is, the user interface, the content generation and browsing interface is the same for both.
The backends would be one to interface with the OHS core engine, and one as a scaled-down standalone version of the OHS engine (or whatever database structure you choose, including web publishing, as SDS presently does).
This allows users to have it both ways. They can do their compositions off line. In fact, they never need to go on line unless they choose to co-mingle some or all of their records with a larger OHS. There will always be users of SDS that will need to keep their records private. But there will also be lots of users who want to play in the much larger sand box that is OHS.
From my perspective, it would be the front end that satisfies both products that would be a core SDS engine. That core SDS engine would, itself, have an API that allows backends to be built either way.
One backend would be an entire OHS-like database (or anything else, for that matter), and the other would be an adapter that maps the SDS API to the OHS API.
One interesting factoid here is that the backend leaves room for proprietary enhancements to SDS functionality, so long as the front end provides a core SDS capability as your system presently does.
For now, I would define the backend of your SDS as that part of the code that maps records to web pages.
To be qualified to work with OHS, the only consideration is that those who use OHS as a substrate for a product may not prevent the OHS from evolving in the same or similar directions that proprietary external enhancements go.
Core SDS involves the linking mechanisms, record constructors and maintainers, and so forth. It's not going to be easy to sort all of this out.
For me, it is not productive to think in terms of any metaphor (e.g. control room) other than content generator/browser.
In the end, I will be interested in making the most of the fact that SDS, as I said, allows users to build personal views of events, and those views can and should become grist for an IBIS-like mill.
Over the top of all that, a community ontology is always evolving, helping to keep discussions aligned. As you say, alignment is good.
Surrounding all that, other players, who happen to subscribe to any given thread, are able to chime in and expand the meme pool.
Surrounding all that, it is possible to have a discovery engine mining threads and looking for new, unnoticed relationships and making those discoveries available to the affected threads.
And, as you may guess, there's even more that can surround all that. Onion-skin architecture, it is sometimes called.
Presently, SDS has been, for you, about managing your own thoughts. SDS should always have a personal management component. But, for the OHS arena, I am inclined to think that collaboration, which includes SDS, will be good for solving much larger problems than those typically ascribed to personal issues.
It is somewhat well documented that structured environments can work both ways: they can either hinder, or help participation. Some folks just don't "think that way" and so forth. Thus, SDS can only be considered a part of the solution space armamentarium, not the whole of that space. SDS records will necessarily have to be a part of other content generation environments. That's what the OHS core engine is all about.
About an agenda for your meeting, I would suggest that you give some consideration to the use cases that SDS can play a role in for whatever metaphor you choose. Should you choose the Lexus/Nexus arena, there could be lots of fun playing with use cases. Why mess with use cases? That's a fair starting place for writing a white paper around which a business model can be formed.
Sincerely,
Jack
Jack Park
jackpark@verticalnet.com