Ideas about Registries and IESR

Last week I attended two workshops held at the JISC offices in London: the Strategic e-Content Alliance Registries Workshop; and the Shared Infrastructure Services Workshop. These are various thoughts and ideas about IESR triggered by discussions at these workshops.

There was some attempt at the Registries Workshop to define a Registry. My offering, that was picked over by the meeting was: "A collection of official metadata records that describe, and assist access to, resources". On reflection, 'official' is not the right word, and suggestions included: governed, authorititive, etc. There was discussion about whether a registry differed from a catalogue or an inventory, but the workshop didn't come up with any significant differences.

A Registry for End Users. IESR's original remit was to be a middleware registry providing machine-readable (XML) resource descriptions to be used by other services. There was an initial requirement that IESR should not have a human-readable web interface at all. In fact, IESR does have a web interface, if only so that its content can be viewed by IESR staff, but it provides just a tabular view of the XML data. It is fairly apparent that so far IESR has no significant use of these machine readable descriptions. Maybe using a middleware registry in a dynamic way is too high a barrier for application developers, or maybe they prefer to choose resources to plug into their applications. Certainly IESR's lack of use is mirrored by the sparsity of machine interfaces into resources. It now occurs to me that it may be more sensible to change tack. IESR could be a registry for human readers that also has machine interfaces. This would correspond with other similar registries, which see their primary interface as being the web interface for human users. In the JISC IE technical architecture, 'service registries' are shown as components of the 'shared infrastructure'. But it doesn't seem unreasonable to me for IESR to also provide a service within the 'presentation layer' that is a web interface into the registry.

Surfacing hidden content. This should be one of the purposes of a registry. Surfacing more obscure and less popular content fits with the 'long tail' idea of Web 2.0. Clearly such resources need to be registered in IESR, but once there they will be discoverable. This does imply use of IESR either by people for general resource discovery, or by applications in a dynamic way. This purpose could be thwarted if IESR were used by application developers to cherry-pick resources to plug-in to their applications.

Advertising and promotion of resources. This is another purpose of a registry, which relates to the point above. I heard a presentation at the ELPUB2007 conference in Vienna about how content created by projects subsequently gets little, or sometimes no, use because no-one knows about it. Registering such resources in IESR would advertise their existence.

Collection descriptions are boring. They need to be embedded in other services for display to the end user. This would seem to present a challenge to IESR if we decide to provide a user facing web interface. Maybe we need two views, one for general resource discovery, and a second for application developer users. It would at least seem sensible to move technical details onto a subsidiary web page. Displaying transactional services would be a further challenge.

Funder stakeholder requirements. It is probable that funders as stakeholders will have some requirements on data descriptions and functionality in a registry. Currently the IESR data contribution model allows a Contributor to edit only those records that they have provided. But funder requirements may imply populating data fields across Contributors' records. In particular:

• There is likely to be a requirement to discover all resources funded by funding body. This implies the need for a new data field isFundedBy. This would be repeatable (there may be more than one funder) and expected to be provided where appropriate.


• There have been requests for a data field isEndorsedBy, which would allow a governing body to indicate which resources within the registry it endorses for use by organisations under its remit. This seems to be functionality on top of IESR. Possibly it could be an application run by the governing body. Alternatively IESR could consider providing this as an additional service on top of the basic registry, essentially an annotation layer.

Google indexing of registry content. There was some discussion at both workshops about whether registry content should be exposed to Google et al. Does this work against the resource in terms of Google ranking because its description is available both from the resource itself and from the registry? This problem would be compounded if records are shared between registries, when there would be even more descriptions of the same content indexed by Google. However the purpose of 'surfacing hidden content' would be aided by exposing it to Google by the registry. Possibly the answer is to expose primary registry content only to Google, i.e. resource description contributed directly to IESR, but not harvested records.

Perpetual beta. This is another tenet of Web 2.0, recognising that the online world is continually developing and changing. This seems to conflict with objectives to create official services with service level agreements and (often articifial) performance indicators. I guess the problem is that a service has to be paid for in some way and funding for a 'perpetual beta' is unlikely to be forthcoming.