W3C home > Mailing lists > Public > public-sws-ig@w3.org > May 2005

Re: SimpleProcess, some suggestions

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Sat, 21 May 2005 08:16:38 +0900
Message-Id: <b7d7ecbfc338f63452228647977d4282@isr.umd.edu>
Cc: public-sws-ig@w3.org
To: Daniel Elenius <daele@ida.liu.se>

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.

Received on Friday, 20 May 2005 23:16:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:14 UTC