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

Re: SimpleProcess, some suggestions

From: Evren Sirin <evren@cs.umd.edu>
Date: Sat, 21 May 2005 23:11:45 -0400
Message-ID: <428FF871.9090504@cs.umd.edu>
To: Charlie Abela <charles.abela@gmail.com>
CC: Bijan Parsia <bparsia@isr.umd.edu>, public-sws-ig@w3.org

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 03:12:04 UTC

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