Every PhD conversation reaches the same two words sooner or later.
Research gap.
Find the gap. Then the problem statement. Then the objectives. Then everything else.
It sounds like step one. It is turning out to be most of the work.
Where I Am
I joined the department on 25 August as a part-time research scholar. PG & Research Department of Computer Science, PSG College of Arts & Science.
My area is RFID. Before admission, the direction I wrote down was AI-driven, RFID-enabled inventory optimization using ERPNext for small and medium enterprises.
The direction is clear. The gap is not.
What "Find the Gap" Means on Paper
The method sounds simple:
- Search Google Scholar and Scopus.
- Read the recent papers in your area.
- Select an article close to what you want to do.
- Find what it did not do, or did not do well.
- That is your gap.
The second-day session covered Google Scholar and Scopus. Searching is the easy part. Searching takes minutes.
Reading takes weeks.
Why It Is Tough
A few reasons, as far as I can tell so far.
RFID is not new. People have been writing about it for decades. Libraries, retail, warehouses, supply chains, hospitals. Almost every obvious idea already has a paper. Often several.
Every paper ends with "future work". Some of that future work was done years ago by someone else. Some of it was never going to be done. Telling them apart means reading what came after.
A gap has to be real, not just empty. Nobody having done something is not enough. Sometimes nobody has done it because it does not matter.
Part-time means after work. I have a full-time job at Semicon Media. The reading happens around it.
The Developer Problem
This is the part I did not expect.
At 2CQR I spent two and a half years on RFID in production. RS-232 reader timeouts. Byte-level UID and CSN conversion. Offline transactions that had to sync later. Kiosks that had to keep working when the network did not.
I know where these systems break.
But "I have seen this fail" is not a research gap. It is an anecdote. To turn it into a gap, I have to show from the literature that nobody has addressed it properly. Then show why it matters beyond the one site where I saw it.
As a developer, if something breaks, I fix it.
As a researcher, I first have to prove it is broken, and that nobody fixed it already.
Different muscle. Still building it.
The Article I Have Not Selected
The usual advice is to select one article and build from it.
I have not selected one yet.
Not for lack of candidates. There are too many that are almost right. Close to my topic, but old. Recent, but in a different domain. ERPNext, but no RFID. RFID, but no ERP at all.
Every one of them is a maybe.
I would rather take longer and select the right one than select fast and spend a year building on the wrong one.
Where Things Stand
- Area: RFID-enabled systems, with inventory and ERPNext as the direction.
- Research gap: still looking.
- Article: not selected yet.
- Reading: around the day job.
I will write again when I have found it.