W3C home > Mailing lists > Public > www-ws@w3.org > June 2004

Re: OWL-S process preconditions

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Fri, 18 Jun 2004 11:07:04 -0400 (EDT)
Message-Id: <200406181507.i5IF74Nv026970@pantheon-po01.its.yale.edu>
To: www-ws@w3.org, public-sws-ig@w3.org


> [Donal Murtagh]
> My understanding is that OWL-S does not currently mandate any language for
> expressing preconditions, although the current frontrunner is SWRL. 

The current frontrunner is to represent conditions as literals, either
XML literals or some other kind.  An attribute of a condition is its
logical language.  Example:

   <owls:AtomicProcess>
      <owls:hasPrecondition>
	<owls:Expression expressionLanguage="&swrl;#SWRL"
	                 rdf:parseType="Literal">
           <ruleml:body rdf:parseType="Collection">
	      <swrl:individualPropertyAtom>
		 <swrl:propertyPredicate rdf:resource="creditCardAuth"/>
		 <swrl:argument1 rdf:resource="#cc"/>
		 <swrl:argument2 rdf:datatype="&xsd;#string">Yes</swrl:argument2>
	      </swrl:individualPropertyAtom>
           </ruleml:body rdf:parseType="Collection">
	</owls:Expression>
      </owls:hasPrecondition>
   </owls:AtomicProcess>

The reason to use literals is to "hide" the RDF from the main RDF
parser.  What a knowledgeable Owl-S parser must actually do is
re-parse the hidden RDF chunks later, when it's possible to do
appropriate substitutions.  In the example above, the
individualPropertyAtom is not really about the variable "#cc"; it's
about the _value_ of that variable in some context.  When that value
is available, the RDF can be reprocessed to yield a statement about
the authorization status of that credit card.

> My own
> view of preconditions is that they amount to a test which evaluates to
> either true or false.

This depends on what you mean by "evaluates to."  The question is
whether a precondition is supposed to be an executable spec or a
metaphysical statement.  In the latter case, the meaning is that (an
attempt to peform) the action will have undefined consequences if the
precondition is false, regardless of wheter the agent attempting it
knows whether it is false.  I think this is the correct reading, but
you probably don't.

> For example, assume we have a book-buying process which takes an input
> CreditCardDetails (among others) and has a precondition CreditCardValid.
> Evaluating the truth of this precondtion could (for example) involve testing
> whether the credit card number has the correct format and whether the expiry
> date is later than the current date. In order to perform this test we need 3
> pieces of information:
> 
> 1.    credit card number
> 2.    expiry date
> 3.    current date
> 
> The first two could be characterised as 'external' in that they are provided
> by the user/agent invoking the process via the input parameter
> CreditCardDetails. Is it true to say that all such external information
> required to test a precondition must be obtained from the process' inputs,
> or can one assume that other information sources are available?

I will let someone else take a crack at answering this one.

> 
> My second question is about how to express such a precondtion via SWRL. The
> most common use for SWRL rules seems to be moving property values from one
> individual to another, e.g. hasParent(?x1, ?x2) ^ hasBrother(?x2, ?x3) =>
> hasUncle(?x1, ?x3) adds a hasUncle property to the object bound to ?x1, the
> range of which is ?x3.
> 
> But how should one express a precondition such as described above in SWRL
> syntax? Assuming CreditCardDetails has properties which provide the
> necessary information (e.g. CreditCardNumber, ExpiryDate), then presumably
> these could be used in conjunction with the SWRL built-ins to establish the
> truth of the precondition, buth what would appear as the consequent (RHS) of
> the rule?

The trick, as in my example above, is to use rules without
consequents, i.e., detached rule bodies.  The consequent ("the action
is feasible") is implicit.

-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.
Received on Friday, 18 June 2004 11:07:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:45 GMT