IESR is a registry of on-line databases in the JISC Information Environment. It smells a bit like ZeeRex.
An IESR record in general describes the Collection, one or more Services and the collection owner or administrator (Agent). Collections may support services using any or all the following means of access:
Resource providers need to supply and maintain descriptions of their resources.
The immediate future includes making the register available via more protocols, e.g. adding an OAI-PMH interface.
95% of all extant service description are currently just web pages!
Current version of metadata schema is 2.3. Fairly stable.
IESR is intended primarily for machine-to-machine use, although human users will no doubt also find it useful.
IESR records can also describe ``transactional services'' that don't provide access to a particular collection: e.g. OpenURL resolvers.
Every Entity in IESR (Collection, Service, Agent) is assigned a unique URI if it doesn't already have one. Entities are described by metadata expressed in XML. Where possible, this metadata is based on open standards, but some IESR-specific terms are necessary and are therefore added in an IESR namespace.
The IESR metadata profile for Collections is where possible consistent with the emerging DCMI collection profile. Various controlled vocabularies can be used. Collections have isPartOf and hasPublication links.
For Services, ZeeRex was not considered suitable (reasons to be discussed later?) so there is a broadly equivalent bespoke schema. However, Z39.50 collection descriptions do include a link to the service's ZeeRex record.
Agents were intially described using VCard, but in version 2 that was thrown away and replaced with another bespoke schema. Lots of NIH syndrome in this project!
Each entity also has administrative metadata such as creator, creation date, etc.
Current breakdown of registered services:
There is of course a human-facing web interface.
Z29.50 access is at z3950s://iesr.ac.uk:2227/iesr. Searching is via BIB-1. Results are available as SUTRS and XML (use element-set name iesr)
A ``composite collection record'' includes information about all services that provide access and all agents that either own the collection or administrate one of the services.
IESR can be used in ``portals'' to provide discovery of resource collections, facilitating cross-search etc.
An IESR-like service could be used as a general-purpose target database for Keystone Retriver in place of custom offerings such as the Library of Texas's TLDD.
Access to the IESR registry will soon be available for harvesting using OAI-PMH.
An OpenURL Resolver will be made available to resolve collection metadata into collection URLs - i.e. to find the collection based on information such as its name and maintainer.
Access to IESR will also be available via SRW (which was described rather badly :-)
There is also talk of a UDDI interface to IESR, except that no-one really knows what it is and no-one wants it.
Current metasearch systems do work, but in a way that creates problems for users, metasearch service providers and content providers. Many of these problems can be ameliorated by the widespread adoption of standards and particularly by moving away from human-facing HTML as the only way for content providers to make their data available.
The NISO Metasearch Initiative brings together all three kinds of parties to try to find solutions that meet the needs of all. There are currently three task groups:
[Lots of stuff, mostly pretty obvious, about collection descriptions and possible relationships between collections.]
Dublin Core Collection Description is supposed to address the discovery problem. The workin group was established in 2001 and has been active from 2003.
The draft DCCD profile does not simply define a set of DCCD elements, but draws together elements from six(!) namespaces:
Does this represent commendable elegance or grotesque over-engineering? Yes.
Continue issues pertain to the data model, date formatting, adminstration and ownership of the collections profile, etc.
This talk will back off from the details and instead take a long-term, UK-oriented, strategic view.
The JISC IE set the scope for IESR (which is after all a register of services participating in the IE.) What exactly does it mean to be ``in'' in the IE? No-one has ever nailed it down. For example, is the Nature RSS feed ``in'' the JISC IE?
The Grid Engineering Task Force is currently building a network of service registries: that is, a registry of registries or a meta-registry. Their work is based on UDDI; they are using jUUDI (pronounced ``Judy''), a Java-based plaform. Their focus seems to be on services rather than collections. Matthew Dovey is leading this work.
Library-portal vendors already include a service registry in their products in the form of a target database. So how do vendors see something like IESR? A useful source? A chance to offload some work? A competing product?
UDDI is largely driven by integration in e-Business. Public registries such as the one at www.uddi.org are ``completely unusable''. UDDI is perceived (rightly or wrongly) as complex, and software support seems to be available only in Java. Simpler uses of WSDL can be more successful, e.g. www.xmethods.com.
ELF is the JISC E-Learning Framework. A VRE is a Virtual Research Environment. These two intiatives overlap. They both tend to want to break up monolithic services into smaller ones communicating via REST or SOAP.
There is a gradual increase in the use of portal frameworks such as uPortal that use ``portlets''. This is leading to a need for registries of portlets, which can be viewed as services in something like the IESR sense. What is likely to emerge is that institutions will run their own local registries, to drive their own institutional portals.
We need to stop thinking of the IESR as a monolithic service, and instead imagine is as a DNS-like distributed service. What approaches are there to implementing this distribution?
We need to re-use existing sources of service- and collection-descriptions, e.g. translating ZeeRex records into IESR format.
SPP seeks to provide portal interfaces for RDN hubs, providing:
SPP has a collection searching portlet preconfigured with a set of collections relevant to the user, who can select a subset. This portlet can usefully use IESR to obtain target definitions and dump the hardwiring.
For the proof-of-concept implementation, SPP used only the human-facing parts of the collection description, e.g. dc.title, dcterms.abstract, dc.rights and iesr.logo.
[It's all pretty mundane.]
Has very broad goals to do with finding web-services niches and encouraging web-services implementations. NISO has a watching brief over VIEWS. There are two subcommittees, one on Authentication and Authorisations, and one on Metasearch. Both are currently at the ``what shall we talk about?'' phase. The web-site is www.views-consortia.org
[Broadly similar to Pete Johnston's summary.]
TG1: it is apparent that authentication and authorisation is still an unsolved problems: there is no silver bullet yet. The task-group hopes to produce recommendations that will change this.
TG3: Talis is not on this group, but is closely following it.
[Results of the NISO metasearching survey.]
Project Silkworm was established a few months ago to investigate the network effect and the value of the customer community, and to make best use of the community to deliver streamlined solutions. The mission statement is:
Silkworm is a pattern of working, a set of values and principles that people, products and services operate by in order to realise the shared value of community.
The first part of Silkworm is to establish a registry of all Talis's customers' Z39.50 servers and web interfaces. For Talis's purposes, service descriptions provide configuration data; collection descriptions enable discovery of service descriptions and discovery of the collections themselves.
Since pretty much all Talis's customers need connection information for many of the same big data providers - EBSCO, etc. - it makes sense for them share their configuration records.
Configuring targets can currently be done using one or more of a selection of existing ad-hoc registers:
The business of locating and configuring targets is, at present, laborious, error-prone and technically demanding. Talis want to solve this problem for their customers.
Talis potentially supports 101 Z39.50 targets, representing 24% of the UK's university libraries.
One of the values of collection description records is as a way of discovering services. It makes sense for users to download collection descriptions, make changes, contribute them back into the community, etc. [Richard didn't make this point, but the best way to facilitate this is to GPL the descriptions.]
Questions about how IESR could be generalised and distributed. I suggested a Zee-Rex like harvesting model as a means of propagating information changes.
Questions about subject thesauri, very long and dull.
Questions about the IESR model, in which one collection is related to multiple services, but not the other way round.
mike@shanks:~$ apm Off-line, battery status low (0:01:00)
Transmission ends.
--