The Protocol Stack

To define these relationships, we have borrowed the concept of a protocol stack from the IT world of network management.

A protocol is a set of rules or transaction relationships. In a technology sense, a protocol stack is a layered set of protocols defining all the transaction relationships in a network; between applications sending and receiving data and all the layers of software in between required to transport the data across the physical network.

The Data Commons Protocol Stack goes further still to include the social protocols necessary to enable the design, implementation, and management of a high-trust system for data sharing and reuse.

The Protocol Stack is a set of agreements. Some of these agreements will be instantiated in technology and some will be embedded in ethical standards and institutional arrangements. Together, this stack of agreements constitutes the contract made between members of the community that underpins the particular institutional frameworks and technology protocols necessary to create and manage the Data Commons.

We envisage the co-designed commons Protocol Stack as a collective asset: anyone who wants to create a trusted data sharing initiative can do so with the knowledge that they are drawing on current best practice and community standards.

Co-design of the commons protocols needs to solve seven specific challenges. We’ve developed an initial stack of seven protocols, shown in the diagram, that each references one of these challenges and together form the contract for a Data Commons.

We see the process of developing this contract as an ongoing discussion amongst the people interested in a Data Commons. The discussions are unlikely to be a linear progression through each of the layers in the stack. As members talk through arrangements for co-design, governance, and management of the commons and work through the more technical requirements of defining and controlling transactions, they are likely to come back to higher-level questions of value and risk and revisit earlier agreements. So the stack should be seen as a set of challenges, not as a project plan or critical path.