Actually, I think pagerank is definitely the right direction. It’s just going to be much better at predicting the top finishes (and more unstable farther down the field).
Page rank basically says to randomly hop between the runners along the edges corresponding to wins and compute the probability of landing on either runner as a winner. This is what the first eigenvector of the graph Laplacian gives you (it’s called a Laplacian because it models the diffusion process of jumping between the runners).
This means your approach is basically returning something proportional to “win probability,” which you are augmenting with weighting. This intuition should also give you an idea for where your approach is unstable — it will be good at estimating winners, but slower runners will have very tiny probabilities of winning and are therefore harder to compare. This makes PageRank good for Google search results, but less good for ranking 1000s of runners.
Another approach is least squares. Suppose for each match-up (an edge in your graph), you write an equation to describe the result:
A - B = 5
means
”Runner A lost to runner B by 5 seconds.”
This gives you more equations than variables, which lets you solve a overdetermined linear system with least squares. This gives each runner an ability score that generally matches up with the time gaps.
Computationally this is a nightmare when scaling up to 100,000 runners. You can get more efficient by instead computing meet scores between two meets with shared competitors. This is still too slow. This is where my current approach with message-passing between meet and runner nodes comes in, which is similar to how Google speeds up its computation of pagerank.
One final comment: the time differential means different things for different races. You can imagine beating someone by 30 seconds in a 5k might be like beating them by 60 seconds in a 10k. For this reason, I don’t use time differences but the difference in the logarithms of the times. This is because log(a/b) = log(a) - log(b).