Network evaluation of knowledge commons

As mentioned in the conceptual paper of a knowledge commons, when each step of a project is communicated and connected to its direct predecessors (e.g., predictions link back to the theories they derive from), we get a Directed Acyclic Graph (DAG). A visual depiction may look as follows (chronological top to bottom, later nodes referring back to older nodes):

Analyses on DAGs can go many ways. This topic is for open discussion of what questions are interesting to ask, how to measure them, and anything else really. These can be both

  • backward looking: evaluating the network as it exists
  • forward looking: planning how new nodes might change the network

I provide some test R code for 9 conditions in the drop down for anyone to simulate various adjacency matrices that can be used to build and test such networks. Row depicts the origin node, and the column the destination node, which leads to a chronological ordering. The upper triangle of the matrix is empty because old nodes cannot refer to newer ones.

R code
ns <- c(10, 100, 1000)
dens <- c(.2, .5, .8)


for (n in ns) {
    for (den in dens) {      
        obj <- matrix(nrow = n, ncol = n)
        sel <- lower.tri(obj)
        adj <- rbinom(sum(sel), size = 1, prob = dens)
        obj[sel] <- adj

        write.csv(as.data.frame(obj), row.names = FALSE,
                  col.names = FALSE, file =

    sprintf('n%s_dens%s.csv', n, den))
    }
}
2 Likes

I love DAGs, but I’m not sure the central assumption (acyclicity) is going to hold here: predictions link back to theories, but theories are built on data. Perhaps this will work if it’s strictly ordered by time (so that links only go forward in time), but this precludes things like simultaneous theory development where two separate theories influence one another.

It may be a price worth paying to enforce DAG structure because of the ease of analysis, although that structure could be imposed during analysis if nodes are timestamped and connections allowed in any direction. Allowing connections in any direction would also allow asymetric connections, so data might be collected to test a theory (theory —> data) but not support it (data -x-> theory).

Maybe I should explain a bit more about the technical underpinnings that result in a DAG and allows for updating theories etc as you refer to.

Say X is the theory we refer to here. At version 5, you register it, but this does not mean X is fixed in this version permanently.

Say Y contains predictions, which follows on the specific fifth version of X, or X+5. Other predictions, say Z that are based on a later version of X, can occur X+10.

This goes on and on. So it’s acyclic because of version specificity only. Does that help illustrate it’s not so much an assumption but a design aspect? (sincerely asking because I need to be able to communicate this)

I think that addresses the point I was making well in technical terms, but it does place considerable pressure on users to get their versions lined up properly, especially given the versioning and timestamping establishes primacy of ideas.
I suppose I would feel pressured in this system trying to deal with common issues such as working out how to cite some idea floated by a colleague but not yet written up in a citeable format (and I suppose I’d want to be able to cite the future write-up as the source for the idea right now!).

All this is supposed to be abstracted away by the UX. Nonetheless, you raise a valid point about feeling pressure, which I’ll note for the UX testing.

Happy to discuss this further in a separate topic to prevent this from going to much off-topic.