doug foxvog wrote:
> On Mon, November 19, 2012 16:44, Edward Barkmeyer wrote:
>
>> I think Amanda is right about getting lost in the academic descriptions
>> of the properties of reasoners and languages. I phrased my concerns
>> inappropriately, it seems.
>>
>> John Sowa originally wrote that no user asks for decidability, users
>> always ask for more expressiveness. I have yet to hear a user ask for
>> either. Industry users are interested in capability and performance.
>> They ask for more capability, but they want a guarantee of performance.
>> "Capability" is the combination of an expressive language for axioms and
>> questions and the availability of a reasoning tool that uses them to
>> return answers.
>>
>
> By asking for more capability, the industry uses are -- without knowing it --
> asking for more expressiveness.
> (01)
And as I said, tooling that does something useful with that expressive
power. Mostly that means "add a feature to something I'm already using,
so I can do more with it. Users rarely ask for something unlike
anything they have used before, unless it is clearly useful and
relatively easy to learn to use. (02)
>> Performance is the returning of answers in a reasonable length of time.
>>
>
> I note that performance is a scale, not a binary relation. It revolves
> around the quality of the answer as well as the amount of time it
> takes to provide it. Within reason, a user (industry or other) would
> be willing to trade off some time for a higher quality answer.
> (03)
Agree. But, as I have said once before, "no answer" is qualitatively
importantly different from any answer. The possibility or likelihood of
getting a response of "no answer" can kill a sale very quickly. (04)
>> Of course. But the line between DLs and FOLs *is* a sweet spot for
>> this.
>>
>
> Ed, i almost always agree with you 95+% of the time, but i beg to
> differ here. No business programmer programs in a DL language,
> from COBOL onward.
> (05)
Umm. Are we on the same topic? No business programmer programs in a
FOL language, either. If you are talking about COBOL as a prototype
"logic programming language", that is another matter. Those things are
highly restricted, negation does not have first-order semantics, and the
inferencing is procedural and explicitly directed. COBOL and Java and
OCL are logic languages, but not FOL languages. (06)
OTOH, database engineers and UML modelers have been developing
Description Logic models (unknowingly) for 25 years, discounting the
first 10 years of getting from Chen and Codd to IDEF1-X and NIAM and SDM
and actual usage in industry. What they didn't have, or didn't know
about, was the DL inference engines. What DAML and its international
counterparts did was to bring the formal DL workers out of the ivory
tower and get recognition for the value of DL rigor to the models
industry was already making. (07)
Amanda may be right that the industry uses of DL inference engines are
not very interesting by comparison with what can be done with directed
reasoning and hybrid reasoners that support Horn clauses and plugins.
But the users that are asking for more expressiveness in those things
are already more advanced, already using 1990s knowledge engineering
technologies, and hoping that something more can be patched onto the
existing reliable tools and algorithms without breaking them. They are
not asking for FOL capabilities and true FOL reasoners (which is what
John was comparing them with). (08)
OWL is for beginners and data modelers -- a much larger populace.
Unlike UML and EXPRESS and IDEF1-X, we can do something with DL models
other than draw understandable pictures and convert them to SQL schemas
or Java classes. There are reasoning tools that work reliably with such
models and produce two useful kinds of results:
- identifying inconsistencies in the models themselves, and
- reasoning about classification of instances, and about properties of
new subtypes (09)
These can also be done by production rules engines, using decision
trees, which is basically the DL algorithm. But their input isn't
usually something that looks like a database conceptual model and has
well-defined semantics. OWL has a standard expressive capability with
standard semantics and well-known and tested supporting algorithms. (010)
In addition, OWL encourages the development of well-defined user models,
because its semantics is well-defined, and because there are
completeness and consistency checking algorithms. Most of the 1990s
technologies depend on models in a proprietary language whose quality is
based on how well it appears to work, and whose formal semantics may or
may not be specified. (011)
>> There are many industry applications that can be met by DLs with
>> their measurable performance, in spite of the fact that their
>> expressiveness is limited and some of the axiom formulations are hard
>> for human experts to read. The land of FOLs is significantly more
>> expressive, but it has many more cliffs and sinkholes that make it much
>> more difficult to predict performance.
>>
>
> I note that a FOL can compute whatever a DL can compute in the same
> amount of time. So, how could a FOL be worse?
> (012)
An FOL per se cannot compute any thing. What FOL reasoner can do it?
Name one. (013)
On another part of this thread, John pointed out that it is the
combination of language and supporting tool that determines
"decidability" and performance. So, if I take an arbitrary OWL model
and convert it to ISO Common Logic, and then supply a dozen
classification problems in the form of 2 or 3 simple property axioms
about a new thing x and ask whether x is an instance of Class C, do you
know of a FOL reasoner that can be proven to do that? That is the
question. (014)
The FOL reasoner has more power, and far more embedded capability to
deal with more complex logical formulations. In theory, it should be
able to solve these simpler problems. But look at the reasoning
requirements in FOL for resolving issues like "A bicycle is a vehicle
that has exactly two wheels." The point of DL's set-based semantics is
that the language can express these ideas quantitatively, and the DL
algorithms can reason about set properties. A typical FOL reasoner can
do that only clumsily unless it has built-in "optimized set reasoning"
and "optimized numerical reasoning" capability, which some do. But that
capability is not implied by saying it is an FOL reasoner. (015)
> If programmed well, an FOL can compute far more calculations efficiently
> than a DL can compute at all. Note that the limitations on FOL are for
> the most extreme situations. It does not mean that any reasoning in
> the FOL will be undecidable.
> (016)
A language cannot compute anything. If you are suggesting that you can
program a faster classification algorithm in Java or Prolog, I don't
doubt it for a minute, but it is irrelevant to the issue. Those are
non-FOL logic languages, with specialized algorithms for their
specialized model theory. (017)
Most FOL reasoning tools have some kind of built-in arithmetic modules,
because they would otherwise be less useful altogether, but fewer have
optimized set -based inferencing concepts. So, No, in general, an FOL
reasoner cannot outperform a DL reasoner doing set-based classification. (018)
I find myself defending OWL and DLs because I see that industry is now
trying to use them, and in the process industry is finally beginning to
capture knowledge in a well-defined standard form that isn't half about
the implementation technology. Yes, it is ugly in certain ways, and
yes, the DL reasoners are very limited in their capabilities, which
limits the direct value to industry. The great advantage is getting the
knowledge captured in forms other than Java, SQL and XML schema which
bury the real intent in implementation claptrap. The formalized
knowledge, even when it is little better than a UML model is available
for processing by knowledge engineering tooling. And DL reasoners are
the first step; they produce the immediate return on investment. (019)
Industry in general is not trying to use FOL and FOL reasoners to the
extent that they are trying to use OWL and RDF. So I don't see scoffing
at those languages as "inferior logic languages" as providing a way
forward for knowledge engineering. (020)
If you think you can do better with FOL tools, at least you can convert
the OWL form to an FOL language knowing that you are preserving the
semantics. And then you can add knowledge using your additional
expressiveness and see what happens. But until some industry experts
write down the industry model, you can't start. Now, if you can
reliably convert Java programs or Jena rulesets to FOL axioms, you can
use them as engineered knowledge as well, and compare apples and
apples. But I don't think you can. (021)
What we have done with OWL and RDF is to create the knowledge
engineering starter kit, that comes with the books on knowledge
engineering for dummies and how to impress your boss with knowledge
engineering. It is no longer a black art. They are not the end of
industry movement to machine reasoning; they are the next step. OWL and
RDF tools may be primitive, and have limited capability, but they work
reliably, because they were designed to do that. There are many other
knowledge engineering tools that can be made to work reliably, and they
may be more capable. But the "sweet spot" we have with OWL and RDF is
that these languages have formal semantics, they have standards, they
have supporting tools, they have supporting books and tutorials, and
they have industry attention. As a consequence, we are finally getting
past thinking of Java, SQL and XML Schema as the forms in which
knowledge is captured. And that can only be good. (022)
-Ed (023)
> I remember a case in an algorithm's class where an inefficient order N
> algorithm was deemed "better" than an efficient NP algorithm. However,
> the complexity of the input necessary before the number of calculations
> curves crossed made this crossing point at over 10^105 calculations.
> I argued that the higher-order algorithm was "better" as no inputs
> given to both algorithms would come out with an answer first from
> the polynomial algorithm within the lifetime of the poser (or the poser's
> machine, or the poser's nation).
>
> -- doug f
>
>
>>> For all of these reasons, IMHO, decidability is a red herring. Worse,
>>> and to mix my metaphors, it is a red herring that has led far too many
>>> talented people on a wild goose chase when they could be doing much
>>> more useful work to advance the state of the science and technology in
>>> really valuable ways.
>>>
>
>
>> I'm not so sure that academic pursuits like decidability actually lead
>> talented people away from useful work. We have a rule that a Ph.D. has
>> to advance the state of the art. It means that to get a Ph.D from a
>> prestigious institution will require you to do a few years work in some
>> esoteric field like decidability. In the course of that work, you will
>> learn what all the academic terminology means, how the concept space is
>> related, and what the state of the art actually is. When you have the
>> degree, you can start doing "useful" things, that use some parts of the
>> knowledge you gained, and the skills you gained in comprehending
>> ill-written technical literature. It is unlikely that you will have a
>> direct application for what you know about decidability, but it is
>> equally unlikely that a talented mathematician will find an industry
>> application for counting graphs or proving the convergence of Sobolev
>> methods, or that a botanist will find industry application for isolating
>> cabbage genomes. The loss only occurs when the talented student isn't
>> prepared for the fact that industry is more interested in what else s/he
>> knows, and continues looking for interest in his/her academic
>> specialty. The purely academic pursuit is part of the rite of passage,
>> and the maintenance of expertise in it may later be important in guiding
>> others. The truly talented people will find useful things to do; the
>> others are just intellectually gifted. It takes most of us a long time
>> to understand what knowledge we really have and what its value is. Some
>> of the gifted never do.
>>
>> -Ed
>>
>>
>>> Best,
>>>
>>> Amanda
>>>
>>> On Mon, Nov 19, 2012 at 1:52 PM, Ed Barkmeyer <edbark@xxxxxxxx
>>> <mailto:edbark@xxxxxxxx>> wrote:
>>>
>>>
>>> [snip]
>>> Everyone agrees that FOL is more expressive and potentially more
>>> useful,
>>> but all of the reasoning procedures that are widely used in academia
>>> either restrict the allowable FOL inputs in some way that greatly
>>> reduces its expressiveness or are programmed to throw up their
>>> hands at
>>> some point -- they "halt" by saying "not determinable" (in some
>>> language). The problem of not knowing the relationship between
>>> input
>>> data -- the sets of valid sentences -- and the "not determinable"
>>> result
>>> is what causes industry to shy away from FOL reasoners.
>>> [sniip]
>>>
>>>
>> --
>> Edward J. Barkmeyer Email: edbark@xxxxxxxx
>> National Institute of Standards & Technology
>> Systems Integration Division, Engineering Laboratory
>> 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
>> Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800
>>
>> "The opinions expressed above do not reflect consensus of NIST,
>> and have not been reviewed by any Government authority."
>>
>>
>>
>> _________________________________________________________________
>> 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
>>
>>
>>
>
>
>
> _________________________________________________________________
> 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
>
> (024)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division, Engineering Laboratory
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (025)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (026)
_________________________________________________________________
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 (027)
|