15 March 2009
Also, found a few good examples of what these more hybrid and decentred approaches are arguing against. See HASTAC's Future of the Digital Humanities, and Mellon's A Digital Humanities Manifesto.
I have been working in or around what we today call eHumanities for over 30 years. I know that what I, and others, were doing 15 to 30 years ago can't really be called eHumanities, but, if you will just for the moment allow me to extend the present into the past. Having such a long-term view of these sorts of developments, and having sat through more seminars, workshops and development meetings than I care to remember, what is striking about all these past eHumanities initiatives is that none of them currently exist. They have all promised to be the next big thing, promised to sort humanities computing out, to provide just those tools which will bring the humanities into the computer age, to build the tools that the humanities need. What is blatantly clear, however, is that none of the hundreds of initiatives and projects that I have witnessed over the past 30 years have any existence now. PLATO (Programmed Logic for Automated Teaching Operations) no longer exists (though it was resurrected as Cyber 1 in 2004). The explosion of CD-ROMs in the 1980s and 1990s, now seem to be pitiful relics of a pre-WWW world. The TLTP (Teaching and Learning Technology Program) of the 1990s spent over 22 million pounds and achieved little of lasting influence. Even The e-University Project, which finished in 2004, has had little lasting influence. The only initiatives that have lasted have been archive based projects. Ones where large archives, or concordances between archives, have been slowly digitized and offered on-line.
So let's return to Bamboo. Bamboo is offered as:
“... a multi-institutional, interdisciplinary, and inter-organizational effort that brings together researchers in arts and humanities, computer scientists, information scientists, librarians, and campus information technologists to tackle the question:
How can we advance arts and humanities research through the development of shared technology services?” (http://projectbamboo.org/what-bamboo)There are a number of familiar assumptions embedded in this project. First of all, it is clear from the Project Bamboo Directions specification that one of the basic assumptions of this project is a one stop humanities services provider. Such a strong SOA model for any community must assume at least two things. First, that the present situation of service provision within the community is a problem, and, second, that the service needs of the community are definable and amenable to SOA tools.
The first of these assumptions is not only false, but not just a little insulting. There is a general assumption among IT departments and university administrators that the humanities are Luddite and need sorting out. In fact, e-Humanities, on-line performance, web-arts, and other humanities web work is healthy, exciting and thriving. It does not need sorting out. What it does need is something even approaching a sustainable level of infrastructure funding.
The second assumption, though related to the first, needs a bit more consideration. There is a fundamental assumption that to effectively and correctly make use of academic computing, it must conform to some sort of Services Oriented Architecture (SOA). This is understandable when considering that university administrators always seek something that they can measure and control. However, why they don't think that this is necessary with the Sciences, whose ICT has always been fragmented, task specific and decentralized, is never explained. The fact that computing in the humanities is constantly striving for the unique, the critical, the local and the subversive, simply confirms to the auditor and administrator that something is fundamentally wrong. Therefore, something centralized, uniform and accountable will sort this "chaos" out nicely.
This approach has been tried and tried again over the past 30 plus years, but fortunately to no avail. It has always failed because the two basic assumptions have always been wrong, and remain wrong. Unfortunately, the powers of control and accountancy do not give up that easily. I am not really at all worried that this time they might succeed and enforce a uniform methodology onto the Humanities -- this really isn't going to happen. What worries me, yet again, is that another large pot of money is going to be dumped down the proverbial drain. Money that is desperately needed for some actual humanities research.
A small peak at what Bamboo wants to do shows the same failure, and the same inevitable outcomes. This stage of the project is exploratory and consultative. They have been convening a number of workshops, and setting up a larger "community" of consulting committees. This seems, on the surface, to be the right thing to do. Set up a broad consultation to get the broadest consensus as to what services are needed. Then commence a development program that takes the community input, translate this into a plan, and then build the services. This is an all too familiar model of SOA and is represented explicitly in the Bamboo project.
The problem is that this model, in all its applications, ignores the most difficult and problematic bits of its implementation. The only certain and unproblematic link in the above model is the link between the Plan and the Build. Questions about the representativeness of the Community, of how the Exploration is conducted, of what is chosen and what is ignored in the Plan are all treated as unproblematic. The outcome of this naive approach is that a partial model of the consultation -- The Whole Thing model below, is transformed into an even more partial, local and planable model -- the More Realistic Vision below.
The problem with SOA, and this model of eHumanities services, is that as the model becomes more defined, the less it has to do with what the humanities do, until it gets to a point where what is realistic bears no relationship with the realism of humanities research.
So what is the real mistake here. Well, it is partially that the model of Service Architecture, while it may be applicable to well defined service contexts, simply does not apply to humanities teaching, research or production. However, I think that the larger error is a complete misunderstanding of what flexibility, locality, and innovation entail. Project Bamboo, inadvertently, highlight this error in its own name. The project defines "bamboo", and hence the proposed metaphor, as:
“In the natural world, bamboo is a highly flexible organic material that serves multiple purposes: it can live as a single stalk on a desk or grow quickly into renewable forests; be used for constructing buildings or decorating them; become as strong as hardwood or as flexible as cloth; … We envision our approach for arts and humanities digital services to be similar: configurable, flexible, sustainable, and reliable – hence the name, Bamboo.” (http://projectbamboo.org/why-name-bamboo)What they completely miss in this metaphor is that while it is true that bamboo is a "highly flexible and organic material", the fact that it serves many purposes does not arise from any form of design or planning in the making of bamboo. None of the properties of bamboo that make it so incredibly flexible, both literally and it terms of the uses it can be put to, were designed for these purposes. In fact, the amazing properties of bamboo were not designed at all.
This is the point. What characterizes the humanities, and almost all of important human endeavour, is the ability to turn the mundane, common and innocuous into the new and innovative. What is needed in the eHumanities is the basic resources and the freedom to explore and innovate. What is not needed is yet more expensive programs designed by system engineers and administrators who have no understanding of what constitutes the useful, the innovative, or the important in the humanities.
11 March 2009
I would go much further, as I have done for over 20 years, that the basic premise is completely wrong. Museums, and museum professionals, only have authority to the degree that they continue to control access to, and the public accounts of, their collections. This is not very difficult when a museum has all of its collections under its own roof, but what museums do not yet realize, and Michael shows this all so well, is that increasingly they are not even able to control these traditional forms of presentation. On-line access to digital collections, no matter how they are served out, is making the traditional position of museum professionals as the arbiters of understanding completely untenable.
This should come as no surprise, though it is a bit surprising that it has taken so long. Back in 1997 I said the following as a conclusion to a talk that made this point to a Museum conference at Leicester University in the UK.
"As museums, we cannot do this [make ourselves relevant] by simply accepting the hype of the internet and offer up more of the same restrictive icons electronically. We do not need virtual museums, we need means of access and communication which speak to new audiences and more directly to our local communities.As far back as 1995 we released a report about a project that I was directing that made these very points. The report was called Objects and Learning, and was a report about the Virtual Teaching Collection. The Virtual Teaching Collection was a project run out of the Museum of Archaeology and Anthropology, at the University of Cambridge, and was working on a system that would allow users to collect, link to, share and discuss digital collections. It was developed just before the Web took off, so it was an application rather than a Web App. As such, it has passed into the history of Applications on no longer supported operating systems (in this case Mac OS 9).
We may be able to effect this development, but only in a small way. We can only achieve and effect by concerning ourselves with how we are used, rather than on what we produce. The internet is not the answer, it is but a medium. The question is whether it does become a medium within which various groups and interests may find a voice."
I suppose that the point of this Post is that though finally there is a growning consensus, even within some museum staff, that the traditional attitude of the museum as an authoritative expert institution is no tennable, there has been some voices around for a couple of decades who have been saying this all along. Mostly, though, I think that my real point is that the battle is far from won. The resistance I see today from museum professionals remains distrubingly like Michael curator in his animation. We have a long way yet to go.
09 March 2009
What interested me about these comments was the hugely diverse readings of Ryan's post. Many focused on how Ryan referred to his wife as "Wife", also arguing that he had implied that his "Wife" was predisposed to be technically incompetent simply by having to explain what are a set of web design principles, and some technical specifications, to his partner. In fact, I do not see that the sexist argument applies at all here. There is no sense that Ryan assumed that his wife was predisposed to technical incompetence, quite the opposite. Though, by Mrs. Tomayko's own assertion, it did make her sound a bit thick. By far the most sexist, and even offensive, statements are to be found in the comments.
What I think is really interesting about the comments, with appologies to the Tomaykos for what they have had to endure, is that these comments counter what seems to be Ryan's main point: that what is really holding back the development of a RESTful Web is the absense of standards. Ryan makes a clear association between the advance of database services on the Web with the acceptance of SQL as a standards query language. He goes on to assert that such a universal standard for REST resources, the nouns in his explanation to his wife, would have an equal or greater benefit.
The comments to Ryan's post counter this arguement by their very diversity. One of Ryan's assertions is that REST resources are "representations" and, hence, correspond to a "concept". After his wife makes clear taht she is not really sure what a URL does, Ryan explains to his wife:
Ryan: Oh, right. Those tell the browser that there’s a concept somewhere. A browser can then go ask for a specific representation of the concept. Specifically, the browser asks for the web page representation of the concept.
The wife has already unquestioningly accepted this association of a representation with a concept, and the two, unproblematically, with a web page when the conversation contiues:
Wife: What other kinds of representations are there?
Ryan: Actually, representations is one of these things that doesn’t get used a lot. In most cases, a resource has only a single representation. But we’re hoping that representations will be used more in the future because there’s a bunch of new formats popping up all over the place.
But what does Ryan mean by "computers can use those same protocols to send messages back and forth to each other"? What messages, saying what, doing what, specifying what, and to what ends? I think this is where Ryan's post deviates from what REST is, to what the Web is, and I disagree with him on what the Web is or should be.
Wife: Like what?
Ryan: Hmm. Well, there’s this concept that people are callingWeb Services. It means a lot of different things to a lot of different people but the basic concept is that machines could use the web just like people do.
Wife: Is this another robot thing?
Ryan: No, not really. I don’t mean that machines will be sitting down at the desk and browsing the web. But computers can use those same protocols to send messages back and forth to each other. We've been doing that for a long time but none of the techniques we use today work well when you need to be able to talk to all of the machines in the entire world.
The problem is that Ryan makes a common mistake. He takes the trivial things and makes them seem to be the problem, and, hence, transforms the really complex problems into trival issues (a traditional error that Clay Shirky identified in the Semantic Web arguement back in 2003) . The problem in the above discussion between Mr. and Mrs. Tomayko is not "How do you get machines to pass information back and forth using REST principles?", but "How do people find, understand and use a web page?"
Web pages are not representations of concepts, they are complex performances, accounts. They are purposfully designed and constructed accounts of something. The complexity is extended as a web page, or web resource, does nothing until it is accessed, used and/or read. The really difficult problem in all of this is getting from the web page to a concept period. On top of this, as the long list of comments to Ryan's post demonstrate, a web page does not represent just one concept, but potentially an infinite set of concepts. What is one person's representation of REST, is another person's exemplar of sexism, and another person's evidence of complete missunderstanding. The concept is not in the web page, but in its use. And its use is as diverse as its users.
This is the real rub, whether the web is a RESTful place or a SOAPy place. In fact, I lean very strongly, if not completely, to the RESTful side, but this is not the point here. Whether to REST or not to REST is an important issue, but one, with others such as the Semantic Web, that will continue to get diverted down blind alleys as long as we think that concepts are simple, stable and representational.