discoverlocate.pngI was involved in some work years ago which developed the discover-locate-request-deliver string of verbs to talk about integrating library services. One emphasis of the work was that discovery was one part only of a whole chain (discovery2delivery - D2D) through which requirements were met. Requiring the user to complete the D2D chain by manual interactions dampened library use: writing down the results from an A&I search and then looking in the catalog to see if the journals were held, for example. As we look at resource sharing environments, we still see that we have imperfectly integrated the D2D verbs. In fact, the integration has been greater with journals as a major focus of the OpenURL resolver is to join up the D2D chain. One wonders whether it will make sense to put the catalog behind the resolver also, and it is certainly interesting to see the importance of resolution in some of the examples below. I now think of the verbs in this way:

  • Discover. Discover that a resource exists. Typically, one may have to iterate to complete the discovery experience: search or browse candidate A&I databases, for example, and then search selected ones. The publish/subscribe model is increasingly important to discovery, as users subscribe to syndicated feeds. One of the major issues facing library users is knowing where to search or subscribe to facilitate relevant discovery
  • Locate. Discover services on found resources. A service may be as simple as notifying somebody of a shelf location. Resolvers are important here: an OpenURL resolver will return services decided to be available on the resource indicated in the OpenURL.
  • Request. Request a service. A user may select and initiate a found service.
  • Deliver. The service is executed. A book is delivered, a document downloaded, or whatever.
Of course, other services will be deployed along the way: authorization, authentication, tracking, billing, etc.

What the web does is give us an integrated discover-locate-request-deliver experience. Some sophisticated infrastructure supports this concatenation: crawling and indexing by search engines, DNS resolution, ....

In library services the joins are more visible, and many of the places where one wants integration are precisely at the seams between these pocesses. Think horizontal and vertical as in the picture. The joins are horizontal where one wants to move between the processes, to traverse process boundaries. Having discovered that an article exists, one wants to find services that will make it available, and select one (or maybe have all of this done for you in the background, just as it does with a web page). The horizonal joins are most likely to be achieved within monolithic systems: the library catalog for example, which may allow you to discover, locate, request and have delivered items. Living in Ohio, one is very aware of the value to faculty and others of OhioLink. OhioLink closely integrates the D2D process for books on a systemwide level within Ohio higher education, and creates great value for its participants and users in so doing.

The joins are vertical where one wants to integrate activities within processes: metasearch is a topical example, where one is trying to integrate discovery across many resources. One may want to locate an item or service in several places - Amazon, the local catalog, a group of catalogs within a consortium - and present back to the user options for purchase or borrowing with indications of cost and/or likely delivery times. A request may be initiated through Inter-Library Lending or through a purchase order, and so on.

Much of the complexity of constructing distributed library systems arises from traversing the boundaries between these processes (horizontal integration) or from having unified interaction with services within a particular process (vertical integration). An example of the former is the difficulty of interrogating local circulation systems for status information; an example of the latter is differences in metadata schema or vocabularies across database boundaries.

I was reminded of the discover-locate-request-deliver string as I have been looking at various publicly available union/group activities recently, and these words crop up from time to time:

  • RedLightGreen offers a rich discovery experience, based on aggregate data from the RLG union catalog. It also has a marvelous name ;-) - one of the few library initiatives to have a name worthy of the Internet times we live in. I speculate that it has not had the traction that one might have expected because it does not integrate the locate-request-deliver verbs so well into the discover experience.
  • The recently visible Talis Whisper demonstration site gives a nice indication of how one might tie these things together, although not all the joins appear to be working in the available site. Interestingly, it offers the user tabbed access to discover, locate and borrow processes.
  • The European Library (TEL) has a facility to search across European national libraries. This somewhat confuses the discovery experience as results are not rolled up into a single set for you. There is little integration of the other services. One can configure it with an OpenURL resolver of choice, but otherwise it does not offer much integration.
  • CURL (which appears to have drifted clear of its acronymic mooring to become the Consortium of Research Libraries in the British Isles) lists as part of its vision to allow researchers, "wherever in the world", to "search, locate and request all resources, whatever their format, easily and quickly from the desktop". Some of those verbs again. One vehicle for achieving this vision is COPAC, a union catalog of the national libraries in the UK and 24 research libraries in the UK and Ireland. COPAC offers discovery over its constituent catalogs. Again, it allows outward OpenURL linking through an experimental user interface, using the OpenURL Router to land in the appropriate institutional resolver. (The OpenURL Router is a UK service which provides a central registry of OpenURL Resolvers. It is similar to, and preceded, OCLC's OpenURL Resolver Regisry.)
  • OCLC's OpenWorldcat does not currently have a destination site; rather, entries may be discovered in Yahoo or Google, or be directly linked to. Where we recognize a user's IP address we offer services (deep link to OPAC, user-initiated ILL, resolver) which we know they are authorized to use.
This cursory overview shows that we have intermittently and imperfectly managed to integrate location, request and delivery into systems whose focus is still largely discovery. However, discovery without fulfilment is of limited interest to an audience which wants D2D services which are quick and convenient, and which hide the system boundaries which need to be traversed in the background. I am also surprised, especially given the linking of discover services to locate services through the resolver in the journals arena, that we have not seen more linking of general discover services (e.g. Amazon) to library locate services (e.g. catalog/circ).

To complete the D2D chain efficiently in open, loosely coupled environments (that is, not within closed communities with tightly integrated systems environments) will require quite a bit of infrastructure development. Much of this relies on better metadata about institutions (libraries, branches), collections (databases, library collections, ...) and services (how to connect to catalogs, ILL systems, resolvers, e-commerce sites, ...), as well as about policies (for example, who can borrow from us and under what conditions) and terms. It is for this reason that we are seeing greater interest in registries and directories which will provide the ability to discover, locate, request and have delivered resources more effectively.

The picture is taken from an early presentation [ppt]I did at OCLC at a seminar organized by Erik Jul.

Related entries and article:

Comments: 4

Nov 23, 2005
Mark Carden


I'm not sure I share your view of the "Discover, Locate, Request, Deliver" sequence. (or maybe I just disn't understand it properly)

