Re: SUO: Re: W3C approves RDF and OWL as recommendations
Philippe,
At 06:24 PM 2/18/2004 +1000, Philippe Martin wrote:
> > a DL should support to a certain degree this connection between
> > relational concepts and their respective relations ...
> > Parent := (some isParentOf) should suffice for a DL inference engine
>
>Indeed, representing the "connection" is permitted to a certain degree.
>
>
>Now here is my solution for the "generation" of the relations from the
>relational concepts.
>For readability reasons, I slightly changed the example I gave in my
>previous e-mails and the construct is now called relationalConceptSignature
>instead of roleTypeDomain. The initial of each relation type name is in
>lowercase. The initial of each concept type name is in uppercase.
>
> My motivation is to permit the users to (only) write
> Father (Animal,Male) < Parent ;
> in the FT notation, or
> (isSubclassOf Father Parent)
> (relationalConceptSignature Father Animal Male)
> in KIF,
> and I want these formulas to be equivalent to
> (isSubclassOf Father Parent) (BinaryRelation father)
> (domain father 1 Animal) (domain father 2 Male)
> (=> (father ?a ?m) (Father ?m))
> (=> (Father ?m) (exists (?a ?m)
> (and (Animal ?a) (Male ?m) (father ?a ?m))))
>
> Furthermore, if Parent is itself a relationalConcept with an
> associated relation (e.g. in FT: Parent (Animal,Animal) < Animal ;),
> I also want the following to be generated:
> (isSubrelationOf father parent)
> Thus, the users do not have to duplicate many relational concepts into
> the relation type hierarchy, they only update the concept type hierarchy.
>
>
>I am hoping that the next three definitions permit this.
>Corrections are welcome.
>
>(defrelation relationalConceptSignature (?roleType ?t1 ?t2) :=
> (exists ((?rel BinaryRelation))
> (and (= ?rel (findOrGenerateRelationFor ?roleType))
> (domain ?rel 1 ?t1) (domain ?rel 2 ?t2)
> (=> (holds ?rel ?a ?m) (holds ?roleType ?m))
What does (holds ?roleType ?m) mean, for example if bound to (holds Father
Bob) ? Does this mean (instance Bob Father) [as with SUMO] or (Father Bob)
[as in some other systems]? If so, why include the 'holds' predicate?
> (=> (holds ?roleType ?m)
> (exists (?a ?m) (and (holds ?t1 ?a) (holds ?t2 ?m)
> (holds ?rel ?a ?m))))
> (=> (and (isSubclassOf ?roleType ?sup) (relationFor ?sup ?supRel))
> (isSubrelationOf ?rel ?supRel))
> )))
>
>(defunction findOrGenerateRelationFor (?roleType) :-> ?rel :=>
> (exists ((?rel BinaryRelation))
> (= ?rel (denotation (cons (lowercase (car (name ?roleType)))
> (cdr (name ?roleType)))))))
>
>(defrelation relationFor (?roleType ?rel) :=
> (and (= ?rel (denotation (cons (lowercase (car (name ?roleType)))
> (cdr (name ?roleType)))))
> (BinaryRelation ?rel)))
>
>The last two definitions re-use the KIF functions called "name" (which
>returns an idebtifier of the given object) and "denotation" (which
>returns the object from the given identifier) and was inspired by one of
>the examples in Section 10.3 of Standford's KIF manual at
>http://logic.stanford.edu/kif/dpans.html#10.3
>I'd be surprised if these definitions were entirely correct and achieved
>the intended effects but they give the idea of the approach.
>
>
>The relation father is actually functional. Thus, I want the users to
>be able to write Father (Animal -> Male) < Parent ;
>in the FT notation, or (isSubclassOf Father Parent)
> (functionalConceptSignature Father Animal Male)
>in KIF, and I want these formulas to be equivalent to
> (isSubclassOf Father Parent) (UnaryFunction father)
> (domain father 1 Animal) (range father Male)
> (=> (= ?m (father ?a)) (Father ?m))
> (=> (Father ?m) (exists (?a ?m)
> (and (Animal ?a) (Male ?m) (= ?m (father ?a)))))
>Hence, the following definition:
>
>(defrelation functionalConceptSignature (?roleType ?t1 ?t2) :=
> (exists ((?rel UnaryFunction))
> (and (= ?rel (findOrGenerateRelationFor ?roleType))
> (domain ?rel 1 ?t1) (range ?rel ?t2)
> (=> (= ?m (?rel ?a)) (holds ?roleType ?m))
> (=> (holds ?roleType ?m)
> (exists (?a ?m) (and (holds ?t1 ?a) (holds ?t2 ?m)
> (= ?m (?rel ?a ?m)))))
> (=> (and (isSubclassOf ?roleType ?sup) (relationFor ?sup ?supRel))
> (isSubrelationOf ?rel ?supRel))
> )))
>
This sets up the basic framework of a relation implied by a class, but I'm
still wondering what the actual value of this is. These definitions by
themselves do not actually assert 'parent' into a knowledge base, they just
make such a relation implied by the existence of the 'Parent' class. Since
that assertion isn't made (unless there's some additional procedural
machinery that hasn't been described), the user is also left without a
concise way to state axioms about the relation.
One still has to state 'findOrGenerateRelationFor' instead of the 'domain'
statements we'd have in SUMO. Why not also assert (instance parent
BinaryRelation) directly, without this additional axiom set?
By creating this framework it seems to me that you now have a "shadow"
hierarchy of existentially quantified but unreified relations, which are
now less accessible to the user than if they were simply asserted explicitly.
Adam
>Philippe