journal writing methods

7/30/2019 Journal Writing Methods

1/29

How to write a Journal/Conference Paper

In general, a conference paper consists of the following sections

1. Abstract

2. Introduction

3. System Description

4. Experiments, Presentation of results, and Analysis

5. Conclusions

6. References

Specific conference papers will have a slight extended format. In this example I

will use the Lake

Water Quality Monitoring DTN project as an example of a work to be reported on

in a conference

paper. The formatting of specific conference papers varies slightly as well;

however, in our field, we

use the IEEE conference paper format. You can get a description from:http://www.ieee.ca/ccece09/paperkit.php#DocumentFormatting

INTRODUCTION

The Introduction should provide the purpose, problem, and scope.

1. Specify what problem (topic) is being addressed.

2. Why is the problem (topic) interesting?

3. What is the current state of the art of solutions?

a. How is the topic currently being addressed in the literature?

b. Why is the current solutions proposed in the literature inadequate?4. What are the weaknesses?

5. What are the disadvantages?

6. What is the proposed solution?

a. What is the conjecture?

b. What is the motivation?

c. Why is it interesting?

d. How does the proposed solution compare with others?

7. In theory

8. In practice

a. What are the weaknesses of the proposed solution?

1


2/29

Fig. 1. Research vector.

b. By defining the proposed solution, the scope is automatically given.

c. This section of the Introduction concludes with a statement that identifieswhat will be given in the remainder of the paper. For example, The

remainder of this paper is organized as follows: The requirements of the

Lake Water Quality Monitoring project are given. This is followed by a

description of simulation environment, which includes a description of

the software that was used to simulate the sensors, nodes, and gateways.

Following this, the experiments and an analysis is given. Finally, the

conclusions and future work are given.

LAKE WATER QUALITY MONITORING REQUIREMENTSThe Requirements section will be a subpart of the Introduction section. Describe

the real environment that you will be monitoring or controlling. Give the

requirements in an ordered paragraph fashion. For each requirement, make a new

paragraph. State the requirement as the first sentence of the paragraph and the rest

of the paragraph will explain why that is a requirement.

SYSTEM DESCRIPTION

The System Description section describes the system that is used to show or verify

the conjecture. The system may be software, hardware, or a combination of

hardware and software. This section is normally called something more specificthan System Description. For example, in the Lake Water Quality Monitoring

example paper, this section could be called Simulation Environment.

The first part of this section could describe the PlanetLab environment, and this

could be followed by subsections that describe the software and/or hardware

design of the sensors, nodes, and gateways.

2


3/29

EXPERIMENTS, PRESENTATION OF RESULTS, AND ANALYSIS

The Experiments section should describe and explain each experiment that was

conducted. The experiments are used to prove or verify the validity of the

conjecture. If you have more than one experiment, separate them into different

subsections, and include an analysis for each experiment in the subsection.

CONCLUSIONS AND FUTURE WORK

The conclusions consist of three parts: (i) summary, (ii) contributions, and (iii)

recommendations for future work. Briefly summarize what was done in the project.

Then state the conclusions and contributions. The contributions should be all

inclusive, and they should state what advancement your work has provided.

Ideally, the advancement should be relative to the field in which your work exists.

For example, probably no one has implemented a DTN in PlanetLab, etc.

REFERENCES

List the references. Be sure to use the IEEE format.

How to write a Journal/Conference Paper:

Or How to Present Technical Results

(Greg Grudics sure fire recipe )

When writing a technical paper, it is generally a good idea to start with a

presentation. Once you have written a 30 to 50 minute presentation that you feel

effectively motivates your results and presents them in a convincing, coherentmanor, the process of writing the paper should be trivial - simply transcribe what

you say in your presentation into a document! Here is an outline for a successful

presentation:

Part 1: Specify what problem (topic) is being addressed.

Why is the problem (topic) interesting!

Part 2: What is the current state of the art of solutions? Or, how is the topic

currently being addressed in the literature? Why is the current literature inadequate?

Part 3: What is the proposed solution?

What is the motivation? Why is it interesting?

3


4/29

Part 4: Discussion.

How does the proposed solution compare with others?o In theory?o In practice?

What are the weaknesses?

Part 5: Conclusion.

Summarize proposed solution and why it is interesting. Summarize weaknesses. Identify open questions.

HOW TO GET YOUR PAPER ACCEPTED AT OOPSLA

