IESR: A Registry of Collections and Services

Ann Apps, MIMAS, The University of Manchester, UK

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:

-   Currently many resource collections have only a Web search for
    humans. Encouragement from funding bodies for the implementation of
    machine interfaces is needed for an architecture designed for
    machine interoperation to be viable.

-   IESR is agnostic about service protocol and covers all those
    currently used in the Information Environment. At present there
    appear to be few SRU services available within this environment.

-   Contribution of technical service details to IESR appears to be a
    barrier. People who have the knowledge to catalogue their
    collections may not have the technical expertise to provide detailed
    service connection information. Possibly some automation in this
    area should be investigated.

-   Use of IESR is still largely visionary. Use cases and test-bed
    applications are required to demonstrate the practical value of the
    registry, and to aid understanding of the necessity of middleware
    and the possibilities it introduces.

-   The suggested dynamic use scenario would not be possible using Web
    Services SOAP. SOAP service interfaces are proprietary, their WSDL
    file describing the syntax but not the semantics of their request /
    response interface. Thus manual intervention is needed to plug a
    SOAP service into a workflow. One possible solution would be to use
    SRW, using ZeeRex to describe the interface semantics. The NISO Web
    Services and Practice Working Group is investigating
    interoperability of SOAP services.

-   IESR intends to investigate the capture of some authentication
    details for a service, in particular its Shibboleth attribute
    acceptance policy. Currently Shibboleth cannot be used in a
    machine-to-machine environment, requiring input from an end-user to
    assert their affiliation.

-   Sharing resource descriptions would be advantageous for reasons of
    both ensuring accuracy, and economy in their production. A
    description would be created by the resource provider, then shared
    by multiple applications and registries, with possible local
    augmentation. But this scenario implies the need for a common or
    derivable schema, a requirement that is satisfied by using
    standards. The standards-based IESR metadata application profile is
    also being used by the US OCKHAM project.

-   Sharing resource descriptions raises rights issues, unless the use
    of an agreed Creative Commons licence were universal.

-   Suggestions for federated or distributed registries solve some
    issues of scalability and data ownership, but lead to the problem of
    how to search across the resultant virtual registry, as discussed
    above.

-   Is there a requirement in the Digital Library domain for a UDDI
    compliant registry? UDDI is a standard for the discovery and
    publicising of services on offer, which matches IESR's remit. The
    provision of an IESR UDDI interface is under investigation but there
    is no clear requirement within the Digital Library community. This
    contrasts with the eScience community who are developing registry
    software (http://www.grimoires.org/), with both UDDI and additional
    metadata interfaces, to record SOAP Web Services, generally within
    projects and applications. UDDI is primarily used to register SOAP
    Web Services, although other service protocols can be described with
    some contrivance. It appears that mapping IESR data to UDDI will
    produce a partial view, losing some of the rich collection
    description detail, at least within the current version of UDDI.
    This obviates its use for sharing resource descriptions based on
    IESR metadata within a distributed registry model.

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.