01. Publish data for unspecified use

Simply make data openly and freely available for unencumbered use by third parties.

Description

Activity - A growing enthusiasm for open access and transparency has empowered some efforts simply to make data openly and freely available for unencumbered (including commercial) use by third parties. Government efforts in the USA, the UK and elsewhere provide clear examples of this trend, as do library-specific initiatives such as the Open Library.
This use case differs from UC2 because it is not about a specific publication format, whereas UC2 is about Linked Data.
Part of use case: | Share your experience
Actors - Libraries, which may require institutional buy-in and may have contractual and licensing implications with respect to suppliers, partners, etc.
Part of use case: | Share your experience
Data involved - Potentially any library data, possibly combined with other metadata (such as course titles). Typically records and fields (tags) for which the institution feels rights and licensing issues are sufficiently well understood. See UC2 for the ‘linked data’ alternative.
Part of use case: | Share your experience
Data flow - Data are placed online, either within the institution or via some third party such as Open Library. Data may be periodically refreshed, and it would typically be the responsibility of any organisation consuming the data to check for any updates.
Part of use case: | Share your experience
Does this require Open Data - There is no requirement for Open Data per se. However, if we presume that the rationale for publication is to ensure the widest possible dissemination then adoption of a generic open data license (such as Open Data Commons or CC0) is the most effective way to make the set of potential uses unambiguous. Restrictive licenses are counter- productive, as is making the data available without some explicit statement regarding potential utilisation. Locally developed licenses and statements regarding use should be avoided where possible as, although perhaps open in spirit, these local variants complicate matters for those wishing to combine data from disparate sources.
Part of use case: | Share your experience
Current Examples - Open Library, CERN, the university and city libraries of Cologne, the university of Ghent
Part of use case: | 2 Comments

Consequences of doing it as Open Data

What will happen? - Quite possibly, nothing at all.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The originator of elements of the bibliographic records challenges release as open data [see also UC2, UC3, UC4, UC5, UC6, UC7, UC15, UC16, UC17]; (3) Loss of future revenue [see also UC2]; (4) Lack of focus on purpose results in no use of available data, either due to lack of interest or inappropriate data formats or licensing.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - In keeping with the principles behind this act, 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.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Model 1: A standard MARC export from the LMS, based on specified criteria. Additional exports on a regular basis. Model 2: Records exported from the LMS based on specified criteria transformed into one or more formats to make data as accessible as possible to a wide range of interested parties [see UC16]. Additional exports on a regular basis.
Part of use case: | Share your experience
Lifecycle implications - None are necessary, although the data will be of most value to the largest constituency if there is some regular process for refresh.
Part of use case: | Share your experience
Hosting requirements - Some server space to host the file; alternatively Open Library, Internet Archive, Connected Commons and others may host on your behalf.
Part of use case: | Share your experience
Existing systems impact - None
Part of use case: | Share your experience
Skills demands - Subject to LMS support for export of MARC records based on specified criteria, this should fall within the capabilities of a systems librarian. Model 2 additionally requires ability to transform data between library specific format and more generic formats. This may be achieved via a third party application or through some basic local development. This would require experience beyond simply running LMS reports.
Part of use case: | Share your experience

02. Publish open Linked Data for unspecified use

Make data openly and freely available as Linked Data.

Description

Activity - A growing enthusiasm for open access and transparency has empowered some efforts to simply make data openly and freely available for unencumbered use by third parties. Government efforts in the USA, the UK and elsewhere provide clear examples of this trend, as do library-specific initiatives such as the Open Library. This is a variant of UC1 involving Linked Data.
This use case differs from UC1 because it is specifically about publication as Linked Data format whereas UC1 is about format neutral.
Part of use case: | Share your experience
Actors - Libraries, which MAY require institutional buy-in and MAY have contractual and licensing implications with respect to suppliers, partners, etc.
Part of use case: | Share your experience
Data involved - Potentially any library data, possibly combined (or linked) with other metadata (such as course titles). Typically records and fields (tags) for which the institution feels rights and licensing issues are sufficiently well understood.
Part of use case: | Share your experience
Data flow - Data are placed online, either within the institution or via some third party such as the Talis Platform. Data may be periodically refreshed, and it would typically be the responsibility of any organisation consuming the data to check for any updates.
Part of use case: | Share your experience
Does this require Open Data - There is no requirement for Open Data per se. However, if we presume that the rationale for publication is to ensure the widest possible dissemination then adoption of a generic open data license (see Rights and Licensing Issues) is the most effective way to make the set of potential uses unambiguous. Restrictive licenses are counter-productive, as is making the data available without some explicit statement regarding potential utilisation. Locally developed licenses and statements regarding use should be avoided where possible as, although perhaps open in spirit, these local variants complicate matters for those wishing to combine data from disparate sources.
Part of use case: | Share your experience
Current Examples - Libris, National Széchényi Library, Freebase
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Library bibliographic data will be linked into the wider web of Linked Data.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC3, UC4, UC5, UC6, UC7, UC15, UC16, UC17]; (3) Loss of future revenue [see also UC1]; (4) While there is currently some momentum behind the Linked Data movement, many of the expected benefits remain, to a large extent, unproven, and some commentators believe that the approach is too complex to gain widespread adoption.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - In keeping with the principles behind this act, 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.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Data transformed from MARC or local storage format to RDF, which is then serialised in a number of ways (e.g. N3, XML, JSON). Most commonly this would then be exposed via a triple store with a SPARQL endpoint, and via a RESTful web interface which would usually provide both human readable versions of the data (i.e. html pages) as well as machine-parsable data (i.e. RDF).

