DAML-S Design Rationale and Outstanding Issues

DAML-S Design Rationale and Outstanding Issues

This informal working document is meant to provide conceptual background regarding decisions that have been made with respect to DAML-S, and also regarding outstanding issues that have yet to be resolved.

Feedback to [email protected], please.

Contents:

The Upper Ontology

Relationship between properties of profiles and processes

The ontology provides for describing certain key properties of a service -- such as inputs, outputs, preconditions, and effects -- both as part of a service's profile and as part of its process model.

Question: Is there some clear-cut relationship, which should be formalized in the ontology, between each of these properties in the profile and the corresponding property in the process model?

This question has not yet been fully resolved.

Process Models

Level of instantiation

The following general principle has been adopted:
In DAML-S, a process is described using CLASSES; a particular USE/EXECUTION of a process is described using INSTANCES.

See also: the thread headed Instantiating a DAML-S Process on [email protected].

Multi-party processes

We recognize the importance of specifying processes with multiple participants, and we intend to evolve the process model to incorporate explicit representations of roles, so as to support such processes.

However, the present process model is inherently (and implicitly) a "2-party" model. For instance, inputs are (implicitly) provided by the requester to the provider of a service. This has been done for simplicity; because it allows us to draw on various familiar conceptual models such as "client/server", "requester/provider", and "caller/callee"; and because it allows for a more compact means of representing commonplace 2-party processes, such as those involving only a buyer and a seller.

The present version of the process model, then, may be thought of as a special case, with simplifying assumptions, of the more general model to come.

Specifying communications (messages)

A Web-based service description must fully specify the messages that are to pass between services participants during the execution of the service -- not only the individual messages, but also the various sequences of messages that can occur.

The present model makes simplifying assumptions about messages, which are closely related to the simplifying assumptions (mentioned above) regarding 2-party processes. To wit: inputs (input properties) to a (non-composite) process specify messages that flow from the service requester to its provider (at the invocation of the process), whereas outputs (output properties) specify messages that flow from provider to requester (at the termination of the process).

As we evolve to a multi-party process model, we intend to evolve the model towards a more explicit representation of messages and conversation policies.

Relationship between the properties of a composite process and its subprocesses

Question: Does a composite process have "its own" inputs (outputs, preconditions, effects)?

Question: How should the inputs (outputs, preconditions, effects) of a composite process be characterized? Should they be developer-specified, or automatically generated according to some precise definition of their relationship to the subprocesses' inputs (outputs, preconditions, effects)?

Relationship between the atomic and composite forms of a process

Provisional characterization: The atomic and composite forms of a process are representations at 2 different levels of granularity. Both are invocable. Executing the atomic form never requires any additional inputs nor generates any other outputs than those specified, except perhaps in exceptional cases (error conditions). "Missing" inputs (those specified for the composite, but not for the corresponding atomic process) are either inapplicable, or assume default values, in the execution of the atomic process (but currently these aren't specified anywhere).

This relationship is roughly analogous to the relationship between a "one-step" path and the complete path through a purchase on a B2C Web site.

Relationship between properties of the atomic and composite forms of a process

Question: Is there some clear-cut relationship, which should be formalized in the ontology, between the the inputs (outputs, preconditions, effects) of the atomic form of a process, and those of its composite form?

This question has not yet been fully resolved.

Expressiveness of the Base Language

Parameter passing

(binding/assignment/unification of process inputs and outputs)

See also: the thread headed DAML-S Expressiveness Challenge #1 on www-rdf-logic.

The following is excerpted from the first message of that thread: 

Imagine we want to describe the following subprocess (part of a larger
process on some B2C web site), expressed here in a logic programming
style:

    chargePayment(Amount) :-
        getCreditCardNumFromUser(CCNum),
        postCharge(CCNum, Amount).
        
What we want to express in DAML+OIL (or DAML-L, when available) is
analogous to what the repeated use of CCNum expresses.  That is, it
restricts the 1st argument input value of postCharge to be identical to
the output value of getCreditCardNumFromUser, when an instance of this
procedure executes.

In DAML-S, there is a top-level Process class, which has an input
property and an output property.  For this example, both
getCreditCardNumFromUser and postCharge are declared as subclasses of
Process, and their inputs (outputs) are declared as subproperties of
input (ouput).  Something like this (simplifying and omitting details):

PREREQUISITE INFO:
  In DAML-S, a process is described using CLASSES; a particular 
  USE/EXECUTION of a process is described using INSTANCES.

    <!-- GIVEN:
          chargePayment is a subclass of Sequence 
                (and Sequence is a subclass of Process)
          An instance of chargePayment is constrained to have an
          instance of getCreditCardNumFromUser as its first element,
          and an instance of postCharge as its second element -->

    <Class ID=getCreditCardNumFromUser>
        <subClassOf Process> .....

    <Property ID=ccNumOutput>
        <subPropertyOf output>
        <domain getCreditCardNumFromUser> ....

    <Class ID=postCharge>
        <subClassOf Process> .....

    <Property ID=ccNumInput>
        <subPropertyOf input>
        <domain postCharge> ....

    <!-- DESIRED CONSTRAINT GOES HERE, and says something like:
           "when ccNumInput and ccNumOuput are instantiated within the
            same instance of chargePayment, they have the same value"
    -->

Defining composite processes by restricting their subprocesses

See also: the thread headed DAML-S Expressiveness Challenge #2 on www-rdf-logic.