Re: SimpleProcess, some suggestions

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?
Can u please expand a bit on this template issue?

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 Saturday, 21 May 2005 15:50:10 UTC