Key to this process will be choosing appropriate ontologies to represent the data. While there is some previous practice in this area, (see http:// dcpapers.dublincore.org/ojs/pubs/article/viewArticle/927), it is probably too early to see this as ‘best practice’ for representing bibliographic data as Linked Data. Common vocabularies used in current implementations are:

As libraries tend to hold information on non-bibliographic resources as well (e.g. audio-visual material), it may be necessary to represent these using more appropriate vocabularies (e.g. http://wiki.musicbrainz.org/RDF for recorded music).

A W3C ‘incubator group’ for Library Linked Data which is currently (May 2010 – May 2011) investigating “how existing building blocks of librarianship, such as metadata models, metadata schemas, standards and protocols for building interoperability and library systems and networked environments, encourage libraries to bring their content, and generally re-orient their approaches to data interoperability towards the Web” (http://www.w3.org/2005/Incubator/lld/)
Part of use case: | Share your experience
Lifecycle implications - Examples to date have merged the human-readable web interface to the library catalogue (OPAC) and the machine-readable RDF, with the implication that this is an up to date representation of the library catalogue, possibly refreshed daily or even more frequently.
Part of use case: | Share your experience
Hosting requirements - There are a variety of options, but the minimum would be space to store the RDF representation of the data, and a web server to serve data on request. However, when publishing this type of data it is becoming common to provide a SPARQL endpoint as well as a web interface, which further suggests the use of a triple store to host the data. An alternative approach is to outsource hosting to a third party, such as the Talis Platform.
Part of use case: | Share your experience
Existing systems impact - It is currently unlikely that existing systems will support publication of bibliographic data as Linked Data. It would be necessary to create the relevant routines to extract data from existing systems, transform into RDF, and publish either directly onto the web, or via a triple store.
Part of use case: | Share your experience
Skills demands - There is likely to be a steep learning curve for those engaging in the publication of bibliographic data as Linked Data. An understanding of both bibliographic data in traditional formats (e.g. MARC) and RDF will be required, which is likely to mean a high degree of collaboration between library staff and technical staff. A good understanding of http, configuration of web servers, and possibly triple store technology will be required, which implies a high level of technical expertise.
Part of use case: | Share your experience

03. Supply data for Physical Union Catalogue

Supply bibliographic records containing holdings data to a Union Catalogue service in order to enhance discovery, location and delivery services.

Description

Activity - The supply under open data license of bibliographic records containing holdings data to a Union Catalogue service in order to enhance discovery, location and delivery services for users, especially for special collections. This may also involve a collaborative or copy cataloguing opportunity [see UC11]. Compare with the variant approaches of UC4 and UC5.
This use case differs from UC4 because it is about the source library adopting open licensing to open up possibilities for exploitation of the data, whereas UC4 is about the Union Catalogue organizing the licensing.
Part of use case: | Share your experience
Actors - Libraries; the external union catalogue service (which may be a shared service)
Part of use case: | Share your experience
Data involved - Bibliographic records, typically containing holdings data and potentially use data
Part of use case: | Share your experience
Data flow - Bibliographic and holdings records are transferred from the member institutions to the service, where they are imported in to the Union Catalogue. The service provider may undertake some enhancement such as linking book jackets or improving records, and the enhanced records may be supplied back to the source institutions or be made available to all contributing institutions.
Part of use case: | Share your experience
Does this require Open Data - If the records are supplied under an open data license, the scope for exploitation by the Union Catalogue, contributing institutions, third parties and users will be unambiguous.
Part of use case: | Share your experience
Current Examples - We are not aware of examples based on open data, though this approach could be adopted by such as Copac and Suncat in the UK.
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; (3) Presence in a centralised union catalogue will increase visibility of library data to a wider audience.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Damage to institutional reputation through provision of substandard product by a third party [see also UC4, UC5, UC16, UC17]; (3) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC4, UC5, UC6, UC7, UC15, UC16, UC17]; (4) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC4, UC5, UC6, UC7, UC9, UC13, UC16, UC17].
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case requires the explicit transfer of records to a third party, and will typically be governed by some form of contractual relationship. Whether that transfer is classed as ‘use’ or ‘supply’ will depend upon the nature of the relationship between the organizations involved. See http://www.jisclegal.ac.uk/Projects/ TransferandUseofBibliographicRecords.aspx.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - All models require engagement with actual or potential union catalogue providers to decide most appropriate record format, although Union catalogue services are highly likely to be familiar with MARC format.
  • Model 1: A standard MARC export from the LMS, based on specified criteria. 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: Records exported from the LMS based on specified criteria transformed into one or more formats to make data as accessible as possible to a wide range of interested parties [see Use Case 16] Additional exports on a regular basis which represent either a full export or just changes (additions, updates and deletions) based on the original export.
  • Model 3: The use of OAI-PMH to harvest either Dublin Core or MARC- XML records with subsequent harvesting to create/update/delete records.
Part of use case: | Share your experience
Lifecycle implications -
  • Models 1 & 2: Regular supply of updated records, either by full export or changes (additions, updates and deletions) based on the original export.
  • Model 3: Continued running of OAI-PMH target.
Part of use case: | Share your experience
Hosting requirements - For Models 1 and 2, hosting may be the responsibility of the shared service; or there may be a requirement for local hosting, from which data can periodically be retrieved by the shared service. For Model 3, provision of an OAI-PMH target would be required.
Part of use case: | Share your experience
Existing systems impact - None other than for Model 3 for which existing systems would need to support OAI-PMH.
Part of use case: | Share your experience
Skills demands -
  • Models 1 & 2: Subject to LMS support of export of MARC records based on specified criteria, this should fall within the capabilities of a systems librarian. If ‘differential’ updates required by Union catalogue service, it would either be necessary for this function to be available in the LMS, or for some basic development to be done locally to produce differential update files (additions, updates, deletions). In the latter case this would require experience beyond simply running LMS reports, although should be within the capabilities of a systems librarian or local IT staff.
  • Model 2: An ability to transform data between library specific format and more generic formats. This may be achieved via a third party application or through some basic development undertaken locally. This would require experience beyond simply running LMS reports, although may be within the capabilities of a systems librarian or local IT staff.
  • Model 3: Running an OAI-PMH service. If this is provided by the LMS this would simply require configuration and should fall within the capabilities of a systems librarian.
Part of use case: | Share your experience

04. Allow Physical Union Catalogue to publish data

A union catalogue publishes bibliographic records as open data on behalf of its contributing libraries.

Description

Activity - The supply under open license of bibliographic records from a union catalogue on behalf of its contributing libraries. The open licensing and the open supply of records are undertaken by the union catalogue service. Compare with the variant approaches of UC3 and UC5.
This use case differs from UC3 because it is about the union catalogue organizing open licensing whereas UC3 is about the source library initiating the licensing.
Part of use case: | Share your experience
Actors - Libraries, the union catalogue, third parties
Part of use case: | Share your experience
Data involved - Bibliographic records, perhaps containing holdings and use data
Part of use case: | Share your experience
Data flow - Bibliographic and holdings records are transferred from the member institutions to the central service, where they are imported in to the Union Catalogue. The service provider may undertake some enhancement and de-duplication activity, with the resulting union database being made available to third parties for exploitation.
Part of use case: | Share your experience
Does this require Open Data - Not necessary, but if the records are supplied under an open data license, the scope for exploitation by the Union Catalogue, contributing institutions, third parties and users will be unambiguous.
Part of use case: | Share your experience
Current Examples - North Rhine-Westphalia Union Catalogue (HBZ); this approach could be adopted by such as Copac and Suncat in the UK.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - (1) The centralised union catalogue will take on aspects of infrastructure, cost and possibly risk regarding the publication of Open Bibliographic data; (2) Staff and students will have the opportunity to access an existing library service in a different way; (3) 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; (4) Presence in a centralised union catalogue will increase visibility of library data to a wider audience.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Damage to institutional reputation through provision of substandard product by a third party [see also UC3, UC5, UC16, UC17]; (3) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC5, UC6, UC7, UC15, UC16, UC17]; (4) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC3, UC5, UC6, UC7, UC9, UC13, UC16, UC17].
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case requires the explicit transfer of records to a third party, and will typically be governed by some form of contractual relationship. Whether that transfer is classed as ‘use’ or ‘supply’ will depend upon the nature of the relationship between the organizations involved. See http://www.jisclegal.ac.uk/Projects/ TransferandUseofBibliographicRecords.aspx.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Data are presumably provided to the union catalogue using some variant of MARC [see UC3], with the union catalogue service taking on any requirement to reformat for downstream reuse.
Part of use case: | Share your experience
Lifecycle implications - As institutions are simply granting a set of additional permissions to a union catalogue service with which they are already associated, there are no additional hosting implications.
Part of use case: | Share your experience
Hosting requirements - As institutions are simply granting a set of additional permissions to a union catalogue service with which they are already associated, there are no additional systems implications.
Part of use case: | Share your experience
Existing systems impact - As institutions are simply granting a set of additional permissions to a union catalogue service with which they are already associated, there are no additional lifecycle implications.
Part of use case: | Share your experience
Skills demands - As institutions are simply granting a set of additional permissions to a union catalogue service with which they are already associated, there are no additional staffing implications.
Part of use case: | Share your experience

