D2D in Ohio

Our close neighbor, Peter Murray, of Ohiolink, has been posting about Service Oriented Architectures. He has just been elaborating with some examples of how one might organize an integrated discovery to delivery experience across a set of independently managed services.
In his example, WorldCat, OhioLink, and local library systems are the independently managed services and he envisages some ways in which a ‘service-oriented’ connective tissue might allow them to be articulated to meet user needs.
For example, it would be good for Worldcat to be able to talk to a local ‘catalog system’, so that one can move from discovery (identifying that an item exists), to location (identifying the status of a found item at a particular service location). Peter desribes a second step where that raw status information could be translated into something more useful (available online; available onsite, delivered in 2-3 days; delivered in three to four weeks; and so on) by interrogating the ‘inventory control database’. In this way, the reader has some guidance which will influence a decision about whether or not to request the delivery of the item.
Now, as Peter notes, OhioLink already provides very valuable D2D integration within Ohio, through its discovery/location service in their ‘combined catalog’, and associated request/deliver service.
So, in another scenario, Worldcat might interact with an ‘intermediary’, such as OhioLink, which in turn would interact with the combined catalog and local services.
Peter’s post is more nuanced than this and I have used a slightly different vocabulary. He raises other interesting topics and this discussion is a part of a projected series of posts which will be well worth following.
He also notes that services do not work with each other in this way at the moment. Certainly, Worldcat.org does not behave like this now. But, of course, these are directions in which we plan to go, integrating ‘find it’ services with ‘get it’ services across multiple independently managed systems. This is one reason for being very interested in interoperating with local ‘inventory control systems’ to support ‘well-seamed’ interaction along the D2D chain. And over time we would like to interoperate with resolvers also, using our OpenURL Resolver gateway and e-serials holdings.
Note: Peter is careful to separate discussion of a ‘catalog system’ and an ‘inventory control database’. It is indeed getting more difficult simply to talk about the ‘catalog’ in these contexts as we are unpicking into separate components some of what the catalog has historically done.
Note: Service is one of those weasel words which has a specialized meaning in certain contexts, which can clash with how it is used in more general contexts. You will notice that I use it in slightly different ways above. One as general functionality (as in ‘a library service’, ‘a dry cleaning service’). One as functionality available at a programmatic interface on the network (as in ‘web service’).
Note: Some of the services that would be required in this service oriented framework would be part of what I have called the ILS Service layer, programmatic ways of accessing the functionality of the ILS. So, for example, the ability of Worldcat.org (or some other application) to ‘reflect’ the status of an item in a library, or to place a hold on it, would depend on such a service layer. Of course, NCIP sits in this space.
Related entries:

• Discovery and disclosure
• Discovery, locate …. vertical and horizontal integration
• What is the catalog?
• A palindromic ILS Service Layer