Hi John, Tara, Chris, comments below:
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Tuesday, January 18, 2011 6:10 PM
Subject: Re: [ontolog-forum] Ontology of Rough Sets
Rich, Tara, and Chris,
I agree with Chris about the use of the term 'class'
Although I like logic, I don't believe that logicians
(or anybody else)
have the right to assign a technical meaning to a
common word and expect
anybody else to use it (especially when it's used for
a rather esoteric
distinction that most people are completely unaware
When I find words that are overloaded with too many
I prefer to ignore them, and I would only use them in
sense as part of a longer phrase. That is one
reason why I avoid
the word 'class'. Unfortunately, there are too
many popular computer
languages that adopted that term -- therefore, I have
to use it when
talking about those languages.
Agreed - a good description of how most
people use the word in context.
> I prefer the type definition that is static,
fixed in time.
> That applies if the class type is defined as a
plurality of instances
> of the type definition, with optional class
properties defined for
> association with the class definition as well.
Two problems with that definition: (1) that's
not how the word is
used in Java and OWL; (2) the number of instances may
be large or
infinite, and there is no way to specify all of them
giving some rule or description for recognizing them.
Re (1): Java has a different semantics for
"class", I agree. The Delphi
definition might have been migrated into dot net, though I have not checked,
since the same architect was fully involved with designing both.
That is why a type is usually specified by some rule
that can be used to recognize instances. That is
definition that is independent of any change in the
Types in Delphi
include the basics (integer,
..) and combiners made from an _expression_ of array, record and class. The
"basic" type Class
is a combiner that specifies slots for methods, properties, virtual,
overloaded, the usual suspects.
As for RECOGNIZING instances, every
instance has a known class derivation line from a type statement, so it isn’t
necessary to calculate that – the compiler knows it at symbol binding
The more general issue of RECOGNIZING instances
isn’t really applicable to program specifications. It is more
applicable to data mining and text mining where patterns are hypothesized in attempts
to discover a “definition”, much like Yorick Wilks’ paper on Preference Semantics discussed
hypothetical patterns of words and their preferences for other words as
alternative patterns. For that, see my patent 7,209,923 which describes
the process of discovering context within databases.
The URL to that patent is attached to this