05. Expose data for federation into Virtual Union Catalogue

Provision of access under open data license to bibliographic records through a virtual Union Catalogue service in order to enhance discovery, location and delivery services for users, especially for special collections.

Description

Activity - Provision of access under open data license to bibliographic records through a virtual Union Catalogue service in order to enhance discovery, location and delivery services for users, especially for special collections. This may also involve a collaborative or copy cataloguing opportunity (see UC11). Compare with the variant approaches of UC3 and UC4.
Part of use case: | Share your experience
Actors - Libraries; the external service (may be a shared service within the sector)
Part of use case: | Share your experience
Data involved - Bibliographic records, typically containing holdings data and potentially use data
Part of use case: | Share your experience
Data flow - Bibliographic and holdings records are made available to the central service by member institutions, where they are cross-searched to give users the appearance of a single Union Catalogue.
Part of use case: | Share your experience
Does this require Open Data - Not necessary, but if the records are accessed under an open data license, the scope for exploitation by the Union Catalogue, contributing institutions, third parties and users will be unambiguous.
Part of use case: | Share your experience
Current Examples - Canadian National Union Catalogue
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) Damage to institutional reputation through provision of substandard product by a third party [see also UC3, UC4, UC16, UC17]; (3) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC4, UC6, UC7, UC15, UC16, UC17]; (4) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC3, UC4, UC6, UC7, UC9, UC13, UC16, UC17].
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case requires the granting (whether implicit or explicit) of data access and usage rights to a third party. Whether that is classed as ‘use’ or ‘supply’ will depend upon the nature of the relationship between the organizations involved. See http:// www.jisclegal.ac.uk/Projects/TransferandUseofBibliographicRecords.aspx.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Z39.50, SRU, SRW, locally developed API?
Part of use case: | Share your experience
Lifecycle implications - Potentially significant, as local infrastructure needs to handle the overhead of every query passed along by the union catalogue.
Part of use case: | Share your experience
Hosting requirements - Potentially significant, as local infrastructure needs to handle the overhead of every query passed along by the union catalogue.
Part of use case: | Share your experience
Existing systems impact - Continued support and maintenance of the local target, plus development work to align with new requirements from the union catalogue.
Part of use case: | Share your experience
Skills demands - Staff concerned with maintaining the union catalogue are likely to possess all the necessary skills to maintain Z39.50-style targets, where these are well defined and provided by their existing system provider. Specific use cases may require local (or vendor) development work, with cost or skill implications.
Part of use case: | Share your experience

