Review History

To increase transparency, PeerJ operates a system of 'optional signed reviews and history'. This takes two forms: (1) peer reviewers are encouraged, but not required, to provide their names (if they do so, then their profile page records the articles they have reviewed), and (2) authors are given the option of reproducing their entire peer review history alongside their published article (in which case the complete peer review process is provided, including revisions, rebuttal letters and editor decision letters).

New to public reviews? Learn more about optional signed reviews and how to write a better rebuttal letter.


  • The initial submission of this article was received on May 31st, 2013 and was peer-reviewed by 3 reviewers and the Academic Editor.
  • The Academic Editor made their initial decision on June 13th, 2013.
  • The first revision was submitted on July 18th, 2013 and was reviewed by the Academic Editor.
  • The article was Accepted by the Academic Editor on July 18th, 2013.

Version 0.2 (accepted)

· Jul 18, 2013 · Academic Editor


I have no further comments. You addressed all reviewer concerns with your revision.

Version 0.1 (original submission)

· Jun 13, 2013 · Academic Editor

Minor Revisions

You should foremost ensure that the tool works on all platforms, and that the usability and interface suggestions of the reviewers are carefully considered. Of these, batch upload of results at the very least is a must to make this tool useful for high-throughput omics studies. Reviewer 1 furthermore correctly points out that you will need to revise the formatting of your manuscript to comply with the PeerJ guidelines.

Reviewer 1 ·

Basic reporting

The authors described a new tool to visualize biological activities of kinase inhibitors onto a phylogenetic tree image. The manuscript is well written and scientific discussions are correctly argued. However the reference format does not follow the PeerJ policies, such as in-text citations and the reference section. Same comments for the figures presented in the manuscript and authors should carefully look at picture size and format here:
This should be fixed before publication.

Experimental design

The work described in this manuscript will be valuable for the researchers working in kinase drug discovery, especially in data analysis from screening assays of kinase inhibitors. The investigation has been conducted rigorously and the methods is well explained. The standalone software provided by the authors works perfectly well.

Validity of the findings

No comments

Comments for the author

I would advise the authors to differentiate between not inhibited and not tested kinases. They could use a grey sphere when kinases have not been screened (from the panel of 518 kinases) since it can be misleading with tiny circles, almost invisible, on the phylogenetic tree due to inactivity of a compound tested on those kinases

Reviewer 2 ·

Basic reporting

The article explains how to use Kinome Render, a newly developed application to facilitate the creation of annotated kinome trees. It is clearly written and details step by step the utilization of the tool. This type of tool is very useful for the easy visualization of kinase inhibitors profiles for instance, as explained by the authors.

The article however fails to provide references to the previous efforts in the design of such tools. The authors state that "some figures in these publications were created by hand in a laborious effort", which is true, but implies that some were not. And indeed, some tools are available. I believe it is of the duty of the authors to reference them. Commercial softwares such as TREEspot by Discoverex have to be named. The Human Kinome Java Component ( has to be taken into consideration and compared to. By minor modifications of the code (available on simple demand) this application can be used for similar purposes as Kinome Render (for instance

Experimental design

Whereas the existing tools only provide (to my knowledge) the possibility to annotate with one type of shapes, the diversity of annotations with Kinome Render has to be praised.

I have concerns concerning the practicality of the tool for large sets of data, which is the stated goal of the authors. The ticking of all the kinases on the web-interface or the copy pasting of the KR language lines for all the kinases is indeed tedious and should be made easier. A tab or comma delimited file as an input (solution chosen by the Human kinome java component for instance) would be immensely more practical as it could be easily generated from an excel file (or similar), which is the common output of many proteomics softwares. The advantages of filtering and sorting of excel could be used to annotate groups of kinases. As would be the vlookup function to convert IPI names of the kinases to the KR syntax accepted names.

If it is possible to modify the KR file to annotate the same kinase with more than one annotation (impossible with the web interface), these annotations are not displayed correctly. I see this as a drawback of the tool. I believe that 2 shapes should be superimposable so as to be able to compare 2 kinase inhibitors for instance. This would require some transparency for the shapes, an automatic ordering leading to "small on top", and an unlimited number of annotations (and not "a maximum of 523 annotations"), all properties implemented in the human kinome java component.

Another concern is the information that "annotations with the biggest scales should be written first so as not to hide smaller annotations in their vicinity". It is quite unrealistic to ask the user to sort his data in this way without him being able to use excel and its sorting possibilities for the generation of the input file.

It is surprising that the legend in the web-interface has to be written in the KR language whereas the authors state that "the web interface allows the creation of an annotated tree without any knowledge of the KR syntax". This should be amended to fulfill the goal of the authors.

Validity of the findings

It is of concern that the supplementary files provided cannot be directly loaded on the web-based tool, after opening them with wordpad. What should be the way to modify them?

Reviewer 3 ·

Basic reporting

No Comments

Experimental design

No Comments

Validity of the findings

The tool does not work with Kinome Render files created in Windows machines. The problem is that only Mac/Linux style line feeds are supported. Using files created on Windows results in numerous syntax errors. This has to be corrected before the manuscript can considered for publication.

The example files provided with the tool also do not work as these are not pure text files, and has the wrong line feeds.

With the correct line feeds the tool seems to work as wanted though.

Comments for the author

The manuscript is well-written and contains the information required to use the tool. However the file format issues above have to be fixed to make the tool usable for Windows users.

The tool itself does not seem too complex, but should be very useful for researchers working with kinases, and makes it very easy to create production grade graphics for inclusion in scientific publications.

All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.