Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: SUO: 21 May 2002 -- Unanswered Questions About SUMO Set Theor y



Dear Mathew,
Thanks for the reply.  I smile when you claim that procedural stuff is "easier."  I've worked both as a knowledge engineer and now more recently as a data analyst (Electronic Data Systems), where I spend a lot of time programming in the more conventional style.  I've often wondered which really is easier!  Try hammering out the MFC framework for writing good Windows apps--the learning curve is non-trivial, even for those with "Type-B" backgrounds.

John Sowa commented on how procedural programming was 'easier' as well.  But I think John's point is close to a non-sequitor.  So what about "how hard" something is to learn? If it's worth learning, count on people scrambling to get the training anyway.  As I mentioned, learning the subtleties of the MFC framework for Windows application programming isn't trivial, but it's quite a popular course of study for developers anyway. 

The anticipated response here is that KR is hard because there's no widespread adoption yet, and hence KR "training" seminars, and the like aren't available widescale either, thus exacerbating the problem.  True, KR has not been popularized for would-be developers, and they don't tend to think of it much.  Also true, people don't get enough set theory in CS undergrad majors, etc.  But that's stating the problem backwards, I think.  The market is efficient (or "greedy") enough to reward those with the right skills and thus to encourage the acquisition of those skills by others.  So we're probably putting the cart before the horse (so to speak) in suggesting that it's the fault of the "establishment" that everyone's gung-ho for while loops but a bit soft on FOL.  When we've got something they want, they'll come running with talent, training, and dollars.

I'm glad to hear that you see things changing, though.  I try not to be cynical about such reports and I think it's a welcome change whenever there is a recognized role for an ontology-based development effort.

best,

Erik

  "West, Matthew R SITI-ITPSIE" <Matthew.R.West@is.shell.com> wrote:

Dear Erik,
 
I buy most of what you say below. However, I would like to suggest a simpler
reason for Real People settling for Type B (procedural) solutions.
 
The procedural stuff is easier to do, and there are lots of problems around
that can be solved by it, and we haven't run out of them yet, so when faced
with two problems, one of which they know how to solve and one of which they
don't, they understandably pick the one they can solve (even if it isn't as
important). Don't forget that SQL is declarative (the core anyway) so it is
not that procedural stuff entirely rules the roost.
 
The only good news I can give you is that from where I sit, I can see that
some of the problems ontologies might be used to solve are just beginning to
achieve sufficient prominence that some of this stuff might get absorbed
into the main stream.
 

Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.r.west@is.shell.com
Internet: http://www.shell.com

