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

At 03:21 PM 9/15/2003 -0400, Drew McDermott wrote:


>Sorry for long delay in replying.
>
>   [Mike Pool, 2003-08-23]
>
>   I've been following this discussion [on classes vs. instances for
>   DAML-S] with some interest because the DARPA Evidence Extraction
>   and Link Detection DARPA Program has been working on a pattern
>   specification language, EPSL, and we have wrestled with similar
>   issues.  I'm copying the group working on writing the EPSL
>   specification.
>
>   [David Martin]
>   >I guess at the heart of my concern is a conviction that, with our
>   >current approach, our process model has absolutely no chance of being
>   >used by a mainstream developer to specify a Web service (even many of
>   >those who understand and support the use of ontologies) - I think
>   >it'll just be rejected outright, because it's so hard to think about
>   >and work with.
>
>   Yes, I think that this is true, However, isn't there another solution
>   here?  Couldn't some kinds of "macros" or abbreviations be introduced
>   that don't explicitly specify the class at the level of detail at
>   which it could possibly be represented but which could act as a
>   pointer to the more detailed specification if some reasoning modules
>   will require it and left out if they don't.  We haven't been using
>   sequences, etc., very much in EPSL; however, should they be necessary,
>   we introduced the following vocabulary to support it, invoking the
>   DAML-S definitions indirectly, so that pattern creators could save a
>   bit of effort.  This approach would also meet the goal of making the
>   services vocabulary usable while pointing to an answer to the
>   question, "but what's the semantic import of such a list?"  Couldn't
>   OWL-S have such abbreviation predicates?
>
>The problem that finally tipped the balance away from "processes as
>classes" is that there are certain things you just can't say in that
>model.  Having macros wouldn't help.  It's easy to design a
>human-readable macro language with feature F, but if there is no
>translation of F into the underlying representation, you're stuck.
>
>One of the really bad problems was specifying data flow between steps
>of a process.  In order to say "Step 3's output is the input to step
>5," you have to be able to say, "In every execution trace of the
>process, the output of the trace of step 3 is the input to the trace
>of step 5."  This isn't hard using set theory, but is, as far as we
>can tell, impossible in the subdialect of set theory given by OWL and
>other DLs.  We made up some ad hoc notations, which are spelled out in
>our documentation for DAML-S 0.8 and 0.9, but they were always
>accompanied by the caveat that the semantics of OWL didn't enforce
>their meanings; these had to be supplied by special-purpose inference
>tools.  The more such extra-linguistic tools are needed, the weaker
>the motivation for using DLs in the obvious way.  We finally decided
>to chuck the whole thing.

Thank you, Drew.  This further clarifies the motivation and I fully concur with your observations about the expressive limitations of DL.   In EPSL we have implemented a technique for representing information such as the sort you describe above and as you note the complete intended meaning must indeed be articulated outside of the DL.

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?  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" and whichever system I'm using that implements this process description must recognize this.

best,

Mike Pool




>There is still a need for one such extra-linguistic mechanism, for
>stating conditions and other constructs from first-order logic.  But
>with processes-as-instances it's much more straightforward for the
>logic notation to refer to entities in a process.
>
>-- 
>                                             -- Drew McDermott
>                                                Yale University CS Dept.

Received on Monday, 15 September 2003 16:49:08 UTC