- From: Drew McDermott <drew.mcdermott@yale.edu>
- Date: Thu, 15 May 2003 10:19:23 -0400 (EDT)
- To: sambrosz@ipipan.waw.pl
- CC: public-ws-chor@w3.org, drew.mcdermott@yale.edu
Date: Wed, 14 May 2003 19:50:03 +0200 (CEST)
X-PH: V4.4@mr1
From: Stanislaw Ambroszkiewicz <sambrosz@ipipan.waw.pl>
Reply-To: Stanislaw Ambroszkiewicz <sambrosz@ipipan.waw.pl>
Content-MD5: IjulhG3xHeV/kiRPRGW5hA==
X-YaleITSMailFilter: Version 1.0c (attachment(s) not renamed)
The crucial point is to start the process from the very roots, i.e.,
from the really primitive concepts and to specify explicitly
the abstraction rules.
I did some practical (however, still initial) work towards this direction;
see the documentation at http://www.ipipan.waw.pl/mas/enTish
I'll check it out.
As to DAML-S, one still missing point (IMO, the crucial one)
is the definition of well formed formulae to express precondition
and effect of service invocation.
We do provide a proposal (in an appendix) for how to add these. The
reason the proposal is tentative is that we wanted to stay within RDF,
and you simply can't do that without stretching the framework at some
point. Our proposal is to indulge in a little reification, which
means that an ordinary RDF processor will miss the formulas. (And
that the encoding of the formulas is rather obese.)
IMO, precondition and effect formula together may (should!)
serve for expressing the complete type of a service, i.e., also
service interface.
I agree.
--
-- Drew McDermott
Received on Thursday, 15 May 2003 10:19:30 UTC