How To Write A Research Paper: Serge Autexier
How To Write A Research Paper: Serge Autexier
How To Write A Research Paper: Serge Autexier
Serge Autexier
German Research Centre for Articial Intelligence Bremen (DFKI)
DP@CICM 2010
Overview
Why writing a paper at all (purpose)? How to organise a paper Kind of publication, when, where How does reviewing work?
http://research.microsoft.com/en-us/um/people/simonpj/ papers/giving-a-talk/writing-a-paper-slides.pdf
Alan Bundy: How to Write an Informatics Paper
http: //homepages.inf.ed.ac.uk/bundy/how-tos/writingGuide.html
Autexier: Research Paper Writing 2 DP@CICM 2010
Communicate Ideas, contribute to advancement of knowledge in your eld Get recognition in your eld (research career) to get promoted, get research positions People are less interested in technicalities of implementations (unless the topic is about programming in a specic programming language) They dont have your specic system, but want to get something reusable out of your work Sometimes ideas and implementation can get very close
DP@CICM 2010
There are different kinds of papers Theoretical papers: you have a problem (e.g. in Mathematics, theoretical Computer Science) and propose a solution
Is a problem decidable, semi-decidable? What is the complexity of sorting a list ?
Engineering papers (e.g. Computer Science, AI): you have a thesis, that can only be tested by experiments
Because the problem is not sufciently explored to have a theory in which to study the question theoretically Examples:
OCR for mathematical texts (Infty) Automated Theorem Proving (in semi-decidable logics) Daniel Kuehlweins evaluation of premise selection for ATP Melanies approach to automate B set theory proofs by reduction to FOL
DP@CICM 2010
The Title
Ideally, the title should summarise the hypothesis of the paper. The reader should be able to work out what the paper is about from the title alone. Cute, cryptic titles are fun, but unhelpful. (James Davenports suggestion: Use them as subtitles)
DP@CICM 2010
The Abstract
The appetizer Also used by reviewers to select the papers they want to review Write it when the rest of the paper is written (or you have a clear structure) Must be self-contained and closed
No citations No references into parts of the paper
DP@CICM 2010
Introduction
Brief context of your work Brief problem description
Maybe use an example to describe the problem (if adequate)
Use proposed solution to motivate/introduce theoretical bases you may need Introduce structure of your paper
either in text, for instance along with the contributions, or as an explicit text The paper is organised as follows: In Section 2 we develop the foundations . . .
At most 1 page
Autexier: Research Paper Writing 9 DP@CICM 2010
Problem 1: Comparing with related work before your idea gets between you and the reader Problem 2: It does not help the reader because she has yet nothing to check against
10
DP@CICM 2010
instead. . .
On the way cite relevant work, but defer discussion/comparison to the end.
11
DP@CICM 2010
Consider a bifurcated semi-lattice D, over a hyper-modulated signature S. Suppose pi is an element of D. Then we know for every such pi there is an epi-modulus j such that pj pi.
Sounds impressive. . . but Sends readers to sleep In a paper you MUST provide the details but FIRST convey the idea !!
12
DP@CICM 2010
Spend time to nd and develop an example, look for everyday problems accessible to many readers. Use it to state the problem Use it to illustrate your technique Use it to illustrate how your technique works Introduce it as a running example very early in the paper (if not already in the introduction)
13
DP@CICM 2010
Explain it as if you were speaking to someone using the white/blackboard Conveying the intuition is primary, not secondary Once the reader has the intuition, she can follow the details (but not vice versa) Even if she skips the details, she still takes away something usable
14
DP@CICM 2010
Evidence
Your introduction makes claims The body of your paper provides evidence to support each claim Check each claim in the introduction, identify the evidence and forward-reference from the claim Evidence can be: analysis and comparison, theorems, measurements, case studies
15
DP@CICM 2010
Related Work
To make my work look good I have to make other peoples work bad
is a fallacy!
16
DP@CICM 2010
Giving credits to others does not diminish the credit you get from your paper
Warmly acknowledge people who have helped you Be generous for the competition. In his inspiring paper [Foo98] Foogle shows . . . We develop his foundation in the following ways. . . Acknowledge weaknesses in your approach as well as its limitations Honesty in science is essential and negative results are also important. Comparison of related work is part of the evaluation
Autexier: Research Paper Writing 17 DP@CICM 2010
If you imply that an idea is yours, and the referee/reader knows it is not, then either You dont know know that its an old idea (bad) You do know, but are pretending its yours (very bad)
18
DP@CICM 2010
A good plan: when you think you are done, send the draft to the competition saying could you help me ensure that I describe your work fairly? Often they will respond with helpful critique They are likely to be your referees anyway, so getting their comments you front is good!
19
DP@CICM 2010
More than a summary The conclusion should both summarise the research and discuss its signicance Try to derive
what your solution shows what can be learned from it reassess the state of the eld in the light of your contribution
Future work:
Some unexplored avenues of the research Identify and briey develop new directions that have been suggested by your research
20
DP@CICM 2010
Appendices
Use to provide additional material for the reviewing process to stay in page limits for main parts. Use it only if really, really necessary
it will not be in the nal version, so the actual readers wont see it, thus it should not be essential to understand the idea of your solution)
For the nal version: make a long version with all these details in a technical report and cite that one Additonnal material can be: proofs of less relevant lemmas, case study details, etc.
21
DP@CICM 2010
Bibliography
Use a bibliography database the maintain and organise your bibliographic references Different kinds of publications (confence proceedings, journal articles, books, thesis) have different mandatory elds to ll Good description in Latex Companion 2nd Edition Build up while reading related work Use it for paper preparation (Bibtex format, but others exist) Nevertheless always check the generated bibliography at the end for duplicates, typos, etc.
22
DP@CICM 2010
Abstract, Introduction
In theory papers you have claims substantiated by analysis and theorems (and their proofs) In engineering paper you must formulate a hypothesis and lay out by which methods you will evaluate it Not explicitly stating the hypotheses makes the contribution of papers vague Dont try to evaluate too many hypotheses at once, this makes the evaluation fuzzy and leads to confusion
24
DP@CICM 2010
Forms of Hypotheses
Hypothesis can be of the following forms: (1) Technique/system X automates task Y for the rst time; (2) Technique/system X automates task Y better, along some dimension, than each of its rivals; Dimensions:
Behaviour: X has a higher success rate than Y or produces better quality outputs Coverage: X is applicable to a wider range of examples then Y. Efciency: X is faster or uses less space then Y. Dependability: X is either more reliable, safe or secure than each of its rivals. Maintainability: Developers nd X easier to adapt and extend than its rivals. Useability: Users nd X easier to use than its rivals.
25
DP@CICM 2010
To conduct the evaluation, you need an implementation of your technique/system You should give a specication of your implementation, not only the description of your implementation (intuition vs. details) Specication:
The techniques that underlie the implementation are (formally) specied. The requirements of the implementation are given.
26
DP@CICM 2010
Implementation
Only the nal state of the implementation should be described (not its history) The major design decisions should be identied and reasons given for the choices made. Abstract away from the code Outline the overall structure of the system and the key algorithms in abstract form,
e.g. using diagrams or formalised English/pseudo code. A worked (running) example is often helpful.
27
DP@CICM 2010
Evaluation
Evaluation is not testing Evaluation is the gathering of evidence to support or refute the hypothesis. Hypothesis 1: (rst time):
system X must be applied to a sufcient range and diversity of examples of task Y to convince the reader that it constitutes a general solution to this task. Descriptions of its behaviour, coverage and efciency should be presented and, where appropriate, a description of dependability, maintainability or useability
Hypothesis 2: (better, along some dimension, than each of its rivals) (Related Work!)
in addition to 1 there must also be a comparison with rival systems along the chosen dimensions Also comparison along the unchosen dimensions, even if this is a negative result for system X; honesty in science is essential and negative results are also important.
Autexier: Research Paper Writing 28 DP@CICM 2010
General Remarks
Conveying an idea requires you guiding the reader No need to show how much you know about the whole area by writing an introduction to the whole eld The reader is not that deep into the problem as you are Help the reader by explaining and avoid superous details Be concise in order to not confuse the reader Clarity/precision:
Crucial for the reader and yourself Unclear/obscure parts
Confuse the reader Can give the reviewer the impression that something is odd/not well developed/not well understood by you May indeed be parts you have not sufciently understood/developed
30
DP@CICM 2010
Quotations: When you quote other authors, give them the credit. How to write a Research Paper [Simon Peyton Jones] How to write an Informatics Paper [Alan Bundy] Quoting own previous work:
best rephrasing it than just copy and paste (context) careful with reusing parts written together with collaborators (quotation)
31
DP@CICM 2010
Use Version Control Systems (SVN) to collaborate Note: imposes format of the document you use for writing, not all document formats are well supported by VC systems, hence suitable for collaboration
Autexier: Research Paper Writing 32 DP@CICM 2010
Workshop papers: possibly peer-reviewed, typically no publication, sometimes post-workshop proceedings or special issues in journals with new reviewing round Conference papers: peer-reviewed, real publications (Informatics and related), reputation depends on conference and publisher Journal articles: peer-reviewed, high quality publication (depends on Journal reputation and publisher)
34
DP@CICM 2010
Avoid world conferences and multi-conferences about everything and nothing Check the proceedings of previous events to get an idea of the style of papers are written in this venue
Different communities have different styles (mathematical, formal logic, technical vs. less technical, application oriented with e.g. UML, XML playing a major role)
Autexier: Research Paper Writing 35 DP@CICM 2010
37
DP@CICM 2010
PC discussion: Reviews are discussed by PC members to come up with a decision of acceptance/rejection (or other forms of acceptance). Sometimes preceded by a rebuttal Final decisions made by PC chair
Autexier: Research Paper Writing 38 DP@CICM 2010
Journal Reviewing
Submission to the editors (journal editors or guest editors in case of spec Paper assignment by editors based on their knowledge who the experts are Reviews written by expert reviewers Reviews are discussed among editors to come up with a decision of acceptance/rejection
Different option: major revisions and new round of reviewing
39
DP@CICM 2010
homepages.inf.ed.ac.uk/bundy/ how-tos/writingGuide.html
Simon Peyton-Jones: How to Write A Great Research Paper