Ed, (01)
In more recent replies to Elisa Kendall and Ray Martin, I softened some
of my criticisms of API4KB and asked some further questions. Your note
raises more points. I agree with some, and I would question others. (02)
> At each level of interest, an architecture is a definition of functions,
> a description of specific components in terms of their functions, and
> a specification for the points at which the components interoperate
> (a set of interface specifications). The architecture forms the basis
> for the detailed specification of a system. But the external interface
> to a system is not dependent on its architecture! (03)
I agree with the opening sentences. But the final sentence raises
the question "What do you mean by external?" That question leads to
more questions about words in the earlier sentences: level, function,
component, interface, and interoperate. (04)
> The external interface specifies the functions provided by the system
> "as a whole", or more accurately "as they are to be provided to clients". (05)
What do you mean by whole and clients? Look at some systems designed
by very knowledgeable people: Cyc, IBM's Watson, and the systems
developed at Vulcan. (See the note below from the CG mailing list.) (06)
> If your architecture includes a component with functional capabilities
> that are consistent with a capability set that is adequately described
> by the API4KB, then you could use the (appropriate variant) of the
> API4KB as the interface definition for that component (subsystem). (07)
Nothing in the systems from Cyc, Watson, or Vulcan has a "capability"
that matches any component of the other -- or of API4KB. Google is
another big company with lots of internal R & D. But their tools
don't map to the components of Cyc, Watson, Vulcan, or API4KB. (08)
> If you are truly ambivalent, give the effort a chance. (09)
There is one point that softened my criticisms of API4KB and suggested
that it might fill a need: the possibility that the API4KB designers
might collaborate with the OntoIop developers and/or Benjamin Grosof. (010)
Those people know logic. If they could get logic into the foundation
for API4KB, that would make a useful contribution. But without logic,
it's impossible to express the *knowledge* in a knowledge base. (011)
John (012)
-------- Original Message --------
Subject: Knowledge Acquisition from documents
Date: Sun, 30 Jun 2013 13:59:51 -0400
From: John F Sowa
To: cg@xxxxxxxxxxxxxxxxxxxx (013)
Knowledge acquisition by reading books is one of the oldest goals
of AI. It was one of the primary goals of the Cyc project, which
was founded in 1984. The Digital Aristotle project at Vulcan Inc
has been addressing that issue by automated and/or semi-automated
methods. Last week, Vinay Chaudhri from SRI International presented
a talk about their collaboration with Vulcan on that problem: (014)
http://ontolog.cim3.net/file/resource/presentation/VinayChaudhri_20130627/KB-Bio-101--VinayChaudhri_20130627.pdf (015)
The title summarizes the issues: "KB_Bio_101: Conceptual Modeling
Challenges in Creating a Biology Knowledge Base". (016)
Following is the audio of that talk: (017)
http://ontolog.cim3.net/file/resource/presentation/VinayChaudhri_20130627/Ontolog_VinayChaudhri_KB-Bio-101_20130627b.mp3 (018)
On a related theme, Benjamin Grosof and Paul Haley, who had worked
at Vulcan, are now trying to commercialize their technology. Following
are slides they presented at the Semantic Technology conference in June: (019)
http://coherentknowledge.com/wp-content/uploads/2013/06/grosof-haley-talk-semtech2013-ver6-10-13.pdf (020)
Paul Haley has also posted a considerable amount of material about
these and related issues on his web site. Most of his web pages
have pointers to related slides and documents: (021)
http://haleyai.com/wordpress/2013/06/15/deep-question-answering-watson-vs-aristotle/ (022)
This web page contrasts their approach with the methods used by IBM
for the Jeopardy! game. I believe that the methods are complementary
rather than conflicting. (023)
http://haleyai.com/wordpress/2013/05/28/background-for-our-semantic-technology-2013-presentation/ (024)
This web page has some discussion and many pointers to background
material related to the slides by Grosof & Haley cited above. (025)
http://haleyai.com/wordpress/2013/06/27/neat-vs-scruffy-and-watson/ (026)
This is a further elaboration of some issues above. Paul H. also
mentions some discussion with me: "Essentially, the neat approach
is more viable today than ever. So, chalk one up for the neats,
including Dr. Sowa..." (027)
My main clarification is that I have always acknowledged the importance
of both the neat & the scruffy methods. I said so in my 1984 book,
and I strongly agree with Alan Perlis: "You can't translate informal
language to formal language by any formal algorithm." Both neat and
scruffy methods are important for different aspects of the problem. (028)
John (029)
_________________________________________________________________
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 (030)
|