Re: Question about representing frame information and unification in PL

On Oct 29, 2008, at 10:49 AM, Srini Ram wrote:

> I found the following example in the documentation for the Knowledge  
> Machine from UOfTexas...
>
> ;;; "Every big car has a large engine."
> KM> (every Big-Car has
>            (parts ((a Engine with
>                       (size (*Large))))))
>
> ;;; "Every powerful car has a powerful engine."
> KM> (every Powerful-Car has
>            (parts ((a Engine with
>                       (power (*Lots))))))
>
> Question 1: How would we we represent above in Powerloom
>   Here is my shot at it
> (defconcept Car)
> (defconcept Size (?x)
>   :axioms ( and
>                 (Size large)
>                 (Size small)
>                 (Size medium)
>                 (closed Size)))

;; I would write this concept as an explicit definition in terms of
;; the set of instances.  PowerLoom will then conclude that it must
;; be closed because there is an explicitly enumerated list.

   (defconcept Size (?x) :<=> (member-of ?x (setof large small medium)))

>
> (defconcept Power (?x)
>   :axioms ( and
>                 (Power lots)
>                 (Power little)
>                 (Power medium)
>                 (closed Power)))

;; Similarly

(defconcept Power (?x) :<=> (member-of ?x (setof lost little medium)))

> (defconcept Car-Part)
> (defconcept Engine (?x Car-Part))
> (deffunction car-engine ((?x Car)) :-> (?y Engine))
> (deffunction part-size ((?x Car-Part)) :-> (?y Size))
> (deffunction part-power ((?x Car-Part)) :-> (?y Power))
> ;; the above is not quite correct...some parts may have only a size  
> or a power, but not both
> ;; every part must have one of the two properties..not sure how i  
> say this in a meta-relation. I can then
> ;; use the meta-relation to say that engine has size as well as  
> power relations, tire has size but not
> ;; power etc.

;; You don't really need a meta-relation to say this in particular.
;; You could make this a requirement directly:

(=> (car-part ?part) (or (exists (?size) (part-size ?part ?size))
                          (exists (?power) (part-power ?part ?power))))

;; But there will be limited inference, since disjunctions are pretty
;; weak constraints.  For the case of Engine and Tire you would get

(defconcept Engine (Car-Part ?x)
    :=> (and (exists (?size) (part-size ?part ?size))
             (exists (?power) (part-power ?part ?power))))

(defconcept Tire (Car-Part ?x)
    :=> (and (exists (?size) (part-size ?part ?size))
             (not (exists (?power) (part-power ?part ?power)))))

;; But this is an area of PowerLoom where we haven't really put
;; a lot of effort into making sure you get inferences or clashes.

> (defconcept Big-Car (?x Car)
>    :=>  (= (part-size (car-engine ?x)) large))
>
> (defconcept Powerful-Car (?x Car)
>    :=>  (= (part-power (car-engine ?x)) lots))
>
> It is more verbose than the KM version and less intuitive. Could I  
> have used some PL features e.g definstance to make the code more  
> readable?
>
> ;; The KM example continues as follows
> ;;; "Suburbans are both big and powerful cars."
> KM> (Suburban has (superclasses (Big-Car Powerful-Car)))
>
> I defined this in PL as :
> (defconcept Suburban (?x Big-Car Powerful-Car))
>
>
>
> ;; KM then shows its unification powers
> ;;; "What are the parts of a Suburban?"
> KM> (the parts of (a Suburban))
> (COMMENT: (_Engine7 && _Engine8) unified to be _Engine7)
> (_Engine7)
>
> Question 2: Would the unification work the same way in PowerLoom or  
> is the behavior slightly different
> The output from PL code above is:
>
> STELLA> (retrieve all (= ?x (Car-Engine t1)))
> There is 1 solution:
>   #1: ?X=|SK|(CAR-ENGINE  
> T1)                                          ;; Seems to work  
> ok...there is only one engine not two
> STELLA> (retrieve all (= ?sz (part-size (Car-Engine t1))))
> There is 1 solution:
>   #1: ? 
> SZ 
> = 
> LARGE                                                             ;;  
> and that engine has the correct
> STELLA> (retrieve all (= ?sz (part-quantity (Car-Engine t1))))
> There is 1 solution:
>   #1: ? 
> SZ 
> = 
> LOTS 
>                                                                 ;;  
> properties

Well, the actual mechanisms might be a bit different.
PowerLoom would have a single skolem instance for the car-engine  
(created because it's a function), and then the attributes are just  
asserted about that skolem.  Unification would only really come into  
play if there were some equivalence assertion between two skolems or a  
skolem and an instance -- either explicitly or implicitly.

So if one were to

     (assert (car-engine t1 e326))

then the skolem and the instance e326 would be unified.
Similarly this could also be done with more than one skolem:

(deffunction favorite-object ((?x Person)) :-> ?x)

   (assert (= (favorite-object Joe) (car-engine t1)))

this would equate the skolems, without needing a concrete instance.

> KM has some other frame features that are useful to make the code  
> clearer /concise
> 1. Embedded frames
> ;;; "Joe is a person, and owns a red car."
> KM> (*Joe has
>           (instance-of (Person))
>           (owns ((a Car with
>                     (color (*Red))))))
>
> Not sure if this can be done in PL without creating a PL instance of  
> car and using the owns relation to relate Joe to that car instance  
> i.e we cannot have embedded powerloom instances... I may be missing  
> the proper use of the frame syntax of PowerLoom that makes this  
> possible.

What you can use is existential quantification.  That is essentially  
what the "a" operator in KM means:

(assert (and (Person Joe)
              (exists (?joes-car)
                  (and (Car ?joes-car)
                       (owns Joe ?joes-car)
                       (color ?joes-car Red)))))

This seems fairly comparable to what the KM form looks like.

PowerLoom does have some frame predicates

    (retrieve ?p (frame-predicate ?p))

but since we haven't really had applications that needed to reason  
with them, the reasoning is not as extensive as you would get in a  
description logic like Loom or OWL.  There is no inherent reason that  
couldn't be added, but it hasn't been a priority for us.

There is also the complication that the more expressive language of  
PowerLoom means there are other logically equivalent ways to state,  
for example, a minimum 1 cardinality.  But they aren't currently  
handled by the axioms and inference machinery.  Partly that is lack of  
effort and partly fear that we can't do it efficiently.  For example:

    (Car ?x) => (range-min-cardinality ?x has-engine 1)

    (Car ?x) => (exists ?e (has-engine ?x ?e))

are logically equivalent, but PowerLoom doesn't have the axioms to  
conclude this.