Public Website                    

HEADLINE Project - Appendix A - Description of the Model

Last Modified: Thursday 19 February 1998 
 
• Presentation of Resources 
• User Profile
• Resource Components
• Gateway Resources
• Resources Database/Compendium
• Personal Environment
• Feedback Mechanisms
• Figure 1
• Delivering Information 
• Launch Mechanisms
• Delivery Formats
• Figure 2
The model for the hybrid library described in this proposal falls into two parts: the presentation of resources to the user, and the delivery of information. The description below identifies the main research/implementation areas of the project which, taken together, provide our interpretation of the tasks needed to develop the hybrid library. 

A1 Presentation of Resources

A1.1 User Profile

The user profile identifies the attributes of the user which can then be used to match against available library resources: specifically, the login process 
• authenticates the user (the technology will be aligned with JISC work on authentication, e.g. Athens)
• constructs, using MIS data, a profile of the user's role as it impacts on selection of resources (status, department, registered courses etc.)
• derives, using client domain identification, the user's physical (and/or logical) location to present an appropriate localised view of available resources
Besides individual user profiles, it will be possible to establish group profiles - e.g. a class or course module profile which might be drawn up via consultation between academic and library staff. An attractive design objective is a "group-ware" capability for a group profile, for instance a facility for members of a group to exchange information on useful sources and amend a group profile by inclusion of new source references. 

A1.2 Resource Components

The resource components are the real-world objects with which the library works: the catalogues, databases, applications, electronic services, Web resources etc. from which the hybrid library is made up. In addition to the data content, resource components may contain metadata, structural, formatting and service delivery elements, all of which add value to the data. 

Different resources provide different functions within the hybrid library, and pose different problems of integration: for example 

• catalogues and indexing and abstracting services used to identify material often stop short of providing access to the documents themselves
• primary full-text sources may not be well integrated with general purpose tools for locating material, e.g. archives specific to individual publishers, individual e-journal titles, institutional publications
• commercial intermediaries go some way to integrating information from different primary sources but may introduce new problems themselves in terms of their charging structures
• financial data services, in particular, are often rich in application-level functionality and thus not amenable to integration below the level of the application
• current awareness and some real-time information products operate on a "server push" model, with the focus on the proactive delivery of information to the user
• print resources need to be referenced electronically for inclusion within the virtual framework of the hybrid library
Inclusion of commercial resources is liable to raise copyright and licensing issues. One of the outcomes of the project should be improved understanding of possible models suitable for use in the context of a consortium. 

The concept of resource components can be extended beyond traditional library resources to include software, local teaching materials (including non-print media) etc. 

A1.3 Gateway resources

Some resource components can themselves act as gateways to other resources, for example Z39.50 clumps, or gateway or consolidation services provided by commercial intermediaries which provide a single access point to multiple resources (some of which may also exist in their own right). Seamless integration of related resource components so as to reflect the whole information search, locate and delivery process is central to the development of the hybrid library. 

A1.4 Resources Database/Compendium

The resources database provides (for each resource) the metadata associated with each component at collection level, and the information needed to manage and support its use. One function of the resource database is to facilitate publication of resource information to the Web and to provide a means of incorporating resource description meta tags, such as those provided in Dublin Core, in Web pages. The fields required are likely to include 
• resource ID
• links to documentation for the resource (user guides, reference documentation)
• resource categories (by subject(s), by type of material etc.) enabling the resource to appear in multiple listings
• standard description (cf. eLib work on collection level descriptions, Dublin Core meta tags)
• interoperability features, such as Z39.50 compliance or inclusion in clumps, enabling resources to be categorised by cross searching opportunities
• use profile, including both positive (e.g. groups likely to need the resource) and negative (e.g. any restrictions on use) factors
• resource location data (i.e. geographical/physical/client domain constraints)
• passwords (if any, typically associated with use profile)
• launch mechanism (see below)
• maintenance information (resource availability, messages re updates etc.)
• intellectual property ownership, copyright holder etc.

A1.5 Personal Environment

The personal environment is the primary access point to all resources available to a user at the institutional level, including library resources, software and intranet services, related to the institution's teaching and research activities. The database model of managing library resources described here enables an easy fit of library services into the broader institutional environment. 

From the library perspective the personal environment consists of the resource subset, containing those entries from the resource database relevant to the individual user, and the user view, presenting these resources to the user. The construction of the resource subset also takes into account the physical location of the user, recognising that immediate access to both paper and electronic resources may be location dependent. 

