Ideally, a final project for a graduate level class in computer science should be a springboard for your own research or master's thesis. That is, you should hope that your final project can be extended, improved or augmented to become either original work that might be publishable, or at least survey work that could become a technical report or a masters thesis. Of course, I will not expect this to happen with every project, but it is something to aim for. At the least, the final project for this class should give you both experience and insight into how computer science research is carried out.
A naive approach to scientific research includes the myth that when something important and ground-breaking is accomplished, then the effort to publish and disseminate that work is secondary to the effort and imagination needed to carry out the original research. I strongly disagree with this world-view, and take the opposite approach: Communication skills are of primary importance and are sorely lacking in many scientists, while imagination and good ideas are abundantly available in most computer scientists. This position might be extreme, but it is indisputable that communication skills are more easily taught than imagination. Thus, a significant portion of your grade will be based on your ability to describe to others the accomplishments of your final project. There are two parts to this assessment: a test of your oral communication via a 10-15 minute demonstration/presentation of your work, and a test of your written communication skills via a final technical report.
The project must include some programming, or at least, some extensive use of off-the-shelf programs to accomplish something novel. This program will be the centerpiece of your demo session on March 10th. I will be your primary audience, but depending on the project goals, I can take on one of several roles. You could imagine that you have a new idea for a startup company: in this case, I will play the role of a venture capitalist that is considering funding your idea. You could be developing new research in AI, in which case I will be your academic advisor, whom you must convince that you have a good idea. (Since I am not requiring novel research for this project, I will pretend that your work is the first of its kind. You will still have to convince me that it is worthwhile research.) If you are developing and demonstrating some industry-specific application of AI, I can pretend to be a business manager in that industry. In this scenario, you will have to convince me that the new AI technology is money-saving, or improves quality in some sense.
The final projects for this class may be either solo projects, or 2-person team efforts. There are pros and cons of either of these, but in general, I would prefer you to work in teams. First, as you should know from any software engineering class, life outside of academia (and often even within academia) always includes cooperative work. Second, a team allows you to effectively divide up the work. An excellent division of labor for a team project is to have one person give the oral demonstration, while the other be lead author on the technical report. Of course, teamwork adds complexities that solo work does not have to deal with: I will need to see documentation that the workload has been fairly shared by both persons. Although I hope that for most team projects both students will receive the same overall grade, I must reserve the right to give different grades if I perceive that the workload has not been shared evenly. Finally, I would expect more to be accomplished by 2 persons than by one: If a team accomplishes X amount, a solo project need only accomplish about 2/3(X) to receive the same grade. (Since two persons cannot really accomplish twice the work of one person!)
Project types and ideas:
As implied by the different sorts of demo sessions, projects may be of several types:
(1) Rational reconstruction: Based on material from the literature, re-build an AI program and replicate its results. This reconstruction need not be completely faithful to the original program, but instead may include improvements, or guesswork where the literature may not completely describe the system's construction.(2) Experimental study: For this project, the emphasis is not on programming, but rather on testing known technology on novel data sets, or against other known technologies. This is the whole raison d'etre for the ML repository. For this project, you may either re-build some AI system, or use software that is available off-the-shelf (ideally, in the public domain). Of course, the less programming you do, the more work I will expect in data analysis and analysis of your experimental results.
(3) Application project: In this type of project, the emphasis will be on the application of AI technology to some industry or domain. I will expect programming in these cases, since each domain typically has specific user/interface requirements. However, you may either borrow or build the underlying AI technology.
Here is a current list of ideas. Unfortunately, my list of ideas isn't as long as I would like, so watch this page for new postings!
1. Application project: Build a system that uses or retrieves information from the CYC knowledge base. (Our ICS department has a partial copy you can play with.)
2. Application project: Build a system that uses or retrieves information from the Ontolingua knowledge base (or ontology) collection. Use the OKBC protocol to interact with the Ontolingua server at Stanford.
2a. Application project: Alternatively, try using the OntoSaurus server. This system competes with Ontolingua as an ontology collection, but it is based on the LOOM language (and doesn't use OKBC, although they are working on this). If you choose this, you should demonstrate the power of LOOM's automatic classification system.
3. Application project: Build a utility model or a Baysian Network for a decision in health care. For example, model the decision about whether or not to recommend a mildly invasive diagnostic test. (I can provide pointers to help you acquire some domain knowledge for this sort of project.)
4. Experimental study: Replicate a machine learning experiment with data from the UCI machine learning repository. For example, demonstrate some (known) differences between different learning algorithms across different data sets. For this sort of project, I want to be clear that some programming is required as part of the demonstration of differences and capabilities. You must do more than use off-the-shelf implementations.
5. Experimental study: Demonstrate some (known) differences between different knowledge representation languages. Compare LOOM, CLASSIC, Ontolingua, CycL, or other languages and formalisms. (or some subset thereof). As with #4, some programming is required as part of the demonstration of differences and capabilities.
6. Application project: Apply a theorem proving system to validate as correct an assembly of software components (characterized by inputs and outputs) designed to accomplish some task. This is a toughy; I would not expect your theorem prover to be efficient!.
7. Application project: apply an NLP system to try to understand scientific abstracts of Journal articles. For example, find all articles published in the Journal of Evolutionary Biology about resistence to HIV drugs (see the CTSHIV Project).
8. Rational reconstruction: Build a non-linear planning system.
9. Rational reconstruction: Build a decision network inference system. This could be combined with project number 3, above. You probably want to look at the HUGIN system as an example.
10. Rational reconstruction: Build a set of agents that cooperate and communicate together. Perhaps they can solve something like a mini-RoboCup problem. (This could be hard!)
Project schedule/timeline:
(1) I strongly recommend that you talk to me about ideas (such as the above list) for your final project sometime before Oct 26th. I should be able to provide a large number of ideas, as well as advice about scoping the project (i.e. what is too ambitious to accomplish in six weeks, vs. what is not enough work).
(2) On Oct 26th you must hand in a written description of your project. This description must describe your goals, and include a detailed plan for what you will have done by when. If it is a team project, it must identify the teammates and specify who will be responsible for what parts of the project. This plan is not completely binding, since you may discover pitfalls along the way. However:
(3) Nov 9th is the last day for significant changes to your goals, and to your division of labor for the project.
(4) Nov 16th is a check-point that should keep you from procrastinating too much. In your detailed plan, you should have described your goals for this checkpoint; on the 16th, you must hand in a brief written report describing how you have achieved those goals. If you haven't quite done what you planned, you must explain what happened, and hopefully what you have accomplished instead. Although this report will not be graded per se, it will affect my overall opinion of your project's progress. Based on this report, I may ask to meet with you: this could happen either because you are doing poorly, or because you are doing so well that you have tweaked my interest.
(5) Dec 2nd is demo day. I would like to have 15 minute presentations, but this may be reduced if there are too many teams. However, I expect that you will not need to attend all of the presentations, but only be present when it is your turn. I will announce the schedule a week or so in advance. The demonstrations will occur in Room CS 432, or some equivalent, where there is a network connection and a big-screen display device. I expect to reserve this room for up to 3 hours. Your demonstration should execute either on Win/NT or as an X-Windows client (Unix). I will also try to reserve the demo room and machine sometime on Dec 1st, to allow you to pre-test your system before demo day. Since you will only have 10-15 minutes, part of your presentation must include glossy powerpoint slides, explaining your goals and acheivements.
(6) Final report. This is due on Dec. 3rd. The final report should be between 7 and 15 pages long (12 pt. font, single spacing) including figures. I strongly recommend figures, but you should not duplicate the work of your demonstration by producing a large number of screendumps of your system.