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

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? 
>
Yes, that is generally how planners work. But our other paper at ISWC04 
focuses on information gathering during planning. Our approach is a 
general  solution for gathering information and getting information from 
the user can be seen as another way for gathering information. Here is a 
link to that paper:
http://www.mindswap.org/papers/ISWC04-Enquirer.pdf

>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. 
>
In SHOP2 concurrency of atomic processes are not allowed but 
interleaving of composite processes is permitted.

>(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))"?
>  
>
There is not a clear semantics about what "not(?person rdf:type 
Registered)" means in OWL. There are three different cases 1) We know 
that the person is registered (person rdf:type Registered is in our KB) 
2) We know that person is not registered (person rdf:type 
complementOf(Registered) is in our KB) 3) We do not know if the person 
is registered or not (neither triple is in our KB) Generally the not 
operator is used in conjucntion with Negation-As-Failure so it would 
mean that "not(?person rdf:type Registered)" would be true in case 3, 
too. If that is the semantics assigned to not operator then those two 
expressions are not semantically equivalent and your conversion would be 
wrong. Since there is no semantics we didn't want to deal with that 
case. Also note that using not with property assertions is much 
trickier, e.g how to evaluate the expression not(?person registeredTo 
?course)?

>(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 ...". 
>  
>
Note that we don't suggest using universally quantified expressions. 
Using a symbol like you suggest would be confusing because different 
people using the service description may have different knowledge and 
they would interpret the expresion differently.

>(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.
>  
>
Well, that is exactly the point we are trying to make in the paper. We 
do not have a solution but point this as an open problem that needs to 
be dealt with.

Regards,
Evren

>  
>
>>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 06:01:10 UTC