-----Original Message-----
From: Erik Larson [mailto:elarson_78746@yahoo.com]
Sent: 23 May 2002 15:33
To: Pierluigi Miraglia; SUO
Subject: Re: SUO: 21 May 2002 -- Unanswered Questions About SUMO Set Theory

 First of all, Hi Pierluigi. How are you? I miss those cog sci discussions with you, Todd, and the rest of the crew (: Okay, you're a good philosopher, so here's a philosopher's argument, contra your position, Adam's, etc about the putative failures of the logicist camp (hope that term will work for you).

Allow me a brief detour here so that I might make my case a bit more clearly later. Call a 'Type-A' construct Bill's axiom:

(=> (and (parentOf ?x ?y)

(age ?x ?x-age)

(age ?y ?y-age))

(> ?y-age ?x-age))

Call a 'Type-B' construct any procedure coded in a standard programming language (I'm abstracting away from details about code here-OOP principles or not, language variations, interpreted versus compiled expressions.) Since it would be silly to paste in some huge chunk of source code, here's a ridiculously simple example that will do just fine for our purposes:

While (i < 100) {

Cout << "Hello SUO!\n";

++i;

}

Now, I take it that your claim is that Type-A constructs either haven't been conclusively discounted as valuable to the 'Real People' (RP) community, or that they in fact are valuable, and it will all be revealed in due course. I'll argue against both disjuncts.

For starters, the obvious thing to note here is that the burden of proof ought to lie with the Type-A proponents. That is a no-brainer: remember we're talking about the RP-community. They regard Type-B stuff as the lingua franca of their field--and it is. So Type-B is (trivially) valuable to their field (i.e., their field is constituted by Type-B constructs).

Now consider Type-A. What can be said in its defense? We can start with what's already been proffered by you and Adam Pease. What is that? A host of practical considerations: Type-A proponents have suffered from lack of focus on RP problems, insufficient funds, poor marketing, and even inadequate processor speeds (my favorite). This position isn't so much immune to argument as it is immune to conclusive argument-but that is all that's required for your purposes. I might claim that I have the genetics to run a marathon in three and a half hours. When someone points out that, well, it's been a year and I still weigh 240 pounds, had asthma as a child, and have never successfully run more than 5 miles without stopping since I was thirteen, I just need my list of practical excuses. No one can give me anything like a counterexample, because my whole training regimen thus far has really been just a string of partial successes, and anyway I'm working in it! W! hen I get enough money to get that new sports drink, and the sneakers...

Okay, you get the point. The upshot is: it's a burden of proof argument, and all evidentiary considerations point away from the viability of the Type-A program for assisting the RP crowd. Demanding "proof" of this negative claim, or acting as if the onus lies on the RP crowd or the Type-A critics is just abdicating the real responsibility and obfuscating where the real problems lie.

What else can be said in defense of Type-A? One thing I hear often is that a FOL axiom will give you new facts you may not immediately want, but that you just might need later. You show a little of this spirit, when you offer that:

Ah! But isn't that the point: that the statement (the

rule) could be_used_ in any of a great variety of ways, most of

which having nothing to do with the original intent of the asserter?

All well and good, but count on the RP crowd to be mighty skeptical. For one, the very reason they love Type-B so much is that there's a way of consistently solving the class of problems they need solved. To put it more directly still, the RP crowd needs to get consistently and reliably from some input M to some output O. That's just the way it is when you're a "real person." What motivates the Type-A proponents to bear down and keep going in spite of this simplicity (and hence increased visibility with failure) is not that the Type-A construct will beat Type-B at its own game-getting to N from M in demonstrably better fashion, that is. Rather, it is this faith in the superior expressivity of declarative approaches, embodied in Type-A constructs, that keeps it all going. This expressivity is a noetic notion; it allows one to say much more stuff about a domain (and hence at least humans will know more about the domain by inspection of formalisms). That is, ip! so facto, a great thing. But for the purposes of the RP community, it's apples instead of oranges.

And therein lies the rub: what is the connection between declarative power and inference? How exactly is superior expressivity supposed to solve practical inference problems for the RP crowd? The Type-A crowd acts as if by the fact of declaration alone, we all ought to be excited about the inferential possibilities. But no one has bothered to show exactly how this is so. Maybe it's because they can't. And this is where the history of failures becomes relevant: it's not for lack of trying, is it? (Is it really just for lack of trying?). Prima facie, If I told you that the way to get more Y (inference) is to throw all your time at X (FOL declaration), but gave no recipe for how X relates to Y and couldn't demonstrate this recipe over time, wouldn't you be sceptical? (Well, maybe I forget myself).

So I conclude that the Type-A proponents are missing a crucial premise in their argument, namely: "The Type-A construct really is suited for a computer (Turing machine) to turn its expression of facts into a powerful set of problem solving inferences, reliably and usably, for the RP crowd." This case hasn't been made. And given the evidentiary considerations to the contrary, and therefore the shift of the onus of proof onto the shoulders of the Type-A proponent, this argument is practically dead, or at least on life-support. Maybe someone can revive it. It will take more than additional talk about expressiveness.

cheers

Erik

  Pierluigi Miraglia <miraglia@cyc.com> wrote:


On Wed, May 22, 2002 at 01:45:54PM -0500, Bill Andersen wrote:
>
> On 5/22/02 13:06, "Pierluigi Miraglia" wrote:
>
> > The interesting question can then be raised about whether similar efforts
> > could be retooled and exploited to address such needs. Well, can they? I
> > for one would be most interested in hearing while either Cyc or SUMO or
> > IFF or... _cannot_ in your view be so retooled. This seems like a clear
> > question, both theoretical and practical, which many (though not I, sorry
> > to report) here seem well equipped to address, although not one that
> > benefits greatly from polling imaginary customers, or so I feel.
> >
> > So let me try to reframe the issue: what is it about an ontology that
> > _would_ make it suitable to address these ne! eds? And what is it with
> > existing ontologies that makes them unsuitable? I look forward to reading
> > your opinions.
>
> Hi, Pierluigi...
>
> An excellent question indeed. And it's hard to argue with your logic wrt
> the point I raised. Who let philosophers on this list anyway? :-D
>
> First, let me offer a few initial points to address the "unsuitability"
> issue, then I will try to offer some constructive opinions as to what might
> serve to make ontologies "suitable"
>
> * It is unclear to "real people" (by this I mean software developers,
> DBAs, data modelers and the companies who build tools to support them)
> just how to go about using this ontology stuff. This has been a failure
> of the ontology community on the whole, most of whose members come from
> an AI tradition, where such concerns have never been very important.

Is there a third categor! y besides real people and AI designers? I used to
belong there :)

