Re: SimpleProcess, some suggestions

Hi, thanks for the pointer.

I've been working on similar lines, and I think that one can actually
envision different template specialisation, depending on users'
ability to cope with different technical levels. A developer has
different knowledge than a normal user and therefore may create a
template using different constraints. In my idea, a template can be
regarded as a case which stores past knowledge or experience and which
can be used to suggest suitable abstract solutions to other users. In
this way service discovery can start off from a user chosen/defined
case, which can also be adapted depending on the case features the
user wants to include, and then, through the use of a planning and
matchmaking component, bind to actual services.

Charlie

On 5/22/05, Evren Sirin <evren@cs.umd.edu> wrote:
> Charlie Abela wrote:
> 
> >When u mention templates, what type of templates are u referring too?
> >Possibly templates listing generic service concepts that could be
> >linked to concept or domain hierarchies?
> >
> >
> Yes, that would be the simplest example. Of course you wouldn't be
> restricted to use just the named categories in a service taxonomy. The
> abstract service definition may encode some other constraints such as
> the policy requirements that the service needs to obey. So when you are
> looking for concrete services that can be matched with the abstract
> description you would only accept the services that match this criteria.
> But we believe it is not always possible to reduce the matching
> procedure to simple instance retrieval (or concept subsumption). When a
> developer is creating a template to solve a certain problem, he/she
> wants to encode the preferences for the steps in the workflow. For
> example, you may want to say that services that are certified by some
> authority are preferred, if no such service can be found, services whose
> customer rating is above some average will be used and so on. The
> prioritization of preferences in the template is yet another important
> issue. For example, if there are more than one available service that
> provides the same functionality, you may prefer the ones with higher
> reliability to the ones that has a lower response time. Therefore, it is
> necessary to be able to express such preferences in the template.
> 
> >Can u please expand a bit on this template issue?
> >
> >
> [1] discusses the above issues in some more detail and explains how HTN
> planning can be extended to plan with such template descriptions. Note
> that, this is just an extended abstract so you will not find all the
> details about the algorithm and the system in the paper. The full paper
> will probably be there in a month or so.
> 
> Regards,
> Evren
> 
> [1] http://www.mindswap.org/papers/extended-abstract.pdf
> 
> >Charlie
> >
> >On 5/21/05, Bijan Parsia <bparsia@isr.umd.edu> wrote:
> >
> >
> >>On May 21, 2005, at 8:48 AM, Daniel Elenius wrote
> >>
> >>
> >>>Bijan Parsia wrote:
> >>>
> >>>
> >>>
> >>>>On May 21, 2005, at 3:39 AM, Daniel Elenius wrote:
> >>>>
> >>>>
> >>>>
> >>>>>How about...
> >>>>>
> >>>>>1) Changing the name of SimpleProcess to AbstractProcess
> >>>>>2) Removing the expandsTo property
> >>>>>3) Changing the range of realizedBy to Process
> >>>>>
> >>>>>Is there any credible scenario where we want to have one atomic and
> >>>>>one composite process linked to the same simple (abstract) process?
> >>>>>
> >>>>>
> >>>>Sure. Any HTN planning (if it is going to use
> >>>>Simple/AbstractProcess). One might expect it to be linked (or
> >>>>inferrably linked) to *many* of each (though, technically, that's a
> >>>>bit of a departure from traditional HTN...it's a departure evren's
> >>>>already made and implemented and it makes a lot of sense).
> >>>>
> >>>>
> >>>But do they typically link to one atomic and one composite?
> >>>
> >>>
> >>No. many and many. but isn't that true in the curent SimpleProcess?
> >>Don't tell me these properties (now) have card=1!
> >>
> >>
> >>
> >>>I'm definitely not saying there should only be one process "realizing"
> >>>each simple/abstract process!
> >>>
> >>>
> >>Well, that's not so very crazy. Crazy enough for me :)
> >>
> >>
> >>
> >>>>>Why does it matter that they are composite/atomic?
> >>>>>
> >>>>>
> >>>>?
> >>>>
> >>>>
> >>>>
> >>>What I mean is, why two different properties?
> >>>
> >>>
> >>Yeah, I think that's nonsense too.
> >>
> >>
> >>
> >>> Why does it matter whether the process that is linked to the simple
> >>>process is atomic or composite? Presumably they both "realize" the
> >>>simple process...
> >>>
> >>>
> >>Yep. The HTN community seems a tad obsessed with maintain the
> >>primative/non-primative task distinction. Doesn't really help, IMHO.
> >>
> >>
> >>
> >>>>>My suggestion means there could be different degrees of
> >>>>>abstract-ness, as an AbstractProcess can be (partly) realizedBy
> >>>>>another AbstractProcess. The concrete process in the end of the
> >>>>>chain (if any) can be either atomic or composite.
> >>>>>
> >>>>>
> >>>>I don't really see the credible scenario for this. I can sorta
> >>>>imagine something, perhaps that would work for planning, or
> >>>>negotitation, or something. But the question, in general, is why
> >>>>Simple Processes at all. Presumably, they are meant to help us make
> >>>>"templates"...I can see wanting to refine or abstract the
> >>>>template...but wouldn't it be better to do it with actual
> >>>>descriptions (e.g., profiles) that woudl have an actual semantic
> >>>>relation (instead of a mere asserted one?)
> >>>>
> >>>>
> >>>>
> >>>That's a good point. This goes farther than my suggestion, as it
> >>>amounts to not using realizedBy/expandsTo at all.
> >>>
> >>>
> >>We discuss this in a Not Yet Accepted paper....maybe Evren will
> >>circulate it anyway...Evren?
> >>
> >>Cheers,
> >>Bijan.
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
> 
>

Received on Sunday, 22 May 2005 09:41:38 UTC