RE: SUO: RE: Re: Missing Ingredients
Murray Altheim wrote:
> Richard Cooper wrote:
> [...]
> > I've been impressed with Lenat's published work on AM and Eurisko,
> > but there hasn't been anything detailed published on Cyc in the
> > open literature that addresses the issue of completeness and human
> > realism. Most of the Cyc work, according to legend, has been
> > in military and intelligence fields, which can support such
> > projects at a loss for many years. I don't have that kind of
> > funding.
>
> Yes, the system I saw in 1979 was a prototype for the US Navy, and
> Cycorp's funding (to my knowledge) has come in large part from
> government grants and projects. I think this is probably why there's
> not been a lot published. It's both trade secrets, military secrets,
> national security, market niche, etc. I think Doug is still pretty
> generous in giving away the ontology, regardless of who paid for it.
>
> > So yes, in general, Cyc is a good example of such an application,
> > but the public details are lacking. Certainly the ontology
> > without software to get up and running quickly is a serious
> > drawback.
>
> Well, it's only a drawback if one considers it didn't exist at all.
> I think more about the fact that even if other components exist,
> *one* of the more interesting parts is being given away. It'd be
> great if the NL stuff was too, but beggars can't be choosers.
Actually, for my purposes, it doesn't help to have one leg
of a table, but be missing all the other parts. I have no
interest in being a beggar.
> > Secondly, Cyc software is in Lisp, which is commercially as dead
> > a language as Latin. Customers have Windows computers by the
> > zillions, and Macs and Linux 386 boxes in large numbers, but
> > very few commercial systems run on Symbolics computers anymore.
>
> I'd say Esperanto rather than Latin, but yes. They still use
> LISP and variants around here at KMi, but I don't consider that
> anything more than legacy, both in terms of systems, invested
> software and training. And the local expertise is in LISP. Few
> if any of the recent KR systems I've seen have used LISP. Some
> in Scheme... but most of the systems lately seem to be even
> simpler than the stuff done a decade ago in LISP, so I must
> say that there must be *something* in LISP that still holds
> sway. I can't say I'm proficient in it, but if I had to learn
> one now, it'd probably be scheme or prolog. (OTOH, Cyc isn't
> really written in LISP but its own CycL language, which may have
> as strong a relationship to LISP as does prolog or scheme. I
> don't know, never looked into it much.)
Scheme, CycL, Common Lisp, ... are all dialects of Lisp. Some
dialects are better, some are worse, but they are all still
Lisp with a macro superstructure. The issues that Lisp doesn't
address, but which are seriously important in commercial
applications, is legion. I certainly enjoyed programming the
Symbolics for a few years in the late 80's, and InterLisp,
and Scheme, and Common Lisp, but the drawbacks for deployed
commercial system in Lisp are enormous. Its a great research
language - my favorite in fact - but it's just a conceptual
language, not a deployment language.
And translating from Lisp dialects to anything deployable is
essentially impractical. The only thing commercially useful
that comes out of Lisp projects is a requirements document that
engineers can write after studying the external behavior of
the Lisp prototype.
Not that I don't find Lisp important and useful - on the contrary,
I think having that language to do research and to build
prototypes has had dramatic effects on computer science in
the last 40 years. I was fortunate enough to work with
Dan Edwards in the 70s. Dan was McCarthy's programmer at MIT
who wrote the first Lisp interpreter, and I was actually so
fortunate as to have him teach the first Lisp class I took
then. He showed me the majesty and power of Lisp, and I
loved it from the word go. However, it just isn't a deployable
language that any serious analysis would confirm for typical
commercial systems. The response time is not predictable,
the ability to train maintenance programmers is dismal, and
the OS and driver support is highly lacking.
> > Do you feel that Cyc would be good in a commercial application?
> > My impression is just the opposite, but I haven't seen Cyc in
> > action. My interests and funding come from commercial sources,
> > so my focus is in that direction.
>
> No. I wish Cycorp all the best, but I don't see projects like this
> as commercially viable. In order to get to the point where it's even
> *conceivably* viable, it's taken a huge amount of investment,
> in terms of money, human time and energy. Now, using just the ontology
> as a framework ontology for a different system, I dunno. I'm sure
> somebody will try. It's too rich a vein to not *try* to tap. I
> have seen it in action, and it is pretty cool. You can ask questions
> in English about movies, and it queries the online movie database
> to answer the question. Cycorp may somehow take this into the
> commercial arena and make money, but they might be the only ones to
> do it.
That's why I like Delphi as the deployment language, and relational
database technology as the symbolic processor for commercializing
these applications. Lisp prototypes in Common Lisp make a great
starting point for a requirements document. Then add the deployment
requirements. Then use Delphi/SQL as the deployment vehicle, and
you have an object-oriented, responsive, capable system.
WordNet is good because it comes in a normalized relational format.
Unfortunately, Open Cyc does not. If it did, and if the vocabulary
were from WordNet or other major lexical sources, it would be
more accessible. Perhaps some time in the future, if Open Cyc
is better supported and more relationally organized, these choices
will change. I hope so. But for now, that's the best bet.
> Murray
JMHO,
Rich