(reprinted from the OOPSLA '91 Proceedings, Appendix, p. 359-363) OOPSLA'96

Call for Student Volunteers

INTRODUCTION

The primary goal of the program committee of a major conference like OOPSLA is

to put together a high quality program of technical papers. The program is created

by soliciting contributed papers from authors and then selecting the best papers

according to some criteria. The process is reactive: the authors submit, thecommittee selects from those submissions. Because of time constraints, it is

generally not possible for the committee to interact with an author to improve the

quality of a paper that fails to meet the acceptance criteria in its submitted form.

Although the reviewers may offer helpful comments to the author of a rejected

paper, the author must find some other forum for the paper (hopefully in an

improved form).

As program chair for the 1991 OOPSLA conference, I decided to address this

situation proactively by writing this article. The purpose of this article is to provide

advice to prospective OOPSLA paper authors, based on my past experience. If you

are a prospective author of an OOPSLA paper, I hope you will be able to use this

advice to make improvements to your paper before submitting it to the program

committee, thus improving its chances for acceptance.

4


5/29

This article will also offer some suggestions to help you decide whether to submit

a paper to OOPSLA at all. Members of the program committee spend a

considerable amount of time reviewing a large number of papers. You should

avoid unnecessarily adding to this workload, by not submitting a paper that is

clearly inappropriate.

CRITERIA

The 1991 OOPSLA conference is looking for papers in two basic categories.

Research papers are papers that describe work whose purpose is to advance the

state of the art of object technology. Experience papers are papers that describe

work in which object technology has been applied for some purpose. The

evaluation criteria for these papers are somewhat different; these differences are

noted in the remaining discussion. Tutorial papers and surveys are not solicited for

the 1991 conference; they should not be submitted. (This policy could change forfuture conferences; check the call for papers.)

The primary requirement is that your paper must contribute to our understanding of

object technology. It must have something new to say, and its message must be of

sufficient importance and interest to warrant the attention of the OOPSLA

community.

If your paper is a research paper, it should describe a new idea or a new technique.

It must describe original work. Your paper should present supporting evidence, not

just conjecture. Idea papers should be backed up by a convincing analysis.

If your paper is an experience paper, it should present new data based on actual

experience that demonstrates the effectiveness (or ineffectiveness) of object

technology, describes problems encountered, and makes suggestions for

improvements. It should provide new evidence, either positive or negative, to

evaluate existing ideas or techniques. It should help provide direction for future

research, as well as provide new insights of value to other practitioners using

object technology.

The distinction between research and experience papers is not absolute. It ispossible to gain experience in a research setting, and it is possible to develop new

ideas or techniques while applying a technology. However, if you focus on one of

these two aspects, you will write a better paper.

Your paper should make its contribution abundantly clear. It is not the job of the

program committee to ferret out this information. One aspect of identifying the

5


6/29

contribution is to cite and make appropriate comparisons with previous work. A

research paper should compare and contrast the work with prior work,

demonstrating novelty. An experience paper should compare its results with other

papers that present similar or opposing data. An experience paper that merely

confirms that which is well known has opposed to that which is widely believed) is

of little value.

Obviously, your paper must not have been published elsewhere in the same or

similar form. Less obviously, your paper must not be under consideration

elsewhere in the same or similar form. While the desire for authors to "hedge their

bets" by submitting the same or similar paper to multiple conferences and/or

journals is understandable, this practice places an unnecessary burden on the peer

review process. It can also cause embarrassment or confusion if the same paper is

accepted at more than one conference. If you believe that unusual circumstances

warrant simultaneous submission to more than one forum, you MUST notify ALLthe program chairs and editors involved; simultaneous submission without notice is

considered highly unethical. (Note that archival journals frequently accept versions

of papers that have already appeared in conferences, but usually it is in your best

interest to get feedback from the conference presentation before submitting a

polished and revised version to a journal.) It is also considered inappropriate to

submit multiple papers to the same conference that cover substantially similar or

overlapping material. (It may be appropriate, however, for multiple papers to be

submitted concerning distinct aspects of a single project, particularly if the various

papers have different authors.)

If you have published previous papers on the same subject, your paper should

clearly indicate the relationship between your new paper and the previous papers.

Finally, your paper must be well written. It must clearly communicate its message

to the intended audience.

PURPOSE

You should answer some key questions before submitting a paper:

The first question you should answer is "Why am I writing this paper?" If the

answer is of the form "to document what I have been doing for the past two years",

then you are in danger of writing a bad paper. It may be a shock to your pride, but

most people are not interested in what you have done for the past two years. If you

need to document your efforts, write a memo or a tech report. Another poor answer

6


7/29

is "to help build my case for tenure". Tenure may be your initial motivation for

writing a paper, but it should not be the only motivation.

The purpose of your paper should be to communicate something to someone. So,

the next questions are "What is my paper trying to say?" and '"Who is the audience

for my paper?" If you cannot clearly answer these questions, then the paper is

likely to be poor.

A focused paper is better than a scattered paper. Resist the temptation to describe

every great idea you had while working on your project. Pick a primary message

and communicate it well.

After deciding what the paper is trying to say, the next question to answer is "Is it

worth saying" Is it a new message, or just a rehash of an old message? Is the

message of value, or potential value, or is it trivial? Is it conjecture, or have youdemonstrated the soundness of your conclusions?

After deciding who the audience is, the next question to answer is "'Is OOPSLA a

good way to reach my audience?" Does my message have value to researchers and

developers of object technology? Does my message have value to practitioners

using object technology?

IS IT PREMATURE?

Many papers are rejected because they are "premature". This characterizationmeans that the work appears to be interesting, but it has not progressed far enough

to be worth reporting in a conference paper. The paper may have more conjectures

or opinions than results. Perhaps there are ideas that look promising, but they have

not been worked out in enough detail. Perhaps more analysis of the issues is

needed. Perhaps the proposed technique sounds interesting, but its value cannot be

determined until it has been implemented.

An experience paper may be called premature if it offers conjectures about

expected results rather than reporting observed results. For example, if you are just

about to release a product, it is premature to claim improvements in softwaremaintenance until the product undergoes a maintenance cycle. If you have just

created a "reusable" library, it is premature to declare it reusable until actual reuse

occurs.

One area of difficulty is portability. Experience has shown that designing a

portable system of any kind can be surprisingly difficult. One cannot convincingly

7


8/29

