From: Dan Connolly ([email protected])
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 http://www.w3.org/People/Connolly/
office: tel:+1-913-491-0501
pager: mailto:[email protected]
(put return phone number in from/subject)
This archive was generated by hypermail 2.1.4 : 04/02/02 EST