| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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: William Burkett [mailto:WBurkett@PDIT.com]
Sent: 24 May 2002 01:54
To: 'Adam Pease'
Cc: ontology@ieee.org
Subject: ONT RE: Ontology case studyAdam:
> -----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.
MW: A well known area of disagreement between us.
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:
MW: n**2 overstates the problem, it is unusual for all systems to need integration with all others. Usually it is 4-6 interfaces per system.
- 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.
MW: A trap for the unwary. You need to make up for the abstraction in the data model with preceision in the reference data to compensate. So not a fundamental problem.
- 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.
MW: Now I would have made the opposite statement, that mapping to a neutral model is easier.
- 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.)
MW: There is certainly an issue here. But frankly, conformance to a neutral model means using it with the semantics defined for it, and not whatever you may fancy, so understanding how the model is supposed to be used is part of the task.
- 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.
MW: There are two possibilities here:
1. The interface needs to be extended because more data from that system needs to be shared. This happens however you do it.
2. The original interface was not correctly mapped, usually some implicit information was missed. Applying the ISO18876 methodology and a little experience should fix this.
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,
MW: As I have pointed out.
but the depth and dimensions of the problem are, I think, still poorly understood (if not mostly unrecognized).
MW: Agreed.
> >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?
MW: not often, but then usually people are not trying to integrate with other users of the model/software. If you are, you (should) know that you have to use it in the same way, so you had better find out what that is.
I don't know how often I've heard "My/our requirements are different".
MW: Always, but of course it's not true. Anyway, a neutral model is not trying to meet the needs of a particular application, that is what the application model is for. The neutral model is supposed to support the integration of different application models.
At the very best, they would use the models/software as a starting point for doing what they want to do.
MW: The correct thing to do would be to integrate any requirements not already supported using an appropriate methodology (e.g. ISO18876).
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.
MW: Where adaptation means changing the intended usage, or duplicating concepts rather than integrating them. Integration does not happen by accident.
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.)
MW: Not true. A community will have to "police"/agree the usage in some sense, or else there is no basis for communication. (This applies to any approach to interfacing).
The only way "standardized" interpretations will arise is by the conventions that arise and are reinforced in a language-use community,
MW: There is nothing to say that this arising cannot be by formal agreement, rather than the informal approach suggested in your statement.
in which case it will pay for people to interpret the ontology the same way.
MW: Like when there are contracts between suppliers and customers, or your boss tells you to.
(Remember: dictionaries don't specify the meaning of words; they document the conventional meanings of usages of a word.)
MW: Indeed, and that kind of freedom is always there. The whole point of achieving integration though is that you give up that freedom and adopt the conventions of a community.
Bill