JISC

Integration

The DNER has the potential to provide real improvements in the presentation of JISC resources and associated services. The DNER can improve integration of the services in various ways (the power and importance of these cannot be over-emphasised):

• integration of access to existing services, through a variety of entry points tailored to appropriate communities rather than to the data owners, data suppliers or even data types.
• integration through enabled cross-searching (breadth versus depth searching)
• integration through linking to value-added services such as ILL, document acquisition transactions, etc, especially in a "joined-up" way where information is carried across appropriately and does not have to be re-keyed
• integration across domains, eg searching across different media types, curatorial traditions etc
• access to a wide range of sources through non-traditional interfaces

Elements of the DNER

Organisational elements to be involved in the DNER need further elaboration but probably include:

• JISC-funded resource providers. These will include the Data Centres (BIDS, EDINA, MIDAS) and other service providers such as AHDS, the Data Archive, NESLI and NISS, the Mirror Service, Digimap etc through their catalogues and document offerings. Resources in this context includes both information resources themselves, and metadata about information resources.
• Portals. These possibly include the subject portals, and the JISC or Central portal. There will also be the potential for local portals (hybrid library implementations), plus media-specific portals (eg image or video-oriented data services, Digimap etc), and possibly portals oriented to particular curatorial traditions (eg archives and museums).
• Third party content providers. There is a strong case for striking agreements with a wide variety of content providers, irrespective of whether their content is offered though a JISC-nominated deal, if it is valuable to and used by the community and would fit into the architecture. An example could include third party electronic journal aggregation services. Portals could potentially make their own decisions on the participation by these services, although there would need to be some minimum standards. Indeed, JISC may need to use branding to control use of the DNER name (whatever it eventually is).
• Infrastructure service providers, including existing inter-library loan (ILL) services such as LAMDA and BLDSC, the proposed "ILL" service for electronic documents, and other electronic delivery services. This could also include maps via Digimap, and census tables, which together illustrate the need for media-specific rather than general request and delivery mechanisms in this area.

The aim will be to try to add relevant information services into their rightful place in a carefully thought information provision architecture, rather than as now in more or less random association depending on historical accidents of contract negotiation. In this sense, the DNER becomes a structured aggregation of resources. "Place" here is used in a logical rather than a geographical sense.

Resource providers

