- From: Evren Sirin <evren@cs.umd.edu>
- Date: Sat, 21 May 2005 23:11:45 -0400
- To: Charlie Abela <charles.abela@gmail.com>
- CC: Bijan Parsia <bparsia@isr.umd.edu>, public-sws-ig@w3.org
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 03:12:04 UTC