claim to have designed a portable system unless the portability of that system has

been tested in at least two environments.

The decision to accept or reject a paper that is premature is a judgment call by the

program committee. A committee may choose in some cases to accept a paper that

presents early work of a profound or provocative nature. However, you should

honestly evaluate the maturity of your work before deciding to submit a paper on

it. You may be able to write a much stronger paper for next year's conference!

IS IT SOUND?

Your paper should convince the program committee that your work is technically

correct. The burden of proof is on you, the author. It is not the job of the program

committee to prove your paper incorrect. If the correctness of your work is in

doubt, your paper will probably be rejected. Soundness of ideas or techniques canoften be demonstrated by the depth and clarity of the analysis, or by reference to a

working implementation. Questions of soundness often arise for papers that present

algorithms or proofs (see the next two sections).

ALGORITHMS

It is self-evident that complex algorithms are difficult to get right. Garbage

collection algorithms in particular have gained a degree of notoriety amongst

members of previous OOPSLA program committees. In general, a description of a

complex algorithm will not by itself be sufficient to convince the programcommittee that your algorithm is correct. The committee will be much more likely

to accept your algorithm paper if it contains at least one of the following elements:

a formal proof of correctness (but see the next section), reference to a working

implementation, or (marginally) a formal analysis of its complexity.

PROOFS

A formal proof is of value only if it is convincing. While a reviewer may be able to

spot an error in a faulty proof, one cannot expect a reviewer to validate a proof.

Therefore, any sloppiness in the formalism is grounds for suspicion (and likelyrejection of the paper). It is better to avoid formality than to misuse it.

In addition to being convincing, a proof must prove something worth proving. It is

not worth anyone's time to read a paper that proves an irrelevant result. Be careful

about including a proof in an effort to make your paper more "prestigious". This

8


9/29

approach may backfire, as a sloppy or unmotivated proof can easily cause a paper

to be rejected that otherwise might have been accepted.

GENERALITY

The audience at OOPSLA includes people from many communities. You willimprove your paper if you can address a broad audience, wherever possible. While

specific examples can be given, the problem and solution should be presented in

general terms.

I will explore this question in the context of object-oriented programming

languages, although it applies to other areas as well. Many papers submitted to

OOPSLA are written in the context of a specific object-oriented programming

language. In many cases, the papers are actually addressing more general issues.

As a hypothetical example, suppose you want to write a paper on "extending the

Foo programming language to support distributed computing". A paper on this

subject could easily address many issues that are not specific to the Foo

programming language, although some might be. Such general issues might

include naming, storage management, concurrency, and distributed schema (type)

management. Your paper would be much stronger, and much more likely to be

accepted, if it addresses these issues in general terms wherever possible, using the

Foo-specific work as examples. If your paper is inherently Foo-specific, then you

should consider submitting it to a more appropriate forum, such as the Foo

Conference, the Foo Journal, or a meeting of the Foo Users Group.

A gray area arises if your paper deals with a distinctive aspect of the Foo language.

A paper that can demonstrate the value (or disadvantage) of a language-specific

feature could be of great interest to all language researchers.

WHAT ABOUT APPLICATIONS?

Suppose you've written an application using object technology. Should you submit

a paper to OOPSLA about it? That depends. What is interesting about it? Is it the

novelty of the application? That might not be sufficient. For example, a novelapplication for allowing users to find library books might better be reported at a

conference on library technology. Is the novelty of the application directly enabled

by using object technology? That could be a good OOPSLA paper! Is the

interesting aspect your experience in using object technology? Then concentrate on

reporting your experience; don't devote an undue amount of verbiage to describing

the application itself.

9


10/29

DON'T BE ISOLATED

Object technology overlaps many established areas of computer science, such as

programming languages, databases, and distributed computing. If you are writing a

research paper, it is important that you be familiar with the larger area, and not

isolate yourself to the narrower domain of object technology. For example, if you

are writing a paper on object-oriented distributed computing, you should think of

yourself as writing a paper on distributed computing (that happens to involve an

"objects" approach). The fact that your approach is object-oriented does not excuse

you from relating the work to the existing distributed computing literature. Similar

comments could be made about many different areas.

WRITING

Effective communication is important for a successful paper. A paper has littlevalue if its intended audience cannot understand it. An incomprehensible paper

cannot even be reviewed.

Most authors will benefit from having their paper reviewed by a skilled writer. If

your native language is not English, you have an extra burden. If at all possible, try

to have your paper reviewed by a native or fluent speaker of English.

FINAL ADVICE

In my experience, most papers are substantially improved by getting feedbackfrom other people. Giving a talk to a small group is an excellent way to get

feedback and to force your self to organize your thoughts. Also, have your paper

reviewed by your colleagues before submitting it to OOPSLA. After all, you can

change your paper based on their feedback; if the program committee rejects it,

there is no second chance (for that conference).

Do not hesitate to attach a cover letter to your paper if there is additional

information that would be useful to the program committee. For example, if you

have published previous papers on the same subject, you might attach a cover letter

to explain in more detail the novel contributions of the paper you are submitting.

Finally, as has been noted elsewhere [Wegman], the conference review process is

necessarily imperfect. The reviewers operate under strict time constraints, and the

committee must make quick decisions. A paper will not receive the careful

attention that it would from a journal. Furthermore, the committee may need to

satisfy other constraints in putting together a successful program. As a result, some

10


11/29

