- From: Charlie Abela <charles.abela@gmail.com>
- Date: Sun, 22 May 2005 11:41:29 +0200
- To: Evren Sirin <evren@cs.umd.edu>
- Cc: public-sws-ig@w3.org
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