Re: [ontolog-forum] Constructs, primitives, terms

[William Frank <williamf.frank@xxxxxxxxx>]

Does this summarize the foundational statements from John Sowa and Mathew in this thread? 

terms that begin as primitive may become defined, 
(in fact these may in fact change places over time: one system may define T in terms of T', and another, vice versa)
people naturally use second order concepts all the time, and this means that we have to deal with the undecidability of some of the things we want to say, and in fact, people know how to do this.
a basic feature of any defined term  is the principle of substitutability: you can always replace the defined term with its definition. 


However, just to keep things accurate, this principle applies to recursive functions as well, quite simply, if a little awkwardly, when using higher order (undecidable) languages. Here is how it works, for addition:

1. theorem

There is exactly one function f such that f(x,y) = f(y,x), f(0,x) = x, and for every x, y (successor f(x,y) = f (x, successor(y)))

2. definition

_{'+' means that unique function f such that …….}

_{so, every time one encounters the symbol “+”, one replaces that symbol with the definiens: “that unique function f such that …."}

thus, the principle of substitutability of defined terms with their definiens is sustained in recursive definitions

this example and its equivalents are easy to find in the literature. 
 
so, I was most surprised to find someone saying:

"It is impossible to define addition in terms of zero and successor."

On Thu, Mar 1, 2012 at 10:16 AM, John F. Sowa <sowa@xxxxxxxxxxx> wrote:

Dear Matthew, Chris, and Nicola,

MW
> One of the problems with primitives is that if you are developing
> an ontology, then it is quite likely that entities that start out
> primitive may acquire a complete definition over time.

Yes, indeed.  That is also a problem with URIs that are supposed to
point to unique definitions.  When you import such a definition into
a context A that contains a lot of other axioms and definitions, the
simple imported terms will be used in more specialized ways.

Then if somebody else imports the same term into a different context B
with different axioms (or procedures), it will be used in a different
specialization.

So far, so good.  But a problem arises when systems A and B exchange
messages that use only the "common" vocabulary defined by the shared
URIs.  They may use the same terms, but their specialized "senses"
of the terms may be inconsistent.

CM
> It is impossible to define addition in terms of zero and successor.
> The reason for this, in a nutshell, is that the addition symbol is
> not eliminable; given the axioms for addition along with the axioms
> for zero and successor, you can "say" things that you cannot say
> in terms of the axioms for zero and successor alone...

Yes.  In general, a "closed form" definition can be eliminated.
For example,

   f(x) =  3x^2 + 5x - 17

You can replace any occurrence of f(y) by replacing x with y in the
defining _expression_.  But you can't do that for functions that are
directly or indirectly defined by recursion.  That is true of most
terms in any realistic ontology.

 

You can adopt a language that prohibits recursion, but that doesn't
solve the problem.  It just makes it impossible to state the full
definition of your critical terms.

Basic contradiction:  You can't have a practical system with completely
specified URIs and a restricted language to define them.

NG
> This is the reason why lightweight ontologies work very well as long as
> their terms are simple and understood by everybody. When we have very
> general, highly ambiguous terms, or technical terms whose meaning is
> not understood by everybody, then the importance of a clear semantic
> characterization (i.e., an axiomatic ontology) increases.

Yes, indeed.  And as in the examples by Chris, those axioms will be
explicitly or implicitly recursive.

The net result (Horror of Horrors!) is that your ontology language
will be undecidable.  But as anybody who has worked with any practical
application knows, people have learned how to use undecidable languages
in practical ways for real-world applications.  In fact, decidable
languages are *never* used in practical applications without having
undecidable supplementary languages to do all the "heavy lifting".

John

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J

-- 
William Frank

413/376-8167


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)