[CollEc] New CollEc

[Düben, Christian]

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 at uni-hamburg.de
http://www.christian-dueben.com

-----Original Message-----
From: Thomas Krichel <krichel at openlib.org> 
Sent: Dienstag, 11. August 2020 05:32
To: Düben, Christian <Christian.Dueben at uni-hamburg.de>
Cc: CollEc Run <collec-run at 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