Re: Preconditions /effects vs Preconditions/Postconditions

>
>
>  
>
>>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.
>  
>
You have just answered the question. This ambiquity is precisely what 
has to be tackled. Looking at the plethora of  service description 
languages available and considering the fact that none of them define 
clearly and precisely what these parameters (especially pre and post 
conditions) are suppose to be, it would indeed involved thinking. If we 
can simplfy this thinking process a bit by some means for the various 
definitions for all these properties, I think it would help everyone 
(requestor, provider). There could be for example a mediation service 
(which could benefit from such an effort) which could be responsible for 
mapping the semantics for a service described in one language to that 
described in another language for another service maybe for composition.

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

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