Now that my Whiskey Data Table (or Whiskey Options Table) is complete, I can turn my attention to creating the context decision tree. The context decision tree in a Recommender contains a series of questions the user will be asked to determine his or her needs and gather any information about the current situation that may impact the decision being made. It also contains the link between each path through the decision tree and the options, or rows, in the data table.
Given these two important roles -- determining the user's needs and pointing to a particular set of options or solutions -- it is not surprising that the context decision tree is the knowtifact that contains the most critical 'expertise' in a Recommender application. In a complex subject like whiskey, there are hundreds of questions one might ask before making a recommendation, and even then it is not obvious what the best recommendation should be. In other words, creating a context decision tree is hard and full of subjectivity.
Because it is such a subjective exercise, if you ask ten different domain experts to build a context decision tree you are likely to get ten different results. This diversity of opinion reflects real life; if decisions were simple and obvious, we wouldn't need to consult with experts. The value of capturing expertise in a Recommender is multifaceted: it makes knowledge available to a wider audience by embodying it in a web app, it makes it possible to compare and contrast the decision processes of multiple experts, and multiple experts can leverage the same options table to build their own Recommender just by building different context decision trees.
The single biggest benefit of creating a context decision tree, however, is both subtle and surprising, and that is that it forces experts to actually articulate their knowledge. You might think getting experts to talk about what they know is not such a difficult thing to do, and that is true. But getting them to create a context decision tree can be very tough, and it raises issues like 'tacit vs explicit' knowledge and 'shallow vs deep' knowledge.
First, much of an expert's knowledge is typically tacit, especially when it comes to their decision making process. They just 'know' what to do, and they often can't explain why they do it. Building a context decision tree requires that they make this tacit decision process explicit.
Second, much of what passes for expertise is really 'shallow' knowledge like product and historical information, and rote process knowledge. This sort of expertise only requires a good memory. Building a good context decision tree often requires 'deep' knowledge, knowledge not only about what and how things are but why things are the way they are. It requires the ability to apply knowledge, not just repeat facts.
I've said from the beginning, I am not a whiskey expert. I started down the road on this demo application because I found a really cool classification chart for whiskies. I was able to take the next step and build the Whiskey Data Table because collecting data is more about diligence than expertise. But now I needed to find a whiskey expert.
Once again I turned to the internet, which is chock full of websites that claim to contain whiskey expertise. I started doing searches with phrases like "how to pick a whiskey" and "how to select the right whiskey". The search engines were able to pull up hundreds of links that purported to answer that question, but when I read what they had to say it was always a regurgitation of the same information over and over -- the differences between Irish whiskey and scotch, between Kentucky straight bourbon and Tennessee whiskey, between the bourbon process and the scotch process, between the mash bill for Canadian rye whiskey and American rye... The closest anyone came to providing useful information for the task at hand was the taste profiles for different scotch regions. Yes, taste is something a beginner whiskey drinker would care about. Mash bills? not so much.
Which brings us to a classic marketing problem. Users/consumers/customers are always looking for benefits -- touchy-feely, use-case specific benefits that will accrue to them as users. Manufacturers/sellers/retailers tend to want to talk about product features -- concrete, well-documented facts about the item or service they are selling. The marketing people are the ones who must make the connection between the two, and advertising and product literature exist to create that bridge.
In a similar fashion, a context decision tree, which is a series of questions that will be answered by the user, needs to be written in the language of benefits and use-cases. My web research surfaced very little knowledge that would help someone new to the world of whiskey decide where to begin. With so many choices, some of which are quite expensive, how can a relatively inexperienced drinker make a selection that is a good fit for his or her current needs? That is what I needed to know to create a good Whiskey Context Decision Tree.
After approximately 100 hours of total research time -- between building the classification tree, the data table, and general whiskey research -- I was going to have to use my own creativity and judgment to build the context decision tree. It was sure to have a lot of flaws, but at least I would be able to generate an initial version of a Whiskey Recommender.
No comments:
Post a Comment