Interim User Requirements Report for the JISC Information Environment Service Registry

Synopsis: This document provides those working on the JISC IESR Pilot Project and the JISC IESR stakeholder and potential user communities with an overview of the user Requirement activities of the JISC IESR pilot project during the first half of its development

Author: Amanda Closier

Date: 15.09.2003

Partners: MIMAS, University of Manchester
The Cheshire Development Team, University of Liverpool
UKOLN, University of Bath.

Executive summary

This report details the initial requirements gathering phase of the JISC funded Information Environment Service Registry (IESR) pilot project. This 14 month pilot is a joint project between MIMAS at the University of Manchester, UKOLN based at the University of Bath and the Cheshire development team at the University of Liverpool.

The report documents the creation and circulation of a user requirements survey after the initial identification of key users from earlier stakeholder analysis. This stakeholder analysis is available from the IESR pilot project's website at http://www.iesr.ac.uk/stakeholdrep.html.

The report discusses and documents the responses that were received in reply to the User requirements survey. These responses defined a set of initial requirements which are included later in the report. The requirements gathering phase fed into the definition of scope for the pilot project which was presented at the Stakeholders' meeting in late June 2003. Full details of the scope of the pilot are included later in the report.

Particulars of the project's requirements gathering and dissemination activities are included, with details of the project's email list, publications and presentations having been included.

Table of Contents

1 Introduction
1.1 Purpose of this report
1.2 The JISC Information Environment
1.3 Shared Services Programme
1.4 The JISC IESR Pilot Project

2 Methodology
2.1 Identification of stakeholders
2.2 Dissemination activities
2.2.1 Email list
2.3 User requirements survey
2.3.1 Responses
2.3.2 Users
2.3.3 Potential User Meetings
2.3.4 Stakeholder Meeting
2.3.4.1 Scope of the IESR Pilot Project
2.3.4.2 Changes to the IESR Metadata (Version 1.1 from version 1.0)
2.4 Publications and Presentations

3 Requirements
3.1 User Requirements Survey Response Summary
3.2 Identified Requirements

4 Conclusions and Future Requirements Activities
4.1 User Requirements Survey
4.2 Further meetings
4.3 Feedback on templates
4.4 Feedback on pilot registry
4.5 Concluding remarks

1 Introduction

1.1 Purpose of this report

This report forms a key deliverable for UKOLN's contribution to the JISC Information Environment Service Registry (IESR) pilot project. It falls under Task 10 in Work Package 4 of the IESR pilot project's plan. UKOLN are required to produce some preliminary user requirements analysis and a report identifying the goals of the IESR by "contacting user communities, developing user scenarios and reporting on findings".

1.2 The JISC Information Environment

The development of the Information Environment is one of the JISC's current strategic activities. This is envisaged as an online environment where access to 'scholarly and educational materials' is made as easy and as relevant as possible for the UK HE and FE communities. One of the programmes supported by this development work is the Shared Services Programme. More information about the JISC IE can be found at http://www.jisc.ac.uk/whatwedo/themes/information_environment.aspx. At the time of writing the structure of the JISC IE is represented in Fig. 1 below (from http://www.ukoln.ac.uk/distributed-systems/jisc-ie/arch).

Fig. 1

1.3 Shared Services Programme

The Shared services programme encompasses those services that fall under the 'Shared infrastructure' area of Fig. 1. In essence the

"...programme aims to develop a suite of shared services that will provide machine to machine (M2M) interfaces that allow machines to survey the information environment for end users. The programme will do this by exploring what common technical standards, terminologies, description schemas and user profiles are required and by determining sustainability and management issues."