good papers will be rejected. Authors should carefully consider any reviewer

comments and get opinions from experienced colleagues before deciding whether

to abandon the effort or to revise the paper and submit it elsewhere.

Additional insight can be obtained from the excellent paper by Smith [Smith] that

describes the review process from the point of view of the referee.

ACKNOWLEDGMENTS

This article has benefited from the collective experience of the current and five

previous OOPSLA program committees.

REFERENCES

[Smith] Alan Jay Smith. "The Task of the Referee". Computer(April 1990),65-71.

[Wegman] Mark N. Wegman. "What it's like to be a POPL Referee, or How to

write an extended abstract so that it is more likely to be accepted". Sigplan Notices

21:5 (May 1986),91-95.

SEE ALSO

The OOPSLA'93 Panel on "How to Get a Paper Accepted at OOPSLA".Alan Snyder

Hewlett-Packard Laboratories

P.O. Box 10490

Palo Alto CA 94303-0969

Back to OOPSLA Homepage

This information last updated by [email protected] Mon Jan 1 12:05PM 1995

How to Write an Academic Conference Paper

ByCraig Brewer, eHow Editor

Writing an academic conference paper can be daunting, especially if you are a

relatively new scholar, graduate student, or even an undergraduate.Difficulty: Moderately Challenging

11
http://www.sigplan.org/oopsla/oopsla96/how93.htmlhttp://www.sigplan.org/oopsla/oopsla96/oopsla96.txthttp://www.ehow.com/members/ds_craigbr9271.htmlhttp://www.sigplan.org/oopsla/oopsla96/oopsla96.txthttp://www.ehow.com/members/ds_craigbr9271.htmlhttp://www.sigplan.org/oopsla/oopsla96/how93.html


12/29

Instructions

Submitting an Abstract

1. Step 1

Look for calls-for-papers (CFPs) long in advance. Abstract submissions areoften due a year before the conference.

2. Step 2

Submit ideas to many different conferences. Do not submit the same abstract to

more than one conference, but submitting different versions of an article to

separate conferences is common. Do not try only for the most prestigious

gatherings, especially if you are just starting out. Regional conferences offer a

great way for up and coming scholars to enhance their CVs.

3. Step 3

Keep your abstract short. Make your claims, but do not try to fully develop an

argument. That is for the paper. Be sure to note what about your project is

innovative rather than just explaining your topic.

4. Step 4

Submit your abstracts early. Since most people wait until the deadline (or evenafter) to submit paper ideas, you have a better chance if you can show you plan

ahead.

Writing the Paper

5. Step 1

Keep it short and clear. People are more impressed with an elegant but simple

statement of a complex idea than of a long, tedious exercise in erudition.

6. Step 2

Keep footnotes and endnotes even if you will not present them during the talk.

If you are lucky, a conference paper can become an article submission, and you

do not want to have to redo research.

7. Step 3

12


13/29

Make and explain your claims, but keep the details of the argument to a

minimum. Conferences are a place to share and get feedback on ideas, not

(usually) to debate minutiae. You can always add more detail in the question-

and-answer period, but overloading your paper with quotations, data, or

statistics will lose your audience.

8. Step 4

Use handouts. Handouts are not only good for helping people through your

argument, but they also leave something tangible for other scholars to

remember you by.

9. Step 5

Practice. Even if your discipline's conferences usually involve simply reading a

paper out loud, knowing how to express yourself orally can significantly

improve how your work is received.

See if you recognize anyone in the audience beforespeaking. This is particularly useful during the question-and-answer period when you may have to field questions from expertsin your field, even those you cite in your presentation.

Use the paper as a chance to network. Even a piece of workin its early stages can be an opportunity to ask established

scholars for advice. Avoid excusing partial or unfinished work because it is part

of a longer article project. Your audience will see through thisand, even if it is true, will wonder why you did not prepare a morepolished presentation.

Write and Submit a Conference Paper Proposal

Each conference has its own program committee, and the number ofproposals accepted for a meeting depends on program size (the number ofsessions), technical coverage (the topics to be covered), and number andquality of paper proposals. Because program committees look for the bestcontributions, writing an effective paper proposal is important.

Organization

13


14/29

Your paper proposal should contain enough information to allow theProgram Committee to make an accurate judgment of the content of yourpaper and presentation. Paper proposals should be around 350 words,which should be ample if you organize your text along the following lines:

Description of the Paper

Outline the scope and nature of the work upon which the paper isbased (e.g., field data, laboratory data, original analysis, or computerwork). If the paper is a review paper, make the extent of coverage clear.

ApplicationsDescribe the possible applications of the knowledge provided in the paper.

Results, Observations, and Conclusions

Summarize the results and major conclusions to be presented in thepaper and state how these differ from previous work on the same subject.State whether new information will be revealed and whether data fromfield, laboratory, or computer will be included.

Technical Contributions

Describe the significance of the proposed paper by listing up to threetechnical contributions or additions to the technical knowledge base of thepetroleum industry.

Elements of a Good Paper Proposal

Appropriate Title

A good title is short and informative (tells the reader what the paper isabout). Use familiar terms and keywords so that someone doing a keywordtitle search for papers on the topic can find the paper. Avoid words that arebased on a value judgment, such as "new" and "improved," unless thematerial to be presented truly is new or an improvement over existing

techniques.

Problem Statement

