RE: ONT RE: Ontology case study
Dear Adam,
See 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: 05 June 2002 16:26
> To: West, Matthew R SITI-ITPSIE; ontology@ieee.org
> Subject: RE: ONT RE: Ontology case study
>
>
> Matthew,
>
> At 11:11 AM 6/5/2002 +0200, West, Matthew R SITI-ITPSIE wrote:
> [snip]
>
> > 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.
> > >
>
> I'm puzzled by this perspective. On the one hand, you've
> been making an
> efficiency claim that one can't have too many sorts of
> constraint checks on
> a DB because it's too inefficient. On the other hand you
> offer "eyeball
> the resultant data" as a solution, which I would think would
> be impractical
> if the data set is so large that automated constraint
> checking is an issue.
MW: You only need to eyeball a sample of the data. When you see
that 2 or 3 rows have the data transposed, and you know a systematic
process has been applied, you really don't need to check the rest
of the data set.
>
> Note also that having the data entry clerk check this
> constraint is not a
> practical solution. Typos happen, humans make errors.
MW: This is a different case. Adding checks on data entry is
quite common. But it is not considered part of the static database
design (that the data model supports). It might also be a check
you run on the whole database periodically.
>
> Adam
>
>
>
> Adam Pease
> Teknowledge
> (650) 424-0500 x571
>