I may not yet be able to build me an OHS, but at least Jack knows how to
concretize (ugly word, that, but a valid one) his ideas. You make a good
teacher, Jack. And I might even begin to grasp what an ontology is. It looks
like mapping back all the world's stage into God's mind from which He, with a
little bit of bootstrapping and programmer's luck can make a better world. (Sm)
H.
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.
> ============================================================================
>
>
> 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 -------------------------~-~>
eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9699/0/_/444287/_/976827665/
---------------------------------------------------------------------_->
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 - 13:11:43 PST