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

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.

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 15:21:39 UTC