John,
I am curious to know what kinds of inconsistency you are referring to: (01)
> 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. (02)
Does this refer to cases where two communicating systems define (or
otherwise logically specify the intended meaning) of the *same* term (e.g.
'widget'), but use different definitions? Of course, they may be logically
inconsistent. But don't the two terms have different URI's (assuming the
URIs depend on the originating system)?
In the interoperability scenario I have assumed that the mediating system
that provides a translation of local systems depending on a common
conceptual defining vocabulary would have to check for identity of
definitions not in the common vocabulary, and *not* assign identity to two
terms that do not have identical definitions, regardless of what local term
is used to label that ontology construct. (03)
Pat (04)
Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416 (05)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Thursday, March 01, 2012 10:17 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Constructs, primitives, terms (06)
Dear Matthew, Chris, and Nicola, (07)
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. (08)
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. (09)
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. (010)
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. (011)
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... (012)
Yes. In general, a "closed form" definition can be eliminated.
For example, (013)
f(x) = 3x^2 + 5x - 17 (014)
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. (015)
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. (016)
Basic contradiction: You can't have a practical system with completely
specified URIs and a restricted language to define them. (017)
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. (018)
Yes, indeed. And as in the examples by Chris, those axioms will be
explicitly or implicitly recursive. (019)
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". (020)
John (021)
_________________________________________________________________
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 (022)
_________________________________________________________________
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 (023)
|