Re: DAML-S 0.6: use of classes vs instances

   [Ian Dickinson]
   A Jena user asked a question about Jena support for DAML-S, and pointed me
   at the latest version of the specs on
   http://www.daml.ri.cmu.edu/ont/DAML-S/Release0.6/. Since I wasn't familiar
   with the details of DAML-S, I've spent a little time trying to get up to
   speed.  I'm sure I'll have a number of questions, but one leaps right out at
   me from reading the Congo and Bravo Air examples.

   In essence it is this: where's the data?

   To be more precise, I notice that all of the definitions are for DAML
   classes and properties. Nowhere are instances defined, or actual RDF triples
   giving the properties of the instances. So when congo.daml says:

   <daml:Class rdf:ID="CongoBuy">
     <rdfs:subClassOf rdf:resource="&process;#AtomicProcess"/>
   </daml:Class>

   this tells me that there is a DAML class CongoBuy, all instances of which
   are also instances of AtomicProcesses, but it doesn't tell me that there is
   an individual CongoBuy service that I can interact with.  

DAML-S is describing process classes.  The individual elements of the
class are the actual actions involved.  Suppose I described buying
a Coke as a DAML-S CompositeProcess, with two 'components',
PutInNickel and TakeOutCoke (if you find a machine that behaves like
this, let me know).  What I mean is that any instance of BuyACoke
consists of two parts, each of which is an intance of PutInNickel and
TakeOutCoke.  But you won't see any actual instances until you get
down to particular stories, i.e., particular occasions when someone
put in a nickel and got out a Coke.  It's a bit like
programming-language semantics, where one might define ";" by saying
"An event is of type "s1;s2" if and only if it consists of two
consecutive events, the first of type s1 and the second of type s2."

That answers part of the "where's the data" question.  The other is,
how (or where) are actual services described.  This is more a job for
the Service and Profile parts of DAML-S.  Here are the basic
declarations: 

  <rdfs:Class rdf:ID="Service">
    <rdfs:label>Service</rdfs:label>
    <rdfs:comment>Top Level Service</rdfs:comment>
  </rdfs:Class>

  <rdfs:Class rdf:ID="ServiceProvider">
    <rdfs:label>ServiceProvider</rdfs:label> 
    <rdfs:subClassOf rdf:resource="#Actor" /> 
    <rdfs:comment>
      ServiceProvider provides general contract details such as address, fax etc.
    </rdfs:comment>
  </rdfs:Class>

You would instantiate a particular Service by writing

   <daml-s:Service ID="CokesForNickels"/>

A Service is an entity accessible through the internet (by ways
specified in its grounding).  A ServiceProvider is a legal agent
(perhaps "Cheap Drinks R Us") that undertakes to keep one or more
Services going.

If I've made an ontological error, and I probably have, I'm sure
someone else in the DAML-S group will correct me.

                                             -- Drew McDermott

Received on Tuesday, 27 November 2001 18:04:08 UTC