Re: DAML-S v1.0 - syntax, semantics and corectness

It came to my attention (ok, in the AAAI symposium session, Ion 
specifically mentioned this fact :)), that this email was posted 
several times in various fora and not gotten a response from any OWL-S 
folks. Sorry, we get swamped. Also, let me say that this is a big and 
chunky email with lots of stuff in it. That makes it go lower on my 
stack. Oh well.


On Nov 21, 2003, at 5:51 AM, Ion Constantinescu wrote:

> Hi there,
>
>  I have already posted the email below but got as only comment the 
> fact that I should submit it maybe to this mailing list :) Sorry if 
> you already got this email.
>
>  After reviewing the beta version of DAML-S v1.0 and I would like to 
> raise some issues and propose some solutions.  In summary they 
> concern:
>  1. syntax of parameter descriptions - what kind of information should 
> they specify (e.g. typing only or something extra, like roles) ?
>  2. semantics of parameter descriptions - what the encoding 
> information represents and what kind of relations can we infer between 
> parameter descriptions (e.g. when two different parameter descriptions 
> are "plugIn" compatible and based on that what types of matches can we 
> define between given service Profiles).
>  3. consitency constraints - how should correct service descriptions 
> look and what kind of constructs should be avoided (e.g. there should 
> not be parameters ambigously defined) ?
>
>  1. As specified by the DAML-S rationale  document (specifying 
> communication), the interactions between web services are defined 
> trough the messages that those web services exchange. In DAML-S the 
> input and output parameters of a web service should describe the 
> respective input and output message that the service could 
> receive/send.

I, personally, don't believe this last bit. In fact, in general, I'd 
like a bit more abstraction than that.

>  Following the above it is straight forward that the same message and 
> obviously the parameters forming it will play at different times 
> different roles - first they will be outputs of the sending service 
> then they will be inputs for the receiving service.

This is, of course, true whether we're talking messages or values, so 
we might want to separate out these issues.

>  Issue (1.1.) - why should parameter descriptions commit to a 
> particular kind of interaction (input/output or precondition/effect)

Is a precondition or effect a *kind* of interaction between services? 
(I guess an effect *could* be, e.g., one effect of process A calling 
process B is that process B kills process A, but that's not 
*essentially* part of the notion of effect; it just falls out from the 
fact that processes are in-the-world to be affected.)

> at their definition when this will actually depend on their binding to 
> particular service (e.g. parameter p1 is an output for service s1 BUT 
> also and input for s2) ?

The formal parameters are distinct. I.e., I'm an output *parameter* of 
process A. In a particular sequence, there might be a data flow from 
this output parameter to an input parameter of B. Thus, in an 
execution, the value which is bound to the output parameter of A will 
be passed to B by being output to that input parameter. The 
*parameters* aren't passed! So, it seems you are confusing the formal 
parameters (and their descriptions) with the values of those parameters 
in certain situations.

>  Messages are defined as sets of parameters.

Huh? Not by me. :) And not clearly in what you said above.

> So a parameter description should provide two kind of informations: 
> information used for specifying the possible values of a given 
> parameter (the parameter type) and information used for disambiguating 
> between parameters, especially between those that have the same type 
> (the parameter role).

Now you've totally lost me.

>  Issue (1.2) - what kind of representation should parameter roles have 
> and to what should they be bind (since in DAML-S v0.9 both a 
> parameterName and reffersTo fields could have been used for that

But these are totally unrelated.

[snip]

Sorry, not following the rest of the discussion of this. I think we 
need to resolve how we're using the term "parameter".

Cheers,
Bijan Parsia.

Received on Tuesday, 23 March 2004 02:42:04 UTC