The resource subset is constructed by matching - using database queries - the user profile constructed at login against the use profile for each resource. This allows the user identification information for the resource (including ID and password, where applicable) to be constructed from the optimal configuration of information from the user and resource use databases, and then to be kept in the background resource subset database in readiness for use should the user wish to launch a resource. 

The user view is constructed from the categories element of the resources database. This provides a library-designed overview of how resources are organised, supporting multiple classification (by subjects, material types etc.) tailored to the needs of the individual user. This view can be expanded to list individual resources, together with further information from the resources database - e.g. user guides, standard descriptions, maintenance information - and the option to access the resource itself. 

A1.6 Feedback Mechanisms

The master resources database is itself included as a resource in the user view to enable the user to extend his/her range of available resources to any listed resource to which access is not restricted. This use can then be fed back into the user profile, and implemented in the personal environment. 

Data on resource use is collected using network tracking tools to create the feedback database. Uses include: 

• further tailoring the personal environment, by feeding information about previous resource use to the resource subset (for example highlighting and dating previous resource use)
• managing proactive communications from the library based on previous activity
• provision of management information about resource utilisation (including use of print materials), to inform institutional decisions about document supply, digitisation, subscription renewals etc.
These concepts are illustrated in Figure 1. 

A2 Delivering Information

A2.1 Launch Mechanisms

The resource subset constructed for each user on login can be used additionally to hold and manage securely essential access data (user ID and password information) required by certain services (e.g. BIDS via Web or telnet; IDEAL electronic journals), as an alternative to supplying each user with a list of IDs and passwords that is both confusing and open to loss and/or misuse. Different kinds of resources employing different formats or access protocols each require an associated launch mechanism that can use the needed access information as part of the launch process, without requiring separate user intervention or foreknowledge. The user-centred model outlined relies on a Web browser interface paradigm. This self-evidently facilitates simple launching of Web and other TCP/IP-based resources together with industry-standard ancillary programs (defined as "helper" or "plug-in" applications in the current browser model) such as Adobe Acrobat and other viewer or multimedia software. The three main launch scenarios may be defined thus: 
• opening a TCP/IP based resource (HTML documents; telnet, FTP sessions; email forms) from a URL: this mechanism can advise users of user ID and password required to access a resource, but cannot input them automatically and seamlessly
• launching searches across single or multiple (heterogeneous) databases (a Web to Z39.50 gateway for example; Web search engines; cf. also request interpretation tools, e.g. as created for the US Navy Virtual Library project)
• launching proprietary applications (e.g. DOS or Windows-based CD-ROMs, on-line services using custom interfaces, etc.)
Applications in the last category present particular problems when launched within the browser, notably security. Allowing a browser to run an untrusted executable file is an obvious security loophole. Moreover, the client PC may require the presence of essential resource files (i.e. .DLL files) and/or configuration files for successful launch of a Windows application resident on a remote server, for example. Viable current solutions to this and related problems can be effected by recourse to scripting languages and the w3launch utility. 

A2.2 Delivery Formats

Electronic services may deliver the information itself in electronic format as the end product of the search process. In these cases the system will need to ensure secure identification of the user to whom the resource will be electronically delivered (within the stateless and inherently insecure environment of the Web), using appropriate standards for encryption and identification. These are already being explored via other JISC initiatives and the project will track the latter to ensure conformity with practice elsewhere. 

Other outcomes include: 

• identification of information available in electronic format for a further charge (payment mechanisms/further approval required)
• information available in print on the library shelf
• information not immediately available but can be requested (ILL, reserve, order)
• combination of delivery options with time/cost variables (e.g. reserve from library, purchase from document delivery service)
The service environment presents the user with all the available delivery options for an item identified as a result of a search, and which is not available immediately in electronic format. The project investigates the use of digital object identifiers (DOIs) as a document retrieval mechanism across datasets. As a step towards the goal of an integrated fulfilment service this project also focuses on extending the range of user services currently available within automated library systems (reservations, requests, renewals etc.), for example 
• use of DOIs in document delivery
• development of in-house document delivery services for print materials
• management of cross library requests (LBS/LSE/UH)
• integration with interlibrary loans (especially LAMDA)
These mechanisms are illustrated in Figure 2. 

Top of page 
Back to Home page 
Forward to Appendix B - Details of Project Plan