(http://www.jisc.ac.uk/whatwedo/programmes/programme_shared_services.aspx)

The Shared services programme sets out to ascertain the requirements for the operation of shared services within the JISC IE and reach an integrated technical solution. It aims to roll operate with developments in authentication and authorisation services and it aims to roll out full services from 2005.

Work under this programme is being undertaken through studies, scoping work and pilot service development.

1.4 The JISC IESR Pilot Project

The JISC IESR Pilot started in November 2002 and is due to end in December 2003. The work is being carried out between three centres. These are MIMAS at the University of Manchester, UKOLN at the University of Bath and the Cheshire team at the University of Liverpool.

The IE Service Registry was proposed as 'a machine-readable catalogue of the high-quality resources that form the Information Environment'. The idea is to enable portals and other services to discover which resources are available and appropriate for their users, and to supply information about how these resources are accessed, through a machine-to-machine interface.

The IESR pilot project set out to:

• Establish the requirements for a Service Registry
• Test a technical solution based on Cheshire II software
• Obtain metadata from JISC-funded services to populate the pilot registry
• Report findings and making recommendations about future developments

Throughout the development of the project the scope of the pilot has been more closely defined and details of what exactly the IESR pilot will attempt are given below. This reflects the iterative process of requirements gathering and specification that has been followed to date.

2 Methodology

2.1 Identification of Stakeholders

Potential stakeholders in the JISC IESR were identified through earlier work for the IESR pilot by Dr Verity Brack and her final report is available through the project website at http://www.iesr.ac.uk/stakeholdrep.html. A list of stakeholders was drawn up by the project and these individuals were then approached to participate further in the development of the IESR pilot. This list of stakeholders was expanded upon the recommendations of the existing stakeholder community and these new stakeholders were also approached to participate. The stakeholder analysis produced a list of interested parties who would either wish to stay informed of developments of wished to participate further. A key crossection of the IESR stakeholder community formed the basis of the IESR potential user community. In parallel with the identification of stakeholders for the IESR pilot, JISC approached several key stakeholders and asked them to produce collection and service descriptions for the pilot project.

2.2 Dissemination activities

2.2.1 Email list

As a result of the stakeholder analysis an email group (iesr-stakeholders@jiscmail.ac.uk) was formed for the identified stakeholders. Its archive can be found at http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A0=IESR-STAKEHOLDERS). At the time of writing there are currently 60 members of the IESR stakeholders jiscmail list. The purpose of this list is to bring together the IESR stakeholder community; to enable and encourage discussion; to publish project news and meetings and to facilitate contact between different stakeholder and user groups.

2.3 User requirements Survey

To investigate potential requirements of the user community of the JISC IESR a user requirements survey was developed. A series of 26 questions (see Section 3) were devised by the project team and the survey was circulated to those stakeholders who had indicated an interest (usually via the stakeholder questionnaire) in becoming more involved with the requirments identification.

The questionnaire sought to discover more about the specific needs of the IESR user community. In particular potential users were asked about: how the IESR could be used; existing service/collection descriptions; the IESR draft metadata; protocols; quality control and administrative issues and whether they had any specific requirements of the IESR.

A working draft of the IESR pilot metadata schema as developed in March 2003 was circulated with this survey to elicit feedback about its structure.

2.3.1 Responses

At the time of writing the IESR pilot project has had 16 responses back from the user requirements survey, some of which incorporate more than one service; for example both MIMAS and EDINA have submitted a combined response for all of their services. Another three responses are anticipated by early August 2003. The level of detail in each response varied widely. At the time of writing responses have been received from all of the key stakeholders participating in the pilot with the exception of one. However this response is anticipated shortly.

Whilst the pilot is limited in what it can achieve and only a handful of key service providers will directly contribute records to the pilot registry, input from other potential users has been crucial. Throughout the initial requirements gathering phase of the pilot many service providers outside the scope of the project have been approached and their input will feed into both the registry's development and the project's final reports.

2.3.2 Users

In the early stages of the pilot's development awareness of the Shared Services programme and potential middleware such as the IESR appeared limited. The stakeholder and potential user community seemed to be split between those who had considerable knowledge of current JISC developments and those who had no knowledge of the Shared Service programme at all.

Increased exposure to the IESR pilot through presentations given by project and JISC staff throughout the initial stages of the project at various key meetings helped to raise awareness in the project's potential user community. These meetings included the Collection Description Focus meeting at the British Library in March 2003 and the JISC Shared Services meeting at the University of Warwick in May 2003. As a result of this a number of late responses to our initial distribution of the user requirements survey were received and a second wave of users was identified. Other potential users were also identified by the original user group. The survey was then distributed to these organisations and this elicited a few more responses.

