| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
- 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.
- 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.)
- 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.
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.)
Bill