I am obviously not expecting a full architecture/answer, I'm more looking for some ideas/hints that will lead me to the final architecture.
So basically the goal of the game, for those who don't know, is to ask questions to the other player that will lead you to the real answer. You usually try to start with questions that will eliminate as much stuff as possible. I hope that's clear.
Now we are not trying to recreate the game. We have our own internal software with a "File a problem/ticket" link, and according to the data that is displayed, we want to try to guess what is the problem. After guessing, we will confirm with the person that this is the correct problem, so all the fields get automatically filled. If not, we'll let the user enter manually the problem.
This is some kind of data mapping I guess.. I'm not sure how we are going to do that.. any idea how to start?
Thanks
You have two real choices here:
1) Use/create a rules engine: try and pre-populate the rules based on some hard-core analysis of your data. This is probably the most effective, but also the most expensive, as you will need some really good data analysis to build your ruleset on.
2) Statistical matching: Create vectors based on the data elements that are available. These vectors will match a database with name/value pairs, which have results from prior tickets. Match as many vectors as possible, and guess based on the highest ranked match. So something like "Give me the most common resolution given: responseCode=500, url=/bankaccount, location=antarctica"
It really comes down to either doing up-front analysis, or reactive data-mining. It's rather orthogonal to architectural concerns. You can decide your architecture based on things like interop requirements, scaling, etc.