2.3.3 Potential User Meetings

In some cases it proved worthwhile to speak to some of the potential users individually and a short series of face to face meetings were held with some of these users to discuss their responses to the user requirements survey. It is envisaged that there will be further meetings with other stakeholders where they have specific requirements which require an in-depth examination of some of the technical issues arising from the development of the registry. For example some of the Geo services being developed by EDINA will pose a challenge to incorporate within the scope of the pilot and further discussion of how this might be done is taking place and will probably involve future meetings. This work is likely to be shared between UKOLN and MIMAS.

2.3.4 Stakeholder Meeting

At the end of June 2003 a stakeholder / user meeting was held at the University of Birmingham. Approximately 20 representatives from various projects and organisations attended.

2.3.4.1 Scope of the IESR Pilot Project

The scope of the IESR pilot project was announced formally after the initial consultation phase at the IESR stakeholder meeting. Descriptions to go into the pilot registry will be provided by the following six potential users in Autumn 2003.

• Arts and Humanities Data Service
• EDINA
• MIMAS
• Resource Discovery Network
• UK Data Archive
• UK Mirror Service

These users have been provided with funding to enable them to create descriptions for the pilot registry and of those listed currently the RDN is the only potential which is in a position to interrogate the pilot registry either dynamically or in batch mode. Representatives from all of the organisations funded to contribute records to the IESR during the pilot phase attended the meeting. However it is envisaged that other identified users should be in a position to test the pilot registry by the end of the pilot project's development.

The purpose of the meeting was to update stakeholders and potential users as to the progress of the pilot project and to provide an opportunity for discussion and input into the development process. Presentations were made by Andy Powell, Amanda Hill, Pete Johnston and Ann Apps. In the latter part of the meeting breakout sessions loosely based on two topics were organised, the results of which were fed back to the entire meeting at the end of the afternoon. These topics were a) Contributing data: procedures for submission; support; quality control and b) Metadata: requirements not already covered; granularity of descriptions and protocols.

The revised scope of the pilot was reported to the meeting and version 1 of the IESR metadata application profile was presented alongside some details on controlled vocabularies used and some examples. Details of the IESR pilot's metadata can be found at http://www.iesr.ac.uk/metadata/.

The day proved useful in bringing up issues not identified in the user requirements survey or in providing an opportunity for users to add more to their initial responses. The revisions of the metadata provoked considerable discussion and as a result of these discussions the following changes were consequently made.

2.3.4.2 Changes to the IESR Metadata (Version 1.1 from version 1.0)

1. Rights

All records in the IESR will be freely available for anyone to read. They will be governed by a Creative Commons licence (by-nc-sa) in their administrative metadata. Suppliers of data to IESR are agreeing to this licence, though it will not be required to be explicitly stated in input data.

This Creative Commons licence means:

Attribution (by): The licensor permits others to copy, distribute, display, and perform the work. In return, licensees must give the original author attribution.
Non-commercial (nc): The licensor permits others to copy, distribute, display, and perform the work. In return, licensees may not use the work for commercial purposes - unless they get the licensor's permission.
Share-alike (sa): The licensor permits others to distribute derivative works only under a licence identical to the one that governs the licensor's work.

See http://www.creativecommons.org for further information.

2. Collection metadata

2.1 Property rslpcd:contentsDateRange added
2.2 dc:subject with no encoding scheme is allowed to enable recording of very specific local keywords that are not in a standard scheme
2.3 JACS and HASSET are available as schemes for dc:subject
2.4 Property iesr:useRights added. This will record rights to use the data from the collection, such as terms and conditions. dc:rights will be used to record a copyright statement for the collection
2.5 The definition of rslpcd:hasPublication has been amended so that it includes general information pages and help guides about the collection

3. Service Metadata

3.1 dcterms:accessRights / authentication type is searchable
3.2 dcterms:accessRights / DNSDomain added replacing AthensPrefix to denote domain in which service is available
3.3 rslpcd:seeAlso added to record further information such as help guides about the service

4. Agent Metadata

