Memorandum

Date: Sat, 22 Apr 2000 08:58:38 -0700 (PDT)

From:	Joe Williams
	altintdev@webtv.net Reply-To: unrev-II@egroups.com

To:	unrev-II@egroups.com

Subject:	Use Case Analysis
	OHS, DKR Design Specification

In response to Lee's use case example, and his request for other examples:

Use Case for Picture

Installing and Using the DKR.

1. Name this DKR. Establish the 'namespace' of this DKR. the first set of 8 characters of this DKR name is provided by you, the DKR administrator. The second set of eight characters is supplied by bootstrap alliance. Together they form a string that uniquely identifies this DKR and allows interface with other DKR installations.

2. Define the DKR GOAL.

   Each DKR Goal, or Problem, is a separate information item. Each entry describes. to the best of the user's current understanding, the purpose of this DKR. An example DKR goal is; "Eliminate World Hunger". Another is: "Identify ways to improve the DKR/OHS interface".

   You can choose the title for this group of entries, either Goal, or Problem, or whatever you feel will serve to focus the efforts of contributors at the purpose of this DKR,

3. Define the main content structures. For this example, the categories are Level 1: Experience, Level 2: Learning, and Level 3 Knowledge. While there can be any number of content structures, the astract naming in this example assumes that information will progress thru these structures with progressively greater detail and refinement, from Experience to Learning, to Knowledge.

   For the general case, there can be any number of levels, any number of categories in each level, and any number of items in each category.

   Implict in the DKR definition is that content is somehow more focused on a goal as the level increases. In this example, Experience is the level at which real life facts and observations are gathered and entered into the repository. These individual data items are deliberated by the participants and organized into cohesive lessons then moved to Learning. Each Learning item proves or supports one Knowledge item, which is linked to a DKR Goal.

4. Load the Knowledge category. Enter a separate informaton item for each descrete fact known about the goal. These should be the few core 'facts' presently 'known' about the goal.

5. Load the Learning category. Each Learning information item is a structured proof or explanation of one Knowledge item. While there may be more than one Learning item for each informaton item, each is linked to and supports only one associated Knowledge item.

   At this stage the repository is ready for general use. You should be able to view the DKR node map and see the relationships between Goals, Knowledge, and Learning.

6. Load the user base. This consists of the list of users available to contribute.

7. Begin operation by requesting improvement to Knowledge and Learning items in relation to achieving the DKR Goal(s). In this model, the information flow is that opinions and evidence would be submitted to the Experience category for discussion, then as appropriate, integrated into the Learning and Knowledge categories.

   As new information items are created, you should be able to view the DKR node map and see the relationship of each item with respect to other Goals, Knowledge, Learning, and Experience items.

8. When sufficient Knowledge is available to actually take action to solve the problem, then the action (exhibition of Wisdom in this example) is taken and the results are recorded. These results are entered info the repository as Experience, to be deliberated upon and incorporated into further refinements of Learning and Knowledge items.