Message 12340 of the SUO list

Subject: Re: W3C approves RDF and OWL as recommendations
         (original subject header for the discussion but inappropriate here)
Date: Thu, 19 Feb 2004 15:15:18 +1000
From: Philippe Martin
In-reply-to: msg12337 by Adam Pease (in answer to msg12331 by Philippe Martin)



Adam,

> 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.

This is what I intended. In my previous answer I wrote that assertions
may actually be made by some inference engines, and I still think this
is a possibility but I don't mind if it happens ... in another system
than mine (as explained below).
Thus, if you think my KIF statements are correct, this is good enough for
me, but if someone adapts findOrGenerateRelationFor so that it actually
asserts the relation, e.g. using the LISP function gensym, this is ok too.

[The following paragraph is a follow-up that I sent immediately after
this message but which is inserted here for convenience]
If the semantics of relationalConceptSignature and 
functionalConceptSignature are not hard-coded in the inference engines,
hence if role types cannot be used in the place of relation types
when making statements (as in: [Person:Mary]->(Father)->[Person:John]),
then the relation types must be generated at least when they are used
in statements (as in:  [Person:Mary]->(father)->[Person:John]).

[The following paragraph is from my answer to the answer of Adam Pease
for this message. It is inserted here for convenience]
> your approach ... prevents users from adding the axioms that would
> define the full semantics of those new relations.
Oh no. If a user wants to add axioms to the relation type "parent",
it is irrelevant whether the type/identifier "parent" has been
previously generated, manually created, or its existence implied.
Whatever the case, the user's axioms will be "additional" axioms for
the relation type "parent". And of course, these additions must be
allowed if the user has the right to add new axioms to the relation
type "parent" and if these new axioms are consistent with the
previous axioms.



> 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?

In the MSO, there are currently 583 concept types (most of which from
WordNet) that are subtype of pm#thing_that_can_be_seen_as_a_relation
and hence are role types. This number will grow.
Not using relationalConceptSignature and functionalConceptSignature (and
their two associated relations) would mean adding 583 relation types (and
as many subrelation links) plus 2*583 definitions for their connections
to the role types. Thus, the users and the inference engines will have to
deal with 3*583 additional assertions. And each addition/modification in
the role types will have to be duplicated in the relation type hierarchy.
Thus, using findOrGenerateRelationFor helps scalability (and especially 
when the semantics of relationalConceptSignature and 
functionalConceptSignature are hard-coded in the inference engines).
The most important point is that I do not want users to have to bother 
with seeing or adding relations and definitions (and most of them would
not add them or add them incorrectly, thus reducing knowledge sharing and
retrieval possibilities). I want the relation type hierarchy to stay as
small as possible, mainly including basic relations (as few content-related
relations as possible), and untouched by "average users". Average users
should only have to update the concept type hierarchy (and not enter
definitions) when the categories they want do not yet exist. Finally,
controls on updates of the concept type hierarchy are stronger because it
countains more information (hence more constraints) than the relation type
hierarchy.

Thus, to keep the relation type hierarchy as small as possible, I prefer
that findOrGenerateRelationFor does not actually generate the relation types.



> 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?

I did not make the difference between (instance Bob Father) and (Father Bob).
Should I have? I used (holds ?roleType ?m) instead of (?roleType ?m) whenever
I could because this is the syntactic form used in the SUMO. However, in the
definition of functionalConceptSignature I had to use (?rel ?a ?m) because
in that definition ?rel refers to a function.


Philippe