<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="MSHTML 5.00.2614.3500" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Mark</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> I've never heard
anyone call them "qualifiers" but me, either. The reason I
do this is the following. In mathesis, every complete idea has both a
quantity and a quality (an arbitrarily-defined state). One is meaningless
without the other. This is one of the central, key points in MME (The
MetaMathesis Essay). Quality is meaningless without quantity, and vice
versa. If you don't agree, ... well, we've had this conversation before,
and my egoistically-optimistically-warped memory tells me that I won that
argument -- but I could be wrong. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> Anyway, since quantity is taken
care of by the quantifier in each of these expressions:</FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Symbol>
<P> "</FONT></FONT><FONT face=Arial size=2>x or <FONT
face=Symbol>$</FONT></FONT><FONT face=Arial size=2>x</FONT></P></DIV>
<DIV><FONT face=Arial size=2>quality is everything else, i.e. the variable,
"x". The variable represents some state, a quality. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> This obviously applies only to
variables in predicate or propositional calculus (and "logic of noun
expressions", as Britannica calls it), not in mathematics. In
mathematics, variables mainly represent quantities -- and perhaps qualities too,
depending on how you look at them. The quality aspect is completely
(infinitely) generalised to represent any quality, unless units are given, in
which case, units restrict (specify or qualify) the quality. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> Actually, vector variables have
both quality and quantity. Magnitude is quantity, direction is
quality. </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> I agree with Mark on
names. One thought I have: names and naming is just one more relation
or attribute to be added to any given node/entity. All
relations/attributes should be taken into consideration if/when models
(worldviews) are merged. For example, if two nodes are candidates for
merger, and each has an attribute which are mutually exclusive, then these two
nodes cannot be merged into identical nodes. (I.e. their relation is not
the "identity relation", which is a vector of length zero; rather their relation
is some other vector of a finite, and probably small, length).
</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> For example, when merging
two theism models together, if one model says that a "god" is mortal (e.g.
Norse mythology, where gods can and do die) and the other says that a "god" is
immortal, (e.g. Mormonism), then we can't combine both "gods", because we are
not really talking about exactly the same thing. They have a shorter
relational vector than most nodes in the model will have, but it is not the zero
(identity) vector. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> Therefore, (I just wanted to
make sure we're all on the same page), identical names is not a sufficient
criterion for making the associated nodes identical. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> Furthermore, it's also not a
necessary criterion. </FONT><FONT face=Arial size=2>Two nodes having
the same name can be a sufficient reason to *consider* combining them, but not
necessary (e.g. synonyms, which must be compared using the other relations and
attributes). </FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> About language/notation: I've
recently been working on a idea modelling notation along the lines of predicate
calculus predicates. It's based on a very simple system (but can be
extended as needed) in which all operations and propositions are represented as
a three-token list, (recursively if necessary). This is a very simple and
straight-forward system that I'd like you guys to consider once I'm done with
it. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> It's fairly flexible. We
can leave it up to the user to decide which order these tokens come in.
For example, he might prefer the standard format of predicate calculus,
mathematics, and Prolog, like Mark seems to:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> P(O1 O2) or
P(O1,O2)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Or he might prefer the more enlightened format of
LISP :-) </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> (P O1 O2)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Or he might prefer this relation-enhancing
format:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> (O1 P O2)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> All of these forms are easily
accommodated. Here "P" represents the predicate, relation, operator,
function-name, internode, intranode, etc; and the two "O"s represent
operands, nodes, arguments, parameters, etc. There is a clear
distinction between internodes and intranodes in mathesis (i.e. there is a clear
distinction between functions and relations -- one is static, the other
dynamic), but there is also a clear and necessary and significant similarity
between them, too. The MME is basically a list of pairs of concepts, where
each member of these pairs is inseparably dependent on the other member of the
pair, like quantity and quality, symbolics and geometrics, etc. Another of
the main principles (points) in the MME is the dependency of the dynamic and
static portions of a model. The bottom line here is, operations are based
on relations. Therefore, I believe that the notation of functions should
be based very closely on the notation for relations. I think this
will be beneficial to the human reader as well as to the search algorithms
that process queries and other things, just like the pattern-matchers (like the
"unification algorithm", which I think is a silly name) in rule-based
expert systems and such. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> Conjecture: all knowledge can be
represented as a list of expressions, each of which is a combination of
(possibly nested) three-token lists. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> We wouldn't want to represent
all knowledge this way, but I think it should be based on this simple
form. And I think operators and functions should be a very slight
variation of the static relation notation, e.g. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> (P O1 [O2]) or (P O1 <U>O2</U>)
or (P O1 [ ]) </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> (I hope you guys have HTML-email
readers.) Here, the return value is one of the nodes in the list with
special indication, like brackets or underlining. For some functions,
the function name would be the token specified as the return value.
It all depends on what function you want. The significant thing to catch
here is, all relations have exactly three corresponding functions associated
with them, and therefore each return value can be indicated based on the basic,
static, binary-relational notation. I'll explain how all this works later,
if anyone is interested. But it sufficeth me to say that I strongly
believe that all knowledge, including all existing functions or operators in
math, logic, etc., can be represented as a binary operator plus its two
operands. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> Upon this, we can
define conventions for lists of more or less than three
atoms/tokens/variables to make it more flexible, and more "LISPy".
</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Luke, </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> yes, we can certainly find
someplace to discuss this stuff when you come. Jeremy and/or Doug has a
whiteboard. Or we could go to Thoughtform in Bountiful, which has
many. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Mark</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> I think I'm leaning toward the
meta-meta-model idea, but I don't think I understand the question well enough to
answer definitively yet. Let's talk about this.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>ciao,</FONT></DIV>
<DIV><FONT face=Arial size=2>tomp</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>----- Original Message ----- </FONT>
<DIV><FONT face=Arial size=2>From: Mark Butler <<A
href="mailto:butlerm@middle.net">butlerm@middle.net</A>></FONT></DIV>
<DIV><FONT face=Arial size=2>To: Thomas L. Packer <<A
href="mailto:TomP@burgoyne.com">TomP@burgoyne.com</A>></FONT></DIV>
<DIV><FONT face=Arial size=2>Cc: <<A
href="mailto:om-list@onemodel.org">om-list@onemodel.org</A>></FONT></DIV>
<DIV><FONT face=Arial size=2>Sent: Thursday, September 28, 2000 11:06
PM</FONT></DIV>
<DIV><FONT face=Arial size=2>Subject: Re: [om-list] Re: Cyc
example</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=Arial size=2>"Thomas L. Packer"
wrote:<BR><BR>> Mark, in Predicate Calculus
(including first order predicate calculus),<BR>> they are called
"quantifiers", including the existential quantifier and<BR>> universal
quantifier. <BR><BR>Yes. My mistake.<BR><BR>> The variables they
quantify are the qualities. <BR><BR>I have never heard variables called
qualities and cannot imagine why one would<BR>call them that. Do you have
an explanation and some references?<BR><BR>-
Mark<BR><BR>_______________________________________________<BR>om-list mailing
list<BR><A href="mailto:om-list@onemodel.org">om-list@onemodel.org</A><BR><A
href="http://www.pairlist.net/mailman/listinfo/om-list">http://www.pairlist.net/mailman/listinfo/om-list</A><BR></FONT></BODY></HTML>