Nathan R. Johnson

I was turned onto Cory Knobel’s dis­ser­ta­tion while I was at a research insti­tute a few week’s ago. Cory had been involved with the NSF’s Work­shop on “His­tory & The­ory of Infrastructure:Lessons for New Sci­en­tific Cyber­in­fra­struc­tures,” which pro­duced a num­ber of awe­some projects related to his­tory and infra­struc­ture. At one point there was a blog/wiki on the Uni­ver­sity of Michi­gan School of Information’s web­site, but it seems to have van­ished. This site exists, but it wasn’t the orig­i­nal work­shop site (still a good set of resources. The most use­ful reports from the work­shop are below.

1. Jack­son, Steven J., Paul N. Edwards, Geof­frey C. Bowker, and Cory P. Kno­bel. “Under­stand­ing Infra­struc­ture: His­tory, Heuris­tics and Cyber­in­fra­struc­ture Pol­icy.“First Mon­day 12, no. 6 (2007)
2. Edwards, Paul N., Steven J. Jack­son,  Geof­frey C. Bowker, Cory P. Kno­bel. “Under­stand­ing Infra­struc­ture: Dynam­ics, Ten­sions, and Design.” NSF Grant 0630263 (2007)

All this is to say that I had been a fan of Knobel’s involve­ment in that project, and I was look­ing for­ward to read­ing his diss. I haven’t made it all the way through yet, but I thought highly enough of a part of the lit review that I wanted to write it here.

Knobel’s review has an extended dis­cus­sion on ontolo­gies, a research area that I’m work­ing on as a part of my work on infor­ma­tion infra­struc­ture. The word ontol­ogy is used dif­fer­ently across dis­ci­plines, and one of the impres­sive parts of Knobel’s dis­ser­ta­tion is the way he han­dles this issue. He describes notions of ontol­ogy orig­i­nat­ing in phi­los­o­phy, STS, and com­puter sci­ence, among oth­ers. He rec­og­nize each and delin­eates dif­fer­ences and sim­i­lar­i­ties among each dis­ci­pli­nary constellation.

That was fas­ci­nat­ing, but what mostly drew my atten­tion was his break­down of ontolo­gies vs. ontic is, because I hadn’t been think­ing of the terms in the same way I read him.

Kno­bel describes ontolo­gies as the exhaus­tion of all pos­si­ble modes of being. An ontol­ogy con­sists of all pos­si­bil­i­ties. Con­versely, the ontic con­sists of the onto­log­i­cal parts that are mate­ri­al­ized through human prac­tice. It seems to me that the ontic is a smaller sub­set of the ontol­ogy, at least to an extent. I say to an extent because parts of Knobel’s def­i­n­i­tion of ontol­ogy would con­flict with the ontic, so the ontic isn’t a prob­lem free sub­set of onto­log­i­cal objects and con­cepts: although con­cep­tual space exists for an exhaus­tion of being, some of those modes aren’t com­pat­i­ble with other modes. Maybe another way to say that is this: although a vast set of objects and things are part of an ontol­ogy, some of those objects would con­flict with other parts of that ontol­ogy — sub­sets of ontolo­gies wouldn’t be able to co-exist in prac­ti­cal lived real­ity. If this is the case (and I think this is the way Kno­bel was think­ing of an ontol­ogy), then the ontic isn’t so much a sub­set of an ontol­ogy, so much as a refrac­tion of onto­log­i­cal con­cepts. My dis­tinc­tion isn’t quite clear to me, yet, and I’ll think about it to try and make it clearer in the future.

The inter­est­ing part to me that Kno­bel helped with was that I wasn’t dis­tin­guish­ing ontolo­gies and the ontic the way he was. The way that I imag­ined it was that ontol­ogy is always a human con­struc­tion. There is a world out there that is unknown by humans, but to be able to speak of it as an ontol­ogy is to simul­ta­ne­ously call it forth in its ontic real­ity. Ontol­ogy and ontic aren’t nec­es­sar­ily sep­a­rate things. Ontolo­gies (the con­cept) exist as a mat­ter of the human abil­ity to refract the mate­r­ial world and hence any ontol­ogy is nec­es­sar­ily ontic.

This might seem unim­por­tant, but think a lit­tle about the dif­fer­ence in human agency in the two def­i­n­i­tions. In the first I described (clear sep­a­ra­tion between ontol­ogy and ontic), there is a set of things that can be called forth. We as peo­ple sim­ply dis­cover ontic out of the pos­si­ble ontol­ogy. In the sec­ond (the blur­ring of ontol­ogy and ontic), we rec­og­nize that any ontol­ogy that we rec­og­nize is the prod­uct of our own par­tic­u­lar sit­u­a­tion. To speak of an ontol­ogy is to simul­ta­ne­ously call it into being as the ontic, even if that ontic is to sug­gest that there is being beyond what we describe. By blur­ring the ontology/ontic def­i­n­i­tion, I think there is a bet­ter crit­i­cal space to rec­og­nize the dis­cus­sion of ontol­ogy is already a prod­uct of a human epistemology.

This isn’t to deny the exis­tence of mate­r­ial, it’s sim­ply to rec­og­nize that con­cep­tual work involv­ing ontol­ogy is indebted to our posi­tion in describ­ing them. I’m strug­gling for a prac­ti­cal exam­ple to give this dif­fer­ence legs, but I think about it and add in the comments.

Blanchette, Jean-François. “A Mate­r­ial His­tory of Bits.“Jour­nal of the Amer­i­can Soci­ety for Infor­ma­tion Sci­ence and Tech­nol­ogy 62, no. 6 (2011): 1042–1057.

I started read­ing this arti­cle because I was inter­ested in revis­it­ing what a crit­i­cal the­ory arti­cle looked like in JASIST. This arti­cle showed up on my radar because it was recently pub­lished and because I had been mean­ing to read Blanchette for a while. Sev­eral friends had sug­gested that his writ­ing would be right up my alley: this arti­cle didn’t dis­ap­point. Smart peo­ple like Blanchette make any sub­ject interesting.

To sum, “A Mate­r­ial His­tory of Bits” describes a crit­i­cal approach to sociotech­ni­cal sys­tems. His focus is on mate­ri­al­ity. That is, he looks at how the phys­i­cal computer’s com­po­nents, par­tic­u­larly its mem­ory, can serve as a lens for under­min­ing pop­u­lar rhetorics of tech­ni­cal imma­te­ri­al­ity. I see it as anal­o­gous to an arti­cle I’m writ­ing describ­ing the con­cept of an infra­struc­tural mon­ster, a crit­i­cal approach that I derive from Susan Leigh Star and Donna Har­away. Like Blanchette, I’m inter­ested in devel­op­ing ways to bet­ter under­stand the polit­i­cal­ity of tech­nol­ogy. Like the essay I’ve been devel­op­ing, Blanchette’s describes an approach designed to inter­vene in a tech­nol­ogy that can be dif­fi­cult to begin interrogating. In my case, I’ve been using the idea of infor­ma­tion infra­struc­ture, which seems sim­i­lar to the com­put­ing infra­struc­ture from this Blanchette’s article.

The arti­cle describes how pro­gram­ming, code, and algo­rithms work to hide the phys­i­cal con­straints of com­put­ing infra­struc­ture. He pro­vides sev­eral exam­ples: the one I like the best is a dis­cus­sion of the von Neu­mann archi­tec­ture of data mod­el­ing. The von Neu­mann model uses a high-level of abstrac­tion in order to pro­vide more usable resources for pro­gram­mers. It acts as an inter­me­di­ary between machine lan­guage and pro­gram­mer. If you’re a web designer, a help­ful anal­ogy might be to imag­ine the von Neu­mann archi­tec­ture as sim­i­lar to a WYSIWYG text edi­tor. The soft­ware acts as a go-between to a more fun­da­men­tal level of code. Like a WYSIWYG, the model also builds inef­fi­cien­cies into the final pro­gram. The von Neu­mann archi­tec­ture makes soft­ware design eas­ier, but with the trade­offs. The von Neu­mann archi­tec­ture abstracts and refracts access to the machine.

One of the trade-offs of this archi­tec­ture is a decrease in pro­cess­ing power. The ease of use coin­cides with inef­fi­cien­cies in using chip resources. As com­puter proces­sors have devel­oped over time, the von Neu­mann model becomes increas­ingly inef­fi­cient, cre­at­ing a pro­cess­ing bot­tle­neck that impedes com­put­ing speed. Simul­ta­ne­ously, sev­eral gen­er­a­tions of pro­gram­mers have been trained with the von Neu­mann archi­tec­ture, and work­ing to re-train or pro­vide alter­na­tive meth­ods works against an entire sys­tem of human infra­struc­ture. This is despite the fact that faster archi­tec­tures exist. The social impedes on the tech­ni­cal. This social infra­struc­ture “resulted in economies of scale that defeated repeated attempt­sat cre­at­ing a viable mar­ket for alter­na­tive, par­al­lel architectures,despite their promise for increased pro­cess­ing power” (1049).

What this analy­sis makes vis­i­ble is the social con­straints of com­put­ing. Despite sug­gests of imma­te­ri­al­ity, what Blanchette shows with this exam­ple are the mate­r­ial prac­tices cou­pled with the con­straints of proces­sors. There are very real human com­mit­ments that are a part of com­put­ing hardware.

I like to think of this con­cept in terms of infra­struc­ture, as its the research area I’m most inter­ested in. Infra­struc­tures work because they become stan­dard­ized. In order for them to span across time and space, cou­pling resources together, they resist change. Indeed, rapid changes in tech­nol­ogy or dis­rup­tions in tech­nolo­gies can break infra­struc­ture. In the case of new tech­nolo­gies, they most likely sim­ply can’t be worked into the exist­ing sys­tem with­out a sig­nif­i­cant com­mit­ment to chang­ing years of infra­struc­ture. In the case of dis­rup­tion, we might imag­ine the work and life wiped out by nat­ural dis­as­ters, as when hur­ri­canes take out cell phone net­works, wreak­ing havoc with real human lives. Infra­struc­ture resists change because of its mate­r­ial con­straints. (1054)

The arti­cle also dove­tails into my inter­est in infra­struc­ture as Blanchette writes:

Thus, in con­trast to the per­cep­tion of com­put­ing as movin­gat a furi­ous pace of tech­ni­cal evo­lu­tion, its infra­struc­turee­volves very slowly. Because of the need to main­tain back­ward­com­pat­i­bil­ity, the incor­po­ra­tion of major changes inthe mate­r­ial basis of computing—e.g., multi-core processing,cloud-based, and wire­less computing—proceeds con­ser­v­a­tive­lythrough muta­tion and hybridiza­tion, rather thanoutright break with the past.

I like Blanchette’s approach, because it makes tech­nolo­gies like soft­ware more pal­pa­ble. Soft­ware may not be some­thing that can be touched like I could a key­board, but there is a great deal of human life behind it. Questioning the inter­face of human com­puter prac­tices and the mate­r­ial of those practices–a key­board, or a processor’s mem­ory space, or another seem­ingly mun­dane com­put­ing resource-provides a good way to bet­ter under­stand social commitments.