At 04:13 PM 6/19/98 +0200, you wrote:
>Dear Jan,
>
[snip]
>
>Although I would second the notion of Prolog based inference being more
>appropriate for questions of "qualitative" nature than pure set based data
>base operations, I would hesitate to offer this as "the" alternative.
But of course, I second your hesitation. I suggested it as an additional
technique, not as a "solve the world" approach.
>..................................................................From
>my opinion, there are some severe fallacies based on the nature of the
>resolution strategies and which make the application of Prolog logic on QDA
>somehow problematic. I (and certainly others as well) would be interested in
>the specific uses that you make from Prolog interpreters for QDA.
Naturally, if one tries to model everything using clauses and first-order
logic, there are problems to be encountered at every turn. Philosophically,
Default Reasoning is one of the most severe. Operationally, knowing when
a system is crisp enough to apply logic and not be misled by its results is
tough. Finally, to be useful in QDA, a Prolog-based facility would need some
means of keeping track of different contexts for various sets of "axioms",
contexts which could be named and associated with basic evidence. But I find
there are housekeeping chores associated with tending and adapting particular
RDBMS for which Prolog is a useful tool and I was thinking of it in those
terms.
For instance, we have inherited a large instance in Informix in which the
documentation is imperfect. I use Prolog to model the RDBMS and semi-
automatically to discover chains of joins which let me retrieve certain
information. (The application is data warehousing.) I also use it to find
breaks in relational chains in data models. I mentioned Prolog
only in the context in which a DBMS was mentioned, and I envisioned it as
a tool in the same sense that a built-in arithmetic calculator pad might be.
Thus, why not use Prolog in the same sense that one might use a spell-checker?
It's purpose would be to monitor consistency in various portions of the
growing semantic net.
>By the way, the program AQUAD makes use of Prolog for specific calculations.
This is good to know. I wasn't aware of it. I will look it up.
>And ATLAS.ti, although not equipped with a Prolog inference engine, lets you
>create output in a specific Prolog notation (Atlas Prolog Notation APN) for
>further processing with separate inference engines. Thus, you can visually
>create semantic networks on screen and then create Prolog code on the fly.
>Just have a look at an ATLAS.ti project's ("Hermeneutic Units") storage
>representation (*.HPR files).
That's good. Is this documented in your manuals? I don't own a copy of
Atlas-TI yet. I only have the demo in hand.
>................................This feature was included to support the work
>of "knowledge engineers" which has a lot in common with QDA procedures (even
>IBM tested the feasibility of Grounded Theory for knowledge elicitation -
>many years ago).
It seems a logical approach to use QDA procedures for eliciting means of
doing things, and that, indeed, is parallel to my interest in QDA, although
I am seeking to understand data needs to support reporting requirements.
I have strong reservations applying GT to knowledge engineering ("KE") even
without knowing details of IBM's experience. I have found that most KE
demands some familiarity with the microworld to be modelled. "Experts" are
too impatient to detail commonsense features of their expertise, and they
are too much in demand to spend lots of time doing this kind of thing.
[snip]
-jt
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|