John F. Sowa wrote:
> I strongly believe that we should support every useful technology.
> However, there are some people in the DL community (certainly not
> all) who have been using the word 'decidable' as a weapon to deny
> funding to every approach other than their own.
All is fair in love, war and funding searches. (02)
> EB> The problem with the use of an "undecidable language" for
> > interlinked Web ontologies is that you may not know when there
> > has been a minor addition or modification to one of the
> > ontologies your reasoning engine is using to answer your
> > queries, with the consequence that everything that worked
> > yesterday doesn't work today.
> The technology for dealing with those issues has been well
> established for decades.
> You don't give a student driver
> an Indie race car for practice. You give the newbies tools
> that put the appropriate constraints on what they can do,
I wasn't talking about links to unreliable ontologies. I was talking
about links to vetted ontologies that may only be slightly extended, and
have the effect of sending my reasoner into very long deliberations
because that one addition did something interesting to the search space
for a certain set of queries. (Typically, the problem is that the
addition made a lot of formerly apparently irrelevant knowledge appear
to be relevant.) (04)
> EB> I am only concerned about capturing available knowledge and
> > using it in certain well-defined patterns to make judgments.
> > And we hope that next year we will be able to do more with the
> > same knowledge base, using better engines or more knowledge
> > about how to steer them.
> "Next year" arrived a long time ago.
"What we have here is a failure to communicate." What I meant is that I
want to capture what the business expert tells me. I don't want to
restrict that to what I can express in OWL. I will use a subset of what
I captured, and some simplifications of the rest perhaps, with a current
reasoner to make useful decisions. Next year, I may be able to use a
better reasoner with a larger subset of the captured business knowledge
to make more difficult decisions. So expressiveness is key -- I want to
capture the knowledge that is available. I will reengineer that
knowledge for specific reasoning applications, but I don't want to
constrain what I capture to what can be used by the available technologies. (06)
> Using an IBM 704 in 1960, Hao Wang implemented a theorem prover
> for FOL that proved all 378 theorems in propositional and first
> order logic from the _Principia Mathematica_ in just 7 minutes.
> That was an average of 1.1 seconds per theorem. (07)
I'm afraid I don't see the relevance. The number of concepts in
Principia is small, and the number of postulates is small. And, like
Newton, if do the proofs in the right order, you can build on your
previous theorems. (08)
The problem with the "real-world" reasoning situations is that the KB is
built from an expanding database of individual facts coupled with a lot
of linkages. If every new base fact creates a lot of relationships,
that makes the complexity expand rapidly, but you can also have a lot of
apparently irrelevant facts suddenly become apparently relevant because
of one linking observation. (09)
> EB> The DL approach constrains what you can write, so that it
> > can guarantee results. For some projects, that is much more
> > important than allowing the capture of every nuance.
> I worked for a profit-making company for 30 years (IBM) and I
> am a cofounder of a startup company (VivoMind). I have the
> highest respect for projects that meet requirements on time
> and within budget.
> DL is just one of a large number of logic-based technologies
> that produce useful results for certain kinds of problems.
> Unfortunately, people are being forced to use OWL for tasks
> that it was never designed to do. They go through contortions
> that make Perl look like the epitome of structured elegance.
I fully agree. Part of that is the silver bullet mentality: OWL is the
best technology available; so whatever contortion you have to perform to
use it is the best you could have done. And we are both familiar with
the software engineer's pride of accomplishment in building a Rube
Goldberg device to solve a problem that would be a simple application of
a technology he is unfamiliar with. But we have made progress -- it is
not a primitive AI application coded in Fortran anymore. (011)
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (013)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (014)
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 (015)