It seems to me that the searcher should be able to "Request" without having to do any "Locating". So to me an ideal flow is more like:
"Search, Discover, Request, Locate, Retrieve, Deliver, Receive".

Nov 28, 2005
Peter Brophy

As we're currently carrying out a short evaluation of JISC's Information Environment Service Registry (IESR), my eye caught the phrase "One of the major issues facing library users is knowing where to search or subscribe to facilitate relevant discovery". In theory, service registries should help the user by enabling dynamic selection of potentially useful targets. However, contrary to your final comment there doesn't seem to be a lot of enthusiasm out there among service providers as opposed to people with a technical worldview for actually building this kind of service (or, for that matter, using it). Is this just a matter of time / building experience / building trust or are we barking up the wrong tree altogether? Is the reality that people will just keep building their own local directories (maybe via their consortia memberships)? What's OCLC's take on this?

Dec 02, 2005
Lorcan Dempsey


Your last point first. OCLC has recently build a couple of registries. The OpenURL Resolver Registry registers institutional resolvers. The rationale is that we want to be able to connect users to their appropriate institutional resources on the web. This is open for participation and use. OCLC has also build a registry of deep OPAC links. The rationale here is that we want to connect people from Find in a Library pages into the correct point in an institutional catalog. This is not open now but we will be making it open. In each case the registry is populated in a couple of ways. By libraries who configure FirstSearch with their details. And by OCLC who collects data in various ways.

Now, what these registries do is they allow applications to cross the boundaries I discuss above. And to do this in well-seamed (to use a term of Peter Burnhill's) way. They reduce the transaction costs of interacting with library resources on the network. They are a form of 'intelligence' which can be leveraged by applications to improve service.

Libraries are building other sources of 'intelligence' so that applications can work in well-seamed ways. For example, they are building knowledge bases with their vendors which help hide the seams in resolution services. They are configuring local metasearch applications with data about targets.

These are all examples of 'intelligence' in the network, which make the network work better. They allow applications to be configured so that they provide the types of integration I talk about above in well-seamed ways.

And the reason I suggest that we will see more registry and directory services is that they are necessary to achieve systemwide efficiencies.

Now, most of the time the data above is meant to be used by an application. My question about the IESR is who does it see as its customer and how does it work with its customers to develop appropriate services? What use cases guided its development?

I think that the type of question you ask needs to be answered in context. In the context of a course, of a reading list, or of an assignment, for example. And how we offer 'suggestions' may be different in each case. Should we be building social bookmarking services around this type of data, or thinking of recommender services based on co-occurrence in courses. I like the way that U Rochester talks about using metasearch to put appropriate bundles of databases into course pages. I have not seen attempts to match user profiles against database descriptions, and am not sure how well it would work.

Anyway, these seem more plausible ways of working than expecting a user to search through descriptions of databases.

Dec 04, 2005
Lorcan Dempsey


Sure ... I think that suggestion is that these are appropriate high-level business processes to think about.

How they might be ordered will vary depending on the circumstances.

And when you think about what actually now happens (with social bookmarking, resolution, etc) there is a lot of interweaving!