ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Foundation ontology, CYC, and Mapping

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Tue, 16 Feb 2010 22:53:20 -0500
Message-id: <4B7B6830.5020504@xxxxxxxxxxx>
Dear Matthew,    (01)

MW> This is your lattice of theories, but I detect a new twist.    (02)

Actually, the only difference is in the subject I'm applying it to.
The summary in the dynonto.htm paper (in 2006) is an extract from
my KR book (2000), and I'm assuming exactly the same operators.    (03)

The following quotation is based on what I said there:    (04)

JFS>> My suggestion for supporting an open-ended number of applications
 >> of any kind is to organize the collection of theories in a hierarchy.
 >> Any change of any kind can be accommodated by inserting a
 >> generalization, specialization, sibling, or cousin.    (05)

MW> What is required here is a way of knowing and managing collections
 > of theories that can be added or subtracted and maintain consistency.    (06)

The four basic operators determine how that collection is managed.
Whenever you add anything to a theory, you create a new theory that
is below it in the hierarchy.  Whenever you delete anything, you
create a more general theory that is above the previous one.    (07)

The question of consistency is hard to determine and often undecidable
by theorem proving technology.  However, most theories are developed
during the process of building applications.  If you have one set of
data about which a theory is true, then that theory is ipso facto
consistent.  An inconsistent theory has no models.  Any theory that
has at least one model is consistent.    (08)

Furthermore, deleting axioms from a consistent theory guarantees
that the result is consistent.  Adding axioms, however, can make
it inconsistent.  But if you have at least one model of the theory
(e.g., a database about which it is true), then you can ensure
the consistency of the additions by checking each axiom that you
add to see if it is true of the existing data.  If you store the
data in a relational DB, you can check the truth of any axiom just
by translating it to an SQL query and executing the query.  If
it's true, the theory extended with that axiom is consistent.    (09)

These are examples of the kinds of properties that can be built
into the guidelines and procedures for managing and maintaining
the hierarchy of theories.    (010)

MW> There will of course be multiple of these based around different
 > upper and perhaps middle ontologies.    (011)

I'm not sure what you mean by "ontologies".  Are you talking about
the multiple theories in the hierarchy?  The same principles apply
at every level from the top to the bottom.    (012)

MW> The other thing that occurs to me is that there will also be a
 > value for what I would call abstract theories that are not attached
 > to any upper ontology, but are crafted so that they take on the
 > characteristics of different upper ontologies when included    (013)

That's fine.  You can "attach" those theories just be putting them
in the hierarchy and applying the rules for combining theories.    (014)

MW> For example, you could have a Linnean structure of living things
 > that did not know about 3D or 4D, but could  take on either flavour
 > when incorporated into those theories.    (015)

My guess is that a conjunction of the Linnean theory with either
a 3D or 4D theory of space & time would not cause any inconsistency.
But you can test the consistency by a variation of the method above:    (016)

  1. Start with a model for which one of the theories is true.
     Store the data that represent that model in a relational DB.    (017)

  2. Take the axioms of the theory that you want to combine it
     with, convert each one to an SQL query, and check them
     one at a time by executing the query.    (018)

Note that the WHERE clause of an SQL query can express full FOL.
Therefore, any axiom stated in first-order logic (or any subset
of FOL) can be tested just by translating it to SQL.    (019)

MW> This could have considerable value in achieving interoperability,
 > and might well be the useful thing that arises from Pat C's vision
 > of a common defining vocabulary, though I don't think there is any
 > such vocabulary that is finite, but if we have extensibility, that
 > does not matter too much, we just add what we need when we need it.    (020)

Actually, the likelihood of inconsistency *increases* when you have
a great deal of common vocabulary.  If two theories have nothing
in common, it's unlikely that they disagree about anything.  But
if they have a lot of terms defined in a common vocabulary,
the likelihood of an inconsistency is greater.    (021)

John    (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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (023)

<Prev in Thread] Current Thread [Next in Thread>