W3C home > Mailing lists > Public > public-sws-ig@w3.org > September 2004

Re: OWL-S: Handling Failures, and automatic generation of composite process IOPRs [was: Re: A bunch of OWL-S difficulties]

From: Drew McDermott <drew.mcdermott@yale.edu>
Date: Tue, 7 Sep 2004 15:58:48 -0400 (EDT)
Message-Id: <200409071958.i87Jwm3G000325@pantheon-po04.its.yale.edu>
To: public-sws-ig@w3.org


> [Daniel Elenius]
> 
> The issues here are tangled indeed ;)
> See my replies below.
> 
> > > [Daniel Elenius]
> > > Here is a whole bunch of issues/questions/comments on OWL-S that I 
> > > wish to discuss. Please dig in on any of them that you like. (The 
> > > comments below refer to OWL-S 1.1 beta.)
> > >
> > > 1) About hasOutput
> > > What is the purpose of the hasOutput property (both in Process and 
> > > Profile)? There does not seem to be a need for it, since all Outputs 
> > > need to be in som Result anyway. And IF the hasOutput property stays, 
> > > the hasEffect property should also come back. There is an asymmetry:
> > >
> > > Process.hasOutput -- Result.withOutput
> > > nil               -- Result.hasEffect
> >

> > [David Martin]
> > Actually, it's not true that all Outputs need to be in some Result.  
> > (We discussed on the phone recently, but I just want to put this out 
> > on the list "for the record".)  Results are optional, and even when 
> > there is a Result, the "withOutput" property is optional.

Other reasons: The outputs property declares the types of the outputs;
the 'withOuput' declares the values.

Composite processes may not have Results.  (See below.)

> [Daniel]
> Yes, OK. But in real life, wouldn't all outputs be conditional? A 
> process can always fail... And I think it would be useful to distinguish 
> the fail-cases from success-cases. This could be as easy as having a 
> subclass of Result call FailureResult for these cases. Even better would 
> be to have some kind of failure/exception ontology to relate to... This 
> is an area where I think OWL-S could do better. Consider BPEL4WS's 
> exceptions and recovery actions for instance. 

You're probably right, but that's a whole new set of issues....

> > >
> > > 2) About mapping Composite IOPEs to Atomic IOPEs and Profile IOPEs
> > > A comment in CongoProcess.owl says:
> > >
> > >      Note: Input, output, precondition, and effect properties of 
> > > *composite*
> > >      processes can, in principle, be automatically generated by tools.
> > >      Since such tools don't yet exist, they have been manually generated
> > >      for this example.
> > >
> > > How would such automatic generation happen? 

It wouldn't.  That comment should be deleted.  

As we discussed in today's telecon, it's probably not feasible to
infer the outputs or effects of a composite process.  A simple case is
where a step generates two outputs, only one of which is a useful
output of the process the step belongs to.  But the real problem is
that it's undecidable what effects or values a composite process is
going to have, unless some strong limits are put on recursion of
'perform's of other processes.  I don't know if the topic of limiting
recursion in Owl-S has ever come up.

However, if a composite process has explicit Results, the process
maintainer has to be diligent about maintaining the accuracy of the
Results as a description of what the composite process does.

> > > 3) More on Results
> > > It seems to me that in many cases, there will be two Results 
> > > connected to the same inCondition -- one for the case where the 
> > > inCondition is true, and one for the case where it is false (an 
> > > error/fail case). Why not have some shorthand for this, rather than 
> > > expressing it as two different inConditions? Also, what happens if no 
> > > inCondition is true? No Result? Should there be a way to express a 
> > > "fallback" Result?

Adopting a "shorthand" convention in XML/RDF is like putting a smaller
hood ornament on your SUV to reduce gasoline consumption.

> > [David]
> > Currently it is expected the inConditions will be exclusive, so as to 
> > avoid any ambiguity and minimize complexity in evaluating them.  But 
> > they needn't be exhaustive.  If there is no inCondition that's true, 
> > then there's no Result, and that's OK.  

Hmm.  I'm not sure I agree that 'inConditions' are normally
exclusive.  In realistic applications it's likely that there will be
orthogonal sets of conditions, where each set is mutually exclusive.

In any case, it wouldn't be hard to put an "if ... elseif ... else"
construct into the surface syntax, although it won't appear in the
next version, which I am hoping to post today.

> > [David]
> > No result just means that 
> > there's no effect, and nothing to be specified about the values of the 
> > outputs.   (That is, there will be outputs, but there's nothing to be 
> > said about what their values will be in the given condition.)

I can believe "no effect," and I can believe that some outputs are
left unspecified.  (Perhaps output 1 says whether some quantity was
retrievable, and output 2 says what the quantity is; if output 1 =
false, then output 2 = "don't care.")  I think leaving _all_ outputs
unspecified would always be a bug.

-- 
                                             -- Drew McDermott
                                                Yale University CS Dept.
Received on Tuesday, 7 September 2004 19:58:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:32:46 UTC