Challenges using Semantic Wiki's for Knowledge Engineering

Jack here...I've been thinking about about Keith's post about Semantic Wiki's and thought I'd chime in. I'm a big fan of anything that makes requirement gathering and/or knowledge elicitation easier, but I'm nervous about the semantic wiki approach.

My understanding is that a Semantic Wiki is a Wiki where the links between pages have been given formally defined (e.g. ontological) relationships. Keith talked about this in his post on controlled Vocabulary when he cited wikipedia "a carefully selected list of words and phrases, which are used to tag units of information. ... Controlled vocabularies solve the problems of homographs, synonyms and polysemes by ensuring that each concept is described using only one authorized term and each authorized term in the controlled vocabulary describes only one concept. In short, controlled vocabularies reduce ambiguity inherent in normal human languages where the same concept can be given different names and ensure consistency."

Sounds good, right? Gathering information is about reducing ambiguity, right? Good old Occam's Razor says otherwise. Any explanation should be as simple as possible, but no simpler. There is a big assumption built into controlled vocabularies and ontologies which is that it is possible and desirable to develop a controlled vocabulary that can be uniformly agreed on by all stake holders (or that any disagreements are minor and can be reconciled within the structure of the formal representation.) This concept implies that there is a single correct and uniform world view that all stakeholders should share and will share with a little effort. This is a large claim that is not supported by any formal model development process or activity of which I’m aware. In fact, getting stakeholders to agree on things as basic as word meanings is immensely difficult, and is so for good reaons. Different stakeholder's may have radically different, but equally useful ways of understanding a domain of interest. These differences may depending on their cultural background, their training and experience and the specifics of their work practice.

While a formal model can be developed even in groups with legitimate conceptual differences, it usually does so at the expense of one of the parties or by the creation of artificial compromises. This may be an acceptable outcome in some situations but not others. In the requirement gathering phase of user interface design, this seems like an overly constraining starting point. If we are to accurately elicit information we need a method that initially captures differences, reconciles them when reasonable but not when unreasonable. Otherwise we are mixing knowledge elicitation with design to the detriment of both.

My vote ... stick with the wiki and skip the formal relationships. This messes up part of why Keith wants formal relationships... that they'll be useful for providing knowledge to AI systems. I've got concerns about that too, but will write about that tomorrow.