In writing a paper, you are assumed to be proposing a solution to aproblem or to be presenting new knowledge that is of interest to oil and gasprofessionals. Your paper proposal should state succinctly the problem you

14


15/29

intend to address. Your problem statement should convince ProgramCommittee members that there is indeed an important problem that meritssolution or further investigation.

Objectives and Scope of Study

State the objectives of the study clearly, listing them if possible.Outline the scope or limitations of your work. Point out the extent ofcoverage, aspects that are not yet well understood, and points that requirefurther study. A candid acknowledgment of the limitations of your workadds credibility to your paper proposal. Because of limited space, paperproposals should avoid a literature review or other extensive backgroundinformation. However, highlighting how your results differ from orcomplement previous results on the subject is appropriate. Typicalobjectives are to develop a new theory or principle; to show practicalapplications of known principles; to develop a solution to an engineeringproblem in a device, material, system or process; to design a new structureor process; or to develop a new and improved method.

MethodState briefly what you did and how you did it. The goal is to outline thesteps and procedures you used to accomplish the objectives of your study.

Results and Observations

Give the major results or findings of the study. Highlight theimportance of results to the area of study.

ConclusionsState the major conclusions of the study. Do not confuse conclusions withresults and observations. Results and observations are facts, whereasconclusions are the lessons learned from interpretation of the facts. Thefollowing is an example of the difference:

Laboratory mice were fed different doses of a chemical from very small tovery large doses. All the mice died within 3 days. Result and Observation:

All the mice died within 3 days.Conclusion: The chemical is toxic to mice even at very low concentrations.

ApplicationsGive the possible practical applications of the results of your study. Howcan the results of your work be applied to finding, producing, processing,

15


16/29

and marketing hydrocarbons and related products efficiently, economically,and in an environmentally safe manner?

Innovations or Technical Contributions

State what is new in your study and its importance to the field. List upto three of the most important innovations or technical contributions in yourproposed paper. Do not be too modest to highlight the innovation ortechnical contribution of your work because it could determine whetheryour paper proposal is selected or rejected.

Criteria for Selection

Your proposal should demonstrate clearly that your paper:

Will contribute to petroleum technology, particularly in the areaidentified as the technical focus for the specific meeting, or will presentother information of immediate interest to E&P professionals. Will presentinformation that is technically sound. Will present new knowledge orexperience, the substance of which has not been published previously.Will not be commercial in nature and will not promote specific companies,products or services.

Submitting Your Paper Proposal

Submitting your proposal online is easy. The Call for Papers page listsconferences currently accepting paper proposals. Clicking on a conferencename will take you to information about the meeting. The submission formcan be accessed from either the Call for Papers page or from the meetingpage.

Obtain necessary company clearance from your management beforesubmitting your paper proposal. Ensure that your managementunderstands that if your proposal is accepted, you will be required toprepare and submit a full manuscript for the conference proceedings and to

present the paper at the conference. You will also be required to transfercopyright of the paper to SPE.

Before you click the link to submit your proposal, you will need to gather allof the following information:

You will need to log in.

16
http://www.spe.org/spe-app/jsp/siteFunctionality/callForPapers.jsphttp://www.spe.org/spe-app/spe/papers/authors/copyright_info.htmhttp://www.spe.org/spe-app/spe/papers/authors/copyright_info.htmhttp://www.spe.org/spe-app/jsp/siteFunctionality/callForPapers.jsphttp://www.spe.org/spe-app/spe/papers/authors/copyright_info.htmhttp://www.spe.org/spe-app/spe/papers/authors/copyright_info.htm


17/29

If you do not already have a login for the SPE website, go ahead andget one before you begin. If you have one, but don't remember yourpassword, go through the forgot password process before you begin tryingto submit your paper proposal. You might want to check that your contactinformation is also correct. Gather the names, mailing addresses, andemail addresses for all of your co-authors. You will have the opportunity tosearch for co-authors in our database. If found, you'll save yourself sometyping, but if not, you'll need to enter information on your co-authors. Besure you have your title and abstract handy, and that you've reviewed thelist of technical categories for the meeting to determine which apply to yourpaper proposal.

The submission form asks specific questions. All information on the formshould be provided.

Enter a title that is concise yet descriptive of the primary content andapplication of the proposed paper. Company names and trade names arenot permitted in paper titles. List the Corresponding Author (the authorwith whom SPE will correspond on all matters concerning the paper)name, company affiliation, and complete contact information (address,phone number, e-mail). List any coauthors in the order in which theyshould be printed in the program. Include each coauthor's company andcontact information. This information is needed for the conference programand to send coauthors information on registering and attending the

conference. Most conference program committees require authors toselect technical categories for their papers. This information is used todirect your paper proposal to the best-qualified committee members forreview. Select the most appropriate technical categories from the list forthat meeting. (For most meetings, the list also will be found separate fromthe online submission form on the website. The list of technical categorieswill always be included in the printable (pdf) form.) Most Call for PaperProposals include "Other" in the category list with a blank to fill in topicsthat are not on the list.

Submit your paper proposal in time for it to be received by the submissiondeadline. If your paper proposal is received after the deadline, it may not beconsidered.

SPE meetings have a "no-paper, no-podium" policy. If your paper proposalis accepted, you will be required to submit your manuscript by the deadline.

17


18/29

If you do not do so, you will not be allowed to present your paper at theconference. So when submitting your paper proposal, be certain that youwill have time to write the full paper if your proposal is accepted.

