Re: Planning under Description Logic ?--an obstacle towards WSAC

Hi,

I've read your paper as well and I've got a few questions and comments.

> http://www.mindswap.org/papers/SWS-ISWC04.pdf
>  
>
questions:
1) Is your modified Jshop planner available for research purposes?
2) Can it enumerate all possible plans (combinations of services)?
3) How to you handle conditioned outputs and effects that are introduced 
with Results in OWL-S 1.1?
4) I'm not an expert in HTN planning but it seems to me that without any 
methods (and only operators)
   it wouldn't do anything, or am I wrong? I have the impression that 
the methods tell you the basic composition steps that    can occur in 
your overall plan/composition. 

comments:
1) The problems you mention at the end of sec 3.3. reminded me of 
truth-maintenance systems
    that have been studied in AI for a while.
2) Analogously, the end of sec 4 reminded me of constraint solving where 
people deal with networks of
    constraint variables and restrictions. Maybe some of their methods 
would be applicable to your problem.

minor comments:
Sorry, I don't want to be a nitpicker but I'd like to help improve your 
publication (might be too late though).

It seems that you managed to mess up you LaTeX and the referees of your 
paper didn't see it:
 1) sec 2.4: "(see Figure 2.4)" should be "(see Fig. 1)"|
 2) sec 3.1: "in figure 2.1" --> "in Fig. 2"
 3) sec 3.2: "in figure 3.2" --> "in Fig. 3"
I'm not a native speaker but I think the following should be:
 1) sec 5:  "Actually, Lisp version" --> "Actually, the Lisp version"
                "contained significantly more number of individuals" --> 
"contained significantly more individuals"
                "We first implemented... and run..." --> "We first 
implemented... and ran..."
                                                                         
                                         ===
                "However, only way..." --> "However, the only way..."

Manshan Lin wrote:

>>>hi all,
>>>I've just read all the discussion about applying AI planning technique
>>>to SWS.
>>>I notice that most traditional planning algorithm are based on first
>>>order logic, which is based on close-world assumption.
>>>      
>>>
>>Er...really? First order....closed-world....BOOM! ;)
>>    
>>
>
>Sorry for my expression, what I actually refer to is the traditional
>planning algorithm. :)
>
>  
>
>>>The question is :
>>>When using DL to describe world state, what adaptions should
>>>traditional AI planning techniques make?
>>>      
>>>
>>Let me point you our paper on Planning for Web Services:
>>       http://www.mindswap.org/papers/SWS-ISWC04.pdf
>>    
>>
>
>Yes, I've read your paper. 
>It is trying integrate OWL-DL reasoner(Pellet) with an AI
>planner(SHOP2) to solvethe evaluation
>of preconditions and applying effects. There are some questions:
>(1) In section 2.2, it seems that HTN planner starts its planning from
>initial state to the goal
>state. Do you assume that the user provides all needed information at
>the very beginning? What's
>more, it seems that the plan generated by the HTN planner does not
>support pallel execution, since
>it only generates a sequence of actions. (Since I'm not familiar
>withHTN planning, point it out
>if I'm wrong. :) ).
>(2) In section 3.1 the fouth paragraph, it mentions due to open-world
>assumption, "as SWRL does
>not allow negated atoms appear in rule bodies, we also restrict the
>preconditions to contain only
>non-negated SWRL atoms". In my opinion, negation is relative. Don't
>you think that "not(?person
>rdf:type Registered)" can be easily converted to "(?person rdf:type
>complementOf(Registered))"?
>(3) In section 3.2, it mentions how to evaluate universally quantified
>expressions. The evaluation
>however returns to the closed world assumption. To avoid ambiguity,
>should it uses another symbol
>to express "as far as I know, all ...". 
>(4) In section 3.3 fouth paragraph, it mentions "we have the problem
>of OK deriving the same assertion
>from other facts even after we remove that assertion from the KB
>...... This is exactly why planning
>systems make the distinctions between primitive and derived predicates
>and do not allow derived predicates
>in effect". How can we make sure that the effects of an operation must
>be primitive? Just like we
>can't require others not to inherit a concept. In some KBs, they are
>primitive, while in some KBs,
>they also can be derived predicates.
>
>  
>
>>It describes our attempt to use OWL as the world state represenation
>>language of the SHOP planner.
>>
>>    
>>
>>>For example,
>>>TBOX: EffectA = intersectionOf(EffectB,EffectC)
>>>ABOX: a individual EffectA
>>>      
>>>
>>Er...So you're talking owl full here? With the same thing both a class
>>and a individual?
>>    
>>
>
>Sorry for my expression again, :(. What I mean is that 'a' is an
>individual of 'EffectA'.
>
>  
>
>>>Then we can choose an operation that achieves EffectA or we can choose
>>>two operations (one achieves EffectB and the other achieves EffectC).
>>>      
>>>
>>I don't udnerstand.
>>
>>    
>>
>>>It's a little like adding some common rules
>>>(in this case EffectB(x) and EffectC(x)->EffectA(x))
>>>to traditional planning domain.
>>>      
>>>
>>I presume you're talking about secondary effects? yeah, they're a
>>problem :)
>>    
>>
>
>No, I mean EffectA(x) equals to the conjunction of EffectB(x) and EffectC(x).
>Just like we can see the glass as half empty or as half full. The expression 
>are different but they have the same meaning.
>That is,
>TheGlassHalfEmptyEffect(x) -> TheGlassHalfFullEffect(x)
>Another example,
>GetMyCarRepairedEffect(x) and GetMyCarCleanEffect(x) ->
>GetMyCarRepairedAndCleanEffect(x)
>
>The concept "GetMyCarRepairedAndCleanEffect" is the intersection of the concept
>"GetMyCarRepairedEffect" and "GetMyCarCleanEffect".
>
>  
>
>>>When EffectB and EffectC are not
>>>atomic concepts, the situation becomes more complex. How to handle
>>>this kind of things in planning algorithms?
>>>      
>>>
>>Well, I won't repeat our paper, but I will add that the problem is
>>*much* trickier when your *domain* may have been gathered from
>>disparate sources. It's hard to forbid use of derived literals in that
>>case (IMHO).
>>    
>>
>
>Best regards!
>
>Manshan Lin
>Email: lmshill@hotmail.com;lmshill@gmail.com
>Affiliation: School of Computer Science and Engineering, the South
>China University of Technology
>Phone: (+86)13711287277
>2004-12-03
>
>  
>

Received on Friday, 3 December 2004 13:24:38 UTC