SUO: Re: W3C approves RDF and OWL as recommendations
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.
> 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 what 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