ILS Discovery Interface - DLF Fall Forum - Nov 6, 2007

I'm not sure I really grok this idea of bindings, it sounds like they run the risk of ending up with a catalog of specialised implementations, rather than a unified API.  But it is very much needed work, and we do have to be practical.  There was a follow-up discussion session, but I missed it.

ILS Discovery Interface (ILS-DI)

http://project.library.upenn.edu/confluence/display/ilsapi/

* We need Integrating Library Systems
* We need practical solutions soon
- The ILS may undergo radical redesign... but our users won't wait for that, and we can't

Scope

Out-of-scope
- acquisitions
- cataloging integration
- item management

in-scope
- patron-driven discovery from search to use
  -- finding relevant resources (discovery)
  -- acquiring them (delvery)
  -- managing their usage (patron info and account)

You are here: Rough draft recommendation being presented and discussed

Early 2008: Formal recommendation to be released

Beyond? Recommendation will be updated as new technologies, functions, tools emerge

Survey on Current Use of OPAC and Beyond

Current use
- majority considering replacing ILS in next 2 years
- widespread frustration with OPAC interfaces, metadata schemes, resource scope
- generally ok with ILS inventory management functions

Beyond the OPAC
- 3/4 using supplementary discovery apps
  -- many locally developed
- wide variety of interactions with OPAC
  -- data export most common

a lot of duplicate work being done on extracting info from ILS

1. Improve discovery by supporting interfaces to ILS
2. Articulate a clear set of interaction expectations for ILS and app developers
3. Making recommendations applicable to a wide variety of systems and technologies
4. Make recommendations that are feasible to implement
5. Work with applications beyond "traditional library" domain
6. Be responsive to the user and developer community

Functions
- areas of interest: data aggregation, real-time search/query, delivery, patron info & services,
OPAC embed / escape / entry

Bindings
* Specific technologies that implement desired functions

Data Aggregation (getting the data out of your ILS)
- GetBibliographicRecords
* want to have selective export (by date or record type)

Real-time search/query
- GetAvailability
- Search
- Scan
- SearchAuthorityRecords
- ListCourseReserves
- ID-based record retrieval

Delivery Functions
* Holds
* RecallItem
* Security, policy issues can be complex for these functions

Patron information and Service Functions
- RenewLoan
- CancelHold

...

OPAC embed/escape/entry

* OutputRewritablePage
* OutputIntermediateFormat

Getting to an official recommendation

* Make sure we're not missing any essential functions
* Get more specific on functions
* Also find or point to specific bindings of the functions
* Try to finish in reasonable time
* Now is the time to encorage implementor involvement

How can my solution be incorporated?

- show the group how your solution works as a binding for an abstract function we've specified

- it has to be openly and fully specified

* it ideally has service and client implementations in product

- it also helps to have
  -- no IP encumbrances

Beyond the recommendation

* periodically update
  -- is there a sustainability model?