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

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) <http://www.daml.org/services/owl-s/1.0/rationale.html>, 
the interactions between web services are defined trough the messages 
that those web services exchange. 
<http://www.daml.org/services/owl-s/1.0/rationale.html> 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.

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.

Issue (1.1.) - why should parameter descriptions commit to a particular 
kind of interaction (input/output or precondition/effect) 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) ?

Messages are defined as sets of parameters. 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).

Issue (1.2) - what kind of representation should parameter roles have 
and to what should they be bind (since in DAML-S v0.9 
<http://www.daml.org/services/daml-s/0.9/> both a parameterName and 
reffersTo fields could have been used for that and we argue that the 
representation proposed in DAML-S v1.0 
<http://www.daml.org/services/owl-s/1.0/> that mixes the naming of the 
parameters with the definition of their roles could lead to ambiguities) ?

Proposed solution
-------------------

The solution that we propose is to use a mix between DAML-S v0.9 
<http://www.daml.org/services/daml-s/0.9/> ParameterDescriptions and 
DAML-S v1.0 <http://www.daml.org/services/owl-s/1.0/> direct properties:
- self-contained ParameterDescription(s) should define parameters as 
pairs of parameter roles / parameter types
- services profiles should bind a ParameterDescriptions to particular 
kind of usage (e.g. input/output or precondition/effect).

This is also closer to the spirit of WSDL where Parmeter(s) form 
Messages that are bound for each particular service as either inputs or 
outputs.

An alternative solution was proposed in DAML-S v1.0 rationale 
<http://www.daml.org/services/owl-s/1.0/rationale.html#expressiveness> 
and is to specify extra constraints that would link different inputs and 
outputs (e.g. p1 output of s1 is always equal to p2 output of s2). Our 
solution will limit you in doing that BUT will also solve in a simple 
way the case that will  probably occur the most (the inputs and outpus 
of two services should match).


Example
---------
A re-visit to the Congo example proposed with  the v0.9 of the 
specification would like the following:

    <!-- a parameter description SHOULD NOT be linked to a particular 
service and SHOULD NOT commit to a particular kind of usage e.g. 
input/output -->

  <profile:ParameterDescription rdf:ID="SignInInfo"> 
        <!-- no flat/string parameter name -->

 
	<!-- parameter role - very useful for disambiguating between parameters with same type -->
        <profile:restrictedTo rdf:resource="&congoProcess;#SignInData"/>

        <!-- parameter type - what values could the parameter have -->
        <profile:refersTo rdf:resource="&congoProcess;#signInInfo"/>

  </profile:ParameterDescription>

  <!-- the parameter role SHOULD NOT commit neither to a particular service nor to a particular kind of usage -->
  <rdf:Property rdf:ID="signInInfo">

    <-- SHOULT NOT extend input/output ; possibly use as parent an existing ontology - here authentication_ontology -->
    <rdfs:subPropertyOf rdf:resource="&authentication_ontology;#authData"/>

    <!-- they could use Process as their domain - in the case of roles expressed as properties -->
    <rdfs:domain rdf:resource="&process#Process"/>

    <rdfs:range rdf:resource="#SignInData"/>
  </rdf:Property>


     <!-- the service profile SHOULD specify the membership of a 
parameter and the role of the parameter (input/output or 
precondition/effect) in the frame of the service -->

  <profileHierarchy:BookBuyingAgent>
    <profile:output> 
      <profile:ParameterDescription rdf:REFID="#SingInInfo" /> 
    </profile:output>	
  </profileHierarchy:BookBuyingAgent>

  <profileHierarchy:BookSelling rdf:ID="Profile_Congo_BookBuying_Service">
    <profile:input> 
      <profile:ParameterDescription rdf:REFID="#SingInInfo" /> 
    </profile:input>	
  </profileHierarchy:BookSelling>


2. Parameter semantics. As stated in the charter of DAML-S the language 
should enable the automatic discovery and composition of web services. 
Still for doing that we need strong semantics regarding the 
compatibility of messages that services can produce/consume and 
equivalently strong semantics regarding the compatibility between 
different parameters that form those messages.

Following from the solution proposed above at 1.  which is to define a 
service as a set of ParameterDescription role/type tuples we can define 
"plugIn" compatibility between two parameter descriptions that have the 
same kind of usage (e.g. input/output). Usually one parameter will be 
introduced by  an existing service (implementation) and the other will 
be introduced by a discovery or composition query (specification). A 
plugIn relation should identify the existing parameters (implementation) 
that could be directly used instead of the parameters requested by the 
query (specification). Of course other types of partial matches (e.g. 
"subsume" or "overlap") can also be defined but we focus for now on 
"plugIn" since it's going to be probably the most frequently used.

PlugIn parameter compatibility:
- a query (specification) and a service (implementation) parameters 
having the same kind of  "input" usage are "plugIn" compatible if:
    - the query parameter role construct subsumes (is more general) the 
service naming construct (the service parameter is-same-kind as the 
query paramter)
    - the service parameter type subsumes the query paramter type (the 
atcual service takes at least all possible values that the query could take)
- a query (specification) and a service (implementation) parameters 
having the same kind of "output" usage are "plugIn" compatible if:
    - the query parameter role subsumes (is more general) the service 
naming construct (the service parameter is-same-kind as the query paramter)
    - the query parameter type subsumes the service paramter type (all 
the outputs produced by the atcual service can be handled by what the 
the query could take)

Based on the previous we can also define how two profiles (query and 
service) can be in a "plugIn" match relation:
- for all service inputs parameters there is a query input parameter 
that is "plugIn" compatible
- for all query output parameters there is a service output parameter 
that is "plugIn" compatible

3. Consistency constraints could be specified and used for verifying the 
corectness of service desciptions. Several kind of constraints could be 
defined but here we provide only two basic ones to serve  as a 
placeholder for other possible ones:

Role Ambiguity Constraint - a service description SHOULD NOT contain 
parameters (either inputs or outputs) that can be ambigously 
interchanged - should not contain parameter roles in a subsume/subsumed 
relation (e.g. p1 has name n1 and p2 has name n2 where n1 subsumes n2).

Parameter Redundancy Constraint - a service description SHOULD NOT 
define as outputs any of the parameters that it receives as inputs. This 
is due to the fact that if the same parameter appears as input and as 
output the service can behave in two way, neither very good:
- either it will produce as output the same value it received has 
already received for the input in which case the parameter will be 
redundant since the invoking agent already knows the input
- or it will produce as output a different value for the same parameter 
that it has as input in which case the service will be incorrect and the 
semantics of the parameter description will have been badly  interpreted

In conclusion I would advocate for a better syntactic description of 
service parameters as role/type tuples, for better semantics regarding 
profile compatibility and last but not least for better formal ways of 
expressing and checking the correctness of service descriptions trough 
consitency constraints.

thank you for your time,
ion