RE: ONT RE: Ontology case study
Dear Adam,
Yes I agree we are getting close.
See some comments below.
Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom
Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.r.west@is.shell.com
Internet: http://www.shell.com
> -----Original Message-----
> From: Adam Pease [mailto:apease@ks.teknowledge.com]
> Sent: 31 May 2002 21:25
> To: West, Matthew R SITI-ITPSIE; ontology@ieee.org
> Subject: RE: ONT RE: Ontology case study
>
>
> Matthew,
> Many thanks for working this through. I feel like we're getting
> somewhere. Although I'd be happy to continue point by point,
> I think maybe
> we can get to the heart of the matter in summary.
> I take your points below to be, broadly, that you have a
> sense that
> database normalization and cardinality constraints cover the
> most common
> cases of database error, and that in the rare cases that more
> checking is
> needed that stored procedures are sufficient. It's always a
> challenge to
> restate someone else's views fairly, so let me know if that's right.
MW: Close but not quite. Entity relationship models deal with ontology
in as much as it can be implemented within a static database design,
as opposed to processing data in a database.
> If that is a fair restatement, my rejoinder would be that
> if one is
> making an efficiency argument, that it has to be made
> relative to the size
> of the database, and the time constraints of the situation.
> If one is
> running a theorem prover on the client machine of say a
> medical records
> technician, and the tests involved are run only over a single
> record at
> time of entry, the efficiency argument is far less
> compelling, it seems to
> me. One could argue that the dramatic hardware speed increases that
> continue mean that even if theorem proving is too slow now,
> that in a few
> years, it will be enough, and that it makes sense to begin
> define precise
> semantics and expressive constraints now. One could argue,
> as I think Bill
> Andersen has recently, that techniques are being developed (at
> OntologyWorks at least) to implement expressive constraints
> in databases
> that do function very efficiently today.
MW: I broadly agree, but there are quite good tools to support
constraint checking on the data in the database, it is just
a different part of the problem, with different tools. I don't
think improving data quality is a killer app for ontologies.
> I'll address the specific request for "how would I do
> this" below, since
> after pleading with others to be concrete and specific, I'd
> better practice
> what I preach.
>
>
> At 10:48 AM 5/31/2002 +0200, West, Matthew R SITI-ITPSIE wrote:
>
> [snip]
>
>
> > > >MW: I don't think there is anything that can merge two databases
> > > >automatically without humans looking at it as part of
> the process.
> > >
> > > Nor do I. What an ontology can do is provide a set of integrity
> > > constraints that can be automatically processed to determine
> > > in part if
> > > that merger was specified correctly.
> >
> >MW: Please explain how you think that might work.
>
> Imagine that a database technician reverses the fields that should be
> mapped from a client database into a common DB. He flips
> birth date and
> hire date (for an employee database for a multinational
> corporation for
> example). As each record is pulled into the common DB it's
> checked against
> the constraint
>
> (=>
> (and
> (instance ?X Employee)
> (birthTime ?X ?BTIME)
> (deathTime ?X ?DTIME))
> (greaterThan ?DTIME ?BTIME))
MW: Well that is fine of course (not wrong). However, in this case
either all are going to be right, or wrong. So my strategy would be
to eyeball the resultant data and do the same test, rather than code
and check the constraint. Just more efficient in this sort of case.
You still need to know that a birth date is before an employment date
(but I do don't I?).
MW: Don't get me wrong. I still think there is a killer app somewhere
in database meets ontology, but I know I don't want to get shot down
in flames suggesting something that can be done as well some existing
way.
>
>
>
>
> [snip]
>
>
> Adam Pease
> Teknowledge
> (650) 424-0500 x571
>