Re: ONT RE: Ontology case study
On 5/30/02 1:34, "Chris Partridge" <chris_partridge@csi.com> wrote:
> CP> Bill, I think I agree with all that you say, but I am not sure of its
> relevance. I have seen an argument on this list many time that using FOL one
> can deduce results that one cannot from a standard database. It has been
> suggested that this is an unalloyed good. I am suggesting that things are
> not so easy.
Well, first I don't know what a "standard database" is - probably you're
thinking of a relational database. And I would agree that all that FOL
gives you is not necessarily good and desirable.
First, I have always been dubious of the utility of classical negation for
any practical purpose. If I say:
"If X likes sports and doesn't like baseball, then X likes football"
I generally don't have in mind the following inference:
"If X likes sports and doesn't like football, then X likes baseball"
Or worse,
"If X likes neither baseball nor football, then X doesn't like sports"
These may make sense for one-deep inferences, like "I want to go to
Cleveland or Chicago and I can't go to Cleveland, so I'll go to Chicago",
but it starts to get weird when the classical negation is buried 10 or 12
ply deep in an inference. This is one of the reasons that Cyc is so
terribly slow - if you ask for someone's age, it ends up trying to prove
that China isn't a soft drink or something silly like that in the process.
Second, some things you just can't define in FOL, like transitive closure or
inductive definitions in general. One example of this is being unable to
prove that Mickey Mouse is not an integer from the Peano axioms, or being
able to prove that a given pair P(a,b) is not in the transitive closure of a
relation P. You can do this with a fixpoint semantics, but you're not in
the classical FOL world anymore.
> CP>Operational systems do things. A banking system will issue instructions
> to make payments and when it receives such a message it makes the payment.
> It seems to me absolutely clear that this is true and that FOL by itself -
> as ChrisM's example shows - cannot. I am just pointing out the difference.
> CP>How would an FOL theorem prover issue payment instructions - and would it
> be doing more than just FOL?
I don't get it. An FOL theorem prover could be hooked up to a banking
system in just the same way a database is. The parties using the system
wouldn't even notice, except that their transactions would take a whole lot
longer! ;-D
> This is just false, Chris. Databases are simply machines that implement the
> relational algebra, which, when recursion/iteration is added, is equivalent
> in expressive power to FOL. What you can do in one you can do in the other.
>> What is false? That in databases there is a distinction between entity
>> and attribute and this is based (however unconsciously) on the Aristotelian
>> distinction between substance and attribute.
That's not true. A relational database is, at its core, an implementation
of relational algebra, perhaps with some extra goodies added like iteration.
If you take any commercial DBMS, and ask a SQL query, you can examine its
execution plan and see these operations that the DBMS executes.
Relational algebra doesn't know anything about substance or attribute - all
it "knows" about are relations and a set of operations (cartesian product,
selection, and projection) that can be performed on them.
Now it may be the case that a particular data modeling *language* may have
such a bias or intention built in. I know that, while he didn't have
philosophy in mind, Chen had notions like object and attribute in mind when
he developed the entity-relationship model, the most common "formalism" for
building data models that are implemented by the data-definition facilities
of SQL. At the same time, the original relational model of Codd that all
relational DBMS are based on (roughly - the original is more powerful than
any current implementation) had no such distinctions in mind.
.bill