Date: Thu, 14 Dec 2000 14:17:15 -0500
| From: | Jack Park |
|
jackpark@verticalnet.com Reply-To: unrev-II@egroups.com |
| To: | unrev-II@egroups.com |
|
dougle@ricochet.net |
| Subject: | Use Cases and Ontologies |
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:
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).
Actors:
Rather high level, what?
They are simply finer grained expansions of the extremely crude envisionment expressed in a use case.
Consider this scenario for UC-ActorViewDocument
Relations:
States:
Actor clicks hyperlink to document.
Actors:
States:
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. ============================================================================
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