[Mimas logo]"epub@mimas"

IESR: A Registry of Collections and Services

Ann Apps

Mimas, The University of Manchester.

Summary of presentation by Ann Apps at:
Workshop: Integrating Services - Integrating Standards, The Hague, Netherlands, 3 March 2006.

View PowerPoint Presentation


The UK JISC Information Environment Service Registry (IESR) (http://iesr.ac.uk) publicises collections of resources along with details of how to access them in a machine-readable format, intended to assist applications such as metasearch portals to serve their users' interests, with the ultimate aim of guiding users to appropriate knowledge. The development of IESR is funded by the Joint Information Systems Committee (JISC), which is responsible for providing and supporting ICT within universities and colleges in the UK. It is a central registry, a middleware shared service intended primarily for machine-to-machine use, within the architecture of the Information Environment. Project partners are Mimas at The University of Manchester, who developed and host the registry, UKOLN at the University of Bath and the Cheshire development team at the University of Liverpool.

Ann explained how the content of IESR is described, giving some examples of current descriptions, the services that provide access to the records in IESR, some possible ways in which IESR could be used, some future envisaged developments of service registries, and some integration issues that have arisen during the development of IESR.

The resources described in IESR are collections, services that provide access to the collections, and agent collection owners or service administrators. Digital data resources are described as collections using a metadata application profile based on current developing standards (the NISO Metasearch Initiative Collection Description Specification and the Dublin Core Metadata Initiative (DCMI) Collection Description Application Profile). "Backbone" searching over collections is provided via the Dewey Decimal Classification System. Services may be either `informational', which provide access to a collection, or `transactional'. Transactional, broker services play a significant role in the Information Environment without providing access to an explicit collection, for example an OpenURL Resolver or a SOAP Web Service within an eScience workflow. IESR describes services using a small set of bespoke metadata, primarily to support discovery, which is effectively a wrapper for more detailed connection information according to the appropriate standard for the service protocol. In IESR context a service has a single access protocol. Although IESR's primary purpose is to assist machine-to-machine applications, `web page' is included as a service protocol to support the many collections that provide only a human search interface. All IESR descriptions have associated administrative metadata to maintain provenance, and to assert a Creative Commons licence that reserves some rights over reuse (non-commercial, attribution required, share-alike).

The IESR API provides various services into the metadata descriptions, and further are planned, either by searching or harvesting, including a human web interface, and also a web-form Editor for registering resources.

IESR expects some of its users to be Digital Library portals, including metasearch applications. A dynamic portal could discover, then provide an SRU metasearch over, collections appropriate to an end-user, without the need for manual intervention to build resources into the portal, potentially widening the user's landscape of useful knowledge. Use of IESR descriptions by harvesting, or by human discovery preparatory to manually plugging a resource into an application, is also expected.

The scope of the IESR is not yet clear. For example, should the registry describe all resources of potential interest to the UK academic sector, or just those created within, or funded by, that community? For IESR to be of maximum benefit to end users it should also include descriptions of free resources, but it is not apparent who will provide these descriptions. Descriptions of commercial resources, for example electronic journal services, would also be useful. Should commercial publishers and aggregators be asked to describe their resources? Even within the current scope, IESR could include a wider range of types of resources, for example library profiles, eLearning resources, institutional repositories.

Expansion to an international landscape raises scalability issues if a single global registry were proposed. Current suggested solutions are distributed or federated registries, which consist of a set of nodes each describing their own resources, and possibly hosting their own registry. How would cross-searching over such a virtual registry be implemented? Metasearch would seem a high barrier for client applications, as would UDDI, even though this is part of its purpose. Possibly aggregated registries could be generated for searching by harvesting records from nodes, maybe selectively, e.g. by subject. The OCKHAM Digital Library Service Registry project in the US (http://www.ockham.org/), with whom IESR are collaborating, have a distributed model where each node describes its own resources, with replication to other nodes via OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting) harvesting in a `DNS-like' way, providing local searching of the entire registry.

Ann indicated various integration issues:

Thoughts after the Workshop

There are still many resources that do not provide a machine-readable interface. SRU is not very widely adopted or known about outside of the SRU cognoscenti who attended this Workshop and the SRU Users Group on the preceding two days. It would seem a good idea to advertise SRU as a low barrier, standard solution for the provision of machine access to resources.

Advertising SRU services in online directories would encourage their use and improve the general profile of SRU. The semantic interoperability provided by SRU should be promoted as a means to implement dynamic middleware solutions, which cannot currently be achieved by the apparently ubiquitous SOAP Web Services.

The information environment includes a diverse range of technologies. Attempts to persuade people to converge on a single service protocol are likely to be futile. Activities aimed at encouraging interoperation between services of different types would seem a better use of effort. The ability to discover within a registry a wide range of resources and their service connection details should assist in the eventual integration of different service protocols within a general service oriented architecture.

Creative Commons License This work is licensed under a Creative Commons Licence: Attribution Required; Non-Commercial; Share-Alike.

18 April 2006

[Go to Electronic Publishing at Mimas]Electronic Publishing          [Go to Mimas home page]Home Page          [Valid XHTML 1.0!]