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

Hi,
 
>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).

Local is a variable used just for AtomicProcesses and that is scoped to the whole process definition. But does it include the precondition? If it does, it can also be used in the result, correct? But only if it's used in precondition, because if it's not, we can not reference it in the result. ????
 
Talking again about parameters, what is the purpose of hasParameter? Congo process and BravoAir process don't have this type of property and I didn't understand it. Aren't hasInput and hasOutput enough for a process description?
 
Thank you again, again, again...
 
Tatiana.
 


Evren Sirin <evren@cs.umd.edu> wrote:

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":
>-----------------------------------------------------------------
>

> 
> 
> 
> 
> 
> >rdf:resource="http://www.daml.org/services/owl-s/1.1/ProfileHierarchy.owl#title"
>/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" />
> 
> 
> 
> 
> 
>

>-----------------------------------------------------------------
>
>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":
>-----------------------------------------------------------------
>- 

>- 

>- 

>- 
> hasAcctID(SignInAlternativesSignInData,
>SignInAlternativesAcctID)
> If an account already exists, sign-in operation will
>be performed and returned acct ID willbe used
> >rdf:resource="http://www.daml.org/services/owl-s/1.1/generic/Expression.owl#SWRL"
>/>
>- 
>- 
>- 
>- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

>- 

>- 

> 


>- 

>- 

> 


> 


> 

> 

> 

> 

> 

> 

>-----------------------------------------------------------------
>
>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


		
---------------------------------
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador do Yahoo! agora.

Received on Thursday, 6 January 2005 21:35:10 UTC