SPE requires that authors of accepted papers transfer copyright of thepaper to SPE. This allows SPE to distribute the paper in the proceedings,to include it in the eLibrary, to consider it for peer review (if requested) andother uses. More on copyright

Tips for Writing Technical Papers

Jennifer Widom, January 2006

Here are the notes from a presentation I gave at the Stanford InfoLab

Friday lunch, 1/27/06. The presentation covered:

Paper Title The Abstract

The Introduction

Related Work

The Body

Performance Experiments The Conclusions

Future Work

The Acknowledgements

Citations

Appendices

Grammar and Small-Scale Presentation Issues

Mechanics

Versions and Distribution

18
http://www.spe.org/spe-app/spe/papers/authors/copyright_info.htmhttp://infolab.stanford.edu/~widomhttp://infolab.stanford.edu/http://infolab.stanford.edu/~widom/paper-writing.html#titlehttp://infolab.stanford.edu/~widom/paper-writing.html#abstracthttp://infolab.stanford.edu/~widom/paper-writing.html#abstracthttp://infolab.stanford.edu/~widom/paper-writing.html#introhttp://infolab.stanford.edu/~widom/paper-writing.html#relatedhttp://infolab.stanford.edu/~widom/paper-writing.html#bodyhttp://infolab.stanford.edu/~widom/paper-writing.html#experimentshttp://infolab.stanford.edu/~widom/paper-writing.html#conclusionshttp://infolab.stanford.edu/~widom/paper-writing.html#futurehttp://infolab.stanford.edu/~widom/paper-writing.html#ackshttp://infolab.stanford.edu/~widom/paper-writing.html#citationshttp://infolab.stanford.edu/~widom/paper-writing.html#appendiceshttp://infolab.stanford.edu/~widom/paper-writing.html#grammarhttp://infolab.stanford.edu/~widom/paper-writing.html#mechanicshttp://infolab.stanford.edu/~widom/paper-writing.html#versionshttp://www.spe.org/spe-app/spe/papers/authors/copyright_info.htmhttp://infolab.stanford.edu/~widomhttp://infolab.stanford.edu/http://infolab.stanford.edu/~widom/paper-writing.html#titlehttp://infolab.stanford.edu/~widom/paper-writing.html#abstracthttp://infolab.stanford.edu/~widom/paper-writing.html#introhttp://infolab.stanford.edu/~widom/paper-writing.html#relatedhttp://infolab.stanford.edu/~widom/paper-writing.html#bodyhttp://infolab.stanford.edu/~widom/paper-writing.html#experimentshttp://infolab.stanford.edu/~widom/paper-writing.html#conclusionshttp://infolab.stanford.edu/~widom/paper-writing.html#futurehttp://infolab.stanford.edu/~widom/paper-writing.html#ackshttp://infolab.stanford.edu/~widom/paper-writing.html#citationshttp://infolab.stanford.edu/~widom/paper-writing.html#appendiceshttp://infolab.stanford.edu/~widom/paper-writing.html#grammarhttp://infolab.stanford.edu/~widom/paper-writing.html#mechanicshttp://infolab.stanford.edu/~widom/paper-writing.html#versions


19/29

Running Example

As a running (fictitious!) example, suppose you've designed and run

experiments with a new algorithm for external multipass merge-sort. Your

algorithm reduces the complexity from O(n log n) to O(n), under the

premise that it's acceptable to have some bounded "unsortedness" in theresult. You plan to write up the results for submission to a major

conference.

Note: This example was used throughout the live presentation but I haven'tfollowed through much in these notes. Thus, the notes include severalexercises for the reader.

Paper Title

Titles can be long and descriptive:

Linear-Time External Multipass Sorting with ApproximationGuarantees

or short and sweet:

Approximate External Sort

Hector believes it's important for the paper (or at least the algorithm) to

have a cute name that sticks in people's minds:

Floosh:A Linear-Time Algorithm for Approximate External Sort

The Abstract

State the problem, your approach and solution, and the main contributions

of the paper. Include little if any background and motivation. Be factual but

comprehensive. The material in the abstract should not be repeated later

word for word in the paper.

(Exercise: Write an abstract for the multiway sort example.)

The Introduction

Here is the Stanford InfoLab's patented five-point structure for

Introductions. Unless there's a good argument against it, the Introduction

should consist of five paragraphs answering the following five questions:

19
http://infolab.stanford.edu/http://infolab.stanford.edu/


20/29

1. What is the problem?2. Why is it interesting and important?

3. Why is it hard? (E.g., why do naive approaches fail?)

4. Why hasn't it been solved before? (Or, what's wrong with previousproposed solutions? How does mine differ?)

5. What are the key components of my approach and results? Alsoinclude any specific limitations.

(Exercise: Answer these questions for the multiway sort example.)

Then have a final paragraph or subsection: "Summary of Contributions". Itshould list the major contributions in bullet form, mentioning in which

sections they can be found. This material doubles as an outline of the restof the paper, saving space and eliminating redundancy.

(Exercise: Write the bullet list for the multiway sort example.)

Related Work

The perennial question: Should related work be covered near the beginning

of the paper or near the end?

Beginning, if it can be short yet detailed enough, or if it's critical to

take a strong defensive stance about previous work right away. In thiscase Related Work can be either a subsection at the end of theIntroduction, or its own Section 2.

