Source: NINES/Collex Adding Web-Service
I was recently informed by Laura Mandell, Director of the Advanced Research Consortium (ARC), that ARC will soon be rolling out a newly developed web-service version of the Collex platform. This marks an important and much needed shift in the ARC/Collex architecture.
For those not familiar with Collex, the software was first developed by one of ARC’s founding member organizations, NINES, “a scholarly organization devoted to forging links between the material archive of the nineteenth century and the digital research environment of the twenty-first.†Since its first instantiation, Collex has tried to advance its stated purpose by providing a “Federated Gateway†to major, peer-reviewed, electronic scholarly resources. Participating digital content providers submit cataloguing data to NINES via RDF, and the items are entered into a union catalogue that is exposed to endusers via the Collex front-end, which provides a host of search, browse, and social networking features.
The idea of a union catalogue of peer-reviewed scholarly research was, at the time of NINES inception, and still is, a good one. It aims for the same long dream towards which current discussions about FRBR, linked data, and the RESTful web also aim. However, there has always been something unsettling about NINES/Collex’s particular approach. Simply put, in trying to create a “linked†data environment that maximizes the potential of webs of information (think Tim Berners-Lee original vision of the Semantic Web), Collex actually did exactly the opposite at the data level. It reduced a dynamic and institutionally diverse web of information into a static, single bucket of information with a single user interface. Driven by an impulse to link out, it instead drew in, creating a silo that effectively re-branded a host of disparate resources, front-ends, funding, and work-efforts as NINES.
As a founding and then General Editor of the Romantic Circles website, one of the largest original NINES participants in terms of the number of contributed peer-reviewed resources, this silo approach always felt to me like a type of digital colonization. Resistance was futile, as NINES had heavy financial support from the Mellon Foundation and equally heavy scholarly support from a veritable Who’s Who of 19th century digital humanists; but I cringed every time I heard someone refer to a resource as a “NINES Resource†when we at Romantic Circles had worked hard to produce it, over many years, with virtually no financial support. (Romantic Circles itself did receive important financial and material support from the University of Maryland, but my work on the site was always performed on my own time, with no recompense, and usually at the expense of more traditional work I probably should have been doing.) Not only did I suddenly have very little control over the search, browse, and collect mechanisms that users would use to locate and interact with my work, but, more importantly, I was loosing intellectual credit for it as well, something that is crucially important to all scholars, and even more so for digital humanities scholars who don’t receive the same institutional credit for their work as those who publish in print. Whereas I had been the founder and General Editor of an important, peer-reviewed, electronic resource (Romantic Circles), I was demoted to a mere contributor to NINES.
Lest this personal observation give the impression that I have not been a supporter of NINES, let me correct the record. It was absolutely essential at the time of NINES founding that digital scholars begin working together on a range of important issues; and the silo model represented a necessary early step in linked data development for a variety of reasons. First, whereas there was lots of talk about web-services at the time Collex was developed, the network itself was neither robust nor pervasive enough to deliver a seamless experience to end-users. The typical web-service experience of the time was something like, “load half a page and wait indefinitely for the rest to show up, if you’re lucky.†Second, and more significantly, the idea of the silo was such a part of NINES early conception that, in a very real way, it became almost impossible to think of NINES in any other way.
NINES was first conceived by Jerome McGann not as an instantiation of Berners-Lee’s Semantic Web (in fact, if memory serves, McGann was actually thinking and talking about NINES before Berners-Lee published his now famous article on the Semantic Web), but as a platform for preserving and ensuring access to the increasingly large body of high quality digital scholarship that, due to the rogue nature of early digital scholarship, had absolutely no guarantee of institutional support or longevity. Resources like The Rosetti Archive, The Walt Whitman Archive, and Romantic Circles seemed likely to disappear from the digital landscape as their founders and editors either retired or moved on to other projects. Preservation was the primary motive behind the conception of NINES, and finding an institutionally supported common platform to collect and host these resources seemed like a natural way to preserve them. Libraries, had, after all, been using the silo model successfully in one form or another for literally thousands of years.
As discussions of NINES evolved internally, discussions about the Semantic Web and linked data were evolving all across the internet, and these two discourses eventually merged. NINES gave up the idea of a common publishing repository and moved towards the idea of defining a common semantic data structure for describing resources such that resources from multiple sources could interact with each other (and with users) in meaningful and interesting ways. But the archival orientation of its nascent period never left the discussion, and it unknowingly suffered as a result.
Unlike the network of ten years ago, today’s physical network and its supporting technologies are more than adequate to support a true, web-service model of data exchange, thereby liberating Collex and ARC from its silo lineage. As I imagine it, an ARC web-service would expose ARC union data via web-service back to the contributing providers, at a minimum, and possibly to the public at large. This would allow content developers to develop their own, unique interfaces and methods for working with the conjoined data. This offers the promise of both speeding the development of new navigation systems and also of increasing the range of ways that people can interact with data. It shifts the creative control back to the street, as it were, opening the door for essentially anyone, anywhere, to develop new and exciting functionalities that work on ARC datasets. Imagine some tech-savvy graduate student somewhere crafting an iPhone app that pings the ARC web-service in order to provide an interactive chronology of Percy Shelley’s work, or some such functionality. For end-users, the net result will be a world of user interface choice. This is a good thing.
Reestablishing the portals of content providers as the gateways to the actual content also serves the important function of re-asserting the content providers branding as the primary branding of resources. Under this model, users working in the interface of any one content provider would be able to work to some extent (short of actually viewing the resource) with the resources of other ARC content providers just as they can using the current, non-web-service version of Collex. But original content providers have a vested interested in highlighting the difference between a locally produced resource and a remote one. This interest serves both parties. Highlighting my resources over yours in my interface starkly differentiates my brand from yours without the interjection of a third brand between. As such, both of our individual products remain more closely tied to our own branding, and, by association, to our own institutional and scholarly credit. This may sound like a trite and self-serving point, but it matters. Scholarly credit and branding is the currency of tenure and job security in the digital realm.
I wish the ARC community luck as they march down this important new digital road. As I am no longer working in an official capacity on any of the ARC member resources, I can’t say how quickly any of them will be able to respond to the new possibilities offered by the web-service model. But, then again, I wouldn’t put it past myself to find some time to code up some ARC service widgets of my own in the near future.
