W3C home > Mailing lists > Public > www-rdf-logic@w3.org > November 2000

Re: comments on DAML-ONT semantics document

From: Richard Fikes <fikes@KSL.Stanford.EDU>
Date: Tue, 14 Nov 2000 22:13:10 -0800
Message-ID: <3A122976.740E4070@ksl.stanford.edu>
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
CC: www-rdf-logic@w3.org
Thanks for your comments.  Here are some detailed replies from me.

> I don't see how this document is much help in determining the semantics of
> DAML-ONT.  The document translates DAML-ONT into axioms written in KIF.
> This might be helpful if the axioms were regular first-order axioms,
> but they instead use many constructs that, to me, are just not natural. 
> 
> For example, the document heavily uses the predicates ``holds'' and
> ``type'', which, I suppose are supposed to mean that a relation holds
> between two objects or an object belongs to a category, respectively.
> However, neither of these are defined in the document.  Further, although
> ``holds'' is mentioned in the KIF standards document, it is not given any
> definition therein, nor it is given a semantics in the model theoretic
> semantics for KIF.  ``type'' is not even mentioned in the KIF
> documentation.  It is fairly obvious what the intended meaning of these two
> predicates are, but this intended meaning is a second-order one, and this
> need for a second-order semantics doesn't seem natural at all to me.
> 
> In addition, and perhaps even more importantly, as these two predicates are
> vital to the semantics there is no way that this document can provide a
> semantics for DAML constructs.

First of all, "type" is intended to be the DAML-ONT property of that
name.  The axioms regarding "type" in our document are Ax84 and Ax85. 
Perhaps additional axioms regarding "type" would be useful.  In
particular, the following comes to mind:

(<=> (type ?x ?c) (and (Class ?c) (holds ?c ?x))

Do you agree that is an appropriate axiom to add?

Regarding "holds".  You are right that the semantics for "holds" is not
in the documents referenced on the current KIF Web site.  I just
discovered that omission this afternoon.  I have not been involved in
the KIF standardization effort recently and so do not know why the
semantics for "holds" was not included in the current documents.  Those
semantics were in section 8.3 of the original KIF specification
(available at http://www.ksl.stanford.edu/KSL_Abstracts/KSL-92-86.html)
and, as you mentioned, are obvious.  Namely:

Given an interpretation I and a variable assignment V, the truth value
with respect to I and V of a sentence of the form "(holds P T1 ... Tn)"
is true if and only if the relation denoted by the semantic value with
respect to I and V of P is true of the objects denoted by the semantic
value with respect to I and V of each of the arguments T1 ... Tn.

I will contact Genesereth to determine what if any rationale there was
for not including the semantics of "holds" in the current KIF documents.

As to whether "holds" is second order, I will defer to Pat Hayes on that
issue.  He claims that "holds" is not second order.

Other than responding to the specifics in your comments, as I have done,
I cannot comment on your claims that the axioms use constructs that are
"just not natural" and a semantics that "doesn't seem natural at all to
me".  Those seem like subjective assessments on your part that I don't
know any way of resolving.

I certainly disagree with your statement that "I don't see how this
document is much help in determining the semantics of DAML-ONT."  I
would claim that it has already been of nontrivial help by bringing to
the surface multiple bugs and unclear meaning in DAML-ONT constructs.  I
would suggest that such an axiomatization is a powerful tool in the
analysis, debugging, and articulation of the intended meaning of a
representation language.

> 1/ ``Disjoint'' is supposed to be a class, but it is certainly not in the same
>    category as ``Thing'' or ``Person''.

I don't know what you mean by that.  The DAML-ONT spec says that
"Disjoint" is a class.  It doesn't include any commentary to
differentiate it as some other form of class.  Axiom Ax8 defines what we
think it means for an object to be an instance of class "Disjoint".

> 2/ There is no way that ``domain'' relationships can be inferred.  The only
>    definition of ``domain'' is given in Ax92, and this is a one-way axiom.

Yes, you are correct.  Axiom Ax92 should be if-and-only-if as follows:

Ax92.	(<=> (domain ?p ?d) 
             (and (Property ?p)
                  (Class ?d)
                  (forall (?x ?y) (=> (holds ?p ?x ?y) (type ?x ?d)))))

Similarly, axiom Ax94 for "range" should be if-and-only-if.

> There is no way to infer that ``Thing'' and ``Nothing'' are in the
>    ``ComplementOf'' relationship as ``Thing'' and ``Nothing'' have direct
>    definitions, but ``ComplementOf'' is defined in terms of ``holds''.

The appropriate semantics for "holds" as given above would enable the
inference to be made.

> 4/ ``oneOf'' is defined to belong to ``Property'', but it looks more like a
>    ``Class''.

The DAML-ONT spec says that "oneOf" is a property.  We were not trying
to do language redesign here, but were rather trying to axiomatize the
current DAML-ONT spec.

> 5/ ``asClass'' is defined as equality.  This means that two classes related
>    by ``asClass'' are the same object, which is not what is meant by
>    equivalency in most KR systems.

Well, that is what the spec seemed to us to say.  If that is not the
intent of the DAML-ONT designers, then let them speak and we will change
the axiom.  You might support that discussion by proposing a candidate
notion of equivalent classes.

> 6/ There is no way of getting from a knowledge base to a ``values-list''.

What do you mean by that?  Are you referring to how a reasoner might use
the notion of "values-list"?

> 7/ ``values-list'' has two arguments in some places and three in others.

I see.  Actually, that is correct since the relation "values-list" is
functional in its last argument, and KIF allows functional relations to
be used either as functions or as relations.  However, I agree that is
confusing and will change all the uses to be in the relational form.

> 1/ ``Thing'' and ``Nothing'' are given meaning without referring to
>    ``holds''.  These are the only two classes that are given meaning in
>    this way.

The additional axiom for "type" given above will take care of that.  

Note that we could have written axiom Ax2 as "(type ?x Thing)" instead
of "(Thing ?x)" and axiom Ax4 as "(not (type ?x Nothing))" instead of
"(not (Nothing ?x))".  Which form do you think is preferable?

> 2/ There are lots of things that belong to ``Property'', which I assume has
>    some relationship to RDF properties, but there is no such connection.

I don't understand this comment.  "Property" is a Class as defined in
the DAML-ONT spec.  We axiomatized that definition as axioms Ax82 and
Ax83.

> 3/ There is no inclusion of any RDF stuff.  For example, I expected to see
>    a mapping of RDF constructs into KIF, or at least a reference to such.
>    Things like ``Seq'' thus are not defined.

We included only those portions of RDF that were defined in the DAML-ONT
spec.  I agree that we need to add axioms for the remainder of RDF.

> 4/ There is no meaning provided for ``Default''.

There is no meaning provided for "Default" in the DAML-ONT spec.  My
understanding is that the DAML-ONT designers mean for its meaning to be
left unspecified, at least for now.  The axioms reflect that lack of
constraint on the possible interpretations of "Default".

> There are other things that are just plain ugly:
> 1/ The ``values-list'' mechanism depends on a lot of ugly machinery.

As with your comments about naturalness, there is no response I can make
about your sense of the axioms being ugly.  Your suggestions for
alternatives that would be less offensive to you are welcome.

> I'm sure that I am missing more problems.

We would welcome your articulation of those problems so that they can be
addressed.

Again, thank you for your comments.

Regards,
Richard
Received on Wednesday, 15 November 2000 01:13:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:32 UTC