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 -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/0/_/444287/_/976821439/
---------------------------------------------------------------------_->
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 - 11:28:12 PST