Re: Doubts about the variables in the process model of OWL-S 1.1

Manshan Lin wrote:

>hi,
>
>Here are some questions :
>(1)
>What do the variables defined by "hasLocal" and "hasResultVar" 
>mean? Existentially qualified variable? 
>  
>
Yes. Difference is Local's are scoped to whole process definition (bound 
in the precondition, used anywhere in the process definition) whereas 
ResultVar's are scoped to the result definition only (bound in the 
result condition, used in output and effect descriptions).

>(2)
>The following is from congo example's process model when defining
>the atomic process "LocateBook":
>-----------------------------------------------------------------
><process:inCondition>
> <expr:SWRL-Condition rdf:ID="BookOutOfStock">
>  <expr:expressionBody rdf:parseType="Literal">
>    <swrlx:AtomList>
>      <rdf:first>
>        <swrlx:DatavaluedPropertyAtom>
>          <swrlx:propertyPredicate
>rdf:resource="http://www.daml.org/services/owl-s/1.1/ProfileHierarchy.owl#title"
>/>
>          <swrlx:argument1>
>            <swrlx:Variable rdf:ID="#aBook" /> 
>          </swrlx:argument1>
>          <swrlx:argument2 rdf:resource="#LocateBookBookName" /> 
>        </swrlx:DatavaluedPropertyAtom>
>      </rdf:first>
>      <rdf:rest>
>        <swrlx:AtomList>
>          <rdf:first>
>            <swrlx:ClassAtom>
>              <swrlx:classPredicate rdf:resource="#OutOfStockBook" /> 
>                <swrlx:argument1 rdf:resource="#aBook" /> 
>            </swrlx:ClassAtom>
>          </rdf:first>
>          <rdf:rest
>rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" />
>        </swrlx:AtomList>
>      </rdf:rest>
>    </swrlx:AtomList>
>  </expr:expressionBody>
> </expr:SWRL-Condition>
></process:inCondition>
>-----------------------------------------------------------------
>
>What does the variable "#aBook" mean?  Universally qualified variable?
>  
>
No, it is an existentially quantified variable. The condition says that 
there exists a book with the given name and it is not in the stock.

>(3)
>The following is from congo example's process model when defining
>the composite process "SignInAlternatives":
>-----------------------------------------------------------------
>- <process:hasResult>
>- <process:Result>
>- <process:inCondition>
>- <expr:SWRL-Condition rdf:ID="SignInAlternativesAcctExists">
>  <rdfs:label>hasAcctID(SignInAlternativesSignInData,
>SignInAlternativesAcctID)</rdfs:label>
>  <rdfs:comment>If an account already exists, sign-in operation will
>be performed and returned acct ID willbe used</rdfs:comment>
>  <expr:expressionLanguage
>rdf:resource="http://www.daml.org/services/owl-s/1.1/generic/Expression.owl#SWRL"
>/>
>- <expr:expressionBody rdf:parseType="Literal">
>- <swrlx:AtomList>
>- <rdf:first>
>- <swrlx:IndividualPropertyAtom>
>  <swrlx:propertyPredicate rdf:resource="#hasAcctID" /> 
>  <swrlx:argument1 rdf:resource="#SignInAlternativesSignInData" /> 
>  <swrlx:argument2 rdf:resource="#SignInAlternativesAcctID" /> 
>  </swrlx:IndividualPropertyAtom>
>  </rdf:first>
>  <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" /> 
>  </swrlx:AtomList>
>  </expr:expressionBody>
>  </expr:SWRL-Condition>
>  </process:inCondition>
>- <process:withOutput>
>- <process:OutputBinding>
>  <process:toParam rdf:resource="#SignInAlternativesAcctID" /> 
>- <process:valueSource>
>- <process:ValueOf>
>  <process:theVar rdf:resource="#SignInSequenceAcctID" /> 
>  <process:fromProcess rdf:resource="#SignInSequencePerform" /> 
>  </process:ValueOf>
>  </process:valueSource>
>  </process:OutputBinding>
>  </process:withOutput>
>  </process:Result>
>  </process:hasResult>
>-----------------------------------------------------------------
>
>I notice that "#SignInAlternativesAcctID" is an output parameter of 
>the process "#SignInAlternatives". However, it occurs in the condition
>of the output. How to evaluate this condition before execution? 
>  
>
You cannot always evaluate the result conditions before execution. 
Sometimes you need to execute the service, get the result back and then 
evaluate the condition (e.g. you cannot know if a book is in stock or 
not without executing the service). However, in this example, you might 
already have the information in your KB about the account ID associated 
with the SignInData. Then looking at the result description you can 
infer that service will not create a new service but simply return the 
existing account ID.

>(4) The last question is not related with variables:
>I still can't understand the "Choice" structure. What's the criteria
>of choosing the execution branches in it? Is it up to the agent? 
>  
>
One criteria is choosing the component whose precondition is true. 
Depending on the current state of the world some of the choices may not 
be usable. If there is more than one executable choice then you would 
probably want to choose based on some other features, i.e. response 
time, cost, reliability, etc.

Regards,
Evren

Received on Thursday, 6 January 2005 01:33:39 UTC