The ILS-DI group is intended to be a small group working over a short duration: eight library professionals from various research libraries across the US, working from mid-2007 to early 2008. We aim to move quickly and work with the resources available to the library community to produce simple, effective, and practical recommendations for integration of ILS's with discovery applications. Towards that end, we aim in our recommendations to

1. Improve discovery and use of library resources via an open-ended variety of applications that build on the data and services of the ILS. Our goal is not to specify or implement the applications themselves, but to specify the interfaces that applications can use. These applications may be local or remote, and may interact with more than just a single ILS.
2. Articulate a clear set of expectations so that ILS service and discovery application developers know what services to provide and how they need to interact. This includes describing specific functions, including their requirements, inputs, and outputs, at a level detailed enough that implementors understand what to implement and clients understand what to expect. For example, instead of simply saying "support networked search" we would specify the kinds of queries and responses that should be supported in a search.
3. Make recommendations applicable to a wide variety of existing and future systems and technologies. Technologies, protocols, and standards are changing rapidly, but the basic functional requirements for discovery applications are in many ways independent of particular technologies. Therefore, we aim to specify both abstract functions and behaviors that describe desired information and services in a technology-independent manner, and concrete bindings that implement these functions using a particular technology or standard. For example, we might specify an abstract function for extracting bibliographic records from an ILS, and then define a particular binding of that function that uses a MARC-XML data format and the OAI-PMH protocol.
4. Ensure that the recommendations will be feasible to implement, in whole or in significant part, in reasonable time and cost. Our aim is to keep our recommendations as simple and lightweight as possible for the desired functionality, and where possible be compatible with existing ILS's or a near-term revision of the ILS. The ILS may well undergo substantial redesign in the future, perhaps in part in response to recommendations like ours, but we do not want to make a recommendation that cannot be implemented without completely reinventing the ILS. To support incremental investments and near-term prototyping, we intend to specify at least one possible binding for each function that uses current technologies, and give a specification that is modular enough that implementors can implement parts of it, and specify which parts they support, without having to immediately support the entire API.
5. Support interoperation and cooperation with applications outside the "traditional library" domain. Library clientele today use a wide variety of applications to locate interesting and relevant content, some of which are designed by libraries, some of which are created by unrelated entities. Once they find content, they like to use additional applications to store, analyze, and reuse it. We want to make sure that library resources can integrate well in this broader environment, and avoid having them isolated in an inconvenient "content silo". We also want to recognize and reuse the standards and tools that are already in use or development outside libraries, and could work well with library content and services. We do not want to needlessly limit these recommendations by requiring the use of standards like MARC or Z39.50 that have very limited use outside the library domain.
6. Be responsive to the user and developer community. Our survey of library developers and decision-makers is summarized in this report and included in more detail in a separate document. We hope that these recommendations address many of the needs and desires exposed in the survey responses and that the functional definitions supply a common reference point for rapid prototyping of interfaces and applications and discussion of present and future ILS capabilities. The recommendations in our report are meant as a starting point. As new applications and implementations are developed, we expect that new functions and bindings may be defined and publicized. Where appropriate, we hope that these can be incorporated into later revisions of these recommendations.