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

Hi Ian -

To Drew's comments in a previous response, I would add just a bit (see
below) -

"Dickinson, Ian J" wrote:
> 
> Folks -
> 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.  

This is an excellent question, about a basic issue.  The DAML-S team has
had an ongoing discussion about this issue - do we want to represent a
process as an instance of some class of processes, or as itself a class
(of specific uses of the process)?  We chose the latter, on the grounds
that it's conceptually cleaner and can also lead to more extensive use
of ontology-based reasoning.

Our first impulse is to think of a process as an instance.  When we
write a procedure in some programming language, we think that our code
specifies a single thing (the procedure), so it's natural to think that
it's an instance of some class of procedures.  But it's equally valid to
think of a procedure as a *class*, each instance of which is a *use* of
the procedure.  I can call the procedure with arguments a, b, c, and
think of that invocation of the procedure as a different instance than a
call of the procedure with arguments d,e,f.  That's the way we are
thinking about a process - as a class of potential uses/invocations.  

A specific use of, say, CongoBuy, can be represented as an instance of
CongoBuy, in principle.  When your software agent sends a request to buy
War and Peace from Congo, that implies the creation of such an
instance.  As to whether each such invocation would ever be spelled out
in its full detail as an instance, DAML-S doesn't specify; that may
depend on particular tools and implementations that use DAML-S.   

There's some mention of this issue here:

http://www.daml.org/services/daml-s/2001/05/rationale.html

(under "Level of instantiation"), with a link to some earlier www-ws
discussion of it.

I hope this is reasonably clear.

Regards,

- David

> Similarly:
> 
> <rdf:Property rdf:ID="congoBuyCreditExistsPrecondition">
>   <rdfs:subPropertyOf rdf:resource="&process;#precondition"/>
>   <rdfs:domain rdf:resource="#CongoBuy"/>
>   <rdfs:range rdf:resource="#CreditExists"/>
> </rdf:Property>
> 
> says that there can be statements relating instances that are CongoBuy's to
> instances that are CreditExists, and that the set of pairs that define
> 'congoBuyCreditExistsPrecondition' is a subset of the set of pairs that
> define 'precondition', but not that a given CongoBuy service has the
> precondition that CreditExists.
> 
> I could use all this information to *validate* any RDF data I could find
> that described one or more CongoBuy services, but I don't see how I could
> find Congo and actually buy a book without some instance data.
> 
> Equally plausibly, I've completely missed the point :-)   All comments
> welcome.
> 
> Thanks,
> Ian

Received on Wednesday, 28 November 2001 03:06:44 UTC