4.1 Removed properties: address, postcode, country, fax. It was decided these are irrelevant for an electronic application. [Note that postcode, etc was of the agent - not necessarily giving any indication of where the collection is or what it's about.]

2.4 Publications and Presentations

Introducing the Information Environment Service Registry: 'In Brief' article by Amanda Hill in D-Lib Magazine, January 2003

Developing the JISC Information Environment Service Registry: article by Verity Brack and Amanda Closier in Ariadne, July 2003

Information Environment Service Registry: presentation by Amanda Hill at the Portals and Shared Services Programme Meeting 22nd - 23rd May 2003, Warwick University

3 Requirements

3.1 User Requirements Survey Response Summary

The following questions formed the user requirements survey which was circulated to potential IESR users for the IESR pilot project. 30 user requirements surveys were sent out to identified users. Of these 16 returns have been received: a response rate of 53%. However it should be noted that some of the responses represent more than one stakeholder as for example both MIMAS and EDINA produced a response from all of their projects and services.

1. How would you / your organisation /service you provide use the IESR? (Either providing descriptions, or as a user of the service)

100% response rate

Three respondents said they would use the IESR descriptions, three stated they would only offer descriptions whereas eight stated that they would both search the IESR for descriptions and supply descriptions of their services for the registry.

2. How do you envisage the IESR fitting in the workflow and/or development of your service(s)? Do you have dependencies on other projects/funding to get started on your use of the IESR?

100% response rate

Six respondents recorded possible limitations or restrictions on their interaction with the IESR which were to do with funding. Either they felt that their funding would run out before any interaction with the IESR pilot (and possibly any future development) could be usefully made or they felt they would need increased funding to allow them the resources to work on developing descriptions and configuring systems.

Three respondents called for clarification on what how the IESR might work and how it could be used.

Two respondents felt their organisations were not ready to participate in such development but may be later (i.e. towards the end of the pilot phase or in any further development work after the pilot).

3. What would be necessary to enable you / your service(s) to make use of the IESR?

88% response rate

Respondents felt that to enable them to make use of the IESR they needed to know more about the proposed protocols and interfaces (these should include a Z39.50/SRW search interface or OAI/UDDI); see examples of use; possibly need additional funding and have access to mappings and common standards. They also felt that the IESR should be able to ensure currency and completeness and have a human interface for checking records. One respondent wanted the IESR to ensure that duplication was minimised.

4. What other services do you see using the IESR? Do you have a view on priorities?

81% response rate

Respondents thought the other JISC Shared services for example Athens and a terminology service would be other services that would make use of the IESR and more than one respondent flagged up that integrating with Athens would be useful. Commercial publishers and institutional portals were the other services mentioned as possible users of the IESR.

5. Have you any existing descriptions of the services you make available?

94% response rate

Six respondents had some form of existing collection or service descriptions, five respondents had nothing. Four respondents indicated that these were either in the process of development or were under consideration.

6. If so what form do they take? What are the key elements of those descriptions?

63% response rate

There were a wide range of differing responses to question 6

• This would be in the form of an XML document with a happy mix of technical and descriptive information
• Based on RSLP Collection-level description format
• Semi-structured descriptions on the institutional website, and additional descriptions embedded within service websites. Key elements include name/title, electronic location. Based on the RSLP schema
• See http://www.edina.ac.uk/support/z-targets.shtml
• For our service level descriptions : connection details for Z39.50 (minimum as per Z directory.) At machine level ? no collection level details exposed.
• Title, description, access, URL, publisher (where applicable), funder. Other data is input such as period of collections deal.
• Each study that we hold has an online catalogue record and includes a number of elements. I suppose that the key elements are title, abstract and coverage but it?s difficult to say because it depends upon your interests.

7. In your experience / opinion do the metadata elements included in the IESR (draft document attached) so far record everything useful about your collection / service?

50% response rate

One respondent felt that the metadata elements in the IESR draft metadata version 1 did not sufficiently record useful detail about their collection / service whereas three respondents felt it did. Four respondents felt that more clarification on some of the metadata elements was necessary before they could comment.

8. Are any of the elements problematic? If so why?

50% response rate

It's hard to tell without seeing them being used in practice. It will probably be ones which have ambiguous descriptions on a form used to edit them, which is something that can't easily be discovered without seeing how those maintaining the data understand the interface they have to the metadata.

Some practical examples of this process in practice might be a useful way of describing the IESR, and consulting a wider audience about potential problems/omissions.

It would be interesting to know which of the element values (apart from the two date values) can be generated automatically (from service information/metadata i.e. OAI provides a base set of values in the identify request that could possibly map onto some of the fields or at least allow lookups) and which will have to be completed manually. If manual data entry is required what procedures would be in place to ensure the consistency and reliability of the data? What domains/taxonomy are defined for any of the fields?

Collection: Identifier (no universal schema given); Concept (We requires use of DDC to allow interoperability; Temporal coverage (ambiguous ? dates of manufacture, or dates of subjects) Administrative: Audience level (no relation to MEG) Owner/Administrator: Identifier (no universal schema given); Name (no normalisation indicated); Address (no safe way of extracting town for interoperability)

Service elements may not have been tested against full range of real-world entities, so may also be problems here.

Can't really say at the moment

Type of collection should have a way of representing media type eg for images and sound files.

One or two look a bit daunting. 'Service grounding' means nothing to me, I?m afraid!

JISC collecting area

For dc:subject we would prefer to use our own thesaurus, HASSET, which is similar to the UNESCO thesaurus. It would be a lot of work for us to map the terms we use over to another controlled vocabulary.

9. Do you feel that there is anything missing? If so what and how important would it be to you?

69% response rate

Respondents felt that the following was missing from the draft metadata :

• Detailed subject information
• Licensing and copyright information
• Detail about controlled vocabularies
• Somewhere to include a 'Service Logo'

10. Are there any elements you feel that should not be included? What are they and why?

38% response rate

There was a limited response to question 10 however one respondent felt that 'JISC Collecting area' should not be included within the metadata

11. Are there any elements you would not use? What are they and why?

38% response rate

Of those elements presented in the draft metadata some respondents felt that they would not use the following:

• Service Grounding
• Spatial Coverage
• Temporal Coverage
• JISC Collecting area
• Administrative metadata
• Educational level

12. Are you in a position to generate metadata for your collection(s) and/or service(s)?

94% response rate

Eleven respondents felt that they were in a position to generate metadata for their collection(s)/service(s). The others felt that it was possible for them to do so with some further work.

13. If not what is preventing you from doing this?

25% response rate

There were four responses:

• Time
• There has not been a perceived need to generate metadata and there would need to be a business case for so doing.
• How some services/collections might map onto the proposed model
• The need for guidelines and specific tools

14. What tools would you need to generate descriptions?

63% response rate

When asked what tools would be needed to generate these descriptions two respondents didn't know, two felt a web based tool would be sufficient, one felt either a web based or a local application could be useful, one felt some form of Excel template and one respondent felt that they could possibly export descriptions from an existing relational database. One respondent was concerned that some element of checking was built into any tool developed for this purpose.

15. In a web interface to the IESR which of the metadata elements included need to be displayed to an end user? Which need to be searchable?

81% response rate

There were a wide range of differing responses to this question :

I wouldn't want an end-user web interface. I want the IESR to be wholly invisible (too many 'ways in' to JISC services for the end user will do nothing but add to the current confusion over what's what, and what what's about! The IESR should be for services like institutional portals, selecting and prioritising on behalf of the user. The metadata may not be up to it, though?

This depends on the user envisaged by the service. If the intention is mainly to enable technical staff at institutions to set up connections to services, then all the metadata will need to be accessible. We note that the process of building usable metadata of this sort has had unexpected pitfalls at several institutions, even with commercially-supported products such as Metalib/SFX.

dc:title, dc:identifier, dc:description, dc:subject, language, access information, audience level, JISC Collecting Area, contact details (vcard:org, vcard:email), summary of service description information

This depends on what functions are being offered or are needed.

It may be useful to record whether a service enables searches by geographical co- ordinates.

Too complex to answer in detail but if some elements are not searched nor displayed, there seems little point in having them. Certainly all searched elements need to be displayed to show the user why they get the results they get.

All ? seems no reason to hide any.

Besides those indicated by the project already - Service Type, Access conditions, Authentication information, Service port, any of the Dublin core elements, some element(s) in Owner/Administrator ? possibly more.

Searchable ? keyword/free text, subject headings, title,

This is difficult to answer since it depends on the expected use of the IESR by end-users (and they will vary in their roles). Perhaps assume that the full record should be displayed and then decide on the fields not required (or which should not be revealed on other grounds)? In any case the Web interface should make use of the controlled vocabularies.

All the mandatory elements. Possibly all of them, but in terms of current needs: Title, Description, Access, Publisher/Creator, Date of license.

Title, description, type, concept, spatial coverage, temporal coverage, owner

16. Will you be using the IESR in machine to machine (m2m) mode? Do you expect to access the IESR using machine to machine protocols, if so which? (E.g. Z39.50, OAI)

94% response rate

Most respondents felt they would use the IESR in machine to machine mode and expected to access the registry via SOAP, OAI or Z39.50. Two respondents were not sure and one thought not in the next twelve months.

17. Or do you expect end users to access the IESR direct through a web interface?

88% response rate

Most respondents did not expect end users to use the IESR directly. Only one respondent thought they would whilst three respondents felt that that there was a possibility that end users might access the IESR both through the web interfaces and through portals depending on who those end users were. Two respondents were unsure.

18. Which protocols does your service(s) support?

75% response rate

Those protocols supported by respondents' services included Z39.50 (10) , OAI (7), SOAP (5), Open URL (2), RSS (1), SRW (1) and OGC (1).

19. Are you building services that are UDDI aware? (If so, how might we put collection description elements into UDDI? How do we ensure users only find IESR records at UDDI.org?

63% response rate

Four respondents replied that they were not developing services that were UDDI aware and four replied that support for UDDI was planned for future development. Only one respondent is currently developing some form of support for UDDI.

20. Are there going to be problems incorporating the IESR into existing portals?

69% response rate

There were a wide range of differing responses to question 20:

It's not necessarily going to be easy, but I'm not sure I'd say there will be problems.

Too early to say! But we would welcome a discussion on how it might fit into our work.

There may be a problem ensuring record integrity. If records are reused by a range of portals etc controls may be necessary to ensure that record integrity is preserved.

No real idea ? probably !

I don't forsee any significant problems

Not exactly sure what is being asked here ? but will likely need to reconfigure portals to take account of the IESR, or react to changes/updates to information in the IESR; and consider how we should utilise some of the new information that the IESR will contain. There may also be difficulties around correctly interpreting the IESR elements as already highlighted.

For one of our services the IESR will provide information about access points, but not how to perform the required searches.

No. Not if unique identifiers mapped to collections and these details published to the owners

Not if use standards approach, but depends whether vendors have developed OAI interfaces.

If the interfaces for a service are well defined and third party services such Athens are synchronised, it should not be a problem. Otherwise, some mappings will be required.

21. The IESR will make its records available as an OAI data provider. Would it be useful for IESR to partition its OAI repository into sets? E.g. by subject?

75% response rate

When asked whether it be useful for IESR to partition its OAI repository into sets and if so how (for example by subject?) five respondents thought it would be, three thought it might be, two had no view and two didn't know.

22. Would it be useful for IESR to write for example a perl script so that records from IESR could be harvested by portal via OAI and converted to local config formats?

81% response rate

When asked whether it would be useful for the IESR pilot to write for example a perl script so that records from IESR could be harvested by portal via OAI and converted to local config formats, four respondents said yes. Five thought it could possibly be useful but qualified their responses. One said no, one didn't know and one felt it was not applicable to their circumstances.

23. Is your service in a position to regularly update its collection descriptions if facilities were made available to do so?

94% response rate

When asked whether their service was in a position to regularly update its collection descriptions if facilities were made available to do so, twelve respondents said yes, one no and one felt it was not applicable.

24. What form of quality control procedures should there be in place to ensure the quality of descriptions remains high?

81% response rate

Respondents came up with a wide range of suggestions for potential quality control and administrative methods, full details can be found in the full response report.

Respondents were then given the opportunity to state any particular requirements they had of the IESR and to indicate priorities and timescales for these. A detailed list of the requirements that were documented from the user requirements survey can be found below.

25. Having answered these questions, do you have any specific requirements, which may affect the development of the IESR? If so, what are they?

50% response rate

26. In what time frame do they need to be incorporated into the IESR? (I.e. immediately, within the next 6 months, within the scope of the pilot or not until the development of a full IESR)

38% response rate

27. What importance do you place on this Requirement and why?

38% response rate

3.2 Identified Requirements

The following are a list of identified requirements of the JISC IESR. These are taken from the responses to the user requirements survey, the IESR stakeholder meeting and in discussions with individual users. Requirements are grouped together by priority and timescale.

Essential - Within the Scope of the Pilot

1. Technical documentation detailing standards, schema etc
First Organisation AHDS
Second Organisation

2. Examples of use. Details on how the Registry is been or may be used would be useful to help the AHDS determine what use they could make of the registry.
First Organisation AHDS
Second Organisation ANGEL

3. Dealing with the Geo services. This Requirement requires a deeper understanding of the nature of the services and so further consultation work is taking place.
First Organisation EDINA
Second Organisation

4. Collection descriptions must include classification number(s) describing content of collections.
First Organisation HILT
Second Organisation

5. Collection descriptions must include description of which subject schemes and/or classification schemes are used within the collection, and specify the version of that scheme.
First Organisation HILT
Second Organisation

6. A guide to good practice
First Organisation AHDS
Second Organisation

7. Descriptions should be maintained to ensure currency.
First Organisation InforM25
Second Organisation

8. Thesaurus 'Hassett' to be added to the list in dc:subject.
First Organisation UK Data Archive
Second Organisation

9. Dewey Decimal Classification number added to each record
First Organisation HILT
Second Organisation

10. Clarification is required on the creation of distinct descriptions for a) a service as an organisation; b) collections managed by that service; c) services offered by the organisation which enable access to collections (e.g. OAI, Z39.50, RSS etc).
First Organisation Humbul
Second Organisation

