Similarity-Driven Edge Bundling: Data-Oriented Clutter Reduction in Graphs Layouts
Round 1
Reviewer 1 Report
The article ‘Similarity-Driven Edge Bundling: Data-Oriented Clutter Reduction in Graphs Layouts’ proposes a graph visualization technique based on edge bundling approach. They also propose a multilevel exploration based on the similarity hierarchy.
The article is well written with a clear introduction and a concise related works section that also compares their proposed approach with the existing works. The authors present 2 algorithms that describe their approach and present evaluation tests. Their proposed approach has two-steps: construction of a tree-like structure also called a backbone and the mapping of the backbone vertices are mapped to 2D space. Globally, the article is easy to follow and the different concepts are clearly presented, there is still some room for improvement.
Take for example, though the two algorithms presented in the article are well commented, it still misses a brief explanation in the article. Similarity Tree algorithm (Algorithm 1) is not described in detail, especially the purpose of each of the functions. It is not clear how MEANS is calculated.
The authors also proposed a Graph drawing, where instead of mapping the graph, they map the backbone considering radial layout and H-Tree algorithms. Again, Algorithm 2 misses a brief textual explanation.
Lines 141-145 present 3 design principles for the backbone construction, however because of a missing previous discussion on the type of data that they are taking into consideration, it is not very clear which types of datasets can fulfil these principles. In section 5, we see a couple of use cases, but it doesn’t describe the characteristics of the datasets used. I think that the authors need to precise the use of their algorithms and the limitations.
There is a significant difference between Figures 9-11 and Figures 14-15. Even though the visualization results obtained in figures 9-11 have been previously studied in the literature and may not need user evaluation, I have doubts about the figures 14-15. The authors need to precise whether they performed user evaluation and if yes, who are these users: experts or beginners.
The authors talk about the fastness of their approach, but the article needs to present some results related to these claims.
Minor errors:
Line 49: An strategy to explore bundling layouts -> A strategy to explore bundling layouts
Line 127: impose by -> imposed by
Author Response
Revision Report
October 30rd, 2020
Dear Guest Editors and reviewers,
Firstly, we would like to thank all reviewers for their work and comments in the previous review round. These comments were beneficial in pointing out areas for improvement. We have modified our manuscript accordingly, and we believe the new revision exhibits the desired improvements in quality and clarity suggested by the reviews. In the revised manuscript, the major changes in the text are marked in blue. Below, we list the received comments and our answers, focusing on the major comments (all minor corrections have also been considered).
sincerely,
The authors
Reviewer 1
1- "…though the two algorithms presented in the article are well commented, it still misses a brief explanation in the article. Similarity Tree algorithm (Algorithm 1) is not described in detail, especially the purpose of each of the functions. It is not clear how MEANS is calculated… The authors also proposed a Graph drawing, where instead of mapping the graph, they map the backbone considering radial layout and H-Tree algorithms. Again, Algorithm 2 misses a brief textual explanation."
We added brief descriptions for both algorithms to improve clarity. For the Similarity Tree Algorithm, we also solved the problem with function MEAN. The problem, as pointed by the reviewer, is that we fail to describe it. What we have described is the centroid function, and both do the same thing. In the new version of the manuscript, we unify the names to avoid misleading the reader, using CENTROID as function name. Thank you for the comment; we think that now the algorithm is clearer.
2- "Lines 141-145 present 3 design principles for the backbone construction, however because of a missing previous discussion on the type of data that they are taking into consideration, it is not very clear which types of datasets can fulfil these principles. In section 5, we see a couple of use cases, but it doesn't describe the characteristics of the datasets used. I think that the authors need to precise the use of their algorithms and the limitations."
The discussion of the type of dataset that can be used is formalized at the beginning of Section 3. It is a graph G= (V,E). The nodes v_i \in V represent data objects d_i \in R and edges e_i \in E represents relationships between data objects d_i, d_j \in D. We slightly rephrased the original text to make it more explicit. We also added in the Discussions and Limitations section some discussion about it, focusing on when our technique cannot be used.
3- "There is a significant difference between Figures 9-11 and Figures 14-15. Even though the visualization results obtained in figures 9-11 have been previously studied in the literature and may not need user evaluation, I have doubts about the figures 14-15. The authors need to precise whether they performed user evaluation and if yes, who are these users: experts or beginners."
That is a good question. We have performed informal tests with lab members during this paper's design phase using a think-a-loud process, where they explain what they are seeing. The results were encouraging up to a certain extent. However, this cannot be used to support the claim of generality since no formal protocol was used, and this test does not present statistical relevance (only a few members participate). One interesting thing one of the participants has observed is that the layout's symmetry is not attractive, although this does not influence the overview interpretation of a graph layout. To fix this problem, she suggests running a force-directed algorithm using the swap H-Tree as the initial layout, reducing the fractal appearance. As a side note, we have discussed executing user tests, but our university is closed since the beginning of the COVID-19 pandemics making such tests impractical to be applied. We added this discussion to the Discussion and Limitations section.
4- "The authors talk about the fastness of their approach, but the article needs to present some results related to these claims."
Thank you for the comments, but we could not find the text where we claim that. In fact, in the conclusions, we mention the opposite "Finally, although SDEB is considerably slower than the state-of-the-art…". The only claim is about computational complexity, stating that the Similarity Tree algorithm is less computationally expensive than the Neighbor-Joining (NJ). NJ is O(N^3), and our approach is O(N log N). Although we discuss that in the result section (in the new version, we moved it to the Discussion and Limitations section), we also put the complexity information when discussing the backbone (last paragraph of section Section 3.1.1). We did not put a running time experiment in the paper comparing these techniques since the graphs we used in the analysis are small (Figure 3). They did not capture the differences in computational complexity, misleading the asymptotic analysis.
5- Minor errors
All the minor errors were fixed.
Reviewer 2 Report
Although the work presented is well designed, explained and written, it has two major drawbacks that prevent its correct assessment:
1) The bibliographic analysis performed is not adequate. There are a significant number of papers published on the same or similar topics that have been published after 2016 (most recent reference provided in the article). This must be resolved so that a correct review can be made, this work cannot be done by the reviewer who has no obligation to provide ALL the recent literature.
2) No conclusions can be drawn that have not been demonstrated or even considered. Considering last conclusion “Finally, although is considerably slower than the state-of-the-art, it does not demand any special hardware to be executed, being very simple to implement and execute”, it can be concluded that the proposal is considerably slower, and furthermore cannot be accelerated, which is a very serious drawback for its possible use. Besides, analyzing the algorithm I agree that it will be difficult to be accelerated obtaining good speed-ups. If we add the dependence of the algorithm with the gamma and beta parameters, which on the one hand is not quantified, and on the other hand will require multiple executions, the inconvenience can be very serious.
Author Response
Revision Report
October 30rd, 2020
Dear Guest Editors and reviewers,
Firstly, we would like to thank all reviewers for their work and comments in the previous review round. These comments were beneficial in pointing out areas for improvement. We have modified our manuscript accordingly, and we believe the new revision exhibits the desired improvements in quality and clarity suggested by the reviews. In the revised manuscript, the major changes in the text are marked in blue. Below, we list the received comments and our answers, focusing on the major comments (all minor corrections have also been considered).
sincerely,
The authors
Reviewer 2
6- “The bibliographic analysis performed is not adequate. There are a significant number of papers published on the same or similar topics that have been published after 2016 (most recent reference provided in the article).”
Thank you for the comment; we apologize for the mistake. In the new version of the paper, we update the related work section to add all the literature we found focused on edge bundling for graphs, not referencing papers related to origin-destination applications, user-centered interaction, and general trails bundling (parallel coordinates, etc.). Despite the recent advances, none technique considers vertex data for bundling. So, the crucial points for the design of our technique and its advances remain the same.
7- “Considering last conclusion “Finally, although is considerably slower than the state-of-the-art, it does not demand any special hardware to be executed, being very simple to implement and execute”, it can be concluded that the proposal is considerably slower, and furthermore cannot be accelerated, which is a very serious drawback for its possible use.”
Good point, but this depends on the requirement “lens” we are using. If hardware to speed-up exists, the front-end application supports its use, multilevel exploration is not relevant (overview of the connections is enough), and it is not essential to use data attributes to guide the bundling, the reviewer is right. The argument of simplicity does not hold. However, if any of these assumptions do not hold, we understand that it is acceptable to be slower since we meet different requirements. We added this discussion in the Discussion and Limitations section.
8- “Besides, analyzing the algorithm I agree that it will be difficult to be accelerated obtaining good speed-ups. If we add the dependence of the algorithm with the gamma and beta parameters, which on the one hand is not quantified, and on the other hand will require multiple executions, the inconvenience can be very serious.”
We could quantify gamma and beta, but in the same vein as the previous question, we limit our application scope by focusing on something specific, removing the interactiveness and user intervention our technique offers. It is important to notice that our approach is completely implemented using java and javascript, which is not intended for speed. So, there is room for speed improvement (not much computational complexity). Since the graph drawing is a simple spline interpolation, CUDA could dramatically decrease the time and virtually make the setting of gamma and beta real-time. Notice that we have two phases in our approach (Figure 1), and the Graph Drawing phase (where gamma and beta are defined) is independent of the backbone construction. And this phase is much faster to execute. For a visual analytics exploratory process, the Backbone Construction phase can be considered pre-processing since it does not have parameters to change. The user interaction experience can be virtually real-time with good implementation. We added this to the discussion in the conclusions.
Round 2
Reviewer 1 Report
I would like to thank the authors of the article ‘Similarity-Driven Edge Bundling: Data-Oriented Clutter Reduction in Graphs Layouts’ for considering my review comments. As a major modification, the authors have added a detailed section ‘Discussions and Limitations’ where they have considered my review comments, which I think may help the readers to better understand the advantages and limitations of their approach as well as the possible future works, especially considering the missing (or limited) user evaluation for their proposed approach.
They have also precised/clarified the input for their proposed algorithms and have added the time complexity of their algorithm in the beginning of the article as well as a brief textual description of the article. The authors have also added new references and compared other existing approaches.
As a minor suggestion, I will suggest the authors to briefly describe their time complexity, its calculation and the different possible use-cases.
Author Response
Thank you for the comment. As suggested, we added a paragraph into the Discussion and limitations section detailing the overall approach computational complexity.
Reviewer 2 Report
The new section "Discussion and Limitations" included by the authors greatly clarifies the contribution of the article. Both the strengths and weaknesses of the authors' proposal are correctly identified in this section.
The rest of the drawbacks have been correctly solved and I consider that now I can recommend the article for publication.
Author Response
Thank you for your support to improve the manuscript.
