Dear Matthew, Pat C, Sean, Len, and Doug, (01)
MW> I suspect we don't really disagree but... (02)
Yes, we seem to agree on the basic issues. (03)
MW> But no amount of logic can capture *all* the meaning of a term. (04)
I very strongly agree. (05)
PC> But in practice many potential relations are left out, solely
> for the pragmatic reason that what is in the ontology is enough
> for the current applications that use it. (06)
I'm happy that I can agree. In fact, I would say that adding too
much detail can sometimes be counterproductive, since it can make
a program more specialized than it needs to be. (07)
PC> Documentation can also help reduce residual ambiguity of elements
> that are not specified by necessary and sufficient conditions, and
> in that way reduce the chances that a programmer will misuse the
> element (e.g. not mix up an "Employee Identification Number" and
> a "Social Security Number" unless they are identical in some
> enterprise). (08)
I agree that clear English prose is better than what most programmers
are forced to work with. I would also add that good diagrams (such
as UML) can also be excellent documentation. Furthermore, good tools
could be used in automated or semi-automated translations from clear
"English-like" prose and diagrams to logic and even to executable code.
See the following slides: (09)
http://www.jfsowa.com/talks/cnl4ss.pdf
Controlled natural languages for semantic systems (010)
SB> The principal interpreter of the world to a computer is the human... (011)
I agree. The semi-automated systems I mentioned above would enable
the human and computer to collaborate. The human would be the ultimate
judge of meaning, and the computer could speed up the processing. (012)
SB> In an enterprise, I would assert that
>
> a) the terms used well understood by the people operating in that
> enterprise AND
>
> b) the terms exactly correspond to the decisions that are significant
> to that enterprise
>
> Given this restriction, it is then possible to encode the enterprise
> specific rules that can be used to define the terms. (013)
I agree, and I believe that controlled NLs can support that process. (014)
SB> When you assert "The rules expressed in those notations will have
> to make the intended meanings explicit with the same level of
> precision as any engineering discipline" in my view, this is not
> a matter of general knowledge about the world, but of the recognisable
> constraints on "normal" usage that an enterprise imposes. (015)
I agree. When I said "knowledge about the world", I considered the
enterprise for which the applications are being developed to be a
very significant, if not the most significant part of that world. (016)
MW> There is still the model theory and the intended interpretation
> that is beyond logic. (017)
The model theory is a metalevel theory about the term rather than
an object level application of the term. For the most important
technical terms, the metadata associated with an ontology should
contain much, if not most of the intended meaning that is useful
for applications. (018)
MW> I will happily agree that capturing more of the meaning in the
> logic is better than capturing less, since it increases the amount
> that can be automated. It is just never possible to capture all of it. (019)
Yes. I would summarize the issues in three points: (020)
1. There is no such thing as a vague program. Every computer
program does something that can be very precisely specified. (021)
2. But what it does so precisely may have no similarity to
what the designer, programmer, or user had intended. (022)
3. The goal of formalization is to tighten the specification in
order to make the implementation conform more closely to the
intentions and expectations of the programmers and users. (023)
JFS>> We have two options:
>>
>> 1. Admit that encoding background knowledge in computer systems
>> is a futile exercise and continue with the programming
>> practices that have evolved over the past half century.
>>
>> 2. Develop formal ontologies that enable computer systems to
>> reason with and about the "intended meaning" of the data
>> they receive from humans.
>> (024)
LY> Are 1 and 2 mutually exclusive? (025)
No. I should have said that the traditional programming methods are
not obsolete and will continue to be used for many kinds of programs
for a long time. (026)
LY> I think the programming practices have been evolving in the
> direction of encoding background knowledge, be it on a less
> formal basis than ontology. (027)
I agree. Database systems, for example, encode knowledge about the
data in constraints, rules, and queries. The SQL WHERE-clause,
which is used in all three of them has the expressive power of FOL. (028)
LY> Does option 1 imply that various degrees of precision can not
> co-exist? I think option 2 simply augments option 1 and I don't
> see anyone making the choice any time soon. (029)
I agree. Large systems combine multiple kinds of software for
the user interfaces, the computations, and the various kinds
of reasoning about various kinds of data. (030)
LY> I believe the precision used by engineers is often much less
> than that used in corresponding mathematical calculations. For
> example when calculating dynamics of mechanical structures like
> bridges the engineering methods are intentionally imprecise in
> allowing for unanticipated loads and dynamics. (031)
Yes, but every branch of science and engineering always uses
approximations, even though the mathematics may be extremely
sophisticated. Even with the fastest supercomputers, major
approximations are necessary for large problems. In fact,
exact solutions are extremely rare, except in very special cases. (032)
LY> And computers are enormously useful in mechanical engineering
> without full (or any at all) understanding of human intentions. (033)
I agree. The same is true for knowledge engineering. The human
intentions determine what subject matter the engineers represent,
what they say about it, and what approximations they make.
But the resulting representation has nothing but math & logic.
There are no human intentions visible in it. (034)
DF> To encode ALL that background knowledge is the Cyc vision. (035)
Doug Lenat never expected to encode *all* knowledge. His hope
was to encode enough knowledge to enable Cyc to read books in
order to gain more knowledge. But they're still far from
reaching that goal. (036)
DF> The specs can be precisely defined (to some level of accuracy)
> in a natural language. It is up to the programmers, not the
> computer, to interpret the specs so that they don't write
> incompatible code. (037)
I agree with both of those points. But a great deal can be done
with semi-automated methods for mapping the specifications to an
executable form. In such methods, the programmer is responsible
for the interpretation, and the computer helps to carry out the
details of the symbol processing. (See, for example, the way
mathematicians, scientists, and engineers use Mathematica.) (038)
DF> The rules and terms (relations, types, and individuals) would
> not be grounded in mathematics or logic. Reasoning via the rules
> based on the terms and statements in a knowledge base WOULD
> be based on logic. (039)
I don't know what distinction you're trying to make. Relations,
types, and individuals are the building blocks for making statements
in logic. Various reasoning methods (deduction, induction, and
abduction) process those statements. But I would say that logic
includes the building blocks, the statements, and the methods
for processing those statements. (040)
JFS>> ... with the same level of precision as any engineering
>> discipline -- i.e., the precision and techniques used in
>> writing mathematical formulas. (041)
DF> The referent for many terms would have to be defined in NL. And
> the boundary conditions for terms would be hard to define. Can
> we formally define a cat? Certainly one could formally define
> a chair, but each ontology to be mapped to would probably have
> a different definition. It might be nice to describe fuzzy
> boundaries for concepts. (042)
Note Len's remarks about approximations in engineering and my
comments above. It's impossible to describe any natural system
precisely in full detail. That's true of all branches of science
and engineering -- including ontological engineering. (043)
But even when engineers make drastic approximations before
applying the mathematics (including mathematical logic), they
are still using mathematics and/or logic. (044)
John (045)
_________________________________________________________________
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 (046)
|