What a base paper is, and how to choose one

What does “base paper” mean in an Indian PhD?

This idea comes from the engineering project culture. In final year of BE and ME, students are many times given a “base paper” to implement. The same habit continues into the PhD. You or your supervisor pick a recent paper that solves a problem close to your thesis topic. You implement it, confirm the results and then improve on it. Maybe a better algorithm, maybe one new constraint handled, maybe a wider test.

Base paper is a working term that guides and committees use. You will not find it as a requirement in the UGC PhD regulations. Used properly, it gives a first-year scholar something concrete while the literature review is still forming. You also get a working baseline for all the experiments that come later.

The problem comes when the whole thesis shrinks down to one paper. Examiners do notice if every chapter is “the method of [12], modified”. Your base paper is only where you start. Many scholars finally have one base paper for each objective, and their literature review shows where each of those papers stands in the wider field.

How do you choose a good base paper?

Pick three to five candidates from your reading and judge all on the same points.

Recent. Usually this means within the last five years. An older paper is also fine when it is a benchmark that recent work still compares against. In that case your comparison has to include the newer methods also.

From a genuine indexed journal. Check the journal yourself in Scopus Sources or Clarivate’s Master Journal List. Our journal checker takes you to the official records. Suppose the journal is predatory or a discontinued one, then the whole thesis has a weak base, and in the viva they will ask why you trusted it. The warning signs are listed in our predatory journal guide.

Reproducible. Read the method section like you have to code it tomorrow morning. Are all the equations there? Does the paper give parameter values, data splits and evaluation measures? Many times short conference papers won’t give these details.

Data and code available. If there is a public dataset, a repository link or a supplementary file, you save months of work. Some journals and conferences give badges for this. The ACM, for one, has an “Artifacts Available” badge. Authors get it when the materials go into a permanent public archive.

Feasible for you. If the method needs eight GPUs, a licensed simulator your department doesn’t have, or a field site in another country, it is the wrong base paper for you, however good it is.

Read every candidate with a critical eye, the way our guide to critiquing a research article explains. The weaknesses you find are where your contribution comes from.

Why reproduce the base paper first, and what if the results don’t match?

First reproduce, and extend only after that. There are three reasons for this. It teaches you the method like reading never can. You also get baseline numbers on your own data split, hardware and software, and that is the only fair comparison for your improved method. And if something in the paper is wrong, you come to know early.

The ACM’s artifact review policy makes a distinction that is useful here. Reproducibility means an independent group gets the same result by using the original authors’ own artifacts (their code and data). Replicability is for the case where somebody gets that result using artifacts they developed independently. When the authors have shared their code, you are reproducing. When you write the code yourself from the paper, you are replicating. Of the two, replicating is harder. Small differences in numbers come up more there.

Before you start, decide one target with your guide, like “Table 4, accuracy on dataset X”, and how far off from it is still okay. Note down library versions, random seeds and hardware also. Put a time limit on this work, say six to eight weeks, and agree on it with your supervisor.

When the results don’t reproduce

1. Check your own implementation first, line by line against the paper. Look at preprocessing, data split, parameter values and the evaluation formula.
2. Run several seeds. One single run can be further away from a reported average than you would expect.
3. Look for supplementary material, errata and the authors’ code.
4. Write to the corresponding author and ask specific, polite questions (“Was the data normalised before or after the split?”). Many authors do reply.
5. Gap is still there? Then you report it honestly. Take your reproduced numbers as the baseline. Mention how far they are from the published figures, and explain what all you tried. Never put the paper’s published numbers in your results table as though you got them yourself.

Scholars get scared when the numbers don’t come, but a failed reproduction, written down with all your attempts, is still a finding. If the gap is big, discuss about it with your supervisor and decide together if a different base paper suits the thesis better.

How do you show a contribution beyond the base paper?

With base-paper theses, the complaint examiners make most is that the contribution is only a tweak. Usually the size of the change is not the issue. What makes the difference is the reason behind the change.

Begin from a gap and not from a modification. Say what the base paper cannot do, why that is a problem, and what your work does about it. Here is an illustrative example, invented for this guide. “The intrusion detection method of [7] assumes that the traffic classes in training data are balanced. Real IoT traffic is heavily imbalanced, and in our reproduction the method’s recall on the rarest attack class fell to 41%. This thesis develops a cost-sensitive variant and tests it on three imbalanced datasets.” There the limitation comes first, then proof from your own reproduction, then the plan. For a pattern to write this, see our research gap statement guide.

For a fair evaluation, compare with the base paper and other recent methods on more than one dataset, and report average and spread over several runs. Also include an ablation study, so it is clear which part of your change gave the gain.

How do you cite the base paper and avoid similarity problems?

Whatever you take from the base paper needs a citation. That is true for the problem formulation, equations and algorithm steps, and for datasets, figures and results too. In your results tables, give the columns clear labels, for example “reported in [7]” and “reproduced (this work)”.

The method chapter is where the similarity risk is highest. After months inside one paper, you start describing its method in its own words. Then the similarity check catches those sentences, even though the citation is given. So write the description fresh, from your own understanding, and keep standard equations as equations. Quote directly only when a sentence really cannot be said better. Our paraphrasing and quoting guide shows how to do it. UGC 2018 similarity levels, and the way universities apply them, are there in the plagiarism limits guide.

Take care with figures also. Redraw a diagram in your own style and put the caption “adapted from [7]”. If you reproduce a published figure without change, you may need permission from the publisher, so check that journal’s permissions page. If you use the authors’ code, follow its licence and cite the repository with the paper.

What do examiners ask about the base paper at the viva?

Some form of each question below is likely to come in your viva-voce. Have a short honest answer ready for every one of them.

• Why this paper, and why not some other paper?
• Did you reproduce its results? How close did you come, and how will you explain the difference?
• In one sentence, what does your work do that the base paper does not?
• Why didn’t you compare with [a newer method]?
• Is your improvement bigger than the variation between runs? Did you test it?
• Does your method still carry any of the base paper’s assumptions? In which situation would it fail?
• If the base paper’s authors read your criticism of their work, what would they say?

The third question counts most. If you can’t answer it in one sentence without bringing in some parameter, work on the contribution first and the slides later. For the rest of the viva, see our PhD viva questions guide.

Checklist: how do you evaluate a candidate base paper?

Before you take any candidate to your supervisor, score it on this list. A paper failing on the first three points has to go, however nice the other points look.

• It came out within roughly the last five years, or it is a classic that recent papers still compare against.
• You checked the journal or proceedings yourself in Scopus Sources or Clarivate’s Master Journal List. You did not just believe the journal’s own website.
• The publisher’s page shows no correction, no expression of concern and no retraction notice.
• Nothing is missing in the method. Equations and algorithm steps are there, with parameter values, data preprocessing and evaluation measures.
• The data is public or you can get it. The code is available, or the method is clear enough for you to write the code yourself.
• Your department actually has the hardware, software licences and lab equipment you need to run it.
• It mentions limitations, or you can see some it does not mention, and they connect to a problem you care about.
• Your supervisor agrees it is a sound starting point, and other scholars in your department have not already worked it to death.
• You are able to explain each step of its method in your own words.