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

RE: ONT RE: Ontology case study




Matthew,

At 11:21 AM 5/29/2002 +0200, West, Matthew R SITI-ITPSIE wrote:



[snip]

> > So why is using an ontology overkill again?
>
>MW: A data model is an ontology, just one with far fewer axioms, but
>inclulding those that are useful in database design. So it is a matter
>of degree. A fully axiomatized ontology just includes a lot of stuff
>that has no value for database design.

If a data model is an ontology with fewer axioms then the terms in the data 
model are lacking explicit mention of some sufficient conditions.  I could 
see how on a particular ontology one might claim that particular axioms are 
unnecessary, but don't understand how you can make this general 
claim.  Could you explain further?

[snip]


> > How about a database in which both John and Jon (should be
> > John) have the
> > same SSN, or hospital records where Mary who was born on
> > 5/2/65 is recorded
> > as giving birth to John on 8/7/68 (should be 8/7/86)?  This
> > sort of thing
> > is not at all rare in real world databases.
>
>MW: This sort of thing is sorted out by referential integrity, and
>is the sort of constraint that is set up in data models. In this case
>you would probably not get the opportunity to enter the name, unless you
>were the first person to enter the SSN and related details, after that
>these would be provided by reference only.

There are two typos in the example.  How would referential integrity catch 
the date problem?

[snip]

> > It's just as easy to come up with an issue relevant to database
> > design.  Let's say that you're integrating databases that are
> > hospital
> > records from different countries.  The schema from one Muslim country
> > allows multiple wives for a given husband and the schema for
> > the US DB
> > prohibits this.  With English comments, there's no way for an
> > automated
> > process to find the problem.
>
>MW: The database structure is likely to be quite different (assuming
>only the current wife is recorded in the US database) and so the constraint
>quite obvious.

Obvious to a human being, but not to a software program, that's the 
point.  With a formal axiom, a theorem prover can catch the problem.  With 
an English comment, a human has to catch the problem.

>  I don't see what advantage the ontolgies would have. You
>would ahve to manually map the concepts in the two ontologies anyway, and
>that is much harder than finding the differences in data structure and
>how/whether the constraints are enforced in the database.
>
>MW: In fact, if the US database is able to hold information about previous
>wives, it will probably be able to hold the data about the multiple
>concurrent muslim wives, since it is unlikely that a constraint restricting
>a US citzen to one wife at a time would have been implemented.

That's assuming a number of things that change the example, including that 
database designers do the right thing.  Mistakes happen, and if all you 
have are English (or some other human language) definitions, no automated 
process can check it.

[snip]


> > >MW: EXPRESS is a language that is computer processable, and
> > is processed
> > >to provide a database. You do not automatically process the KIF in
> > >your ontology, to produce a database design, it is read by
> > humans, so you
> > >should use something that they understand. It is the information you
> > >convey, rather than the information you contain that matters.
> >
> > Let's distinguish between what is currently done with today's
> > tools, and
> > what this standardization effort is supposed to enable.  A
> > logic based
> > ontology enables computer processing, so the SUO ontology is
> > not intended
> > just for human eyes.  Also keep in mind that for human eyes, we have
> > Michal's pseudo-English presentation and a graphical browser,
> > as well as
> > English comments.
>
>MW: Fine. But what is it for ...

You made a comment above that the when the ontology is used by humans, it 
should be presented in a language they understand.  That's the point I 
answered.  We do present it in a human-readable form, as well as in formal 
logic.

[snip]


> > >MW: Well if I had an ontology, I certainly wouldn't ignore
> > it (as long
> > >as I could make sense of it) but I would translate it into a
> > data model
> > >as my first step if what I was doing was database design.
> >
> > ...and you're free to do that.  Knowing that many people are
> > put off by
> > logic, we've translated SUMO into Protege and DAML.  We'd be happy to
> > implement other translators as our time allows.
>
>MW: That would be potentiallly useful, although one thing I have seen is
>that the best way to say something in one language, does nto necessarily
>translate automatically to another language in the best way to say it there.
> >

I agree.

Adam



Adam Pease
Teknowledge
(650) 424-0500 x571