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.

Things, Properties, Actions and Relationships

I'm at a nice place right now on a number of my projects: the beginning.

Right after the proposal is accepted and before you really realize how hard the problem is going to be and how little you'll actually be able to accomplish in the grand scheme of things, it's a wonderful time of hope and promise. This is also known as the analysis phase.

In this blog post, I'm going to delve into a particular aspect of the analysis phase where you try to capture the important things, properties, actions and relationships. In other words, you try to capture the taxonomy/glossary/schema used by the important stakeholders in your problem space.

A number of fields have defined processes to address this problem: HCI uses contextual inquiry, information architecture or cognitive task analysis (CTA), software engineering uses requirements analysis or object oriented analysis, artificial intelligence uses CTA or knowledge engineering, etc. As a side note, I'm continually amazed by how each field uses terms and methods that are so eerily similar, yet often without seeming to realize it. I'll have to go deeper on this topic in another post.

So what are we really talking about here? At a deeper level, we're really talking about language and meaning. What are the words and symbols that people use and what is the underlying conceptual meaning that they attach to those words?

In philosophy, ontology is the study of what things exist and of the basic categories and relationships between those things. In information science and artificial intelligence ontology is a formal representation of a set of concepts and their interrelationships. This is closely related to concept learning from psychology and the concepts of taxonomy and controlled vocabulary.

I don't really want to go into depth on each of these topics right now, but I will say that after a bit of exploration, controlled vocabulary seems to have the closest match to what I'm looking to develop for each of the projects that I'm working on. I found a nice series of articles on boxes and arrows starting with What is a controlled vocabulary? that I'm currently reading.

In my next blog entry, I want to explore some specific methods and tools for capturing and sharign controlled vocabularies. I currently have the following two specific leads:

1. Creating a Controlled Vocabulary, and
2. Concept Maps

See you next time!

-Keith