It’s been just over a year since I started studying for my Ph.D. — formally, I entered the program in April 2009. With at least two years to go, how do things look with some hindsight? What do I think it means to obtain the Ph.D. degree, or, more specifically and usefully, to be a researcher in computer science?

Much of what I’m noticing are things that sound obvious and natural, like everyday truisms, when expressed with words, but the idea I have of it goes a little bit deeper than that. For instance, we all get told over and over throughout our lives, starting in high school, that we have to become good communicators. So it’s not going to be a surprise to anyone when I say that I think the process entails becoming a much better communicator than I’ve ever been before. Maybe what’s different is that I am trying to communicate things that haven’t been communicated before, things that I invented — or things that have hitherto been communicated only by a very small number of people. (Most of the communication I did prior to becoming a Ph.D. student may not have been terribly original.) Basically, reading and understanding a large amount of scientific papers, and understanding them with a particular use in mind, either having or getting a sense of how they fit into your own work. Then, writing your own papers, and communicating, somehow, what you thought, and what you were the first person to think, so that somebody else might read it like you read the works of others, and use it similarly. Then, presenting research, discussing it, and understanding what is being presented and discussed by others — similar challenges in speech instead of in writing.

I can’t speak for other fields, but in computer science ( I work with programming languages and software engineering), I find that a lot of this, for me, has been about building up a certain mental dexterity with formalisms. Understanding the implications of formalisms as you read about them and seek to apply them. Communicating formalisms to others. Some of this is still difficult, in particular the “communicating to others” part, but I think I am achieving things in this regard.

Communication, then, where does it take us? One of my mental images of academic knowledge is a big directed acyclic graph (a tree) where papers reference other papers. A surprisingly big part of writing a paper is ensuring that your work can get assimilated into this graph easily — placing it well, referencing the right things, making sure that you can be referenced easily. Also: defining the boundaries of your work extremely well — here’s where it begins, here’s where it ends. We assume precisely this and arrive at precisely that. It really seems that these things can never be made clear enough.

Which leads to another mental image of research: the paper/unit of work as a building block. The more solid it is, and the harder and sharper its surfaces and edges are, the better structures can be built from it (though I think there are other kinds of valuable works too). That’s one direction I think I need to be aiming for as an aspiring researcher.

There is now an opportunity to do a paid internship for 2-6 months at Japan’s National Institute of Informatics in this project. If you are a masters or Ph.D. student who is interested in programming languages and software engineering, and you think the project sounds interesting, please do consider applying. Unfortunately the internship is only open to students of institutions who have signed MOU agreements with NII. The list of such universities, which includes many institutions from around the world, as well as more formal information, is available here. If you know or want to learn Scala, all the better!

One way of making a name is stringing words together until the meaning is sufficiently specific. E.g. “morphism averse co-dependent functor substitutions in virtual machine transmigration systems”. Thus the abstruse academic research paper title is born.

Sciences sometimes give new meanings to existing words. This could be called overloading, following the example of object-oriented programming. E.g. a “group” in mathematics is something different from the everyday use of the term. A “buffer” in chemistry is something different from a software or hardware buffer, even though a fragment of similarity is there. And so on. This overloading of words gives newcomers to the field a handle on what is meant, but full understanding is still impossible without understanding the actual definitions being employed.

Sometimes new terms can be created using inventors’ names and everyday words. E.g. a “Lie group” or the “Maxwell equations”, or “Curry-Howard correspondence”. This is potentially useful, but perhaps not something you can do freely with your own research without seeming like you’re trying to inflate your ego excessively. (Even though researchers love inflating their egos, nobody wants to admit it.)

There’s a similar problem in software development. When we invent names of functions, classes and variables, the lack of words becomes very clear. Intuitively, what is an “adapter registry”? An “observer list”? Or an “observer list mediation adapter?” My feeling is that we often end up compounding abstract words because we have no better choice. And here lies a clue to some of the apparent impermeability of difficult source code. We need better ways of making names. We’re inventing ideas faster than our language can stretch.