11. Comprehensive data creation guidelines/training.
First Organisation MIMAS
Second Organisation

12. Practical support for record creation and maintenance.
First Organisation AHDS
Second Organisation JISC Resource Guides

Desirable - Within the Scope of the Pilot

13. We may need to be able to distinguish sub-collections of a collection to provide an optimal level of service to users in respect of some services.
First Organisation HILT
Second Organisation

14. It must operate in M2M mode. It must be easily accessible and contain high quality, valid, timely and relevant data.
First Organisation TALIS
Second Organisation

15. M2m interfaces that fit with current structures in uPortal are available in the very near future as funding ends Feb 2004.
First Organisation PORTAL
Second Organisation

16. Collection descriptions may need to include a unique identifier for a collection.
First Organisation HILT
Second Organisation

17. IESR development should prioritise the provision of landscaping mechanisms for portals.
First Organisation PORTAL
Second Organisation

Priority not stated - Within the Scope of the Pilot

18. Must also support eGMS (http://www.e-envoy.gov.uk/oee/oee.nsf/sections/guidelines- metadata/$file/_Toc6128913).
First Organisation TALIS
Second Organisation

Essential - For Future Development

19. M2M soap interface.
First Organisation Humbul
Second Organisation

20. Manual checking of descriptions.
First Organisation MIMAS
Second Organisation

21. M2M relationship with access management services such as Athens.
First Organisation Humbul
Second Organisation PORTAL

22. Professionals to classify content of collections.
First Organisation University of Birmingham
Second Organisation

Desirable - For Future Development

23. It may be useful to record that a service enables searches by geographical co- ordinates
First Organisation AHDS
Second Organisation

24. Logo to be added to Service metadata. Specifically for OpenURL resolvers. They may wish to indicate a preference for the button shown to the user.
First Organisation MIMAS
Second Organisation

Essential - Timescale not stated

25. Recording of media types available to be described in record. To allow searches for example to find image repositories/collections or music repositories.
First Organisation SOSIG
Second Organisation

26. Records within the IESR should display some indication of the described service(s) status. ILRT displayed an interest in having access to logs generated by IESR on last known status of service targets.
First Organisation SOSIG
Second Organisation

27. Business case for a need to generate metadata about InforM25.
First Organisation InforM25
Second Organisation

28. Unique identifier for each service described and access to a people friendly description of that service for example access to a list of unique i.d.s and the corresponding titles of the service(s) described.
First Organisation SOSIG
Second Organisation

29. Information about licensing and copyright issues.
First Organisation ANGEL
Second Organisation AHDS

30. Detailed subject coverage description.
First Organisation SOSIG
Second Organisation PORTAL

31. Alerting service for updates to the registry. I.e. when a record is edited, created or deleted - all those using the records should be alerted.
First Organisation JISC Resource Guides
Second Organisation

32. Documentation describing the IESR and the interfaces provided.
First Organisation EDINA
Second Organisation

Desirable - Timescale Unknown

33. Checks on the information provided against the actual service described e.g. Z39.50 information should be checked against target.
First Organisation EDINA
Second Organisation

34. Automated prompt to review/update records within the registry.
First Organisation UK Data Archive
Second Organisation

35. Human editor for IESR records to act a as point of contact for support.
First Organisation UK Data Archive
Second Organisation

36. A 'human' interface would be required to pick out and check information on collections and services.
First Organisation EDINA
Second Organisation

37. Automated checking of described service's status.
First Organisation AHDS
Second Organisation Learning & Teaching Portal

38. Automated email system to send out messages to services indicating prolonged downtime periods. This would help avert problems where for example services are moved onto different machines but the record has not been updated.
First Organisation SOSIG
Second Organisation

39. There are only a few mandatory elements: some elements probably need to be mandatory in certain cases e.g. Administrator ? at least one of the contact elements should be required.
First Organisation EDINA
Second Organisation

40. Some form of editorial control/checks on the information provided.
First Organisation EDINA
Second Organisation

41. Checks on items such as machine addresses and port numbers.
First Organisation EDINA
Second Organisation

42. A contact point to refer problems to; with an expectation of quick resolution.
First Organisation EDINA
Second Organisation

43. Integration with Athens and other JISC services.
First Organisation PORTAL
Second Organisation Humbul

44. Ability to access the IESR via SOAP in addition to z39.50 and OAI.
First Organisation EDINA
Second Organisation PORTAL

45. Access to statistics to enable record revision where necessary.
First Organisation AHDS
Second Organisation

4 Conclusions and Future Requirements Activities

4.1 User Requirements Survey

It has become apparent after the return of the user requirements survey that further questioning of those users that have responded will be necessary to add more detail to their requirements. In some cases one to one meetings have already been held to refine and/or clarify initial requirements. In many case this is to discuss potential issues with technical implementation of specific requirements.

It will also be necessary to re examine user requirements after the initial testing phase where users will contribute records to the registry and then again after a working pilot registry has been accessed externally by one or more key user groups.

4.2 Further meetings

It is envisaged that future IESR stakeholder and user meetings may take place. These are likely to focus on the funded data providers for the pilot's duration but may be opened to the wider user community for evaluation purposes.

4.3 Feedback on templates

The IESR pilot has produced some templates for data providers to use to compile their own service and collection descriptions. There will be some overlap with the user support role at MIMAS but there may be revisions of existing user requirements after data created using these templates has been provided.

4.4 Feedback on pilot registry

Further requirements gathering will come out of the testing phase towards the end of the IESR pilot. It is envisaged that the second phase of the requirements gathering will focus on the key stakeholders and data providers for the pilot. The second half of the pilot will focus on the practical implementation of the service registry and as such another series of small meetings and possibly training sessions would provide further opportunity to revise requirements. This feedback will contribute to the Final Requirements Report for the IESR pilot project which should be available in early 2004.

4.5 Concluding remarks

There has been considerable interest in the IE Service Registry and the number of identified potential users has grown steadily. Whilst some of the requirements identified in the initial stages may not feed directly into the development of the pilot, it is envisaged that they will have an impact on any development of a full service registry.

The second half of the IESR pilot project will see the practical development of the pilot registry and the generation and contribution of descriptions to it. Feedback from the later stages of the IESR pilot will be recorded in a final requirements report at the end of the project.