Dear John, (01)
You wrote, among other things: (02)
>... logic is simpler and more general than any
>programming language. Anything you can represent
in any program
>can be defined in logic in a way that's
independent of the many
>constantly changing features of NLs and
programming languages. (03)
I strongly disagree with this judgment. Logic
programming languages such as prolog, or rule
based expert systems are deceptively simple, and
don't cover all the functionality that a
programming language covers. It may look more
intuitive and certainly simpler than programs, but
logic has its own area of most valuable usage, and
that area overlaps with programming languages, but
cannot compete in other areas. (04)
The thought process is very simple; if logic is
so easy, and so simple to learn compared to
programming languages, why are there so many
nondeclarative programming languages? Nearly
every major software product is written in a
procedural language, or most likely five or six
such languages. (05)
Relational DBs can do nearly anything prolog can
do, but more efficiently, with SQL. But SQL has
its own niche, which is also distinct from logic,
in that it supports very large databases, while
logic programs are nearly always tiny. (06)
Logic programming languages have their place all
right, and certainly monopolize the inference
process, but even programming languages can do
logic if given a unification method. For my Elk
for Patents, I use inference, but it is written in
Delphi, not in a logic programming language,
because of the difficulty of mixing logic
programming with procedural programming. In
nearly every application (excluding credit
agencies, government, and academic research),
procedural languages are vastly more widely used. (07)
-Rich (08)
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2 (09)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of John F Sowa
Sent: Tuesday, June 17, 2014 8:57 AM
To: ontolog-forum@xxxxxxxxxxxxxxxx
Subject: Re: [ontolog-forum] Requesting Opinions
on the Benefits of Predicates as Nodes (010)
Mark, Rich, and David, (011)
On the technical details in this thread, I agree
with Pat.
But there are a huge number of design issues and
wishes
bound up in very complex ways. Some fundamental
comments: (012)
1. Complexity: An unfortunate aspect of large
systems and standards
for them is that they put far too much into
the core. The result
is a huge blob with an overwhelming amount of
parts, details,
and terminology for them. (013)
2. SBVR: This happens to be the issue of the
month, and it's
as good an example to start with as any. But
the same issues
and complaints arise with large systems of
any kind, including
operating systems, database systems, Semantic
Web, etc., etc. (014)
3. Onions and layers: The single most important
paper on how
to design a large system was Dijkstra's 1965
paper about the
T.H.E. operating system. All the commercial
vendors said that
it was unrealistic for large systems. But of
all the major
systems today, the most successful are the
ones that come
closest to preserving the onion structure:
BSD Unix is the
core of all the Apple systems, and Linux is
the core that
supports the largest supercomputers, the
largest server farms,
and the majority of cell phones. (015)
4. User interfaces: People once complained that
Unix was
"user hostile". Ironically, the most
user-friendly systems
today are based on some version of Unix.
Systems that try
to put "user friendliness" into the core end
up with a complex
mess that is unfriendly for both users and
system developers. (016)
5. Implementation: Ad hoc changes in the core
for some special
purpose are always a mistake. Windows NT
version 3.5 had a clean
core (based on the OS/2 design). But Bill G.
insisted on putting
the screen handler beneath the core for
"improved performance".
As a result, NT 4.0 and all its successors
are less secure and
more crash-prone. By contrast, the original
Macintosh had a
great user interface supported by
unmaintainable spaghetti code.
For the NeXT system and Mac OS/X, Steve J.
built a better user
interface on top of BSD Unix. That decision
was better for both
end users and system developers. (017)
ML
> The intended user set of both SBVR and the
Date-Time Vocabulary
> is business analysts and maybe some business
people, not
> philosophers or physicists. (018)
That excuse inevitably leads to disaster. Users
never see the core,
and putting the user's point of view into the core
helps nobody. (019)
It's interesting that you mentioned physicists,
because Dijkstra
had a PhD in physics. That may have enabled him
to see that what's
under the covers need not resemble the user
interface in any way. (020)
RC
> Why solve problems that have already been solved
another way for
> the calculated dates, times and durations? The
only reason that
> occurs to me is based on inference or other
logic. (021)
To answer the first question, there is an
open-ended variety of
different ways of representing time. Any standard
for dates and
times must support *all* of them and relate them
to the common
conventions used in programming systems and
everyday language. (022)
For the second point, logic is simpler and more
general than any
programming language. Anything you can represent
in any program
can be defined in logic in a way that's
independent of the many
constantly changing features of NLs and
programming languages. (023)
DW
> To my way of thinking, July is the name of the
(infinite) set
> of all time intervals that can be classified as
overlapping with
> the month of July in any year. (024)
That's one possibility, which may be useful for
some applications.
But all applications should be able to share data
that says
"The US Declaration of Independence was signed on
4 July 1776." (025)
Different systems with different "microtheories"
and different
legacy software must accept data at that level of
detail and relate
it to whatever reasoning or computational methods
they use. (026)
Fundamental principle: Every large system of any
kind must be
built on a very clean and simple logical core.
That core should
*support* all the languages (natural and
artificial) above it,
but it should never *depend on* the details of
anything above. (027)
All the complexities of SBVR, Windows, the
Semantic Web, and
many other system are the result of violating that
principle. (028)
The SW layer cakes, for example, put XML, RDF, and
URIs in the
foundation, and they put logic on top of them.
That decision was
a mistake, and the W3C keeps redefining that
so-called foundation. (029)
Notational and implementational details change
constantly,
but the semantics of FOL has not changed in over a
century. (030)
John (031)
__________________________________________________
_______________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr:
http://ontolog.cim3.net/mailman/listinfo/ontolog-f
orum/
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?WikiHomePa
ge#nid1J (032)
_________________________________________________________________
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 (033)
|