Re: ONT RE: Ontology case study
Matthew,
At 09:24 PM 5/28/2002 +0200, West, Matthew R SITI-ITPSIE wrote:
[snip]
> > >MW: An ontology is really overkill for this.
> >
> > I think this is simply a question of personal preference and
> > experience. My understanding is that you're not familiar
> > with logic so
> > it's not surprising that it seems imposing.
>
>MW: I am much more familiar than I was when I arrived here, so
>my principle concern is utility and economy.
>
> > I'm not familiar
> > with the
> > EXPRESS language so it would seem like overkill to me to use
> > EXPRESS syntax
> > for describing something in a much smaller and more familiar
> > (to me) syntax
> > of SUO-KIF.
>
>MW: Well this is compact vs expressive. I generally prefer compact
>myself, so this is not the reason. Rather economy, and using the
>tools of the community you are working in. I haven't tried to
>suggest that people here should use EXPRESS or some other data
>modelling formalism. Neither would I suggest other communities
>used KIF, unless their current tools couldn't support the business
>requirements, and KIF obviously did.
So why is using an ontology overkill again?
> >
> > > Though I should perhaps make
> > >clear some distinctions I use related to terms like ontology.
> > >
> > > - Taxonomy, a dictionary of standard terms and their
> > natural language
> > > definitions.
> > >
> > > - Thesaurus, a taxonomy with subtype/supertype relations.
> > >
> > > - Data Model, a structure of types and relations against
> > which instances
> > > of the types and relations can be stored. Definitions of
> > the types and
> > > relations are in natural language. Some constraints are
> > defined, usually
> > > in terms of the cardinality of relationships.
> > >
> > > - Ontology, types, relations, and possibly instances of
> > those together
> > > with axioms, usually in First Order Logic, that define
> > the rules that
> > > apply to members of the types and relations.
> > >
> > >Data Models are what are usually developed/used to design a
> > database. The
> > >axioms of an ontology are generally of little use/relevance
> > either in the
> > >design of the database,
> >
> > Again, a question of perspective. If one doesn't read logic,
> > the axioms
> > would certainly be of little use. If one does read logic, and has a
> > theorem prover available, the axioms could be used to test
> > the consistency
> > of the schema.
>
>MW: Not many people - particularly business users - read logic. They
>have a tough enough time with data models, and we usually present those
>in a somewhat simplified form to check that we understand what they
>need.
...and we do the same with logic. Check out Michal Sevcenko's SUMO browser
for one very simple algorithm that presents logic in an English-like form.
> >
> > >or in the population of it by instances.
> > >
> > >So in general my question for this sort of case would be:
> > Why would you
> > >develop an ontology (more work) when a data model will do?
> >
> > Because if I have a schema like
> >
> > Table: Foo
> > col 1: parent name col 2: parent SSN col 3: child name col
> > 4: child SSN
> > Mary M. Smith 555-11-1234 Robert J. Smith
> > 555-11-4444
> > Robert J. Smith 555-11-4444 Mary M. Smith
> > 555-11-1234
> >
> > Table comments:
> > parent: "The parent of a child specified in the child columns."
> >
> > No automated process can read the English and determine that
> > the database
> > is bad. If you have instead a formal ontology that defines
> >
> > (=>
> > (parent ?X ?Y)
> > (not
> > (parent ?Y ?X))
> >
> > as part of the formal definition of the parent relation, then
> > an automated
> > process could catch the problem. I'm sure you could find
> > some existing
> > database constraint language that could handle this
> > particular constraint,
> > but not all the constraints that are easily specified in
> > logic, unless of
> > course the database constraint language is a particular
> > syntax for logic
> > (which many language designers seem to be moving towards, see
> > OCL in the
> > UML for example).
>
>MW: The utility of this is determined by the frequency with which
>people put this kind of bad data into the database. This kind of
>error is very rare, simply because the people putting the data in
>know it is wrong. Now typo's are very common, but I don't see how
>axioms can help with the miss-spelling of names.
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.
> >
> > >Of course ISO15926-2 is a data model developed specifically
> > to solve this
> > >sort of problem, with ISO18876 an architecture and
> > methodology for it.
> > >
> > > > We then "compiled" the ontology by hand into
> > > > a relational
> > > > database.
> > >
> > >MW: Most data modelling tools can compile automatically to a
> > relational
> > >database, so more expense here.
> >
> > True, but that's only because these modeling tools are built
> > on technology
> > that's been around a bit longer, so it's not surprising there
> > would be
> > software implemented for it. That doesn't mean there some technical
> > obstacle. Another issue is that existing DB languages are
> > less expressive
> > than logic. If the data modeling tool is just an ER diagram, it maps
> > trivially into a DB schema.
>
>MW: As one design option yes (but certainly not the only one). Yes DB
>languages are less expressive than logic, but my point is that that has
>not value unless/until you need that additional expressiveness, and then
>you generally want it in a different context, e.g. checking data quality,
>rather than doing database design.
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.
[snip]
> > > > I've provided references in
> > > > previous messages
> > > > to other government research projects where we've used
> > ontologies for
> > > > integration as well.
> > > > One impact of an ontology that I find undeniable is that
> > > > at the very
> > > > least, a formal ontology can serve as a more precise set of
> > > > comments about
> > > > the meaning of database tables and fields than informal English.
> > >
> > >MW: I disagree. The disadvantage in this application of a
> > formal definition
> > >is that only those who understand the formalism can understand it.
> >
> > That's true for any language including EXPRESS, EPISTLE etc.
> > How is this
> > an argument against logic and ontology?
>
>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.
> >
> > > I think
> > >the only time that stating axioms formally is sensible (in a
> > commercial
> > >application) is when they are going to be acted on by some
> > application
> > >(usually of course some sort of inference engine).
> >
> > That's a reasonable statement to make about expression of
> > information in
> > logic, but it doesn't address the at least anecdotally demonstrated
> > advantage of ontology in supporting modeling tasks, as oppposed to
> > generating a model from scratch.
>
>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.
[snip]
Adam
Adam Pease
Teknowledge
(650) 424-0500 x571