| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Adam, Bill, Pierluigi, Chris, etc:
This reply is a bit dated now, so I am including the full responses from Adam and Pierluigi for reference:
http://suo.ieee.org/email/msg08530.html (my original message)
http://suo.ieee.org/email/msg08531.html (Adam Pease response to me)
http://suo.ieee.org/email/msg08536.html (Pierluigi Miraglia response to me)
BTW, if this message doesn't display correctly, then I'll have to switch to my work account, since this is the best I can do with this mail client (as far as I know).
Responses to me and then my response:
Adam:
I think you're lumping together several issues.
One issue is the value of upper ontology. That is a view I have to work to
promote regularly. I convince some people but not others. Another issue is
the value of declarative programming representations. That one I
don't work on since I thought it was pretty clear that it's a useful tool in
the programmer's toolbox.
Erik:
Yes. Your two points here are the lumping charge and that declarative programming representations ARE useful. First point. The value of upper ontology to Real People is something I didn't directly address but is certainly implicit in this discussion (in other words, yes it was "lumped" in). I'll cover it directly in a moment. Second point. The best way to address this, I think, is to return to the "derivation of uninteresting consequences" point that Bill Andersen made earlier about FOL axioms and Real People and explain a distinction:
Begin Bill:
(=> (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:
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.
End Bill.
Bill's example is a declarative programming representation, true. But it is also a FOL axiom that was written (one would assume) for the purposes of expressing a bit of knowledge, namely: that parents are older than their children. My prior message made explicit reference to Bill's example and attempted to support his point that there seems to be a problem for Real People (end users) who are given rules of this nature to work with. I think the problem is specifically that the rule was written to express knowledge. It was not written with the derivation of its consequences (i.e., inferential considerations) in mind.
This is a point I've made in my posts to SUO from the start. I think it is a major problem for knowledge engineers who think that what characterizes their field is (or is *just*) the expression of machine-readable knowledge (particularly if they also think this will bear fruit for Real People). Note that!
the 'uninteresting consequences' problem is immediately lessened if you substitute in some other declarative programming representation that was written with the derivation of its consequences in mind. To take Adam's example: an expert system rule written to apply to a specific domain and to generate a specific consequence that is important to the end user's of the system. So since both of these examples are declarative programming representations, but only the former really exhibits Bill's "impedance mismatch" problem (nice term, Bill!), I'll admit that my use of 'declarative' in my prior posts wasn't ideal (Well, at least to the extent that people were confused. I wasn't confused! I was referring to Bill's axiom all along). Fair enough?
Pierluigi:
I wasn't defending "declarative approaches" over
"procedural" approaches in general. This is much too
broad an issue.
Erik:
See my comments to Adam above. Also note that the broadness of this issue as you construed it anyway would only *help*, not hurt your case (I take your case to be that Bill-type axioms written to express knowledge are a Good Thing). It will help because you get some stuff that *will* work--Adam's expert system rules, for instance-to ride along with our so-called impedance mismatch rules "for free." So I only helped your case, if I was construed broadly.
Pierluigi:
I thought Bill's example was not intended as a comparison between
declarative and non-declarative approaches, but rather of very distinct uses of what we call generically "representations."
Erik:
Okay, but what's the point? I thought that I just *stipulated* that a "Type-A Construct" is a representation. Didn't I give as an instance of a Type-A Construct Bill's example itself! In other words, my term and the generic "representation" term refer to the same thing: a FOL axiom. So what's the confusion here?
Pierluigi:
About Bill's example, a point I tried to make was
precisely that the "value" of that rule need not lie only, or even
primarily, in its "inferential possibilities." Generally I try to keep
inference and ontology issues separate.
Erik:
Well, thanks for saying that Pierluigi, because that is exactly what I think should *not* be done. Not for Real People anyway. I'll agree (Bill and I have had this discussion off-line) that for discussion purposes we ought to keep ontologies and inferential issues separate: ontology issues are model-theoretic and inference issues are proof-theoretic, if you like. But for the purposes of engineering, this isn't what you want to do, IMHO.
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 and 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.
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).
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.
-Erik