- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Sat, 8 Nov 2003 17:18:18 -0500
- To: Monika Solanki <monika@dmu.ac.uk>
- Cc: "Huhns, Michael" <huhns@engr.sc.edu>, public-sws-ig@w3.org
On Saturday, November 8, 2003, at 11:10 AM, Monika Solanki wrote: > Hi Michael, > > The property that makes it special does not lie in the syntax but in > the semantics. Precondition is a property which is required to be > true, before the execution of the service. There's two aspects of a precondition, its own logical form, and the fact that it is embedded in larger conditional (effectively). So, if a precondition is that <<My Credit line is greater than 1000>>, the form of that assertion *could* just be a regular condition. and arguably should be. It's the *relationship* between that formula and the process that adds the extra semantics, much like putting a formula in the body of a rule "changes" its semantics (*if* it is co-true with the other atoms, then the consequential atoms must be true). > So there could be several formulae that could be classified as > Conditions, however if any such formula is tagged with a qualifier > that it is a precondition, it makes a difference in the interpretation > of that Condition for the execution of the service. I think having a precondition class such that it is a subclass of condition, and it is also a subclassof a someValuesFrom restriction on the inverse of hasPrecondition would be fine. Note that this means that the same "pre"condition could be used both as a precondition and as a "regular" test condition in the same composite process. If I had a conditional process: Pre: P If P then Q else R Then, assuming P isn't significantly time sensitive, I can eliminate the redundant conditioanl test and branch, since the actual behavior of the above process will be the same as Pre: P Seq: Q Cheers, Bijan "Back from Travel" Parsia.
Received on Saturday, 8 November 2003 17:17:11 UTC