- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Sat, 21 May 2005 08:16:38 +0900
- To: Daniel Elenius <daele@ida.liu.se>
- Cc: public-sws-ig@w3.org
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). > Why does it matter that they are composite/atomic? ? > 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?) I guess asserted ones can help, but it's worth thinking about this careful and grounding it in actual practice so we don't perpetuate the SimpleProcess unspecification. Cheers, Bijan.
Received on Friday, 20 May 2005 23:16:43 UTC