In order to evaluate Mendeley, let’s ask ourselves what we want from a bibliography management system in the modern research environment. At a bare minimum, we want an easy way to catalogue and search PDF documents, and of course compile the all-important reference list at the end of the laborious writing process. Mendeley does this, as well as bring a social networking aspect into the picture. It tries to recommend papers that are relevant to your work, as well as give you an easy way of sharing interesting papers with colleagues.

In contrast to Aigaion, which I wrote about previously, Mendeley is not a web based system but a desktop application. This definitely has benefits as the interface is quite slick. I can set the application to watch my “papers folder”, and any PDFs I save to that folder, or its subfolders, will automatically be scanned and entered into Mendeley. Metadata, such as author, title and references, is automatically extracted from the document in most cases, though I found I had to manually revise it sometimes. There’s a built in command that searches for the metadata by paper title on Google Scholar, which comes in very handy in such cases.

Mendeley is built around an internal PDF viewer where the user can highlight text, add little stickies with notes, and so on. This works quite smoothly, but on the Mac platform, it’s definitely not as polished as the Mac’s built in Preview PDF viewer. Mendeley is using its own PDF rendering layer, and it shows in the slower loading times when you scroll the documents. Some additional work could be done here. This is my only major complaint so far, though.

Much like the Evernote application, Mendeley has the option of storing all the papers on a central server, so that I can easily access them (and any annotations I might have made) from a different computer by signing in with my user name and password and then syncing the files. This means I don’t have to give up the benefits I get from a centralized server. It might be nice, however, to have the option of running my own Mendeley server, so I’m not dependent on the Mendeley company’s server somewhere – but then I would forgo the social networking benefits of course.

This application has similarities to how last.fm is used for music, in that people build a profile based on what they consume. Indeed, Mendeley is describing itself as a last.fm for research (video presentation). Let’s compare research and music as forms of media.

• Most music listeners probably don’t make their own music – most people who read research papers probably write their own papers.
• Songs sample other songs (the remix culture), but it’s relatively recent – researchers have always done this in order to establish basic credibility.
• The atomic unit of music is the song. The atomic unit of research is the research paper (the PDF in today’s internet based world, at least in my discipline) – but could this change in the future? Do we have to constrain ourselves to the article format?

In summary, Mendeley is probably the most useful, workflow friendly bibliography system I’ve tried so far. If you’re in research, I’d recommend you give it a try. If I get time, I plan to also investigate a more Mac-centric tool called Sente in the future.

The Savage Minds blog recommends that you don’t use Mendeley as your main tool yet due to its relative immaturity, but I have seen no showstopper bugs so far.

I started using Aigaion for mine. Then I found out that there’s an open system called bibsonomy, which is potentially much better since it lets you tag and share bibliographies socially, and it seems to already know about all the major computer science papers.

Again (see: The problem with standards), I’m frustrated by the fact that I can’t move my data around between applications as I like without lots of manual effort. A worthy research problem would be making data truly application independent once and for all.

One of the most important problems in software engineering is reducing the impact of change. To this end, recently methods such as inversion of control (dependency injection) have become popular, in order to reduce the coupling to concrete interfaces. However, even with these schemes, there is still a dependency on specific names and abstract interfaces.  My project aims to investigate the possible use of semantic methods to address this problem. In essence, I want to allow developers to use semantic interfaces rather than syntactic ones to describe and access their components. 

Specifically, I am investigating techniques commonly used in the context of Semantic Web Services, such as ontologies and semantic/syntactic mediation, and their applicability to this problem. 

We may regard services as being somewhat large scale components. However, I am interested in applying these methods not just for large scale services distributed across the web, but also for small and numerous software components running in a single process. In such a setting, performance and scalability are important issues to investigate, in addition to the usual problems of reliability, correctness of composition, etc.