ONT RE: Ontology case study
Bill,
Replies below:
At 05:54 PM 5/23/2002 -0700, William Burkett wrote:
>Adam:
>
> > -----Original Message-----
> > From: Adam Pease [mailto:apease@ks.teknowledge.com]
> > Sent: Thursday, May 23, 2002 2:10 PM
> > To: William Burkett; ontology@ieee.org
> > Subject: RE: Ontology case study
>...
> > >*The* most significant problem with this paradigm, however, is the
> > >development and application of mappings. What is "mapping", really? Can
> > >it be understood and taught to the general ontology-using public? Your
> > >effort was successful because you were dealing with a closed system of a
> > >known and well-defined scope and data meanings. How can the mapping
> > >lessons you learned (and were learned in the above efforts) be applied to
> > >an open system with a huge, unknown, and constantly evolving scope and
> > >fuzzy, ambiguous, context-sensitive data meanings?
> >
> > The mapping problem is significant, to be sure, but is a problem in any
> > sort of integration effort, whether using ontologies, or a more
> > conventional data warehouse approach. I would suggest that at least the
> > problem is more manageable than typical systems integration approaches
> > where n components require n^2 mappings.
>
>While I agree that mapping is an issue regardless of the integration
>paradigm/approach used (e.g., neutral model, data warehouse, database
>federations), I don't agree that the neutral model offers any advantages
>in terms of manageability. In fact, I think the problem is actually far
>more complex and less manageable than n^2 direct mappings. Sure, you
>reduce the number of mappings to 2 * n, but then you have to deal with:
>
> - loss of semantic precision when "generalizing" local data into the
> neutral model, making extraction (interpretation) of meaning in the
> neutral model by other connected data source imprecise or wrong.
That could be a problem if the neutral model is not specific or detailed
enough. That needn't be the case however.
> - Mapping "data source A" -> "neutral model NM" and "data source B" ->
> "neutral model NM" is not the same mapping "data source A + B" ->
> "neutral model NM". If there's an overlap of information in A and B,
> there's a kind of "information multiplexing" involved that makes correct
> mapping more difficult.
I'm not sure I understand. Could you provide an example?
> - Mapping between A and B is straight-forward because the "system" is
> essentially closed: you know what is in A and what is in B. Mapping A to
> a NM is less deterministic: you *think* you know what is in NM, but if
> others are free to map to it, their interpretation of what is in the NM
> will likely be very different from yours. In other words, the assumption
> that all mappers will interpret the NM in the same way while mapping is
> false. (Hell - the assumption that any two people will interpret *any*
> model the same way is probably false, too.)
I believe this is actually a good counterexample. While the terms and
relations in a database representation don't have a formal semantics (note
that I didn't say SQL itself doesn't have a formal semantics), axiomatized
terms and relations in first order logic do. The axioms completely specify
the meaning of the term so there is not as much of an issue about people's
different interpretations. Of course, if the axioms are not detailed or
specific enough that's a problem just as it would be with any
underspecified representation.
> - When a new "node" is added to the community of integrated "nodes"
> mapped to a common NM, the mappings of all the nodes need to be reviewed
> to see if they still "interpret" the NM properly given the expansion of
> its semantic applicability with/for the new node.
I would have to disagree with this as well. The interpretation of a term
does not change just because some additional term is added to the
ontology. All the past mappings would still be correct. The only issue
would be whether the mappings are specific enough and take appropriate
advantage of the presence of a new term.
>Off the top of my head, these are just some of the problems with a neutral
>model integration approach. These problems can be overcome
>methodologically, of course, but the depth and dimensions of the problem
>are, I think, still poorly understood (if not mostly unrecognized).
>
>
> > >While I think you can sell the neutral ontology integration model as a
> > >problem solving approach, getting people to know about and use SUMO (or
> > >any other "upper" ontology) as neutral ontology in their solution is a
> > >different kind of sales job altogether. And it is one that I don't think
> > >will be very successful - any well-defined and well-bounded integration
> > >effort will want to use their own.
> >
> > Can you discuss further why you feel they'd want to use their own? I've
> > found that unlike in the research world, people who want to accomplish a
> > practical commercial task are very happy to adopt someone else's models or
> > software if it helps them get their job done.
>
>But in adopting someone else's models or software, how often do they use
>them exactly as is? I don't know how often I've heard "My/our
>requirements are different". At the very best, they would use the
>models/software as a starting point for doing what they want to
>do. Adopting and adapting a neutral ontology model to the usage and needs
>of your local (integrated) community defeats the whole purpose of using it
>as a generalized integration model. People will interpret and use the
>model as they wish, and this can't be policed (and shouldn't because it is
>not wrong of them do this - it's natural.) The only way "standardized"
>interpretations will arise is by the conventions that arise and are
>reinforced in a language-use community, in which case it will pay for
>people to interpret the ontology the same way. (Remember: dictionaries
>don't specify the meaning of words; they document the conventional
>meanings of usages of a word.)
Well, we're drawing on the anecdotes of personal experience here, not
having the results of some survey that specifies how various groups of
people use various types of software. I would only try to support my view
further with the fact that the vast majority of Java programmers use, and
subclass the JDK, rather than feeling a need to modify it.
Adam
>Bill
Adam Pease
Teknowledge
(650) 424-0500 x571