Rick and Chris,
I'll begin by saying that I agree with the points that Chris M. made
about model theory, but I'd also like to make a few more points that
are related to the broader issue of what aspects of "meaning" are
missing in model-theoretic semantics. (I put the word 'meaning' in
double quotes to indicate that I'm using it in the very informal
sense of anything that anyone might consider relevant.)
As an example, I'll take a short snippet from another thread in this
forum. (My apologies for beating such a simple example to death.)
MAH> Two classes: Water and Fish.
> Restriction: Fish subclassOf livesIn some Water
> Two instances: Goldfish type Fish, River some Water.
To avoid distracting interpretations of the English words and all
the machinery of OWL, I'll just use short abbreviations and treat
the terms as though they were predicates
in predicate calculus:
Four monadic predicates: W, F, G, R.
One dyadic predicate: LIW.
(For all x)(There exists a y) F(x) -> LIW(x,y).
(For all x) G(x) -> F(x).
(For all x) R(x) -> W(x).
This specification gives us the signature (list of monadic and
dyadic predicates) and some axioms for a little theory. That
theory could be satisfied by infinitely many models. But the
only thing that those models can tell us is that those axioms
are consistent. That is certainly useful information, but it
is only a small part of "meaning".
Consistency is a *metalevel* term for talking about theories,
but there are many other kinds of metalevel terms that are
important for ontology. Aristotle, for example, would add
a metalevel comment about accidental and essential
For fish, living in water is an accidental property because
some fish can live out of water for a while. Way back when,
there were a few fish that crawled out of the water and became
amphibians. Aristotle would say that being an animal is a more
fundamental or essential property than living in water. Since
OWL permits multiple inheritance, we could add another axiom:
(For all x) F(x) -> A(x).
But we also have a problem about water. Unlike animals, which
tend to occur in discrete lumps, water is continuous stuff,
which can be subdivided very finely (as far as we can see).
And we have a serious problem in applying quantifiers like
"for all" and "there exists" to continuous stuff.
Therefore, we have to talk about "chunks" or "pieces" that
consist of water. But unlike solids, for which the term
'chunk of iron' is appropriate, water is a
liquid that must
have some kind of container to keep it from dissipating.
That brings us to rivers, which consist of water, but they
have an implicit container with boundaries called river banks.
Furthermore, they are continuously flowing so that the water
at one point is constantly being replaced by other water that
comes from upstream. Therefore, saying "All rivers are water"
(as the above theory implies) would lead to false conclusions
or inconsistencies if that theory were combined with another
theory that more correctly said "All rivers contain water
that is flowing."
The moral of this story is that even a tiny little theory can
very quickly delve into the depths of all the problems that
a large upper ontology is intended to cover. But even if we
picked one (such as Cyc, SUMO, DOLCE, BFO, etc.), there would
still be many more questions that are fundamental to "meaning":
- What is the purpose of this theory?
- Why have you chosen to define those particular terms?
- What is your application?
- Are those definitions and whatever other axioms you take
from some upper ontology consistent with the implicit
assumptions built into your intended application?
- What problems in those applications will your ontology solve?
- What new problems might it create?
All this and many more issues that go far beyond model-theoretic
semantics are involved in the informal notion of "meaning".
RM> I think model theoretic semantics (MTS) should become more
> than good old fashioned model theory. I use this term as it
> has been used by Harold Simmons here ...
That book is a good 180-page summary of the topics that are
covered in a typical course on model theory. But note that
not a single one of the questions I discussed above are even
mentioned, much less answered by anything in that book.
I agree that much more is needed, but I don't believe that it
belongs in a course on MTS. A course on ontology might be a
better home, but most such courses have now degenerated into
OWL-hacking (which generates examples such as the one above).
RM> If the patterns or idioms from applied semantics do exist can a theory
> of meaning be established based on them? Where in this case meaning is
> both denotation and interpretation, whether intended or unintended.
I wouldn't derive a theory of meaning from the applications,
but I would certainly want anybody who derives a theory
more general considerations to test it on as many applications
as possible before presenting it as a standard for the world.
RM>>> ... and complex enough signatures to include
>>> symbols that are interpretants, signs and objects.
CM>> You lost me.
RM> Here's a diagram with labeled nodes and edges.
That is an example based on Peirce's semiotics, which I strongly
recommend. But CSP wrote many volumes of published and unpublished
manuscripts, in which he covered an enormous range of topics.
I would not recommend any single excerpt from Peirce's writings
or anybody else's (including my own) as a universal foundation.
In the 1990s, the standards bodies were talking about "proactive"
standards instead of
giving their blessing to already accepted
de facto standards. The W3C took that advice and ran with it.
Two bright guys, R. V. Guha and Tim Bray, sat down and came up
with a first-pass cut at a simple knowledge representation, which
they called RDF. Now, even Tim Bray admits that it was a mistake.
But it's a world-wide "standard" that cannot be changed.
As another example of the opposite approach, remember the design
competition that led to Ada in the early 1980s. The DoD sponsored
the competition for a new programming language, and they did almost
everything right in specifying requirements and sponsoring several
levels of tightening specifications (Strawman, Woodman, Tinman,
The winner of that competition (later named Ada) was not bad, but
it suffered from a tragic flaw. And like the ancient tragedies,
the flaw resulted from the hero's hubris -- in this case,
a committee of very good experts who considered themselves
omniscient. They declared that the complete Ada definition
was a sacred tablet whose commandments must be obeyed in
their entirety. They prohibited heretics who ignored any
of the commandments from adopting the sacred name.
Since Ada had been strongly influenced by Pascal, everybody who
had a Pascal implementation immediately modified their software
to add as much of Ada as could be quickly built on top of the same
foundation. That subset, which should have been called Ada 1.0,
included all of Pascal plus some widely implemented and tested
features that were very useful. Borland and many other vendors
implemented that subset in six weeks and demonstrated it on the
platform that was rapidly becoming a de facto standard: IBM PC.
Unfortunately, DOS did not support multitasking, and full Ada
untested, untried multitasking model that could
not run on DOS and was widely criticized as its weakest feature.
If the DoD committee had approved the obvious subset, Ada 1.0
would instantly have replaced Pascal as the standard for the
IBM PC and hence all future system software.
Instead, DoD refused to allow subsets, and the world got stuck
with C -- a language that violated every requirement specified
for Ada. C had and still has many flaws that were corrected
in the Ada 1.0 subset, which was small enough that it could be
compiled with the same efficiency as C. Furthermore, the Ada 1.0
foundation was clean enough that it could have been generalized
to a much better object-oriented language than C++.
The moral of this longer story is that the Ada approach was too hot,
and the W3C approach was too cold. For the Goldilocks solution, I
would recommend a design competition, such as Ada, guidance
committee, such as DoD or the W3C, and a more democratic way of
voting than any committee can support: let the users decide.
My recommendation is for a design competition similar to the
one that led to Ada. Let the committee evaluate the proposals
and implementations and make its recommendations. But instead
of blessing a single winner, the committee could award prizes
to the ones they liked best. However, *all* the submissions
would be made publicly available, vendors would have the rights
(copyright and patent free) to pick and choose any of the
submissions or any combination of them, and everyone could
choose any implementation they preferred to use.
This competition could have multiple stages, as Ada had.
But users and vendors could participate in every stage in
any way they chose. And the committee could use feedback
from all the users, implementers, and vendors
making any final determination of an official standard.
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
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