This is one of the possible Use Cases.
This is a fairly detailed use case about e-procurement contracts, where proposed/final contracts are exchanged, and where the rules can make use of -- by merging in after semantically-interoperable translation -- background ontologies of a default-inheritance style similar to that of object-oriented programming languages and frame-based systems, e.g., the MIT Process Handbook. (By BenjaminGrosof)
This use case is based primarily on the example in the RuleML-2005 conference paper "Extending the SweetDeal Approach for E-Procurement using SweetRules and RuleML", at http://ebusiness.mit.edu/bgrosof/#sweetdeal-procurement+sweetrules-ruleml2005.
This use case is still undergoing editing.
FOR NOW: see the above paper, at http://ebusiness.mit.edu/bgrosof/#sweetdeal-procurement+sweetrules-ruleml2005.
3. Benefits of Interchange
List below some benefits of interchange in this use case, i.e. why interchange matters.
4. Requirements on the RIF
List requirements of this use case on the RIF.
5.1. Actors and their Goals
List the different parties who interact in this use case, along with their goals. They should be named with abstract role names, like "Buyer", "Seller", "Buyer's Agent", and "Government Agency".
Actor 1 - wants ...
Actor n - wants ...
5.2. Main Sequence
Provide the typical course of events, ordered as below in a sequence of steps.
First step of sequence
Last step of sequence
5.3. Alternate Sequences
Describe possible variations of the main sequence in separate subsections, assigning a title to each.
5.3.1. (Title of Alternate Sequence)
Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).
Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.
6.1. (Title of Narrative)
Describe an individual scenario. Samples rules and other test data may be optionally included.
Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.