- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Sat, 21 May 2005 08:55:34 +0900
- To: Daniel Elenius <daele@ida.liu.se>
- Cc: public-sws-ig@w3.org
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 Friday, 20 May 2005 23:55:38 UTC