06. Publish grey literature data

The supply under open license of bibliographic records describing institutional grey literature.

Description

Activity - The supply under open license of bibliographic records describing institutional grey literature.
Part of use case: | Share your experience
Actors - Library, academic authors of grey literature, repository managers elsewhere in institution
Part of use case: | Share your experience
Data involved - Bibliographic records describing institutional grey literature; may also involve full text of documents and associated research data.
Part of use case: | Share your experience
Data flow - Data on grey literature collected from across the institution, typically in the context of an institutional repository.
Part of use case: | Share your experience
Does this require Open Data - Not necessary, although explicit open licenses for set of metadata, full text and associated research data will make use and re-use easier.
Part of use case: | Share your experience
Current Examples - University of Ghent, University of Southampton (ECS)
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - (1) Institutional researchers will be able to increase visibility of their work; (2) Colleagues and students will have access to material not available by other means.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC4, UC5, UC7, UC15, UC16, UC17]; (3) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC3, UC4, UC5, UC7, UC9, UC13, UC16, UC17]; (4) If ‘full–text’ items are included in the data, there is a risk that any publishers of the material may challenge the release as open data.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - Some grey literature comprises eprints and preprints for material published elsewhere; there is the potential for inadvertently contravening licenses and publishing agreements. Some grey literature comprises early results and analysis from research; there is the potential to dilute the impact of later publications, or to release contradictory results.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Dublin Core, for dissemination via an OAI repository?
Part of use case: | Share your experience
Lifecycle implications - Modest; infrastructure to support an institutional OAI repository.
Part of use case: | Share your experience
Hosting requirements - Relatively minor
Part of use case: | Share your experience
Existing systems impact - There is an ongoing requirement to encourage deposition and use.
Part of use case: | Share your experience
Skills demands - Configuring an OAI repository is relatively straightforward. Evangelising deposition into the repository is a harder and more of a long term task.
Part of use case: | Share your experience

07. Contribute data to Google Scholar

The supply under open license of bibliographic records containing holdings data to Google in order to enhance discovery, location and delivery services for users.

Description

Activity - The supply under open license of bibliographic records containing holdings data to Google in order to enhance discovery, location and delivery services for users.
Part of use case: | Share your experience
Actors - Library; Google
Part of use case: | Share your experience
Data involved - Bibliographic records containing holdings data. Google supports this for data published from link resolvers (aimed at electronic resources), the details are available at http://scholar.google.com/intl/en/scholar/libraries.html). Currently Google seems to only support links to library printed holdings via OCLC WorldCat, although it would seem logical that the current harvesting of electronic holdings information could be expanded to print holdings through negotiation with Google.
Part of use case: | Share your experience
Data flow - Bibliographic data, plus details of link resolvers etc, are provided to Google. Robots refresh Google’s crawl of the data ‘periodically.’
Part of use case: | Share your experience
Does this require Open Data - Many university libraries already allow Google to harvest holdings data from their link resolvers, so while Open data is not necessary, it would establish an interesting principle in the supply chain.
Part of use case: | Share your experience
Current Examples - Google Scholar
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; (3) Presence in Google Scholar will increase visibility of library data to a wider audience.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC4, UC5, UC6, UC15, UC16, UC17]; (3) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC3, UC4, UC5, UC6, UC9, UC13, UC16, UC17]
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - The transfer of rights, and associated licensing issues, are not always clearly described by Google. This may cause concern.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - The format Google currently support for institutional holdings information is documented at http://scholar.google.com/intl/en/scholar/institutional_holdings.xml.
Part of use case: | Share your experience
Lifecycle implications - Minor; provision of modest file storage to host periodic data dumps for crawling by Google.
Part of use case: | Share your experience
Hosting requirements - Relatively minor, unless local link resolvers etc are poorly configured and accept requests from all visitors
Part of use case: | Share your experience
Existing systems impact - Minor
Part of use case: | Share your experience
Skills demands - Working with existing vendors, local systems staff probably possess the necessary skills to modify link resolvers, produce periodic data dumps, etc.
Part of use case: | Share your experience

08. Publish activity data

The publication of library activity data, typically at ‘Title’ level, including the number of transactions such as loans by time period (e.g. Academic Year).

Description

Activity - The publication of library activity data, typically at ‘Title’ level, including the number of transactions such as loans by time period (e.g. Academic Year). This may involve links to user courses in order to support more finely tuned analysis (i.e. activity per Title per period per course). This data will typically be used to make recommendations to users (‘Users like you borrowed …’) and to provide management information (stock optimisation, shelf locations, short loan designation, purchasing recommendations – see UC9).

