Tuesday, October 21, 2008

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

1 comment:

John laPlante said...

About requirements and contextual inquiry, I think there is often a big difference. Requirments often start with features that have implicit users and their tasks. CI and the like start with the user and what they do. I think the use case approach from software engineering tries to make the user more explicit and is one reason why I like the extreme methodologies. They tend to be light on requirements but they at least make the basic problem apparent which allows people to make intelligent decisions about solutions.