Thanks for raising a couple of good questions/issues about DAML-S.  I'll answer the first one (and just touch on the second) in this message.

David Buttler wrote:

Hi,

I have a question regarding how to specify a DAML-S process.
In my understanding, DAML-S is based on DAML+OIL.
In the document titled "Annotated DAML+OIL (March 2001) Ontology
Markup", there is an example of defining a Person class.  Then, near the
end of the document, there are several example Persons instantiated.
The example Persons use the definition of a Person in DAML-S.
e.g. part of the definition is as follows:

<daml:Class rdf:ID="Person">
   <rdfs:subClassOf rdf:resource="#Animal"/>
...
</daml:Class>

An instantiation looks like this:
<Person rdf:ID="Ian">
  <shoesize>14</shoesize>
  <age>37</age>
  <shirtsize><xsd:string ref:value="12"/></shirtsize>
</Person>

However, a DAML-S process seems to work differently.  The definition,
defined in Process.daml, (and which looks almost exactly like the Person
definition) starts like this:

<rdfs:Class rdf:ID="Process">
  <rdfs:comment> A simple process class </rdfs:comment>
  <rdfs:subClassOf
rdf:resource="http://www.ai.sri.com/~daml/ontologies/services/1-0/Service#ServiceModel"/>

</rdfs:Class>

But then the example looks like this (CongoBuy):

<rdfs:Class rdf:ID="CongoBuy">
  <rdfs:subClassOf
rdf:resource="http://www.ai.sri.com/daml/ontologies/services/1-0/Process.daml#Process"/>

</rdfs:Class>
....

It looks as if CongoBuy is a kind of a Process.  I was expecting that it
would be an instantiation of a Process.  Is it just me, or is that
somewhat inconsistent?  What fundamental piece of DAML-S am I missing?
 

Our answer is the latter; that is, that an instance represents a particular use of a service.

Thus, in an example such as Congo, which specifies how some service works, you won't see instances.  Instances will occur when the service is actually used (at runtime, if you like).  That is, when a service is used, one can imagine an instance (of CongoBuy, in this case) being generated to represent that use.  Indeed, we do imagine such instances being generated and used, at runtime (perhaps as an aid in executing or in monitoring the progress of the service use).  A couple of the main advantages of this approach are:

(A1) It allows for a natural way of representing a specific use of a service (that is, as an instance of some subclass of Process), that can be reasoned about, type-checked, etc., in the same conceptual framework as that in which the services are declared.

(A2) It allows for the fullest and most natural use of DAML+OIL typing mechanisms.  For example, if subprocess ValidateCreditCard has an input called creditCardNumberSubmitted, of type CreditCardNumber, it's in the spirit of DAML+OIL to declare that like this:

a) Class ValidateCreditCard is a subclass of class Process (or, more likely, a descendant class several generations removed);
b) Property creditCardNumberSubmitted is a subproperty of property "input" (which is defined in DAML-S with Process as its domain);
c) creditCardNumberSubmitted can be used with ValidateCreditCard as domain, and CreditCardNumber as range

On the other hand, if ValidateCreditCard were to be declared as an INSTANCE, that breaks the natural chain of inheritance in specifying the inputs of ValidateCreditCard (and their types), and makes it more cumbersome to do so.

It is true there are some disadvantages to this approach; among them are:

(D1) It is apparently less intuitive for many or most of us, at least on first blush (as you can attest).

In particular, for those accustomed to writing procedures in ordinary programming languages, like C, it's not familiar to declare a procedure as a class.  But I would claim that, while it's not made explicit in code,  it is nevertheless perfectly reasonable to conceptualize a procedure as a class of execution instances, and moreover, that it's not unusual to think of it that way, at some level, when we are reading and thinking about program code.

(D2) It means that the important relationships between subprocesses must be specified using constraints, rather than instantiation.  For example, you want to say that process ValidateCreditCard performs the following sequence: first, it compares the credit card number to a local database, and second, it sends the number to a national database for verification.  In our approach, this must be specified using CONSTRAINTS on the class Sequence.  In effect, you must say something like this:

   When Sequence is instantiated as part of an instance of the ValidateCreditCard process, its first element must be an instance of (say) CheckLocalDb, and its second element must be an instance of (say) CheckNationalDb (both of which are also processes).

I claim that this way of expressing things is perfectly reasonable to think about (once you're gotten used to it), BUT unfortunately, can be rather ugly to express in DAML+OIL.  It may be, and it's my hope, that some "syntactic sugar" will be developed to smooth things over.

(Finally, note that what I've just said about specifying relationships between subprocesses as constraints, I believe, provides at least a partial answer  to your second question (which I haven't copied in this message).  If there's more to be said about that, I or one of my DAML-S colleagues will generate an additional message.)

Regards,

-- David Martin