Monday, November 25, 2019

Writing a Conference Abstract in Syntax – Some Practical Advice

It is that time of year again, and I have been doing some abstract reviews. I have quickly written up the following advice to help abstract writers.

The purpose of an abstract is to convince a reviewer to accept your talk/poster to a conference. The only way that is going to work is if the reviewer understands what you have written. Therefore, clarity is the key. Your abstract should be crystal clear.

As a corollary, do not attempt to jam all your thoughts into the abstract. While you might find it more satisfying to present the entire system in all the wondrous detail that you have developed over the last year, the reader will no doubt find it impossible to read. Narrow down on your most important proposal, or in the extreme case, your two most important proposals. Summarize your proposal, outline how it works and outline any supporting evidence you have for it.

More generally, do not assume the reviewer is a mind reader. Do not assume that they make the same assumptions you do about particular sentences. Do not assume that they make the same framework assumptions that you do.

A conference abstract is a completely different animal than a paper abstract. The goal of a paper abstract is to let the reader decide if they want to read the paper or not. A paper abstract is typically a paragraph or two long. A conference abstract is longer, and must give some support for the proposals made, since the conference abstract must convince the reviewer to accept the talk/poster.

If you make a proposal to explain a certain set of data (e.g., the object of the verb receives inherent Case), think about converging support for your proposal outside of the narrow data domain you are looking at. If the only support for your proposal is the data that you are trying to explain, then your explanation is in fact circular. Data X is explained by proposal Y. And I should believe that proposal Y is the right way to go, because proposal Y is justified by explaining data X. Your proposal will be much stronger if you have converging support for proposal Y (e.g., additional tests, cross-linguistic data, theory internal considerations, past proposals by other people). You do not have to go over the converging support in the abstract in detail, but you should at least outline what you have in mind.

While the space demands of an abstract make it tempting to drop all or most of the references, the result will be a disaster. If you do not give references, it looks like you do not know what you are talking about, and your abstract will be rejected. Also, if you leave out a well-known reference that argues against the points you are making, the reviewer will probably pick up on this, and reject your abstract.

You are writing a syntax paper, let’s see some syntactic data. As syntacticians, we love to get our hands dirty with syntactic data. We love to see a “cool fact”! If your entire abstract is filled with discussion and no data, no reviewer is going to be comfortable with this.

If you present an example, briefly walk through it. Don’t assume that when you give an example, the reader can make the connection between that example and the points you are trying to make. Do not try to save space by making the discussion as compact as possible.

Ask your professors and colleagues to give you feedback on the abstract. This will definitely be helpful! They will tell you how somebody looking from the outside in understands what you have written. Do not wait until the last minute to write the abstract, since that will make it impossible to get feedback.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.