How to write an abstract - School of Mechanical & … to...How to write an abstract What is an...
Transcript of How to write an abstract - School of Mechanical & … to...How to write an abstract What is an...
How to write an abstract
What is an abstract?
It is common in engineering literature for a paper to begin with an abstract.
A summary or abridgement of the document - tells readers what they will find in the paper.
What an abstract isn’t The following definitions all come from the Oxford English dictionary under the entry for ‘abstract’
Insufficiently factual or practical; dealing with ideas and generalities rather than events or specific outcomes. Difficult to understand; abstruse. Separate, distinct; set apart from; withdrawn, secluded
An abstract for a paper or a thesis is none of these things!
Elements of a Good Abstract
A good abstract does three things States the research/engineering problem Announces key themes States the main finding or presents a launching point that anticipates the main findings
Abstract Patterns
Well written abstracts fit one of three patterns
Context + Problem + Main Point Context + Problem + Launching Point Context + Problem + Launching Point + Summary
Context + Problem + Main Point
Effectively an abbreviated introduction One or two sentences to establish the context, e.g. previous research Continues with one or two sentences to state the problem or hypothesis being addressed Concludes with the main finding of the work
CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. In this study no significant differences were found in the quality of software produced by a cohort of PhD students working with a text based editor or with an integrated development environment
Context + Problem + Main Point
CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. In this study no significant differences were found in the quality of software produced by a cohort of PhD students working with a text based editor or with an integrated development environment.
Context + Problem + Main Point
Context + Problem + Launching point
One or two sentences to establish the context, e.g. previous research. Continues with one or two sentences to state the problem or hypothesis being addressed. A sentence or two on the general nature of the results.
CFD Software development folklaw has held that text based editors (e.g. vi) and a command line tool chain promote more serious work than do integrated development environments (e.g. Eclipse), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it purported to confirm. This study evaluates the quality of software produced by thirty-eight PhD students using either command line tools or an integrated development environment.
Context + Problem + Launching Point
Summary
States the context of the problem, but before reporting results it summarized the paper focusing on the evidence supporting the results and/or the methods used to achieve it.
Context + problem + summary + main point
CFD Software development folklaw has held that text based editors and a command line tool chain promote more serious work than do integrated development environments (IDE), a belief that seems to be confirmed by Jacobs (2009). But Jacob’s study was based on the same folklaw that it puported to confirm. In this study, thirty-eight PhD students in Mechanical Engineering whose work involved software development were randomly assigned to use one of two development environments, one with a Unix command line tool chain supported by the vi editor and the other with the Eclipse IDE. Software produced was evaluated on three criteria: content, format, and testability. The two groups did not differ in any of the three criteria.
Context + problem + summary + main point
You want people to read your paper!
Nowadays, most people identify papers of interest to them using search engines that look for key words in titles and abstracts
Help them find your paper, by imagining yourself searching for it.
Ask yourself, what words would I use if I was looking for this paper.
Put in your title and the abstract.
How do I start?
Here’s a three step formula I’ve found helpful 1. Topic: I am studying _____ 2. Question: because I want to find out
what/why/how _____ 3. Significance: in order to help my
reader better understand _____
Understand your aims
If you are still struggling to write, its probably because you are confused about what you are writing about.
Seek clarity by articulating your aims.
The aims of this work are 1. …
2. …
3. ...
Critique the following
Critique the following
Critique the following
Some final thoughts …
An abstract must be a fully contained description of the paper
It must make sense all by itself
Keep in mind Word count limitations Danger of using ‘weasel words’, e.g. might , could, may, and seem Make sure the keywords you pick make assigning your paper to a review category and finding the paper once its printed obvious