16. Publish data for lightweight application development

Publishing library data under an open license with the specific intention of encouraging third parties to develop applications and services using the data.

Description

Activity - Bibliographic data held by a library has the potential to deliver value far beyond the OPAC and the internal systems of the library itself. As an adjunct to course websites, as a driver for reading clubs, and as a source of reference data for bloggers, readers, and genre enthusiasts, authoritative bibliographic data deserves to be used in all manner of third party applications. These might be developed by or for a community, and might be free at the point of use, or incur a fee. In all cases the existing library OPAC remains freely available to all.
This use case differs from UC17 because it is about open-ended experimental community development possibilities whereas UC17 is about exploitation in a commercial development.
Part of use case: | Share your experience
Actors - Libraries, Application Developers
Part of use case: | Share your experience
Data involved - Bibliographic records, possibly involving regularly refreshed holdings data or access to an API enabling live queries against holdings
Part of use case: | Share your experience
Data flow - A dump of basic bibliographic data, supplied to the developer or more widely to a potential developer community, and ideally periodically refreshed.
Part of use case: | Share your experience
Does this require Open Data - Not necessary, but it would avoid the need for multiple developers and institutions to enter into formal contracts. Non- commercial licenses of various kinds would explicitly prevent this entrepreneurialism.
Part of use case: | Share your experience
Current Examples - University of Huddersfield, Warwick public libraries
Part of use case: | Share your experience

Benefits

Institution - Something for nothing; ‘cool’ attitude; encouraging innovative engagement with scholarship
Part of use case: | Share your experience
Library Service - Something for nothing; ‘cool’ attitude; meeting a perceived requirement
Part of use case: | Share your experience
Researchers - Flexibility and choice in accessing institutional services
Part of use case: | Share your experience
Students - Flexibility and choice in accessing institutional services
Part of use case: | Share your experience
Replication - High
Part of use case: | Share your experience
Case for not doing it - Combination of reputational concerns and distraction from core mission
Part of use case: | Share your experience

Motivation

Principles - Choice, flexibility, free market, let a thousand flowers bloom. Just because the institution provides an OPAC, it doesn’t mean that all users will be most comfortable with that as their interface. Rather than devote effort to building alternative interfaces, why not expose the data and let those who are interested and motivated do it? Books need not always be central to the use case; much of the real value might actually be found in cases where bibliographic data simply offers a means of enriching or enhancing some other use.
Part of use case: | Share your experience
Costs - Avoids the need for the institution to invest in alternative interfaces.
Part of use case: | Share your experience
Services - By making data available in ways that users prefer, usage and satisfaction may rise.
Part of use case: | Share your experience
Rationale for not doing it - Concerns about (1) user perception of any charge for use of the resulting application; (2) quality and updating of resulting apps, which that might reflect poorly upon the institution; (3) a third party profiting from institutional data. Furthermore providing data for these purposes is simply not core to the institutional mission.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Staff and students will have the opportunity to access an existing library service in a different way.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Backlash against a charge for accessing freely available information (from local users and external observers) [see also UC17]; (3) Damage to institutional reputation through provision of substandard product by a third party [see also UC3, UC4, UC5, UC17]; (4) Popular product puts unsustainable strain on infrastructure (eg, by repeatedly polling holdings status inefficiently) [see also UC17]; (5) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC4, UC5, UC6, UC7, UC15, UC17]; (6) Increased visibility of collection leads to demand beyond ability to supply [see also UC3, UC4, UC5, UC6, UC7, UC9, UC13, UC17].
Part of use case: | Share your experience
Potential Opportunities - (1) Development of innovative / compelling third party services based on open data; (2) An ecosystem of enthusiastic developers emerges, keen and able to provide alternative means of accessing key institutional services via data dumps and APIs [see also UC1, UC2, UC17]; (3) Increased use of library collection by internal and external users through improved discovery services [see also UC3, UC4, UC5, UC6, UC7, UC9, UC13, UC17].
Part of use case: | Share your experience
Consequences of not doing it? - None that are significant
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - Is this Open Data? If it is, the license should be explicit and as open and unencumbered as possible in order to facilitate genuine reuse. See the general guidance on Licensing Issues for further detail. If not, what is the relationship between institution and developer? Is it a single supply of a single data set for a single purpose to a single developer, under an explicit contract? Does the institution want some share of revenue? How does that affect licenses and contracts?
Part of use case: | Share your experience

Practicalities

Data exchange formatting - All models require engagement with likely third party developers to decide most appropriate record formats. Third party software developers are less likely to be familiar with MARC format, and may prefer MARC-XML or simpler representations. It is highly likely that at the least ‘availability’ data would be provided by API for which reference should be made to (1) good practice at http://blogs.ukoln.ac.uk/good-apis-jisc/ 2009/04/15/good-practice-for-apis/; (2) OpenSearch, DLF-ILS and DAIA specifications.
  • Model 1: Records exported from the LMS based on specified criteria transformed into one or more formats to make data as accessible to the interested parties. Additional exports on a regular basis representing either a full export or just changes (additions, updates and deletions) based on the original export.
  • Model 2: Provision of an appropriate API.
  • Model 3: A combination of data export and API.
Part of use case: | Share your experience
Lifecycle implications -
  • Models 1 & 3: Regular supply of updated records, either by full export or changes (additions, updates and deletions) based on the original export.
  • Models 2 & 3: Continued running of API.
Part of use case: | Share your experience
Hosting requirements - Depending on decisions regarding data exchange methods and formatting, either hosting for data files or an appropriate API platform is likely to be required.
Part of use case: | Share your experience
Existing systems impact - There is potential impact upon existing systems if APIs are queried regularly.
Part of use case: | Share your experience
Skills demands - (1) If data exchange is done solely via download of an initial data and periodic updates, subject to LMS support of conditional MARC export, this should fall within the capabilities of a systems librarian. (2) For provision of data via API, the skills required with depend on LMS (or other) support for appropriate APIs. Where APIs do not exist software development would be required. (3) There may also be third party skills issues involving requirement to transform data to generic formats and to support the developer in understanding library data and systems.
Part of use case: | Share your experience

Costs

Setup - The necessary export capability should already be included within the LMS or equivalent local systems. Configuration to meet specific requirements may require modest effort that will normally be within the abilities of systems staff.
Part of use case: | Share your experience
Ongoing - The costs associated with sustaining this capability are low, but will inevitably be affected by the frequency with which data updates must be supplied.
Part of use case: | Share your experience
Cost of doing nothing - No additional costs will be directly accrued through inaction. However, failure to innovate in this area may result in existing systems becoming increasingly dated in appearance and capability. This may lead to a decline in use within the institution, as potential users look elsewhere.
Part of use case: | Share your experience