Jack,
Great work moving ahead on KM. How would your analysis apply to the following
use case that moves Doug's ideas from the laboratory into daily life....
http://www.welchco.com/02/06/05/61/00/12/1401.HTM#0001
Experience shows the scenario (in the above link) for handling daily working
information in legal practice, also, improves medical practice, engineering,
reading a book, digging a ditch. To enhance competency, we have to do KM, not
just talk about it. Your submission today is a good start, although it would
help to see alignment with the project record, as Doug requested the other
day.....
http://www.welchco.com/sd/08/00101/02/00/10/25/095632.HTM#L821202
...that fosters a culture of knowledge moving from IT to KM. Why is the law a
good model for improving competency in all disciplines? One reason might be
that it has worked out methods over thousands of years for making judgments
about the efficacy of conduct in all fields. If we look closely at that
process, the architecture of human thought is revealed, which is the foundation
for improving competency.
Rod
Jack Park wrote:
>
> I have been thinking about use cases, ontologies, and scenarios. I bring to
> these thoughts my experience with qualitative process theory, a
> representation and inferencing mechanism by which one can express physical
> processes in ontological terms.
>
> QP theory says that we need to know stuff about the following:
> actors
> relations
> states
> QP theory allows us to build an 'envisionment' in which a graph (sometimes
> very large graph) is built with its origin being a node called 'initial
> conditions.' I have imported a metaphor about theator into QP theory, so,
> one 'sets the stage' by defining initial conditions. There is no 'script'
> on this stage, just process rules, some of which can 'fire' changing the
> stage setting allowing for other rules to fire. Each 'firing' defines a new
> stage setting (node in the graph). When multiple rules can fire against a
> particular node, you have multiple branches from that node to new nodes.
> The process continues until no more rules can fire, or until 'stopping
> rules' --which define some goal stage setting -- fire.
>
> Thinking in newtonian terms, moving from one node to the next along some arc
> means that the arc represents some 'mechanism' or presence of a causal
> mechanism at work (e.g. the rule that fired). Defining the entire
> vocabulary of such a QP universe is, indeed, defining an ontology. Process
> rules appear as 'axioms' in the ontology.
>
> Now, what are use cases? They are simply very course grained envisionments.
> Basically, the presence of actors, and a description of the gross change to
> occur between initial conditions (which are not stated in use cases) and
> final conditions (which are also not stated in use cases).
>
> Consider this use case: UC-ActorViewDocument
> Actors: user, OHS
> Action: user views document with OHS
>
> Rather high level, what?
>
> Now, what are scenarios? They are simply finer grained expansions of the
> extremely crude envisionment expressed in a use case.
>
> Consider this scenario for UC-ActorViewDocument
> Before:
> Actors: user, OHS, Home Page, Desired Document
> Relations: user sitting at OHS terminal
> States: OHS 'Home Page' displayed.
> Actions:
> In this scenario, the action is a user behavior, not a process rule
> firing
> Actor clicks hyperlink to document.
> After:
> Actors: same
> Relations: same
> States: Desired Document displayed
>
> Why is this interesting? or, why should anyone care about this?
> Turns out that we now have a shell with which to invent OHS. We can now
> begin to refine the scenario to include a bunch of rule firings implying
> behaviors of OHS itself. From that, we get a simulation of OHS in action.
>
> Back to ontologies.
> Consider this: in the use case arena, there will always be a huge number of
> 'common' use cases, very much like the example above. Once we have all the
> common use cases constructed, we can now begin to layer more specialized use
> cases that imply, or rely on the existence of common use cases. We might
> think of these as 'domain specific' use cases. So, we begin to think of the
> common use cases as the 'roots' of --eventually--a forest of specialized
> usecases. The common use cases represent the basis for interoperability
> among the specialty domains.
>
> Now, just substitute the term 'ontology' for the term 'use case' and you
> have the mapping. Bingo. Get the ontology right, and the rest falls out
> (sm).
>
> Summary:
> I believe that I have outlined the case for:
> using QP theory as a kind of formalism on which we begin to map out use
> cases and scenarios
> developing use cases and scenarios, leading to an OHS ontology from
> which the entirety of OHS can then be developed.
>
> What I have not outlined is the need to bring pragmatics and knowledge
> representation best practices into this picture. For that, film at 11...
>
> ============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
> ============================================================================
>
> eGroups Sponsor
> [Click Here!]
>
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/0/_/444287/_/976831286/
---------------------------------------------------------------------_->
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Thu Dec 14 2000 - 14:12:22 PST