Actually, this winter I had not one, but two papers rejected. And although I never dispute the rejections (it just means I failed to present my work adequately), I wanted to reflect on why both papers were rejected, and what I can do to make them accepted to other conferences.
With our bitemporal paper I was really upset that it didn’t make it to ICDE 2018, because I know that the work itself was magnitudes better than the work, which was accepted for ICDE 2016. Which leaves me with two options: either the topic was not relevant for the Industrial track, or we didn’t present our work well enough, so that it’s novelty would be visible.
I think its’ more that we didn’t explain ourselves well enough. I was trying not to dedicate 1/3 of the paper to explaining the theory which lays underneath our implementation, and now I think it was a mistake. I didn’t elaborate on the fact, that our second dimension is asserted time, not system time, and what is a semantical difference. So when our our reviewers are saying – “everybody have bitemporal time” – yes, that’s correct, but our two-dimensional time is different!
I know that the “asserted time” concept is not that easy to grasp when you read about it for the first time, and we didn’t provide any formal definitions. Nor did we provide any formal definitions for the bitemporal operations. It does not matter, that we’ve followed the asserted versioning framework bible… We should have give the formal definitions, and we should have highlighted, that it’s not “bitemporal implementation for Postgres”, but that “we use Postgres to implement the asserted versioning framework, because Postgres has some cool features, which makes it easier”.
Oh, well. There is always a next conference :). Also, I think we should separate this paper into smaller pieces – this one was an attempt to summarize three years of development.
Something to work on! And also – to continue development of the bitemporal library itself.