17. Allow commercial use of data in mobile application

An application developer might use bibliographic data from an institution to create an iPhone application to provide an alternative means of accessing the catalogue.

Description

Activity - With the rise of App Stores in the mobile phone market, opportunities are created for the provision of cheap applications that leverage institutional data. Given this setting, an application developer (perhaps a student) might use bibliographic data to create an iPhone application to provide an alternative means of accessing the catalogue that some users might prefer. The application costs 79p. There is no requirement that students buy an iPhone or the app, and the existing OPAC remains freely available to all. Alternatively, a library may contract with a developer for something specific but elect to make the data open in order to encourage other developments.
This use case differs from UC16 because it is about commercial development approved by the library whereas UC16 is about open-ended community development.
Part of use case: | Share your experience
Actors - Libraries, Application Developer
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, 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 be undesirable, preventing this entrepreneurialism. A completely open license keeps the opportunity open for others.
Part of use case: | Share your experience
Current Examples - We are unaware of examples involving open licenses.
Part of use case: | Share your experience

Benefits

Institution - Something for negligible cost.
Part of use case: | Share your experience
Library Service - Meeting a perceived requirement in a ‘cool’ way at negligible cost.
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: data liberated for this purpose should be re-usable by other interface developers
Part of use case: | Share your experience
Case for not doing it - Concerns about (1) user perception of the charge; (2) quality of any apps and how that might reflect upon the institution; (3) third party profiting from institutional data
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 does not mean all users will be most comfortable with that interface. Rather than devote effort to building alternative interfaces, why not expose as open data and let those who are interested and motivated do it?
Part of use case: | Share your experience
Costs - Mobile is just one example; more generally this may reduce 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, both usage and satisfaction may rise.
Part of use case: | Share your experience
Rationale for not doing it - Concerns about (1) user perception of the charge; (2) quality and updating of any apps and how that might reflect upon the institution; (3) third party profiting from institutional data
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - (1) Staff and students will have the opportunity to access an existing library service in a different way; (2) Additional discovery channels will add value to the user experience and may increase demand on some areas of the local collection, whilst displacing demand from other areas.
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 UC16]; (3) Damage to institutional reputation through provision of substandard product by a third party [see also UC3, UC4, UC5, UC16]; (4) Popular product puts unsustainable strain on infrastructure (e.g. by repeatedly polling holdings status inefficiently) [see also UC16]; (5) The originator of elements of the bibliographic records challenges commercial exploitation of data [see also UC1, UC2, UC3, UC4, UC5, UC6, UC7, UC15, UC16]; (6) Increased visibility of collection leads to demand beyond ability to supply [see also UC3, UC4, UC5, UC6, UC7, UC9, UC13, UC16].
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, UC16]; (3) Increased use of library collection by internal and external users through improved discovery services [see also UC3, UC4, UC5, UC6, UC7, UC9, UC13, UC16].
Part of use case: | Share your experience
Consequences of not doing it? - Inability to provide appropriate services on a wide range of platforms results in sections of the member population relying on those platforms disengage from the library service.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - It is assumed that although the use case is allowing the commercial use of data, this is based on release of Open data. Data released must allow the intended reuse, which means that non-commercial licensing is not appropriate. It may be appropriate to include elements such as ‘attribution’, although elements such as ‘share alike’ may prove more challenging for commercial partners. As data is being released as ‘open’ data (i.e. freely) there is a question of what is being charged for, and whether this is allowed by the license applied to the data. This implies that a commercial model would have to be based around services and software, not the data itself. See the general guidance on Licensing Issues for more.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - All models require engagement with the target commercial partners to decide most appropriate record format. 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