Hi John,
You wrote:
A KB that includes an ontology plus a DB of facts is
effectively a more specialized theory. That is true of either a 4D or a
3+1 D approach. But since the same ontology might be used with a wide
variety of different DBs, it would be useful to keep them distinct in practice.
Mostly, I agree, and that KB ontology you named is the one I consider
to be the one true ontology of a process. All the interconnections of a
process are based on the ontological types known for the entire duration of execution
for a process like that.
The exact drawing line between the KB and DB is not all that clear, and
depends on the observer as a projection of the one true ontology. For
example, I can write SQL events that update some data when other data changes,
perhaps to reflect the change in data, perhaps the change in time, or more
symbolic representations of problem domain objects.
For most programs with small tasks, one process is enough. Bu for
systems requiring some degree of complexity in behavior, multiple processes
must also be run, some with the entire one true ontology, and others with only
parts of it, all intercommunicating in preordained sequences and predications
within the messages.
Is that also compatible with your view? If so, the issue is only in
how to organize the message definitions to fit the needs of each end of every
communication. Understanding each message is a function of mapping it
against other knowledge extensions gleaned by experience from the one true
ontology's parts.
And if the issue is communication, must the communication translators
be complicated ontologically? Or should they just run the inputs to the
outputs without any other processing.
If the comm drivers are more complicated, then, they must have access
to the one true ontology (OTO) so they can map from one part of it (the input
message) to the other part (output message buffers).
But this approach incorporates numerous processes, each of which has to
be able to accept changing versions of the OTO as a system is built, and the
OTO emerges from the knowledge the engineers and their clients develop over the
life of the design phase.
That would mean that all ontological engineering would have to be done
from requirements initially, possibly extended with each stage of refinement,
and finally brought into OTO state when the system finally launches.
JMHO,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Thursday, January 27, 2011 5:11 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Categorical Views of a Universe
Doug and Rich,
DF
> A network of interconnected ontologies on different subject matter
or
> ways of looking at the universe (e.g., 3D vs. 4D) is what John
Sowa and
> i, among others have been promoting.
RC
>> Would those ontologies change with time, or just die out as
individuals
>> and be replaced by their some chain of descendants, like us
An ontology is a theory. Each revision of a theory is a new
theory.
Whether you throw the old one away depends on how much storage is
available. But given today's systems, I would suggest that you
keep
each theory ever developed in a hierarchy:
1. Adding an axiom to a theory creates a more specialized
theory.
2. Deleting an axiom creates a more generalized theory.
3. Modifying an axiom creates a sibling of a theory that is
immediately below the same parent as the old
theory.
How you name the theories is independent of the hierarchy, but the
metadata or a name with a version number would be important.
RC
> we should consider multiple independent ontologies, perhaps
> even weakly and strongly interconnected ones.
Yes. If you keep every modification of every ontology, you'll
get a strongly interconnected hierarchy. But you don't have to
store them all in the same place, and you can highlight some
or deprecate others.
So you could have links with greater (call it what you like)
strength, salience, importance, etc. All the paths could be
accessible, but the metadata could add further information,
including recommendations, warnings, prohibitions, etc.
DF
> Knowledge bases built on the ontologies would change
rapidly. The
> ontologies, themselves, would change at a slower rate. So
long as
> the changes were additions (new types of accounts, genes, products)
> they could remain the "same" ontology -- however,
versioning might
> be useful.
A KB that includes an ontology plus a DB of facts is effectively
a more specialized theory. That is true of either a 4D or a 3+1 D
approach. But since the same ontology might be used with a wide
variety of different DBs, it would be useful to keep them distinct
in practice.
For more detail about the hierarchy of theories, see Sections 5 to 7
(pp. 15 to 25) of the following paper:
http://www.jfsowa.com/pubs/rolelog.pdf
The first 14 pages cover a lot of philosophical and historical
issues. Skip directly to p. 15 for the hierarchy of theories,
the operations on it, and its use in a versioning system.
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx