Warning:
This wiki has been archived and is now read-only.

Use Case Linked Data and legacy library applications

From Library Linked Data
Jump to: navigation, search

Back to Use Cases & Case Studies page

Name

Linked Data and legacy library applications

Owner

Uldis Bojars

Background and Current Practice

Libraries are using various information systems, most of which currently do not use or support linked data. A new generation of linked data -enabled information systems is appearing. Some of these applications and their use cases are described in the use cases collected by the W3C Library Linked Data XG.

For this use case, let's consider a library that uses a number of information systems. Some are legacy or not linked data -enabled applications (e.g., an integrated library system, a resource discovery system). Other are linked data applications (i.e. they use or produce linked data) such as a digitized map archive or a linked data -enabled authority record database.

Let's assume that the majority of users prefer to access library information systems via a unified front-end user interface (rather than using many different user interfaces for each individual system) and that this front-end currently does not use or support linked data.

In such a scenario, people using the main front-end application (e.g. a resource discovery system) would not benefit from linked data produced by other, linked data-enabled library applications.

Goal

  1. ensure that users of legacy applications get access to and benefit from linked data introduced in other information systems within the library;
  2. help system developers evolve a set of library information systems, where some applications are legacy and some - linked data applications.

Target Audience

Users from the general public, system developers and architects.

Use Case Scenario

A user who is using the main library front-end application:

  • wants to access rich information available about records in [various] library information systems;
  • the system shows catalog metadata required but does not make available to the user the rich data about the entry found (because this data is provided by another system and the front-end was not developed to make use of it);
  • as a result, a user does not have access to rich information sought.

To convert this into a "positive" use case:

  • a user [of a front-end application] gets access to the rich information provided by the system that holds the information about resources a user is looking for (e.g. maps) even though the front-end application was not originally built to support this.

---

System developers have created pilot applications that (a) provide rich data about objects in the system; or (b) provide additional functionality not present in legacy applications. They aim to:

  • allow all users, including those of legacy applications, to benefit from the addition of these new applications;
  • limit the complexity within a set of information systems available at a library.

Application of linked data for the given use case

In this use case, the addition of linked data applications creates a challenge for system architects how to adapt legacy systems to make use of new linked data applications.

The use of linked data to address this challenge may differ in each individual case. One possibility would be to make a front-end application "transparent" to linked data, providing URLs to resources on linked data applications.

---

Assuming that various components of our library information systems start using / publishing linked data (e.g., an authority DB, and digitized newspapers and maps applications), how do we build / adapt other information systems within a library so that they make use of this linked data? In particular, if a legacy application is acting as a front-end to other library systems, how would this system use linked data provided by other systems? Out-of-the box, such system may not be linked data aware, but it would be a waste to create linked data applications (e.g., authority data enriched with additional relations, schemas, linked to other datasets) and then not use them in the primary user-facing system of the library.

Existing Work (optional)

Related Vocabularies (optional)

Problems and Limitations (optional)

The main question of this use case is how do we transition from pilot linked data applications to the use of linked data throughout library information systems.

Problems

How to adapt legacy applications to make use of new, linked data -enabled applications?

With the addition of linked data applications, some data may be duplicated between legacy and new applications. This problem refers to managing complexity mentioned earlier in the use case. If information is duplicated and may change in one or both information systems, how is information between these systems synchronized?

  • An example can be authority data which are present / managed both in a legacy application (e.g., an integrated library system) and in an experimenatal linked data application. Which system shall library staff use to maintain authority records, considering that the data in the legacy application need to be maintained while users are using it? How to avoid situation when records are updated in both applications or how to avoid conflicts if they are [updated in both]?

When shall developers use linked data as an interface between applications and when other methods (e.g., importing data dumps) are preferable?

Limitations

Legacy applications may be limited in what can be changed or how quickly the change can be made.

It is possible that new information systems acquired by libraries are not linked data aware. For example, policy may require libraries to acquire existing, proven applications for key library information systems. Until library linked data applications are ubiquitous, new purchases may also be "legacy" applications. If this assumption is true, the need to integrate legacy and linked data -enabled applications will be important for some time.

Related Use Cases and Unanticipated Uses (optional)

References (optional)