Many Computer Science students don't seem to get taught how to write research papers. I suppose this is because we focus on producing evidence (working software) everyone can download. I wrote the below advice originally for a review, but then realised two of my own PhD students had the same problem, so now it's a blog post...
Every individual paper has to focus on something. It has to have a thesis, a statement that could be true or false, that it proves or disproves. In general, for AI, the thesis will be something like
AI (especially ALife) papers sometimes bounce back and forth between two justifications: biological plausibility and efficiency. Don't do this. Each paper is only about one topic, its primary contribution can only be to one discipline. Note that your overall research programme can be about both, and you can have chapters in a dissertation or other book about each. But any one paper needs to stand up to a single, clear set of criteria.
In the papers that motivated this blog post, the abstract never said what the current state-of-the-art system OR its extension were for. The "Introduction" did not contain the motivation, or the results, or the roadmap, which are the three things that every Introduction needs. Rather the introductions wandered through background information on the older systems. Actually, this is also a common failure mode in talks. Information on history should go, if anywhere in a "Background" section, after the Introduction. In general, the Background section should establish the state of the art so you can prove you have gone beyond it.
Order of writing: Don't try to polish the introduction & abstract before you finish the results. The first time you write the Introduction it's just to have an outline for the rest of the paper, then you go back and make sure it's the outline of the actual paper after you've really written it. Focus first on the Results after that outline, as they determine the content of the rest of the paper. Results, then method that explains the results, then background to set up the method, then conclusion/discussion, THEN the intro again, & abstract.
Update May 2016: see also a newer post, Demonstrating that a paper ought to be published.
Acknowledgements: Ian Horswill taught me about the ALife paragraph when I was a PhD student. Emma Norling pointed out the Introduction vs Background paragraph was still too rooted in the original paper, so I've fixed that now.
Every individual paper has to focus on something. It has to have a thesis, a statement that could be true or false, that it proves or disproves. In general, for AI, the thesis will be something like
- proving that a particular approach is more efficient or provides more accurate predictions than existing approaches for a problem or class of problems.
- proving that a particular approach is tractable for a problem or class of problems. This is only interesting if the problem was previously unsolved, otherwise you should be doing something like 1.
- some venues will accept something called "a position paper" or "white paper" which just presents a novel idea without proof, but such papers should always be presented as such from the beginning, and they still need evidence e.g. an extremely good literature review or careful reasoning, and normally would also present a research programme for proving or disproving the claims of the paper.
AI (especially ALife) papers sometimes bounce back and forth between two justifications: biological plausibility and efficiency. Don't do this. Each paper is only about one topic, its primary contribution can only be to one discipline. Note that your overall research programme can be about both, and you can have chapters in a dissertation or other book about each. But any one paper needs to stand up to a single, clear set of criteria.
In the papers that motivated this blog post, the abstract never said what the current state-of-the-art system OR its extension were for. The "Introduction" did not contain the motivation, or the results, or the roadmap, which are the three things that every Introduction needs. Rather the introductions wandered through background information on the older systems. Actually, this is also a common failure mode in talks. Information on history should go, if anywhere in a "Background" section, after the Introduction. In general, the Background section should establish the state of the art so you can prove you have gone beyond it.
Order of writing: Don't try to polish the introduction & abstract before you finish the results. The first time you write the Introduction it's just to have an outline for the rest of the paper, then you go back and make sure it's the outline of the actual paper after you've really written it. Focus first on the Results after that outline, as they determine the content of the rest of the paper. Results, then method that explains the results, then background to set up the method, then conclusion/discussion, THEN the intro again, & abstract.
Update May 2016: see also a newer post, Demonstrating that a paper ought to be published.
Acknowledgements: Ian Horswill taught me about the ALife paragraph when I was a PhD student. Emma Norling pointed out the Introduction vs Background paragraph was still too rooted in the original paper, so I've fixed that now.
Comments