Think of services provided to human interfaces as P-services – where p stands for person (or presentation). Think of services provided to machine interfaces as M-services where m stands for machine (or mediated).
Our dominant model of delivery is P-service, a web interface oriented for presentation to human users. M-services have tended to be a minority interest, very much in the back-office. That is about to change as we move into a flatter web world of light-weight M-services.
Think of the first generation of protocol adoption which saw the emergence of Z39.50 and ISO-ILL, protocols developed in an OSI idiom which did not travel outside a library niche and which have seen steady if not spectacular usage. These support B2B interaction between library applications, and typically those connections have been few in number. They connect isolated peaks. In fact, like EDI approaches in business they were developed before the web itself.
Typically, at the consumer end, the M-services are combined in an application – a metasearch engine, a resource sharing system, and so on – which needs significant technical attention. The costs of consuming and combining M-services has traditionally been high. They typically cannot be combined easily by an end-user using desktop tools. And maybe the structure of the library systems industry has also limited broader adoption.
A second generation of protocol adoption has seen the emergence of OAI-PMH, OpenURL, SRU, and NCIP. Here, a web services idiom is prevalent, and it will be interesting to see whether that flexibility supports better adoption outside the originating community. In general, these protocols are more lightweight. They are designed to encourage wider adoption in a ‘flatter world’, a world where we want to mix data and services in many user applications. OpenURL is a good example of how a lighter weight approach has delivered real value as it has been implementated widely to join up the journal article supply chain.
Until recently the general distinction between P- and M-services seemed quite clear-cut. Recent developments in the wider environment bring them closer together – consider RSS, for example, Ajax, and REST-style URL-based protocol interaction, which move machine-based interaction closer to the user. In the flatter world of today’s web, we want to be able to more flexibly recombine data and services to support user experiences.
This prompts thinking about a third generation of protocol adoption. Here the emphasis is actually moving M-services right into the browser, closely linked to the P-services which create the user environment. In this case, library based protocols need to play well with more general approaches; we need effective bridges. Here are a couple of examples:
- COinS. Here the aim is to make links to appropriate licensed material available more broadly. COinS specifies a way of embedding citation information in a web page, where it can be recognized and activated by a client-side program.
- We are experimenting with the Microsoft Research Pane to surface library servies in MS Office applications. We have written gateways between the MS web services and SRU and other machine interfaces, which allows us to bring up any SRU database in MS Office. This work was done for the terminology services project.
At the Access 2005 conference Ross Singer impressed the audience with a compelling presentation of how one could stitch library services into user environments leveraging the ‘sloppy underbelly’ of the web. He showed firefox extensions, bookmarklets, scraping and scripting approaches, acknowledging that while they create real value they are in their nature often not as robust as one would like. This presentation clearly struck a chord in the crowd.
A major strand of library activity needs to be to make hooks into library services available in such a way that we can more readily develop services and tools to build compelling user applications of the type that Ross suggested. This thought is behind my question at Access [ppt]: what would a library service which can only be delivered through common services (Flickr, delicious, Technorati, ….) and browser tools (toolbars, bookmarklets, ..) be like.
We seem to have turned a corner: we recognize that it is vital to put the library in the user environment. It is nice when the user comes to the library environment, but we cannot assume that they always will: we need to be where they are.
In this context, I was interested to come across Libx the other day. This is a firefox extension which combines several of the approaches that Ross described to place access to library services at several places in the a user’s webflow. (I was pleased to see that one of the services it uses is xISBN, a web service that we provide which accepts an ISBN and returns ISBNs for other editions, versions, etc, of the same work).
See also Jenny’s recent post linking to presentations on similar matters.
Libx link via Science Library Pad.
