Returning to the topic of scale in relation to the impact and efficacy of our projects, a couple of questions arise at this juncture: To what extent should technology automation and systemization play a part in the development of DH projects? Additionally, to what extent should and can the DH community at large serve as publishing gateways and aggregators in order to scale the impact and the investment of time and effort of DH teams?
Having divided our approximately twenty-five person class into five teams with roughly five persons per team, collaboration at this scale has allowed for a relatively minimal effort needed for systematizing and automating workflows and/or data/media pipelines. One wonders how our collaboration and objectives might have changed if instead of five projects, our class had been divided into two projects with roughly twelve to thirteen collaborators on each team.
In relation scaling the dissemination of academic work, traditional academic publishing has often involved large scale publishing networks and pipelines. The traditional publishing industry served as a dissemination platform at scale for scholarship largely authored by individuals. In the new model, digital projects are often created and built by a team of collaborators and are deployed and disseminated without an intermediate publishing network. While individually authored scholarship relies on informally associated collaborators, including among others librarians and colleagues, the technical, multimedia, and analytical computation tools involved in digital projects bring together a number of specialized and dedicated roles in a more formally organized DH team.
Perhaps another path would have been to divide the class into three or four teams consisting of one or two digital projects and one platform infrastructure team that would be dedicated to developing or integrating projects with infrastructures and networks, thereby providing the intermediate agents traditional publishing once provided. The efforts of the team would necessitate the incorporation of research, technology skills, and knowledge that would serve as a part of the DH toolkit going forward. Members of this infrastructure team might divide their time between the digital projects and the infrastructure efforts. As an additional benefit, more cohesion would develop within the larger group as a whole and potentially more interconnection would emerge with the DH community at various levels. A effort of this kind raises the question of the extent to which infrastructure is a sine qua non aspect of the DH discipline and not merely an object of study as a DH subfield.
While a monolithic platform for the dissemination of digital scholarship would be neither efficacious nor desirable, technology solutions that facilitate an interconnected ecosystem of digital work would offer a way to leverage labor and thus amplify the impact of DH efforts. Critical theory and transdisciplinary understanding underlying DH suggests that while technology is by no means the panacea claimed by tech futurists, technology solutions might nevertheless offer opportunities for furthering the humanities in general and digital endeavors in particular.
Along these lines, one might well imagine building out and interconnecting already existing networks of DH databases that aggregate digital works constructed by DH teams. Given how the Internet has long since outgrown the file based hypertext architecture designed by Tim Berners-Lee just over thirty years ago, the challenge becomes how to represent and promote temporally-based user experiences involving video, hypermedia, and dynamic interactions. One possible approach in this effort might be to build off the architecture underlying the Internetworking project SOLID, another endeavor led by Berners-Lee to store “data securely in decentralized data stores called Pods. Pods are like secure personal web servers for data. When data is stored in someone’s Pod, they control which people and applications can access it.”