This is related to but does not include the harvesting of e-journal activity data from Link Resolver usage logs, as undertaken by such as the MESUR project and the ExLibris bX service.
Part of use case: | Share your experience
Actors - Libraries; individuals or organisations that wish to process and use the data
Part of use case: | Share your experience
Data involved - Bibliographic records (may be partial as the downstream applications may not require full records) containing activity data (typically loans, but may also be requests, downloads, searches)
Part of use case: | Share your experience
Data flow - Extract from catalogue and make generally available for download or supply directly to a processing organization. This is a one-way process.
Part of use case: | Share your experience
Does this require Open Data - If the records are supplied under an open data license, the scope for exploitation will be unambiguous; otherwise different licensing constraints may need to be applied depending on use.
Part of use case: | Share your experience
Current Examples - University of Huddersfield and others in the JISC MOSAIC project
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - (1) Greater use of library stock by undergraduates (as evidenced at Huddersfield); (2) better targeted purchasing of stock and electronic access arrangements.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Demand for harder to service data – for example, course linked recommendations (‘users like you’), sequential borrowing patterns (‘users borrowed next’), diverse activity (e.g. search as well as loan); (3) Concerns (founded or not) raised about potential misuse of ‘personal’ data.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case involves the transfer of some data to a third party. As bibliographic records need only contain enough data to identify the item uniquely (e.g. a minimum of ISBN and Title), there should be no significant issues with commercial bibliographic record suppliers. The more significant legal issues relate to Data Protection, and it will be important to follow normal data protection practices in order to ensure that unauthorized organizations do not gain improper access to personally identifiable data.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - MARC is not a useful format unless specifically demanded by a supplier. Data can be extracted in tagged and delimited formats readily exported from LMS or other logs. However libraries may consider publishing their bibliographic data in formats more accessible to developers; for example, the JISC MOSAIC project recommended an XML- based schema.
Part of use case: | Share your experience
Lifecycle implications - Involves the incremental supply of updated and new records. Annual or termly publication would suit most purposes other than the demands of students to know what their peers are doing right now (which may best be serviced locally from the LMS).
Part of use case: | Share your experience
Hosting requirements - The published data will be small but will still need to be accessible for download.
Part of use case: | Share your experience
Existing systems impact - Not all LMS systems log activity, even for loans; some libraries will need to turn on the logging; there may be demands to integrate with borrower course codes; not all activity takes place in the LMS, though the LMS is the recommended place to start.
Part of use case: | Share your experience
Skills demands - Subject to LMS support of a loans log, this will fall within the capabilities of a systems librarian. More ambitious integration with course codes or other forms of activity data may need additional skills.
Part of use case: | Share your experience

09. Supply holdings data for Collection Management

The supply of records containing holdings data to a shared service in order to support collection management.

Description

Activity - The supply of records containing holdings data to a shared service in order to support collection management and to optimize holdings. Libraries face increasing pressures on space, and initiatives such as the UK Research Reserve seek to enable holdings decisions on a larger scale than the individual institution. Holdings records (and some of their associated bibliographic information) are transferred to an external entity, which uses these records to inform decisions.
Part of use case: | Share your experience
Actors - Libraries, which MAY require institutional buy-in, and the external service (possibly a shared service within the sector)
Part of use case: | Share your experience
Data involved - Bibliographic records containing holdings data
Part of use case: | Share your experience
Data flow - Bibliographic and holdings records are transferred from the member institutions to the service, where they can be analysed. Whether these combined records are available for local management purposes or supplied back to member institutions depends on the service design.
Part of use case: | Share your experience
Does this require Open Data - Not essential, as use by the external service and potentially by the other partners can be closed.
Part of use case: | Share your experience
Current Examples - We are not aware of examples based on open data, though this approach could be adopted by such as UK Research Reserve.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Accurate and timely records supply will enable the shared service to become more optimal and will directly benefit the local library.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Coordination of the changes arising to holdings data in the local catalogue; (3) The shared service may use the records in a public search interface, taking traffic away from the local OPAC and duplicating arrangements with other shared services; (4) Increased visibility of collection leads to demand beyond ability to supply [see also UC3, UC4, UC5, UC6, UC7, UC13, UC16, UC17].
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case requires the explicit transfer of records to a third party. Whether that transfer is classed as ‘use’ or ‘supply’ will depend upon the nature of the relationship between the organizations involved. See http://www.jisclegal.ac.uk/Projects/ TransferandUseofBibliographicRecords.aspx.
Part of use case: | Share your experience

Practicalities

Data exchange formatting -
  • Model 1: A bibliographic and holdings MARC export from the LMS, based on specified criteria. Additional exports on a regular basis which represent either a full export or just changes (additions, updates and deletions) based on the original export.
  • Model 2: Supply of holdings data in an alternative (to MARC) format, possibly exported from the LMS, but also from other systems such as spreadsheets, ERMS or OpenURL resolver knowledgebases. Additional exports on a regular basis representing either a full export or just changes (additions, updates and deletions) based on the original export.
Part of use case: | Share your experience
Lifecycle implications - Regular supply of updated records, either by full export or changes (additions, updates and deletions) based on the original export.
Part of use case: | Share your experience
Hosting requirements - Either the responsibility of the shared service or local hosting will be required, from which the file can be retrieved by the shared service.
Part of use case: | Share your experience
Existing systems impact - None
Part of use case: | Share your experience
Skills demands - Subject to LMS support of export of MARC records based on specified criteria, this should fall within the capabilities of a systems librarian. If ‘differential’ updates required, it would either be necessary for this function to be available in the LMS, or for some basic development to be done locally to produce differential update files (additions, updates, deletions). In the latter case this would require experience beyond simply running LMS reports, although should be within the capabilities of a systems librarian or local IT staff.

Model 2 additionally requires (1) Ability to transform data between library specific format and to more generic formats. This may be achieved via a third party application or through some basic development to be done locally. This would require experience beyond simply running LMS reports, although should be within the capabilities of a systems librarian or local IT staff. (2) Ability to extract data from a variety of systems. This may be achieved via a third party application or through some basic development to be done locally. This would require experience beyond simply running LMS reports, although should be within the capabilities of a systems librarian or local IT staff.
Part of use case: | Share your experience

10. Expose holdings / availability data for Closest Copy location

Expose bibliographic data including holdings and potentially availability that can be used to provide a closest copy location service.

Description

