Re: [OWL-S] arguments for PAI and PAC

   [Mike Pool]

   I guess my remaining question concerns the extent to which moving
   to PAI solves rather than just ignores this representational
   problem.  Despite moving to a "classless" system, isn't the above
   (i.e., your sentence, "In every execution trace of ...")  still
   what one is trying to communicate in one's representational
   language?  Even if the process language uses instance-level
   prototypes, in the end the user must recognize that the information
   contained therein is equivalent to what you've suggested above, no?

I posted some stuff on the formal semantics of DAML-S to www-ws@w3.org
recently, and of course you're right --- processes do denote execution
traces, more or less, in that semantics.  (Someone else may find a
better one in which they denote something else.)

The question is whether it's a good idea to expose the semantics via
DL-style classes.  It seemed like a good idea at the outset --- why
not? --- but DL's put strong limits on expressiveness in order to
retain decidability.  Having gained the ability to talk about
execution traces explicitly, we found we had lost the ability to do a
lot of other things easily or at all.  Then it turned out that we
never actually wanted to talk about execution traces.  It would have
been just fine to leave them in the semantics.  On top of that, in a
system where processes are individuals, if we ever need to talk about
execution traces, we can use a role (traceOf, or whatnot) to say "This
individual, trace TR, is an execution trace of that individual,
process PR."

It's scary reversing a design decision seemingly so deeply embedded in
the system, but it turned out to be surprisingly easy, partly because
that very design decision had kept the system "shallow" in lots of
places; there wasn't that much to uproot.

   In other words, if in a PAI approach I say, "the output of step 3
   is in the input to step 5" I really mean "whenever (for all) an
   instantiation/execution trace of the process occurs, the output of
   the third step is the input for the fifth step" ...

Yes.

   ...and whichever system I'm using that implements this process
   description must recognize this.

No.

Well, it depends on what you mean by "recognize."  Does a Fortran
compiler "recognize" the formal semantics of Fortran?  Only
implicitly, where by "implicitly" I mean something like this:

 Notation processor P implicitly recognizes the semantics of notation
 N if, whenever P infers expression B (in notation N) from A (in
 notation N), it must be the case that the semantics says that B is
 true whenever A is true.

"Infers" can probably be generalized here, but you get the idea.  The
person who _wrote_ P must "recognize" the meaning of N, but P doesn't
have to in any sense except being correct. 

-- 
                                             -- Drew McDermott
                                                Yale Computer Science Department

Received on Tuesday, 16 September 2003 09:16:11 UTC