I openly admit that I am not a fan of that two stage procedure with an unweighted (binary) first stage and a weighted second stage. However, I see that you really insist on having it in the app. Thus, I came up with a solution that produces the same results as your two stage procedure while being a lot more efficient: W_{i,j} = 1 - (N_{i,j} * 0.001). Unless any two authors published at least 500 papers together this transition function results in the same shortest path as the two stage approach. Just like you insist on the above mentioned unweighted-weighted combination, I am not dropping the weighted cases. To evaluate how intuitive the weighted edges are to new users I asked various people to test the app. And nobody struggled with the intuition behind edge weighting. It is the same as requesting the fastest route between two places on Google Maps. To account for your concerns I already set the binary option as the app's default case. Users have to actively tick a box to change from the unweighted (binary) to weighted cases. So, how about you get your optimized unweighted-weighted approach and I keep the weighted edges in the app? Christian Düben Research Associate Chair of Macroeconomics Hamburg University Von-Melle-Park 5, Room 3102 20146 Hamburg Germany +49 40 42838 1898 christian.dueben@uni-hamburg.de http://www.christian-dueben.com -----Original Message----- From: Thomas Krichel <krichel@openlib.org> Sent: Dienstag, 11. August 2020 05:32 To: Düben, Christian <Christian.Dueben@uni-hamburg.de> Cc: CollEc Run <collec-run@lists.openlib.org> Subject: Re: New CollEc Düben, Christian writes
I can come up with rankings and with an exportable text file.
Maybe somebody else can, if he knows how to access the raw data.
But that has to wait. Over the past few months I spent much of my time on GraphEc, CollEc and teaching and neglected my research. With multiple upcoming conferences and potential research visits, that needs to change. I have to spend the next weeks on research. My suggestion is to keep both versions of CollEc running for now and to postpone the official transition between versions until October. Until then, we could run the web application at e.g. collec2.repec.org to highlight the upcoming transition.
I fully agree. I will think about how to do this.
The text in the Shortest Paths tab mentions the potential existence of multiple shortest paths. And that is addressed by the choice between the binary case and three transition function cases.
I think there are two issues here. There are multiple shortest paths by one weighing schemes and there are Let me repeat what I said before. I don't think we should expose non-expert users to non-binary paths, because of the triangularity issue. Therefore I think it is best to examine a set of multiple binary paths, evaluate them against other weighing measures and discard those that don't have minimum length against them. That itself is presumably not difficult to do but it is difficult to do so that it runs fast. The exported data does not need to be completely up-to-date. We can first do new nodes, and then form a queue for the rest of the nodes.
Which shortest path is displayed in the Shortest Paths tab does not affect the computed centrality measures. For closeness the number of shortest paths between two authors does generally not matter. Only the distance between the two people is considered. And the code deriving betweenness internally computes all shortest paths, but only writes the resulting betweenness result to disk.
But all shortest paths of all nodes under all weighing schemes are available somewhere. -- Cheers, Thomas Krichel http://openlib.org/home/krichel skype:thomaskrichel