Activity - Expose bibliographic data including holdings and potentially availability that can be used to provide a closest copy location service. There may be opportunity to include availability for print on demand and download as well as the number and status of physical copies. The service may be operated by a 3rd party or by a consortium at regional or national level.
Part of use case: | Share your experience
Actors - Libraries; 3rd party or consortium services at an appropriate level
Part of use case: | Share your experience
Data involved - Partial bibliographic records (or full depending on service set up) with holdings and perhaps availability
Part of use case: | Share your experience
Data flow - Involves provision of a service (e.g. API, web service, Z39.50 / SRU / SRW server) to enable the closest copy service to report availability in terms of holdings and / or availability. Alternatively (outside the scope of this UC) involves supply of data (and therefore low level of reliability in terms of holdings and availability).
Part of use case: | Share your experience
Does this require Open Data - Whilst not essential, if the records are supplied under an open data license, the scope for reuse both within and beyond closest copy service will be unambiguous. Look for reciprocal open data licensing before engaging with collaborative services operated by a third party.
Part of use case: | Share your experience
Current Examples - We are not aware of examples based on open data, though this approach could be adopted by any shared service.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Although there is no guarantee of any specific outcome of releasing this data, it could facilitate the emergence of location based services enabling researchers, students and others to identify closest copy to their current location
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) A ‘closest copy’ service, may not be well aligned with the realities of access on the ground; (3) Increased visibility of collection leads to demand beyond local resources ability to supply
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This use case requires the granting (whether implicit or explicit) of data access and usage rights to a third party. Whether that is classed as ‘use’ or ‘supply’ will depend upon the nature of the relationship between the organizations involved. See http:// www.jisclegal.ac.uk/Projects/TransferandUseofBibliographicRecords.aspx.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Z39.50, SRU, SRW or locally developed API
Part of use case: | Share your experience
Lifecycle implications - Potentially significant, as local infrastructure needs to handle the overhead of every query passed along by the union catalogue.
Part of use case: | Share your experience
Hosting requirements - Potentially significant, as local infrastructure needs to handle the overhead of every query passed along by the union catalogue.
Part of use case: | Share your experience
Existing systems impact - (1) Continued support and maintenance of the local target, which must be persistently available; (2) possible development work to align with new requirements from the locate service; (3) possible challenges relating to the catalogue entries for more ambitious implementations covering digital copies.
Part of use case: | Share your experience
Skills demands - Staff concerned with maintaining the external locate service are likely to possess all the necessary skills to maintain Z39.50-style targets, where these are well defined and provided by their existing system provider. Specific use cases may require local (or vendor) development work, with cost or skill implications.
Part of use case: | Share your experience

11. Share data for Collaborative Cataloguing

The development of bibliographic data through a collaborative partnership for the purpose of generating, improving and enhancing records.

Description

Activity - The development of bibliographic data through a collaborative partnership for the purpose of generating, improving and enhancing records. The Use Case assumes that this is being undertaken by a structured group of library partners for the mutual improvement of their catalogues, though the resulting records will be designated as open data and therefore be available for wider use. The effort may be coordinated or by a third party entity.

Services in which the collaborators are not restricted to libraries (or other professional organizations) should be considered as instances of crowd sourcing (see UC12).
This use case differs from UC12 because it is about a closed group of cataloguers and libraries whereas UC12 is about the opening up the cataloguing process itself.
Part of use case: | Share your experience
Actors - Libraries that wish to collaborate; perhaps a third party providing the overall service
Part of use case: | Share your experience
Data involved - Most likely full (but possibly partial) bibliographic records
Part of use case: | Share your experience
Data flow - Selective supply of current records and return of new / edited records.
Part of use case: | Share your experience
Does this require Open Data - Whilst not essential, if the records are supplied under an open data license, the scope for reuse both within and beyond partner catalogues will be unambiguous. Look for open data licensing before engaging with collaborative services operated by a third party.
Part of use case: | Share your experience
Current Examples - Biblios.net
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Collaborative cataloguing within an open data paradigm is likely to open up a range of potential economies and opportunities.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Standards agreed for catalogue records fail to meet local needs; (3) effort and resource required to coordinate across partners outweighs benefits and savings
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - In keeping with the principles behind this act, 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.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Such services have traditionally been based on the exchange of MARC and MARC XML records. Given open data licensing, the resulting records may be made available by the coordinating service in a wider range of developer friendly formats, including RDF.
Part of use case: | Share your experience
Lifecycle implications - The lifecycle of such efforts is potentially complex. Planning the ingestion of the collaborative outputs is especially important, including any remaining local QA.
Part of use case: | Share your experience
Hosting requirements - Hosting for editing and download will be the responsibility of the coordinating party.
Part of use case: | Share your experience
Existing systems impact - The LMS should support the logistics of this approach through MARC export and import options.
Part of use case: | Share your experience
Skills demands - Subject to the capabilities of the LMS, this will fall within the capabilities of a systems librarian.
Part of use case: | Share your experience

12. Supply data for Crowd Sourced Cataloguing

The supply of bibliographic data to volunteers for the purpose of improving and enhancing records.

Description

Activity - The supply of bibliographic data to volunteers for the purpose of improving and enhancing records; this may also involve the creation of new records. Such activity may be directed (e.g. volunteers being requested to focus on specific fields, or to add new records for a specified collection) or it may be opportunistic (i.e. volunteers invited to edit and add as and when they see fit). This Use Case assumes this is being undertaken to benefit the initiating catalogue(s), though the resulting records will be designated as open data and therefore be available for wider use. It will not necessarily involve a third party coordinating organization, though there are attractions in terms of process, quality and web-scale critical mass in such services.

