The Google Scholar discussions have underlined the emerging importance of the desktop (or, rather, the browser) as a venue of integration. The discussion of toolbars, FireFox extensions, bookmarklets and RSS feeds highlights the growing availability of desktop tools for interaction and integration. We could call these ‘intrastructure’<*>. They tie together data and applications in flexible and simple ways. They operate ‘close to the surface’ of the web information space, typically use web protocols and want to ‘keep it simple’. Intrastructure is in the interstices of larger infrastructural pieces, feeling its way like a vine into places it can flourish.
This proceeds alongside the developing trend towards ‘life caching‘, or work or learning caching, the accumulation of personal collections of documents, data, images.
Libraries are looking into how they leverage this intrastructure to make services available at the point of need, rather than making users always come to some central network location, whether it is the library website, or the library ‘portal’ (see here for a short and here for a long discussion of portals). Indeed, one thing to ask of ‘portal’ developments is whether they try to recreate on the network the comforting collocation of the physical library place, rather than reaching into the places where users work and learn.
Some recent examples of making services available at the point of need using these approaches are the discussions about using RSS for feeds from the integrated library systems; about using bookmarklets and RSS to tie together Amazon feeds and library systems; about using bookmarklets to link between Amazon, Google, or Open WorldCat results, and local library catalogs. The FireFox OpenURL extensions (see the work by Peter Binkley and Andy Powell) are also good examples, where an intrastructural component (the FireFox extension) leverages the infrastructure of Google Scholar and resolution services to create value. Our FRBR bookmarklets are another example, where a simple bookmarklet leverages the xISBN web service to bind together different versions of works across several search systems.
In many cases such intrastructural tools work with ‘infrastructure’. Google, Amazon and eBay, for example, are all building infrastructure, and allowing others build unpredictable intrastructure on top of it. A major part of such infrastructure is the accumulating reservoirs of data which are being mined, analyzed and exposed. Amazon and Google are powerful computational and data hubs, which are opening themselves up to a variety of intrastructures to co-create value with their users. Look at how a service like All Consuming is built on top of various other services. Intrastructure helps release the value of infrastructure in creative use.
In a similar way, we are very encouraged to see tools begin to appear which will work with OpenWorldCat to help release the value of the switch it provides on the open web between library users and library services.
Now I haven’t discussed web services. Web services come in different flavors and there is an ongoing discussion about the relative merits of simplicity (RESTful approaches) and more elaborate approaches based on SOAP. Simple web services are part of what I am calling intrastructure. The main idea is that it can be built quickly and without the need for extensive development capacity.
So, we have seen a rapid progression to the desktop, at the same time as other developments proceed apace. Succumbing to the librarian’s rage for order, we can see features which emerged successively but which continue to exist in concert in the library information environment:
- Monolithic data repositories, accessed through a human search interface. This is still the dominant model: our systems provide limited hooks to bind them into user environments with intrastructure.
- Portalization. In a first stage, built with the relatively heavyweight Z39.50 protocol and complex but necessary knowledgebases. A variety of screen scraping and other approaches are symptomatic of the absence of simple, intrastructural, ways of getting data in and out of such systems. More recently, we have seen the emergence of the OpenURL approach to linking, tieing databases together with lighter intrastructural resolution services.
- We have just begun to see a growing tendency to factor out individual services as web services which can be recombined in various ways. We are seeing the reinterpretation of many protocols and requirements in a web services and XML idiom. In the library space this is particularly interesting as we want to develop pluggable library functions which can be inserted in institutional portals, course management systems, library websites, personal environments. Whatever the technology, I do not understand why all libraries do not have a simple catalog search box on their home page, and anywhere else that seems appropriate!
- Browser level integration through intrastructural tools like bookmarklets, RSS feeds, browser extensions, and so on.
Amid this profuse development, what are some trends we might see? I see three big things which we do not have, but which would benefit us greatly:
- We need to commoditize common problems: isolate issues which are susceptible to general solution and move them to infrastructural solutions. For example, how much redundant effort is being spent on the construction of knowledge bases to support portalization and resolution. This lends itself to being implemented as shared infrastructure, and we have seen some consolidation in this space. This means that libraries may have to map more processes to shared infrastructure. The tradeoff is that this releases energy and imagination for intrastructural innovation in the local environment. The world now moves so fast and in so many directions that it makes less sense than ever to tackle the same problem everywhere and over and over.
- There is a danger that the desktop will become too crowded, and difficult, for the non-initiate user to manage. This suggests that it would be useful to have a local integrative environment where services can be assembled and articulated easily, a dashboard or portfolio of some sort. FireFox extensions are a step in this direction, but FireFox is not a pervasive use environment. Maybe this will be the next big thing from Google?
- We need to understand that on the network everything is a service. The quality of what we can do with it depends on the functionality of what the service makes available, what hooks there are for vines to attach to. Most of what we interact with is still made available as a dumb user interface, which cannot be repurposed. Increasingly, we would like services to be ‘webulated’, made available at known URIs in a form that allows us to more easily integrate them with emerging intrastructure and user environments. RSS, web services, OpenURL, SRW/U: whatever the mode of connection, we want to be able to stitch more effectively.