This sounds right, I don't know enough. Is there such a thing as a
collection of "use cases" or typical scenarios that non-real-people might
inspect to get an idea? I remember that months ago you posted an example
having to do with 'organization' or some such on this list. Any more like
that?

But in any case, this looks like an integration problem itself -- between
cultures. So perhaps it might be solved by doing some meta-ontologising,
i.e., by creating frameworks and voccabularies in which the 2 (or 3)
communities may communicate with rather than ignore each other.

>
> * Systems based in first-order logic suffer an "impedance mismatch" with
> database and other systems (e.g. The semantic web) that will ultimately
> be based in some kind of database or logic programming technology that
> has the finite model property. It is a difficult ! problem to cast
> first-order theories into a form that can be readily used in these
> systems. Thus some fundamental work is required in this area.

Much exciting stuff going on there, but I need help: please elaborate if
you have time. Is the point essentially that FOL is much too powerful or
expressive for the sort of things you expect the semantic web to handle?

> * As you mention, such systems were not built with these sorts of mundane
> applications in mind. This is one area where the focus of the W3C
> "ontology" community gives them an advantage. One example of this would
> be an axiom in a SUMO or Cyc such as the following:
>
> (=> (and (parentOf ?x ?y)
> (age ?x ?x-age)
> (age ?y ?y-age))
> (> ?y-age ?x-age))
>
> Few would disagree that this axiom makes perfect sense, but from a
> pure FOL standpoint it can be used (only) in the following ways:
>
&g! t; 1. To prove that ?y-age is greater than ?x-age
> 2. To prove that the age of ?x is not ?x-age
> 3. To prove that the age of ?y is not ?y-age
> 4. To prove that ?y is not the parentOf ?x
>
> A database user, for example, is interested in NONE of these uses. For
> them, this is an integrity constraint.

Ah! But isn't that the point: that the statement (the rule) could be
_used_ in any of a great variety of ways, most of which having nothing to
do with the original intent of the asserter? That rule is precisely the
kind of statement you;d expect a half-decent ontologist to include when
giving a definition of the concept 'age-of' (or 'parent-of'). So your
example suggests to me that the rule, though derived probably from
apriori analysis, _can_ be used an integrity constraint on sets of data.
But note that it can still be used as a rule in a logical framework. So
we are making progress, aren't we?

BTW, ! I'd dare to guess that many ontologists conceive of such rules as
something very similar to "integrity constraints," if I understand your
expression: they are semantic constraints on the concept(s) involved.

(I think I might be implicitly disagreeing with your parenthetic 'only',
here: what can be proved from the rule is not the only concern of someone
toiling on a FOL system. Capturing logically valid sentences of a theory
is often the primary concern.)

>
> I promised to mention some things to help with the "suitability" issue.
> First, it should be clear that the points above give some clues as to some
> positive steps that can be taken. More concretely, my first step would be
> to find some industrial partners who would be willing to act as "guinea
> pigs" for some concrete applications of SUO, and to listen closely to what
> they say. Beyond that I can't say much more - my company has invested a lot
! > of our time and energy addressing the points raised above and (I believe) we
> have some good answers.
>
> Hope that is of some help...
>
> .bill

It is to me. However, remember also to provide some elements of
destructive criticism when you find the time: I, and probably others,
wanted to know why the extant ontologies we discussed before (cyc, sumo,
etc.) not only do actually but _will_ fail to fulfill these requirements.

thanks Bill,

--
- - - - * * * * * - - - - * * * * * - - - - * * * * * - - - -
Pierluigi Miraglia Cycorp, Inc.
Ontological Engineer 3721 Executive Center Dr.
(512) 514-2988 Austin, TX 78731



Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience



Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup