Re:DAML-S ws composition: Is the cycle complete?

Quoting Charlie Abela <charlie@semantech.org>:

> 
> 
> 
> ----- Forwarded message from Bijan Parsia <bparsia@isr.umd.edu> -----
>     Date: Tue, 30 Sep 2003 09:16:30 -0400
>     Wrom: QZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGP
> Reply-To: Bijan Parsia <bparsia@isr.umd.edu>
>  Subject: Re: DAML-S ws composition: Is the cycle complete?
>       To: Charlie Abela <charlie@semantech.org>
> 
> On Tuesday, September 30, 2003, at 08:04 AM, Charlie Abela wrote:
> [snip]
> > Yes it will provide some positive effect in performance, since the
> > process will
> > be limited to just executing the composed service ones its abstarct
> > description
> > is cached somewhere, also reducing the issue of communication with a
> > matchmaker/registry (this will be used if any of the components of the
> > composite WS was to fail for some reason.
> 
> I was thinking of it increasing planning performance (in an HTN
> planner). The problem with reusing *plans* is that they tend to be more
> specific (and more ground) than your original set of methods (after
> all, they are *derived* from the domain). So suppose you take the
> output of SHOP2 currently...it's just a sequence of ground operations.
> You can make it a method, but it'll only even possibly get used in
> planning if this method *is* your plan. If that method is found
> quickly, then including it will speed up your planning for that case.
> But it won't extend the set of plans you can find.
> 
> SImilarly, if you had a conditional plan, and added it as a method,
> you've not extended the domain in any interesting (i.e.,, generative of
> new plans) way.
> 

To recursively feed the plan back to the planner could result in a more 
effective plan, I read that somewhere. You have any links to such?
I was more referring to reusing of DAML-S descriptions than plans, since as u 
said the plan will tend to be specific. But creating a complete DAML-S 
description and make it accessible for others to discover and use in other 
compositions is the idea which is more in line with what is possible with corba 
and com components. 

> [snip]
> >> Again, I'd be very surprised if the conditional plans themselves made
> >> very interesting methods. They might, as I said, tune performance
> >> (though I'm skeptical).
> >>
> >> Perhaps you could explain what you were expecting, and how you think
> >> it
> >> might be achieved?
> [snip]
> 
> > Well I am a bit surprised about your response since the composition
> > cycle IMHO
> > would be complete if there is reusablity of the composed service, not
> > just by
> > the person who created it(manually or using some composition engine)
> > but by
> > third parties.
> 
> Well, we do (and want to) publish and *share* plans. If we plan at a
> "higher level" than some other domain, we might be able to put together
> something novel and interesting from their point of view. However, I
> thought you wanted to feed the generated plan *back into* the same
> planner during the same planning cycle.
> 
> >  So I'd suppose that a planner/or any other application, should
> > be able to output information which can be based on prior stored
> > information of
> > the involved services, a complete WS description, that includes
> > profile,
> > process and grounding is built.
> 
> Sure. But I don't think f this as caching, but as publishing.
> 
I have used the wrong words here. 
 
> >  I have been thinking about this issue and since
> > I don't have an extensive background in AI planning algorithms I don't
> > really
> > know if this is possible using this method. Though as you mentioned,
> > your SHOP2
> > planner is being extended to handle conditional planning. I am not
> > sure though,
> > whether this means that conditional statements are used in the output
> > plan.
> 
> Yes. Generating conditional plans (i.e., plans with conditionals)
> 
Therefore these plans can eventually be transformed into DAML-S descriptions 
with conditional statements. Right? Does this imply that to be able to output a 
composed DAML-S process model with if-then-else or split etc, the planner will 
have to handle such control itself? I hope I am not confusing things here.

> > Maybe one can use a "normal" planning algorithm and then introduce
> > heuristics
> > at some point during the planning phase to identify features in the
> > plan which
> > can be handled concurrently of conditionally and then produce a
> > full-fledged WS
> > description.
> 
> The problem isn't so much introducing conditionals per se, it's getting
> *generality* into the plan. You tend to plan toward the specific. It
> doesn't mean that the results aren't useful (they are!) but it's tricky
> to make them *recursively* useful, which is what I thought you were
> after.
> 
> You should check out Sheila's work on Planning With Complex Actions.
> 
> To summarize: Yes, we're generalizing all our work to allow the saving
> of compositions with control constructs, but that isn't always as
> helpful or interesting as one might have hoped :)
> 

Can u elaborate a bit on this part? What do u mean by not being helpful or 
interesting?

> Cheers,
> Bijan.

Regards

Charlie

-- 
Charlie Abela
Research Student,
CSAI, Department,
University of Malta

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Received on Wednesday, 1 October 2003 01:42:22 UTC