End, if it can be summarized quickly early on (in the Introduction orPreliminaries), or if sufficient comparisons require the technicalcontent of the paper. In this case Related Work should appear justbefore the Conclusions, possibly in a more general section"Discussion and Related Work".

The Body

Critical rule of thumb: A clear new important technical contribution should

have been articulated by the time the reader finishes page 3 (i.e., a quarter

of the way through the paper). Aside from this rule of thumb, which applies

to every paper, the structure of the body varies a lot depending on content.

Important components are:

20


21/29

Running Example: When possible, use a running examplethroughout the paper. It can be introduced either as a subsection atthe end of the Introduction, or its own Section 2 or 3 (depending onRelated Work).

Preliminaries: This section, which follows the Introduction andpossibly Related Work and/or Running Example, sets up notation andterminology that is not part of the technical contribution. Oneimportant function of this section is to delineate material that's notoriginal but is needed for the paper. Be concise -- remember thecritical rule of thumb.

Content: The meat of the paper includes algorithms, systemdescriptions, new language constructs, analyses, etc. Wheneverpossible use a "top-down" description: readers should be able to see

where the material is going, and they should be able to skip aheadand still get the idea. In general the paper should tell a story. (Don't,however, fall into the common trap of telling the entire story of howyou arrived at your results. Just tell the story of the resultsthemselves.)

Performance Experiments

We could have an entire treatise on this topic alone and I am surely not the

expert. Here are some random thoughts:

Many conferences expect experiments. It's easy to do "hokey" or meaningless experiments, and many papers

do.

It's easy to craft experiments to show your work in its best light, andmost papers do.

What should performance experiments measure? Possiblities:

o Pure running time

o Sensitivity to important parameters

o Scalability in various aspects: data size, problem complexity, ...

o Others?

What should performance experiments show? Possibilities:

21


22/29

o Absolute performance (i.e., it's acceptable/usable)

o Relative performance to naive approaches

o Relative performance to previous approaches

o Relative performance among different proposed approaches

o Others?

The Conclusions

In general a short summarizing paragraph will do, and under no

circumstances should the paragraph simply repeat material from the

Abstract or Introduction. In some cases it's possible to now make the

original claims more concrete, e.g., by referring to quantitative performance

results.

Future Work

This material is important -- part of the value of a paper is showing how the

work sets new research directions. I like bullet lists here. (Actually I like

them in general.) A couple of things to keep in mind:

If you're actively engaged in follow-up work, say so. E.g.: "We arecurrently extending the algorithm to... blah blah, and preliminary

results are encouraging." This statement serves to mark yourterritory. Conversely, be aware that some researchers look to Future Work

sections for research topics. My opinion is that there's nothing wrongwith that -- consider it a complement.

The Acknowledgements

Don't forget them or you'll have people with hurt feelings. Acknowledge

anyone who contributed in any way: through discussions, feedback on

drafts, implementation, etc. If in doubt about whether to include someone,

include them.

Citations

Spend the effort to make all citations complete and consistent. Do not just

copy random inconsistent BibTex (or other) entries from the web and call it

22


23/29

a day. Check over your final bibliography carefully and make sure every

entry looks right.

Appendices

Appendices should contain detailed proofs and algorithms only.Appendices can be crucial for overlength papers, but are still useful

otherwise. Think of appendices as random-access substantiation of

underlying gory details. As a rule of thumb:

Appendices should not contain any material necessary forunderstanding the contributions of the paper.

Appendices should contain all material that most readers would notbe interested in.

Grammar and Small-Scale Presentation IssuesIn general everyone writing papers is strongly encouraged to read the short

and very useful The Elements of Style by Strunk and White. Here's a

random list of pet peeves.

Just like a program, all "variables" (terminology and notation) in thepaper should be defined before being used, and should be definedonly once. (Exception: Sometimes after a long hiatus it's useful toremind the reader of a definition.) Global definitions should be

grouped into the Preliminaries section; other definitions should begiven just before their first use.

Do not use "etc." unless the remaining items are completely obvious.

o Acceptable: We shall number the phases 1, 3, 5, 7, etc.

o Unacceptable: We measure performance factors such asvolatility, scalability, etc.

Never say "for various reasons". (Example: We decided not toconsider the alternative, for various reasons.) Tell the reader the

reasons!

Avoid nonreferential use of "this", "that", "these", "it", and so on(Ullman pet peeve). Requiring explicit identification of what "this"refers to enforces clarity of writing. Here is a typical example ofnonreferential "this": Our experiments test several different

23
http://en.wikipedia.org/wiki/Strunk_and_Whitehttp://en.wikipedia.org/wiki/Strunk_and_White


24/29

environments and the algorithm does well in some but not all of them.This is important because ...

(Exercise: The above rule is violated at least once in this document.Find the violations.)

Italics are for definitions or quotes, not for emphasis (Gries petpeeve). Your writing should be constructed such that context aloneprovides sufficient emphasis.

(Exercise: The above rule is violated at least once in this document.Find the violations.)

People frequently use "which" versus "that" incorrectly. "That" isdefining; "which" is nondefining. Examples of correct use:

o The algorithms that are easy to implement all run in linear time.

o The algorithms, which are easy to implement, all run in lineartime.

Mechanics

Always run a spelling checker on your final paper, no excuses. For drafts and technical reports use 11 point font, generous spacing,

1" margins, and single-column format. There's no need to torture your

casual readers with the tiny fonts and tight spacing used inconference proceedings these days.

In drafts and final camera-ready, fonts in figures should be no smallerthan the font size in the body of the paper.

Tables, figures, graphs, and algorithms should always be placed onthe top of a page or column, not in the body of the text unless it isvery small and fits into the flow of the paper.

Every table, figure, graph, or algorithm should appear on the same

page as its first reference, or on the following page (LaTex willing...).

Versions and Distribution

Many papers have a submitted (and later published) conferenceversion, along with a "full paper" technical report on the web. It'simportant to manage versions carefully, both in content andproliferation. My recommendation is, whenever possible, for the full

24


25/29

paper to consist of simply the conference version plus appendices.The full paper should be the only public one aside from conferenceproceedings, it should be coordinated with latest (final) conferenceversion, and modifications to the full paper should always overwriteall publicly accessible previous versions of it.

I believe in putting papers on the web the minute they're finished.They should be dated and can be referenced as technical reports --it's not necessary to have an actual technical report number. Never,ever put up a paper with a conference copyright notice when it's onlybeen submitted, and never, ever reference a paper as "submitted toconference X." You're only asking for embarrassment when the paperis finally published in conference Y a year or two later.

Abstracts

and how to write them

Doug Arnold

Language and Linguistics,

email: [email protected]

June 21, 2001

Abstract

The ability to write a good abstract is one of the standard skills of an

academic. The abstract is a standard part of an academic paper, and the

acceptance of conference papers is generally done on the basis of

abstracts. This paper provides an overview of the different kinds of abstract

that are required, focusing on abstracts written for submission to

25


26/29

conferences. The organizational structure of a typical conference is

reviewed, in so far as it bears on evaluation of abstracts, and a list of

desirable, and undesirable properties of abstracts is presented. The paper

concludes with an example as a basis for discussion. characteristics

Types of Abstract How a conference works

Things the Referees will like

Things Referees will notlike

Suggestions for writing Linguistics abstracts

LSA Guidelines

Examples (A)

Referees Comments

Footnotes

How a conference works

How a conference works

local organising committe

programme committee

chair

subject area specialist (about 5)

referees (up to 30 or more)

Papers may be anonymized or not. Electronic submission may be required,

permitted, or not permitted. Each paper is sent to one subject area specialist on the

committee, and to at least two referees who comment in detail.

Referees are asked to rate a paper on various dimensions, typically on a scale of 4,

and to provide an overall evaluation. The will also make comments for the author,

and comments for the programme committee only.

1 Definite Accept

2 Tending to Accept

26
http://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_1.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_2.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_3.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_4.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_4.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_4.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_5.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_6.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_13.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_14.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_15.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_1.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_2.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_3.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_4.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_5.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_6.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_13.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_14.htmlhttp://www.essex.ac.uk/linguistics/pgr/prof_dev/abstracts/index_15.html


27/29

3 Tending to Reject

4 Definite Reject

The typical dimensions include: presentation/argumentation (does this paper reflect

an acceptable level of argumentation and presentation); content (is the content of

this paper good enough); relevance to the conference themes. For example, a

conference might invite referees to:

Rate the abstract on the following (4 point) scale, taking into account the

interest of the topic, originality, scholarship, clarity and technical

adequacy...

These comments form the basis for the discussion at the meeting of the programme

committee where the programme is settled. At this meeting, papers may be read by

other committee members.

Types of Abstract

Types of Abstract

A

(Extended) abstract for submission to a conference:

short (1 page) long (>5pages)

B

Part of a full paper (cf. above): short -- mainly an advert for the paper,

but should also be informative of key ideas.

27


28/29

C

For information, e.g. for an journal of abstracts Linguistic Abstracts, or

for one's own future work. Surprisingly, this is not the same as type B.

evaluative

non-evaluative

Here I focus on type A.

Planning and Writing Research Paper

Consider the following questions:

What is the topic? Why is it significant?

What background material is relevant?

What is my thesis or purpose statement?

What organizational plan will best support my purpose?

Writing the Introduction

In the introduction you will need to do the following things:

present relevant background or contextual material define terms or concepts when necessary

explain the focus of the paper and your specific purpose reveal yourplan of organization

Writing the Body

Use your outline and prospectus as flexible guides

Build your essay around points you want to make (i.e., don't let yoursources organize your paper)

Integrate your sources into your discussion

Summarize, analyze, explain, and evaluate published work ratherthan merely reporting it

28


29/29

Move up and down the "ladder of abstraction" from generalization to

varying levels of detail back to generalization

Writing the Conclusion

If the argument or point of your paper is complex, you may need tosummarize the argument for your reader.

If prior to your conclusion you have not yet explained the significanceof your findings or if you are proceeding inductively, use the end ofyour paper to add your points up, to explain their significance.

Move from a detailed to a general level of consideration that returnsthe topic to the context provided by the introduction.

Perhaps suggest what about this topic needs further research.

Revising the Final Draft

Check overall organization: logical flow of introduction, coherenceand depth of discussion in body, effectiveness of conclusion.

Paragraph level concerns: topic sentences, sequence of ideaswithin paragraphs, use of details to support generalizations, summarysentences where necessary, use of transitions within and betweenparagraphs.

Sentence level concerns: sentence structure, word choices,punctuation, spelling.

Documentation: consistent use of one system, citation of all material not

considered common knowledge, appropriate use of endnotes or footnotes,

accuracy of list of works cited.

journal writing methods

Documents