Switch Focus
Use Cases
- 01. Publish data for unspecified use
- 02. Publish open Linked Data for unspecified use
- 03. Supply data for Physical Union Catalogue
- 04. Allow Physical Union Catalogue to publish data
- 05. Expose data for federation into Virtual Union Catalogue
- 06. Publish grey literature data
- 07. Contribute data to Google Scholar
- 08. Publish activity data
- 09. Supply holdings data for Collection Management
- 10. Expose holdings / availability data for Closest Copy location
- 11. Share data for Collaborative Cataloguing
- 12. Supply data for Crowd Sourced Cataloguing
- 13. Supply data to be enhanced for own use
- 14. Publish data for LIS research
- 15. Allow personal use of data for Reference Management
- 16. Publish data for lightweight application development
- 17. Allow commercial use of data in mobile application
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.
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.
Actors -
Libraries, Application Developers
Data involved -
Bibliographic records, possibly involving regularly refreshed holdings data or access to an API enabling live queries against holdings
Data flow -
A dump of basic bibliographic data, supplied to the developer or more widely to a potential developer community, and ideally periodically refreshed.
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.
Current Examples -
University of Huddersfield, Warwick public libraries
Benefits
Institution -
Something for nothing; ‘cool’ attitude; encouraging innovative engagement with scholarship
Library Service -
Something for nothing; ‘cool’ attitude; meeting a perceived requirement
Researchers -
Flexibility and choice in accessing institutional services
Students -
Flexibility and choice in accessing institutional services
Replication -
High
Case for not doing it -
Combination of reputational concerns and distraction from core mission
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.
Costs -
Avoids the need for the institution to invest in alternative interfaces.
Services -
By making data available in ways that users prefer, usage and satisfaction may rise.
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.
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.
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].
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].
Consequences of not doing it? -
None that are significant
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?
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.
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.
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.
Existing systems impact -
There is potential impact upon existing systems if APIs are queried regularly.
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.
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.
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.
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.
