| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Everyone,
I really hate this emailer! I just viewed my comments and they're not so readable. I will save this ANSI from notepad...........
Oh I should include: see my responses to Mike below:
Mike,
We've had offline discussions about topics here and there but I suppose I never really answered you directly. Sorry. Nothing intended, just busy.
At 07:31 AM 6/2/2002 -0700, Erik Larson wrote:
That is my lead-in to ontology considerations: build ontologies with solutions to problems in mind! If you already have an 'Ontology', reformulate it to cover a set of solutions important to your customers (or to facilitate a set of apps you have or want to build).
Practically speaking, this will mean at least two things:
1. Upper Ontology concepts are necessary (e.g., for partitioning categories of things: keeping disjoint categories disjoint, etc), but it's silly to spend a lot of effort writing axioms for high-level terms, since the rules will almost always have consequences that no one cares about, and even if they might in some cases, it's not as if you'll know what this value will be beforehand, and be able to pre-empt the process by making your terms and rules "up front." Also the terms themselves will tend to change as different inference requirements change. Even if you can define a bunch of 'context' theories an! d cram terms into them to preserve local consistency, truth,relevance, etc, the way the contexts themselves have been chosen will also need to change as different problems are posed. This suggests a minimalist approach to upper ontological terms (for that matter, of ontologies generally)--the less "bloat" you can get by with, the better.
Mike Pool:
Hi Erik:
Your points here have given me a lot of pause for thought. I think that I disagree a little bit with your ontology heuristics, here but let me try to get clearer on what you're claiming here and also try to give some general indication of why I think I might disagree.
Regarding your point in (1), I'd like you to provide a bit more argument or clarification here. If we think that a concept is important enough to include in our upper ontology, why assume that its meaning isn't relevant enough to bother to attempt to further articulate with axioms? You seem to have acknowledged that subtyping and disjointness rules are important for upper ontology concepts. How do you jump from the acknowledgement that the conclusions from subtyping and disjointness rules will be entirely germane to our applications to the assumption that rules that articulate any other kind of information are, as a default rule, usel! ess? This isn't obvious to me.
Erik Larson in response to Mike Pool:
Well, you don't like this comparison but I think it helps illustrate what I keep harping on: suppose someone were to build the Golden Gate bridge, but out of sand--just hard enough for the structure to stand, but noone could walk or certainly not drive on it. That would be a magnificent thing and an engineering masterpiece-- imagine Golden Gate bridge composed of sand! But why is it a bridge? What use is it? That is what I *don't* want to conclude about an ontology. And I think one of the ways to avoid this is to be ever diligent about making sure that the axioms that aren't application specific (they're not directly constructed for derivation of consequences) are a minimal set. What does that mean? Well, that is why I thought we might need partitioning--because as Bill is fond of saying, you want a computational ontology to weed out bad interpretations. But how much&nb! sp;axiomatization does it take to do that?&n! bsp; Here I think the idea is to get clear what the ontology will do by way of assisting an application that will link to it. Outside of this prosaic focus, you'll be in the weeds and wasting time and resources.
Erik Larson:
2. Large chunks of ontological terms won't be reusable from domain to domain, because they must be choosen to fit with axioms that are written to get a set of specific derived consequences for end-users. This will naturally tend to make a vocabulary more specific to its uses. I've seen how this happens first-hand, in a prior engineering project where our team had, ostensibly, lots of concepts already asserted in the KB on our topic for us to use. Once we clearly understood the problem-space however, it was obvious that we had to ignore large chunks of the pre-existing terms to make any progress. Even when we could partially salvage existing knowledge, it had to be re-written in a way that would facilitate the specific needs of our project, and this took practically as much time as creating everything afresh. (True, some of the upper ontology terms were more reusable, but also less relevant).
Mike Pool:
I'm not quite sure that I understand the first two sentences in section 2. Regarding re-use, of course, you're correct that there is a lot of different knowledge that will be germane to a domain and we shouldn't assume that rules written for one facet of the domain will be reusable for reasoning about another facet of the domain. If you give me a set of rules designed to reason about automobile purchasing it's possible that it may not be very useful for reasoning about automobile repair. I may have to write new rules for reasoning about automobile repair. This claims seems to be true and noncontroversial but is there more to it than this?
Erik Larson in response to Mike Pool:
Well I think I was driving at the irony of creating huge chunks of terms ostensibley for reuse and then having them not reusable anyway. The whole 'reuse' issue needs to be thought through carefully, I think. I my forays into conventional programming I see models of reuse that are clear and obvious enough (if I write a method for calculating interest on a loan, I can call that method in scores of programs without rewriting it, and it's easy to see how that saves me time). Reuse of ontologies is different, both practically speaking (ontologies tend not to get reused nearly as often as one might expect or hope) and for some principled reasons that are going to be difficult to articulate. Basically, it has to do with notions of semantics and the sense we give terms when we create them with one thought in our heads, then change to a different context and realize it's just not quite right, etc etc. (this section I'll have to come back to, but that! ! is the idea)
Erik Larson:
In short (well, I guess I should say "in long" now), IMHO don't bother writing rules that just 'express knowledge', and don't bother creating (too many) terms with just that motivation either--at least not if you want to solve problems for Real People.
Mike Pool:
What is an upper ontology but something that "just expresses knowledge"? Are you claiming that it is useful to write some rules that just express knowledge and not others? Why is it useful to have subtyping and disjointness rules, rules which certainly seem to just express knowledge, but no other rules?
Erik Larson in response to Mike Pool:
Yes true. By your line or reasoning I think we can agree that they ought to be small and well construed (i.e., application-inspired).
Mike Pool:
Or do you actually have a more radical view? Do you think that each application is so different from each other one that trying to find some subsuming body of useful knowledge, an upper ontology, is pointless? I disagree with this claim, just for the record, but I'd like to hear more before trying to persuade you if it is your own view. (I'm more sympathetic to the claim that an upper ontology should be quite small but very well axiomatized. Part of the reason I'd be more sympathetic is because it's conceivable that human intelligence is like this, i.e., based on a relatively small number of very well understood concepts. It's hard, however, to imagine generating anything resembling intelligence, i.e., an ability to generate solutions to problems, if a system has very little understanding of *any* upper ontology concept.)
Erik Larson in response to Mike Pool:
I'll abstain from comments on the cog sci fit with any of this, but suffice it to say that I think some superset of a computational ontology (in the narrower sense that people with AI or philosophy backgrounds have) that involves getting reuse of code from abstraction or generalizing on either declared concepts or programmatic constructs (i.e, classes in OOP) already plays a major role in making large, distributed software apps doable. The idea of an ontology is a good idea (maybe even a Good Idea), but I think it takes some new focus to get it rolling along for Real People. Maybe I propose this methodology as an intuition pump (apologies to Dennett): build an app that uses an ontology (oh, recurse on that.... find an app that needs an ontology). Then try to make it do what you planned with a minimal set of mid-level terms. If it never requires a bunch of OU work, don't bother. If it does, you'll know just what needs to be done.
Mike Pool:
By the way, please tell me who these Real People are and please let me now how I can attain such enhanced metaphysical status if I don't already have it.
Erik Larson in response to Mike Pool:
This is a Bill Andersen-ism. It means roughly the set of people who have to use some application to do something, where if it doesn't work the way it is billed, breaks, can't integrate, etc, shareholders begin to get mad, money is lost, productivity suffers, people get fired, economies turn downward, traffic lights don't work, pay checks don't get sent, schedules for employees aren't generated, stock values aren't updated, customer reports can't be compiled, statistics on meter usage aren't available, flights are delayed, values in column C aren't tallied, etc etc. All you have to do to be a Real Person is to count on Word to save out your thesis, and to be prepared to be really pissed off if it decides to crash or stop responding instead.
I'm not sure how philosophically interesting Real People are, but I think that is the general idea.
cheers,
Erik
best,
Mike Pool