Re: axioms and (not) changing a language

From: Dan Connolly (
Date: 02/20/01

"Peter F. Patel-Schneider" wrote:
> There was a comment during today's teleconference to the effect that an
> extension to DAML+OIL would be trivial as long as there was a (KIF)
> axiomatization for it.

Well, perhaps not trivial, but well-specified, yes.

>  This belief seemed to spring from the fact that
> there is a KIF axiomatization for DAML+OIL.

No, it springs from a belief that KIF (or any equivalent
FOPC notation) is a reasonably precise way to specify things.

> This is decidedly not the case.  Extending DAML+OIL by adding axioms to the
> axiomatization is a very dangerous endeavour.  Some extra axioms can be
> accommodated, and will not change the characteristics of DAML+OIL.

Which characteristics are you talking about?

Decidability? something else?

You referred to a decision that DAML+OIL should be decidable.
Would you please cite a record of that decision? I must have
missed it.

Are these characteristics that we should guard closely
documented in our spec? Please point me to them.

>  Others,
> although seemingly innocuous, would drastically change DAML+OIL.
> Determining just what changes will be made by a particular set of extra
> axioms is extremely difficult.
> To illustrate this point, consider RDF(S).  RDF(S) has a KIF
> axiomatization.

It does? I can sort of imagine one, but I've never seen one.
You have rasied a number of questions (about bags containing
themselves etc.) that I don't know how to answer; I wouldn't
expect a KIF axiomitzation would leave such unanswered questions.

>  One could argue, as above, that extending RDF(S) by a
> collection of extra axioms is trivial.
> However, suppose that we extend RDF(S) by the DAML+OIL axioms.  We now end
> up with a very different kind of representation language, with very
> different characteristics.

How so?

I'm afraid I completely don't understand the point you're making.

Dan Connolly, W3C
office: tel:+1-913-491-0501
  (put return phone number in from/subject)

This archive was generated by hypermail 2.1.4 : 04/02/02 EST