Re: Preconditions /effects vs Preconditions/Postconditions

Quoting Monika Solanki <monika@dmu.ac.uk>:

> 
> Drew McDermott wrote:
> 
> >   [Charlie Abela]
> >   I wonder whether it is expected for a Web Service developer creating such
> a 
> >   service to go into such a hussle as to identify all these possible
> combinations 
> >   of pre and postconditions, effects, you name it. 
> >  
> >
> I am  not sure, when you say "Web service developer", it means :
>
> (a) The guy who is actually providing such a service and therefore also 
> providing all the models with it
> (b) The guy who has actually all the models before him and trying to put 
> them together for a specific goal.
>
I was refering to the person who is actually involved in the creation of the WS 
ontologies. So as you put it, id would be person (a). Though I would assume 
that person (b) could possibly also be involved in extending, by 
adding/combining information to some of the WS descrptions, expecially the 
process model, to create a new composed service. This task will eventually be 
handled by an agent and possibly also in an automated way. Though I think its 
still quite early to pretend that a user agent could possibly generate a new 
process model when given incomplete information.
 
> If it is (a) (which I strongly believe it is) then, I believe it is 
> necessary for him to actually identify the required parameters to ensure 
> that his service is indeed usable by other agents for whatever task - 
> discovery, composition etc.
> 
Precisely my point, he has to sit down and figure out how his service could be 
used, but given the different perspectives/background of the people involved 
and also to some extnet, the ambiguity in the definitions of what could be a 
post condition or an effect for his service, then I'd suppose he would have to 
sit down and think for some while. This can be seen in this thread, a post-
condition for someone is seen as an effect for someone else.

> >   I think the more this is complicated the less it is looked at in a
> favourable 
> >   way. I also think that there should be some way by which to say that
> given a 
> >   number of preconditions and postconditions or effects then a service can
> be 
> >   identified, and other extended information regarding such service would
> be made 
> >   available in some other location, maybe also in some repository that
> defines 
> >   general business logic.
> >
> >You've got a good point.  The major beneficiaries of a detailed model
> >of a web service are agents that want to reason about what it can do,
> >and in particular agents that want to combine it in creative ways with
> >other web services --- the "composition" problem.  Web services
> >themselves want to _prescribe_ how they are to be used; they have
> >little motivation to enable other uses.
> >  
> >
> I understand that prescribing the fact about how to use, includes 
> identifying all the details like IOPEs as well, or am I missing 
> something. I am not sure what is meant by other uses. Now whatever means 
> are used in identifying/prescribing those (provider or third party)do 
> not really matter or do they?
> 
> >I've always imagined that _third parties_ might produce more detailed
> >models of web services and get paid for keeping them up to date as the
> >services evolve.  E.g. amazon.com.com might maintain a declarative
> >model of amazon.com.
> >
> >  
> >
> I believe, it does not really matter if the service developer (provider) 
> maintians it himself or delegates it( This could be a hidden fact as 
> well). As long as the properties are available, everything should be fine.
> -- 

My suggestion was aimed at providing a developer some means by which to limit 
the development/advertising phase. I don't know if its sensible, but if in the 
DAML-S descriptions there is some way of indicating certain properties that are 
applicable to the developer's particular service, since these are by nature 
applicable to similar services, then the developer would not go into the hussle 
of defining each and every bit of these properties. If I'm not mistaken, UDDI 
registry for example, makes use of the tModel to classify services, and such a 
feature could be eventually used to also classify business logic + other 
information related to certain services, in a similar way.
An agent trying to compose a number of services will undoubtly require similar 
domain information in case it is required in the process.

> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
> Monika Solanki
> Software Technology Research Laboratory(STRL)
> De Montfort University
> Hawthorn building, H00.18
> The Gateway
> Leicester LE1 9BH, UK
> 
> phone: +44 (0)116 250 6170 intern: 6170
> email: monika@dmu.ac.uk
> web: http://www.cse.dmu.ac.uk/~monika
> **>><<**>><<**>><<**>><<**>><<**>><<**>><<**
> 
> 
> 

Charlie

-- 
Charlie Abela
Research Student,
CSAI, Department,
University of Malta

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Received on Tuesday, 16 September 2003 09:34:15 UTC