Re: [unrev-II] Use Cases and Ontologies

From: John J. Deneen (JJDeneen@ricochet.net)
Date: Thu Dec 21 2000 - 23:40:39 PST

  • Next message: Paul Fernhout: "Re: [unrev-II] Is "bootstrapping" part of the problem?"

    Jack, your applied QP theory about 'envisionment' with process rules firing,
    etc., has an interesting correlation with a paper about "Collective Mental Maps
    (CMM) with weighted links algorithms from our friends at the Principia
    Cybernetica Project:

    "Collective Intelligence and its Implementation on the Web: algorithms to
    develop a collective mental map", Computational and Mathematical Theory of
    Organizations
    <http://pcp.lanl.gov/Papers/CollectiveWebIntelligence.pdf>

    "Collective intelligence is defined as the ability of a group to solve more
    problems than its individual members. It is argued that the obstacles created by
    individual cognitive limits and the difficulty of coordination can be overcome
    by using a collective mental map (CMM). A CMM is defined as an external memory
    with shared read/write access, that represents problem states, actions and
    preferences for actions. It can be formalized as a weighted, directed graph. The
    creation of a network of pheromone trails by ant colonies points us to some
    basic mechanisms of CMM development: averaging of individual preferences,
    amplification of weak links by positive feedback, and integration of specialised
    subnetworks through division of labor. Similar mechanisms can be used to
    transform the World-Wide Web into a CMM, by supplementing it with weighted
    links. Two types of algorithms are explored: 1) the co-occurrence of links in
    web pages or user selections can be used to compute a matrix of link strengths,
    thus generalizing the technique of "collaborative filtering"; 2) learning web
    rules extract information from a user's sequential path through the web in order
    to change link strengths and create new links. The resulting weighted web can be
    used to facilitate problem-solving by suggesting related links to the user, or,
    more powerfully, by supporting a software agent that discovers relevant
    documents through spreading activation."

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

    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 21 2000 - 23:54:46 PST