One of the areas we targeted for attention back in 2006 as we set the work agenda with our new Research colleagues was the nature of interactions with the Integrated Library System(ILS). It was clear that external systems were more often calling on and relying on services embedded deep in the ILS yet there were no standard services offered. We thought it would be interesting to work with the RLG Partnership to design and define an ILS Service Layer – an agreed upon set of services for an ILS to expose. Our initial focus was going to be on connecting a discovery environment (e.g. WorldCat, Google Scholar, etc.) to ILS functionality (e.g. get availability).
Two things reduced our investment in this project. The advent of WorldCat Local made this into a very important product focus since WorldCat Local doesn’t work very well without that well understood service layer. And in more or less the same time frame the DLF convened a Task Group to recommend standard interfaces for integrating the data and services of the Integrated Library System (ILS) with new applications supporting user discovery. We volunteered to be part of that working group but because of the OCLC service offering were invited only to comment when ILS vendor input was solicited.
In any event our colleague, Janifer Gatenby, had done a very thorough job of looking at the data in the ILS in preparation for this work. She gave a lot of thought to where this data ought to reside for maximum effectiveness. In the current network environment many data types that are supported at the local level might be both more efficiently managed and usefully invoked if they resided at the group or network level. She’s codified her thinking and her recommendations in a paper just published in Ariadne.
Her paper,
The Networked Library Service Layer: Sharing Data for More Effective Management and Co-operation is sensible, accessible and deserves consideration as we re-configure library services and the management processes that support them.
She particularly focuses on where the data should reside and specifies some of those levels:
* globally sharable data (e.g. bibliographic metadata, holdings, issue level holdings, suppliers, statistics, reference query-and-answer pairs)
* Data that can be shared within one or more co-operatives to which the library belongs (e.g. selection / rejection decisions, weeding reasons)
* Local data that are not shared (e.g. budgets, invoice details, some user information)
In our discussions we’ve taken to talking about this as the specific gravity‘of a service or its associated data.
This is the kind of thinking that pushes us to consider what it will really take to put our services into the users workflow.
Editing note: As soon as I hit the publish button for this post I noticed that Lorcan had also written about Janifer’s paper in a post titled Data at the Network Level. I was pleased to see that he seized on the same excerpt I quoted above.
Jim coordinated the OCLC Research office in San Mateo, CA, focusing on relationships with research libraries and work that renovates the library value proposition in the current information environment. He retired in 2016.
One Comment on “Where should the data live? What’s it’s specific gravity?”
Comments are closed.