Previous vs. concurrent/independent work

Should Paper X cite Paper Y as previous or concurrent/independent work? This is sometimes tricky: maybe Paper Y circulated privately before Paper X, maybe the authors of Paper X knew about Paper Y maybe not — nobody can know for sure. One can say that the authors of Paper Y should have posted Paper Y online earlier to prevent this issue, but that is not standard practice and might lead to other problems, including Paper Y never getting published!

I propose the following guiding principle:

“If a different accept/reject outcome would have forced paper X to cite paper Y as previous work, then paper X should cite paper Y as previous work.”

The reasons behind my principle seem to me especially valid in the fast-moving theoretical computer science community, where papers are typically sent to conferences and thus seen by the entire program committee plus around 3 external referees, who are typically experts — only to be rejected. Moreover, the progress is extremely fast, with the next conference cycle making obsolete a number of papers in just the previous cycle.

3 thoughts on “Previous vs. concurrent/independent work

  1. I think that the “concurrent/independent work” rather than “prior work” is actually the more common situation in TCS precisely because things are so fast moving. A reference of concurrent/independent work generally does not prevent, and even supports, separate journal publication of the referenced paper.

    Conference publication seems to be the main issue you are concerned about. Because TCS is fast moving so we often have the situation that both X and Y are submitted to the same conference. Committees have to be very careful about this, whether or not there is a direct link.
    – If both papers have similar main new consequences, the decision on both should be the same unless X cites Y as prior work. In the prior work case, one has to ask about the incremental value of X over Y.
    – If the papers are concurrent/independent and one is significantly stronger than the other, if the results of the weaker one would have been accepted if the stronger one didn’t exist, then both should be accepted.
    – However, if there is also some prior Z that has the key main ideas of Y and X, and X is sufficiently stronger than Y, even if X cites Y as prior work, then Y does not necessarily need to be accepted, particularly if an immediate jump from Z to X seems natural. This is the kind of tricky situation that committees often have to deal with.

    I am glad that TCS takes a generous view of concurrent/independent work I gather that in physics the first arXiv timestamp with an idea gets by far the lion’s share of the glory even when it is a matter of a day. (This is hearsay – I recall reading about an example of this in one of Brian Greene’s books.) That would be a much worse direction to go.

  2. Paul,

    thank you very much for your comment. I think many of the points in your comment are very interesting.

    I think one issue is that implementing or enforcing some of what you say is left to people like me — clueless reviewers. Outcomes are in many cases random at best, and more to the point, I am not aware that guidelines such as the ones you mentioned are common knowledge. I am referring both to the journal vs. conference aspect, and the simultaneous submission. A paper is killed with a shrug, and I suspect in many cases this happens in violation of reasonable interpretations of your points. Sure, the program chairs do their utmost to moderate this well, but again, I am not aware that this is done in any consistent way, also because people have different views of these issues and many other factors are at play which are terribly hard to quantify.

    What I was trying to do with this post is coming up with a principle (addressing one aspect of this big issue) that can be implemented by the authors.

    I am very much open to the idea that the TCS community is better than physics, say, even in this respect ;-) However, it might happen that a say STOC/FOCS conference publication gets an exaggerated share of the glory. And the potentially serious issue here is that the accept/reject decisions are made by humans. One benefit of arxiv is that it’s purely mechanical. You know what to follow, and it’s not filtered. If a paper appears there that’s relevant to your work you should pay attention to it, otherwise you more or less know there is nothing. Instead, as we speak dozens of TCS papers are being reviewed behind closed doors, their existence unbeknown to the community except for the experts who are reviewing them.

  3. Dear Paul, regarding “If both papers have similar main new consequences, the decision on both should be the same unless X cites Y as prior work.” I do not think that “cites X the paper Y or not” should be relevant at all. Say, then X, knowing Y, could just not cite Y just purposely, which, in my eyes, is just a “scientific crime”. But if Y (cites) and improves/simplifies X, then this is a normal way for research.

    I feel that the claim “TCS is so fast moving” is just the disadvantage of the entire organization of the “TCS business”. Doing science was, and remains (at least in Math) “silent” for centuries. This is different from sport: “who was first”. So, by seeing papers X,Y and Z on arxiv, I would be only happy to see the solution from different aspects. I really need to know no “champions” for that. I only need to know the results (with possibly simple proof given, perhaps, in Y,Z or elsewhere).

    Of course, I understand that the “TCS conference system” is running, and it is difficult to change it. Just because the carriers of many young scientists hang on this system. But it would be at least good that those running this system would understand its weakness.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s