Data Centres host datasets of interest to the JISC community. These include datasets arranged through JISC auspices, as well as those negotiated independently. In one sense, these datasets are the DNER in primitive form. However, the DNER vision foreshadows a much wider range of capability than merely a distributed set of datasets. The DNER should make these datasets available to users in appropriate combinations for various stakeholder groups. In order to achieve this, a standard remote resource access system is required. At this time, this will be Z39.50 in most circumstances, although other protocols such as WHOIS++ and LDAP will have their roles (a reasonable description of Z39.50 can be found at http://www.biblio-tech.com/html/z39_50.html and
http://www.biblio-tech.com/html/z39_50_part_2.html).

Although as shown below, Data Centres will continue to have a role as portals (and may continue to host the dominant form of access, direct to datasets via the native interface), in this context it is the data hosting nature of Data Centres which is relevant. Data Centres will be up-graded to provide Z39.50 targets to their datasets under the DNER.

There are licensing and other intellectual property issues implied by the DNER, such that Data Centres cannot provide open access to datasets. At this point, it is also worth noting that a trust relationship may be required between any portal and the resource providers it wishes to connect to, confirmed through some form of authorisation or authentication.

For the purposes of the DNER, it seems necessary to divide data into two types: broadly, metadata and information resources. Metadata includes bibliographic data as well as data describing non-bibliographic resources (eg maps, census and time series tables, images etc). Information resources include a wide range of end-use documents, ie "text" such as journal articles, digitised resources, and the same non-bibliographic data: maps, census and time series tables, images etc.

In some cases, users actually want to retrieve the metadata (so metadata are also information resources), and are either not interested in the actual documents, or expect to find them through some off-line process (eg through a visit to a library to borrow the book). In many cases and increasingly, however, the user actually hopes to retrieve the actual documents through an on-line process. In such cases, the user will first search the metadata, then choose from among the descriptions provided to them a number of resources they wish to obtain. While Z39.50 and other like protocols can be commonly applied to both the submission of a query and the return of the resulting metadata, the protocol is not necessarily suitable for the transmission of the full resources themselves. In certain cases, it will be more appropriate to include pointers to an alternative retrieval path (via HTTP or FTP, for example) within the metadata returned. The security (and non-repeatability) of this data path is as yet an un-resolved issue.

Third party resource providers would not in general be funded to provide the required interfaces. The appropriate interface capability would become part of the negotiating requirements for dataset provision and hosting. Third party resource providers are not eligible to bid under this RfP.

Portals

The user would access the DNER through a range of different access points, here termed portals. We can identify a number of different portal types. Some actual portals will be combinations of these portal types. It is worth emphasising the distributed nature of this approach to DNER interfaces, as well as the distributed nature of the target resources. Portals would in most cases provide Z39.50 origins in the DNER, although in some cases other protocols and interfaces may be used, including native and web-based interfaces.

JISC or Central portal

This is a cross-service access point. A user without specific subject or media alliances might be expected to start here. It may well be closely identified with and linked to the JISC web site. This portal would support a searchable catalogue of collection-level descriptions of datasets (cf UKOLN's ROADS-based pilot), and could transfer the user to a Data Centre (or third party dataset host) service for native/depth searching. The central portal should also offer access to (possibly a number of) cross-searching mechanisms. The AHDS Gateway is a useful illustration of this type of portal. It offers a cross-search, but also links direct to the AHDS targets to allow users to either view more detailed data or carry out more focused searches with localised, tailored, interfaces

Central and subject-oriented portals must handle the case where a particular dataset is not subscribed by the user's institution. It would be helpful if some interface conventions like the "greyed-out" service names could be used, giving users information on the existence of other services even if they cannot access them.

Subject-oriented portals

These would provide access specifically targeted to particular subject groups. They might very appropriately be encompassed within the RDN subject gateway hubs, expanding the range of hub activity from identification of collections of resources to searching within and across those resources. "Depth" versus "breadth" options might be offered: depth searching implies perhaps switching to the native search interface which exploits all the features of the dataset in full, while breadth searching might sacrifice that to extend the range of datasets searched, but at a reduced level of functionality and some blurring of meaning.

Here, the DNER services would be placed in context with other services relevant to the subject area, including access to quality Internet-based information, and possibly non-DNER commercially provided services. EEVL offers perhaps the best example of this kind of development.

It is possible the much-valued SuperJournal type of subject clusters could be re-implemented through the DNER.

Local portals

Local portals are essentially hybrid library developments, allowing tailored access to a selection of datasets of importance to an institution, plus integration with other locally licensed datasets and local products.

Systems should be set up in most cases to consult local resources first, eg the local OPAC or local CD-ROMs before external or charged services. There should be good links to local resources, eg electronic short loan collections.

Although the idea might appear in other types of portals, information landscapes linked to user and class profiles are likely to appear here. In the re-constructed SuperJournal example hypothesised above, local portals could allow these to be created on an individual basis.

There is also likely to be considerable variation in attitude to some value-added services, especially those with incremental costs. Where incremental cost services (such as ILL) are provided in any sense "free at the point of use", management of budgets etc would be critical issues best addressed through local portals.

It is worth noting here that Z39.50-enabled resources may be directly available to the suitably equipped user, without the need for going through a portal, subject to resolution of licensing and authentication issues.

Media-specific portals

These portals are oriented to the requirements of particular media types. An obvious prototype example is Digimap, designed from the ground to help the user find and obtain maps or data subsets based on digital mapping products. Another example might have been the proposed JISC Image Delivery Service, although in practice this might now be virtual. However, media-specific portals might also include video data, audio data, numeric data, dynamic data, etc. While there should potentially be strong inter-operability at the metadata/catalogue level (given suitable profiles, ie definition of common access points and result formats), there is currently much less likely to be commonality in the request and deliver functions.

Data Centre portals

This is the current approach, where the portal is usually restricted to the datasets offered by the particular Data Centre. Localised interfaces to resources (eg EDINA's own query screens for EDINA datasets) remain important and valuable, fulfilling a different requirement. This is the current "depth" option. These native interfaces could be enhanced to support cross-searching of other Data Centres' datasets, and also delivery of documents from other Data Centre document databases, etc. However at this stage, development of other portal types has priority.

Curatorial tradition portals

This category is included to cover portals oriented, for example, to the museum and archives communities. One example is the current HE Archive Hub procurement [ref]. There will be difficulties here which relate to differences of language (eg creator or artist rather than author), of profiles, and of services (eg object delivery of a Castle is not possible!).

Enriched interface portals

Although most interfaces to information resources are simply text-based, this is not always true (cf Digimap), and should not be assumed. This type covers portals which use novel or non-traditional aids to finding information. Examples might include a portal with a spatial access metaphor to non-spatial data (cf Alexandria Digital Library). Other possibilities might include voice-recognition, tune recognition, image-content-oriented searching etc.

Many of these technologies are on the horizon, and there is a potentially very interesting development programme possible in taking these emerging technologies and applying them in the context of the DNER. There is however no particular reason why Enriched interface portals should not also be other types of portals (as for example, Digimap is also a media-specific portal) but the category is included separately for the moment because of the need for substantial further development in this area.

Infrastructure service providers

As indicated, the idea is to link together various parts of the discover - locate - request - retrieve - use chain. It is essential therefore that infrastructure services allowing access to the actual text or information resources are provided. At their simplest, these will be inter-library loan or document delivery services, where "document delivery" is interpreted broadly.

15 July 1999