Hi Chris,
You’re right – I should be more
open-minded. Thanks for your insight.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Christopher Menzel
Sent: Tuesday, January 18, 2011
6:57 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum]
Ontology of Rough Sets
On Jan 17, 2011, at 8:38 PM, Rich Cooper wrote:
Hi Azamat and Chris,
Shame on those who claim that Thing can be a Class and an Instance at the same
time! Only multiple inheritance modelers would even face that issue
in the first place. I am not a C++ fan.
Rich, this is not a matter of who claims what. It is simply a fact that
there are languages that support self-membered classes and likewise a fact that
there ontologies in those languages in which Thing is a class. Once
again, you might prefer not to
use such languages or avail yourself of such ontologies but, unless you can up
with an objection to them that is far more cogent and rigorous than that you
are "not a fan", it is just silly to try to "shame" those
who prefer them.
In addition, your reference to C++ here suggests you might be confusing
programming languages with knowledge representation languages. As does your
talk of programs, creation, destruction, etc:
The Delphi VCL classes descend from TClass and TObject separately.
TObject is not an instance of TClass, so that every instance
of TClass is an actual TClass, and every instance of a TObject is a
TObject, and ne’er the twain shall hook up.
Only refinement processes tease out the actual classes and instances. A
program comprises a graph of refined classes and each class has a suite of
instances, varying in time of creation and destruction as to definition of each
instance at time t.
But its messy to use iterations of any kind of instances if you cant discern
the difference between a class and an instance. Those infinities can
be pesky, but they sure show up in the real world.
Restrict your database to entities (dynamic) and properties (static) and you
can organize it better. Expand into philosophically
interesting directions and get problems.
And this (not that I find it at all clear) suggests that you are
confusing a database theory with model theory.
The choice is clear to me.
From your perspective, given both what you know and what you don't,
that may be true. But, instead of "shaming" those who adopt
approaches that seem wrong-headed to you, maybe you could take it as a sign
that there is something new for you to learn.