Services in which the collaborators are restricted to libraries (or other professional organizations) are similar in terms of open data but significantly different in other respects (see UC11).
This use case differs from UC11 because it is based on the opening up the cataloguing process itself whereas UC11 is about open data benefits in a closed cataloguing collaboration.
Part of use case: | Share your experience
Actors - Libraries; individuals and organisations that wish to make a contribution; optionally third party coordinating services
Part of use case: | Share your experience
Data involved - Most likely full (but possibly partial) bibliographic records
Part of use case: | Share your experience
Data flow - Depending on the software available, the methods of version control, the activity may take place within the catalogue or outside the catalogue (both cases using a browser-based application) or it may involve the supply of records (directly to volunteers or through open access). Providing open access to the resulting ‘crowd sourced’ records may best be treated as a separate process, especially if there is an interim QA step.
Part of use case: | Share your experience
Does this require Open Data - If the records are supplied under an open data license, the scope for exploitation will be unambiguous and the incentive for improvement will be greater.
Part of use case: | Share your experience
Current Examples - Biblios.net, Open Library
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Unpredictably paced, variable quality records will require processing, the challenges of which can be addressed through a more directive approach to community engagement (see the community science work of Galaxy Zoo).
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) Reduction in the quality and authority of catalogue records; (3) effort and resource required to make use of crowd source data outweighs benefits;
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - In keeping with the principles behind this act, 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
Part of use case: | Share your experience

Practicalities

Data exchange formatting - For editing, a web interface seems preferable. If a dataset is to be released for editing, it may be wise to release a standard set of attributes (not a full MARC record) in a format that can be handled by the user (e.g. CSV, XML). The availability of the resulting records as open data (in a range of formats) is best handled as a separate issue.
Part of use case: | Share your experience
Lifecycle implications - The lifecycle of such efforts is potentially complex. Planning of the synchronization and release of the outputs is especially important.
Part of use case: | Share your experience
Hosting requirements - The data to be edited may need hosting as a download or a separate catalogue instance. The resulting published data will need to be accessible for download.
Part of use case: | Share your experience
Existing systems impact - The LMS will not necessarily support the logistics of this approach, though MARC export and import options (for example) may be sufficiently flexible.
Part of use case: | Share your experience
Skills demands - Subject to the capabilities of the LMS, this will fall within the capabilities of a systems librarian. Depending on the approach, a cataloguing website may also be required which will need careful workflow engineering.
Part of use case: | Share your experience

13. Supply data to be enhanced for own use

Supply copies of the library’s data in return for access to enriched metadata.

Description

Activity - The structured nature of library data makes it eminently suitable for automated enrichment in a variety of ways, from identifying alternative versions of a particular work (paperback, hardback, e-book, etc) to adding associated content such as book jacket images, tables of contents, and reviews. Where such enrichment is maintained by third parties, it is often easiest to supply those third parties with copies of the library’s data (even if just an ISBN list) in return for access to the enrichments.
This use case differs from UC12 because it is about exploitation of catalogue data by users without a return path to the library whereas UC12 is about a process intended to benefit the catalogues.
Part of use case: | Share your experience
Actors - Libraries, external services
Part of use case: | Share your experience
Data involved - It depends which enrichments are being sought, but typically some subset of the bibliographic record
Part of use case: | Share your experience
Data flow - Bibliographic data are supplied to the external service for matching and enrichment. Records containing the enhancements (or, perhaps, just links to those enhancements on a third party site) are then transferred back to the library. If it is an area of concern, libraries should ensure that they understand whether or not the external service will keep a copy of the original data.
Part of use case: | Share your experience
Does this require Open Data - There is no requirement for Open Data. Indeed, mingling of creative works (subjective reviews, book jackets), commercially licensed data (such as Table of Contents) and Open bibliographic data may have the potential to complicate downstream reuse by all parties.
Part of use case: | Share your experience
Current Examples - LibraryThing covers service
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Library systems supporting the enrichments will be more engaging, and possibly more informative.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) It will be too difficult to incorporate enrichments into existing systems; (3) Third party providers of enrichments will become scarce; (4) Third party providers of enrichments will not be sufficiently rigorous, leading to false matches; (5) Increased visibility of collection leads to demand beyond local resources ability to supply [see also UC3, UC4, UC5, UC6, UC7, UC9, UC16, UC17].
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - This is likely to involve an external organization and therefore the following considerations should be actively addressed ahead of selecting the service. (1) Does the institution own the enrichments in perpetuity (i.e. What happens when it stops paying if this is part of a subscription service?); (2) Does the external provider have any continuing right to hold or use data supplied to them by the library for enrichment? (3) Where can content be used? e.g. Book jacket image use within VLE? (4) What is the impact of integrating additional data with existing records, and how does this affect the rights relating to both individual database items, and the overall database.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - This will depend on the service engaged.
  • Model 1: Supply of a list of identifiers (e.g. ISSN, ISBN, OCLC Number) as simple text.
  • Model 2: Supply of one or more identifiers on a ‘just-in-time’ basis to an API, which returns enhanced data such as book cover or ToC.
  • Model 3: Supply of ‘stub’ (very short) records in MARC, or other format to be enhanced.
  • Model 4: Supply of MARC records to third party platform, where records and additional enhancements are hosted.
Part of use case: | Share your experience
Lifecycle implications - Model 2 has no implications. However, Models 1, 3 & 4 require regular supply of updated records, either by full export or changes (additions, updates and deletions) based on the original export.
Part of use case: | Share your experience
Hosting requirements -
  • Models 1 & 2: Typically very low. In many cases, book jacket images are not even hosted on institutional servers.
  • Model 2: Small amount of local hosting required for ‘stub’ records.
  • Model 3: Hosting provided by 3rd party.
Part of use case: | Share your experience
Existing systems impact - Models 3 and 4 have no significant impact. However, Model 2 is likely to require addition of HTML or Javascript to local record display. In some cases this is not possible within an LMS OPAC, although might be achieved through additional frameworks such as Juice (http://code.google.com/p/juice-project/).
Part of use case: | Share your experience
Skills demands - Integration of enrichments into OPACs and other systems may be more or less challenging, depending upon the system being used. Subject to LMS support of export of identifiers or partial or full MARC records based on specified criteria, the requirements of Models 1, 3 & 4 should fall within the capabilities of a systems librarian.
Part of use case: | Share your experience

14. Publish data for LIS research

The publication of library catalogue data for Library & Information Systems (LIS) research purposes.

Description

Activity - The publication of library catalogue data for Library & Information Systems (LIS) research purposes. Whilst the research may take place within the institution and elsewhere in the HE community, it may not be helpful to plan on that assumption. Specific research requests (both one off and recurrent) may specify data elements (e.g. MARC tags, Dublin Core attributes) and format (e.g. MARC, XML, comma delimited). This Use Case however focuses on general supply for open research use, the researcher being responsible for extraction of the required views.
Part of use case: | Share your experience
Actors - Libraries; individual researchers or organisations that wish to study the data (who may be fulfilling contracts for other entities)
Part of use case: | Share your experience
Data involved - Full or partial bibliographic records which may be required to contain holdings data; see also UC8 for transaction level research involving ‘activity data’.
Part of use case: | Share your experience
Data flow - Extract from catalogue and make generally available for download or supply directly to a researcher or organization. This is a one-way process.
Part of use case: | Share your experience
Does this require Open Data - If the records are supplied under an open data license, the scope for exploitation will be unambiguous and may cover use more generally; otherwise different licensing constraints would need to be applied depending on use.
Part of use case: | Share your experience
Current Examples - The British Library offers the British National Bibliography [over 3 million bibliographic records] as open data under a CC0 (Creative Commons Zero) License. CC0 was adopted in response to feedback from researchers that CC-BY-NC-SA (Creative Commons Attribution-NonCommercial-ShareAlike) License was too restrictive.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Open standardized publication would enable the library to address demand much more efficiently.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The nature of research funding and commercial market research is that freeing the data is unlikely to generate a flood of research demands. However there might be a risk that the institution is too readily cited in research without consultation over such as context.
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - In keeping with the principles behind this act, 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.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - In order to establish a standard release dataset, it may be wise to release full records, including holdings, in both MARC export and MARC XML formats.
Part of use case: | Share your experience
Lifecycle implications - Involves periodic re-releases. Annual publication would suit most research purposes.
Part of use case: | Share your experience
Hosting requirements - The published data will need to be accessible for download.
Part of use case: | Share your experience
Existing systems impact - None
Part of use case: | Share your experience
Skills demands - This will fall within the capabilities of a systems librarian.
Part of use case: | Share your experience

15. Allow personal use of data for Reference Management

The supply of bibliographic data under an open license to be used by library members (and other users) in reference management software.

Description

Activity - The supply of bibliographic data to be used by library members (and other users) in reference management software (e.g. using Zotero or EndNote).
Part of use case: | Share your experience
Actors - Libraries; Suppliers of bibliographic data to libraries; Library members/users.
Part of use case: | Share your experience
Data involved - Bibliographic records.
Part of use case: | Share your experience
Data flow - Bibliographic data are made available either through standard interfaces or as downloadable files of selected records in appropriate formats.
Part of use case: | Share your experience
Does this require Open Data - Data made available by the library for these purposes needs to be open to the extent that a third-party can take, store and reuse the data.
Part of use case: | Share your experience
Current Examples - The vast majority of University and Research Library catalogues already offer this functionality (e.g. COPAC http://copac.ac.uk/faq/#import) though not typically under an open license.
Part of use case: | Share your experience

Consequences of doing it as Open Data

What will happen? - Members of the library, and other users of the library catalogue, will be able to download records into personal reference management software, and other software that can make use of structured bibliographic data.
Part of use case: | Share your experience
Potential Risks - (1) Loss of control over institutional data; (2) The originator of elements of the bibliographic records challenges release as open data [see also UC1, UC2, UC3, UC4, UC5, UC6, UC7, UC16, UC17]
Part of use case: | Share your experience

Rights and Licensing Issues

Rights and licensing issues - The JISC Legal resource “Transfer and Use of Bibliographic Records” (http://www.jisclegal.ac.uk/Projects/ TransferandUseofBibliographicRecords.aspx) differentiates between ‘Make available’ and ‘Use’. If records are provided to users who are not library members, this is seen as a ‘Make available’ activity, with associated issues outlined by the guide. Agreements with suppliers of bibliographic data to the library should be checked to ensure they allow this use, and under what restrictions. For the library associating rights and licenses with the records being downloaded by individuals, clearly any licenses should allow reuse in a wide variety of contexts, which must include some level of re-publication of the information contained in the records to allow use of the resulting references and citations in published work.
Part of use case: | Share your experience

Practicalities

Data exchange formatting - Reference management software is generally capable of importing bibliographic data in a variety of formats, including both open and proprietary standards. Common formats for downloading records and importing into Reference management software include MARC, RIS (http://www.refman.com/support/risformat_intro.asp) and BiBTeX (http://www.bibtex.org/). Some Reference Management software packages also support searching catalogues using the Z39.50 protocol and saving records directly.
Part of use case: | Share your experience
Lifecycle implications - None
Part of use case: | Share your experience
Hosting requirements - None
Part of use case: | Share your experience
Existing systems impact - In the unlikely event of the existing system not supporting appropriate download formats for end users, this would need to be added. However, it may be that formats need amending to work with specific packages, or new formats may need adding to support specific packages. Again Z39.50 is widely supported in Library management systems, although some configuration may be required.
Part of use case: | Share your experience
Skills demands - Configuration of the library system to offer appropriate download and/or Z39.50 access should fall within the capabilities of a systems librarian.
Part of use case: | Share your experience

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

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

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

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

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

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