D-Lib Magazine
December 1999

Volume 5 Number 12

ISSN 1082-9873

International Information Gateway Collaboration

Report of the First IMesh Framework Workshop

Lorcan Dempsey, Tracy Gardner, and Michael Day
United Kingdom Office for Library and Information Networking (UKOLN)
University of Bath, UK

Titia van der Werf
Koninklijke Bibliotheek, National Library of the Netherlands
The Netherlands

(Point of Contact: Lorcan Dempsey, l.dempsey@ukoln.ac.uk)

 

The report is structured in the following main sections:

1. Introduction -- Some background information about the Workshop and IMesh itself.
2. A discussion of issues -- The body of this report takes the form of a discussion of issues that emerged over the three days of the workshop. These are presented here under the following headings: general issues; business issues; content and service issues; technology issues.
3. Recommendations and outcomes - Some specific activities were proposed.
4. Acknowledgments
5. References

---

1 Introduction

1.1 The first IMesh framework workshop

The "Subject gateway" has become a part of the lexicon of network information use in the research, learning and cultural arena. For the moment, we can say that it typically refers to a network resource discovery service that provides database(s) of resource descriptions created according to specific selection and quality criteria. A recent review of international subject gateway activity (conducted through Summer 1999) described over thirty subject gateways throughout the world outside the UK. There are also up to ten in the UK, giving an overall figure of approximately forty gateways that provide significant, quality-controlled services. The review suggested that there were particular concentrations of activity in the UK, the Nordic countries, the Netherlands, the US, and Australia [Kirriemuir, 1999].

In June of this year, approximately thirty-five delegates from twelve countries convened at the University of Warwick in Coventry, UK, to discuss their shared interest in gateways. The objectives of the workshop were to:

• explore the potential for international collaboration in (subject gateway) activity,
• identify useful points of contact,
• promote strategies which lever collective effort in mutually beneficial ways.

Or in other words, to share information, and to see what came up that usefully could be taken forward, individually and collectively.

Delegates had a policy, service or technology stake in gateway activity, and explicitly, were expected to actively participate in developing a collaborative agenda. Not all the initiatives represented had a specific "subject" focus. This is true also of wider subject gateway discussions, where participants often have a commitment to the creation of databases of descriptions of high quality Internet resources without having a specific subject focus. This has led to the parallel use of "information gateway". In this piece, we use the two terms "subject gateway" and "information gateway" interchangeably.

Details about the workshop and its delegates are available from the workshop website [IMesh workshop].

1.2 Background

IMesh is a loose association of subject gateway activity. Included are a mailing list [IMesh Mailbase], some informational web pages [IMesh website], and some collaborative activity. "IMesh" itself is a contraction of "international mesh" and is suggestive of mutually supportive activity. (The term was proposed by Nicky Ferguson.) The idea for an IMesh Workshop arose from discussions at the ECDL'98 Conference in Crete [Wiseman, 1998]. Norman Wiseman and Chris Rusbridge, of the Joint Information Systems Committee [JISC] of the Higher Education Funding Councils, secured JISC funding for this first workshop and asked the Resource Discovery Network Centre [RDN] to organise the event. In parallel, Susan Calcari, of the Internet Scout Project [ISP], agreed to advance discussions about a follow-up event to be held in the US at an appropriate interval.

2 A discussion of issues

Breakout sessions specifically addressed business, content/service, and technical issues as a way of raising general concerns, and their conclusions were revisited in plenary session. This section summarises issues; it is not intended as a complete record of discussion.

2.1 General issues

Several general questions were posed.

2.1.1 What is a subject gateway?

It was recognised that gateways would have some or all of the following characteristics:

• services based on resource descriptions
• high level of manual creation/intervention, often by information and/or subject specialists
• search and browse access
• collection development policy, supported by selection and quality criteria
• collection management policy, supported by maintenance and updating procedures.

However, for pragmatic reasons, it was decided not to insist on a general definition of what a subject gateway was, or to spend overmuch time discussing it. In practice, this meant that the community of services represented at the workshop defined, to a large extent, the boundaries of interest. There were some moments later where boundary issues were raised. For example, at one stage it was noted that most discussion broadly assumed public sector involvement while, in fact, there are several commercial services which match the above characteristics.

In summary, from a "naming" point of view, it was felt that the term "subject gateway" was useful in an indicative rather than a definitive way. As a label, "subject gateway" was sufficiently inclusive to be useful for jointly addressing a collection of services which had certain shared characteristics and challenges, but those services were not sufficiently uniform to make it a very precise label. In the context of IMesh, it was recognised that participation was open to anybody who wished to participate in a helpful way at this early and informal stage in its life.

2.1.2 Why collaborate?

IMesh is conceived as a venue for collaboration. It was recognised that inter-gateway collaboration may have two distinct broad motivations: (1) to improve the service provided to the end-user (the end user focus) and (2) to help improve the efficiency of gateways themselves (the service focus). Most of the specific reasons for collaboration raised at the workshop fell into one of these two categories. It was also recognised that if these benefits were to be achieved, structures and agreements for collaboration would have to be in place.

Helping to provide a better service to the end user

Improved inter-gateway collaboration could help provide a better service to the end user in one of several ways:

• Saving users' time and effort - Large or linked distributed databases with a minimum of duplication should be able to save users' time and effort that would normally be spent searching a number of gateways with different search interfaces.
• Broader collections - Where gateways collaborate, broader and more useful collections of resources can be retrieved.
• User requirements - With inter-gateway collaboration, there may be a more complete understanding of the needs of users, which could lead to the improved design of user interfaces and the integration of suitable subject indexing schemes and add-in services.

Helping to improve the efficiency and effectiveness of services

Gateways themselves also potentially benefit from improved inter-gateway co-operation. New gateways can build on the experiences and technological infrastructure developed (or adapted) by other gateways. Established gateways can also help spread the costs of developing a large database of resource descriptions. As part of this "service focus", the workshop identified some specific motivations for increased collaboration:

• Success stories - A major issue facing the gateways is that of sustainability: how to secure enduring support to allow longer term planning and continued operation. It would be useful to share successful strategies and models in this area. Arguments for support may be strengthened if models are available elsewhere.
• Sharing the costs of development and best practice - Efficient collaboration between gateways may lead to a reduction in costs, especially at the start-up stage and for labour-intensive tasks like cataloguing. Collaboration also may enable the sharing of best practice and the production of guidelines. Together these factors could potentially accelerate the development of new gateway services.
• Avoiding duplication of effort - (For example, in cataloguing) two or more individual gateways covering the same general subject area would probably each need to catalogue a common core of resources. Collaboration between these gateways would mean that any sites catalogued by one gateway would not need to be catalogued by another.
• Sustainability - A collaborative venture between two or more gateways may find it easier to achieve "critical mass" in the form of gateway size and number of users.
• Software development - Technical collaboration between gateways enables software development to be shared amongst sites, saving costs. Additionally, a range of gateways will have different requirements -- potentially contributing to the development of higher quality software with more general capabilities. Such an approach allows individual gateways to focus development effort on their specific requirements and offers reduced entry costs for new partners.
• Interoperability - collaboration between gateways means that implementations are likely to be based upon the consistent application of agreed technical standards. This leads to improved interoperability between gateways.

Potential costs of collaboration

At the same time, it was recognised that collaboration has potential costs as well as benefits.

• Overheads - Collaboration may result in saved time and effort in some areas, but may also mean increased costs in the form of meetings and other necessary communication.
• Loss of control - It is possible that some gateways would not be able to tolerate having incomplete control over the choices of the resources they describe, the technical and cataloguing standards used, etc. Current information gateways often contain many customised services, of which the database is only one. These additional services may be "lost" if one gateway is subsumed in another.
• Loss of competitive advantage - Gateways could be rivals for the same user market. Collaboration may not be in the interests of all gateways and could lead to a loss of competitive advantage for one gateway in comparison with other gateways.
• Quality of lowest common denominator - Where gateways are based on divergent standards, any resulting service that combined them would probably function at the level of the "least-good" service.

2.2 Business issues

Business issues were conceived broadly to include sustainabilty, user responsiveness, rights issues and collaboration.

2.2.1 Sustainability

It was clear that funding patterns varied in operation across the gateways. However, reliance on "soft money" -- project or research funding that is temporary, unpredictable, or fragile -- was common. This reliance created issues for long term planning, collaboration, and service development. Some gateways had commercial partners, some were part of a wider service, and some stood alone. There was a general interest in business planning, in sharing "success stories", and in appropriate institutional bases for activities. It would be useful to create a "body of knowledge" about transitioning from such "soft money" contexts to more sustainable funding environments.

2.2.2 User responsiveness

Individual gateways have collected data about use, and there is some investigation of user behaviour and the relationship of subject gateways to other services. However, it was recognised that it would be useful to know much more about who was using the gateways, in what ways they found them useful, and how they related to other information resources.

Shared approaches to PR and marketing were also thought to be useful areas for common attention. Individual gateways would benefit from general promotion of the gateway approach.

2.2.3 Rights issues

The gateways have created resources of significant value and are governed by different rights management frameworks. Longer term collaborative arrangements depend on appropriate agreement.

2.2.4 Collaboration

At one level, collaboration relates to "business" strategies, as strategic dependencies rely on a view of directions. However, at another level, where services are individually and collectively exploring their options on a number of fronts, opportunistic or tactical alliances and agreements may be very important.

There was agreement that collaboration would benefit from facilitating structures, but at this stage gateways were reluctant to incur the overhead that having very formal structures would involve. Typically, collaboration might develop on a bilateral basis or between small groups of initiatives.

2.3 Technical issues

The focus of the technical strand of the IMesh workshop was interoperability. The next challenge is to join services together in ways that add value, and to enhance the functionality of subject gateway software to meet ever-emerging requirements. Interoperability is necessary for the first objective in order to allow gateways using different software to communicate; interoperability is required if the second objective is to be achieved without unnecessary duplication of effort.

2.3.1 Observations

From a technical perspective, the main observations from the workshop are that:

• a variety of technologies are in use by subject-gateways;
• functionality is continually being improved due to user requirements and new research;
• standalone services need to be joined together in ways that add value.

From a technical perspective these observations mean that it is not the case that current software meets all requirements. There is a requirement to develop added functionality, to support interoperability in a scalable manner and to develop software that can be rapidly adapted to meet new requirements.

The IMesh Toolkit project [IMesh Toolkit] was announced at the workshop and an introductory presentation was given by Tracy Gardner and Chris Lukas. The IMesh Toolkit project is being funded under the NSF/JISC International Digital Libraries Initiative, and started in September 1999. The project partners are UKOLN [UKOLN], University of Bath; ILRT [ILRT], University of Bristol; and the Internet Scout Project [ISP], University of Wisconsin-Madison. The Toolkit project is intended to produce a consistent framework for the development of subject gateway software. The focus is on the sharing of both software and metadata. Where possible, the toolkit will build on existing and ongoing work (ROADS [ROADS], DESIRE [DESIRE], Isaac Network [ISAAC], and RDN [RDN]). One of the main aims of the project is to reduce the entry costs for new subject gateways, including reducing the effort required to support specialised or local functionality. A research thread will also run though the project to consider issues that arise in a distributed subject gateway environment. The toolkit will provide a basis for this research, and the research will provide input and validation for the toolkit.

2.3.2 Collaborative activities

A number of specific activities that would benefit from collaboration were identified by technical participants.

• Taxonomy of current practices - A study resulting in a document that captures current practice in subject gateway software, including architectural decisions that must be made, and available standards. Such a study could also provide the basis for a technical area on a website (possibly www.imesh.org) providing pointers to technical subject-gateway related information.
• Interoperability requirements analysis - The next step is to consider how systems built using different technologies can be made to interoperate in meaningful ways. An analysis of both the "interoperability points" (areas in which interoperability is desirable) and the options for interoperability at those points would be covered.
• Consensus-producing workshop - With the above information at hand, it was felt that it would be useful for the IMesh technical collaborators to meet and achieve a level of agreement for future work. Two key activities were identified:

• Consider the options for standardising on protocols within the subject gateway community. The standardisation of search and retrieval protocols at the API-level was considered to be of great importance and could provide a focus for initial work.
• Produce a set of recommendations for future-proofing current subject-gateway systems. This activity would address the concern expressed by a number of IMesh workshop participants that future technical developments would leave them without an upgrade path.

• Interoperability testbed and registry - The aim of this activity is to produce an environment in which collaborators can test software interoperability. This activity would depend on the interoperability requirements analysis and on decisions made at the consensus producing workshop; however, it would be possible to start an interoperability testbed based on technologies currently in use (as determined by the taxonomy of current practices). Additionally, a registry of schemas in use by collaborators (including metadata vocabularies and service profiles) would support registry-based software development.
• Producing shareable service provision components - A longer term goal would be to achieve interoperability at a lower level of granularity than systems communicating at their boundaries. An ideal situation would be the IMesh collaboration agreeing on protocols and/or APIs that would allow a number of functional components (e.g., providing particular ranking algorithms, user interface elements or metadata translation) to be developed by different collaborators using different (IMesh-compliant) software and to be re-used by other collaborators.

Note that there is no requirement for a standard set of tools for use in all subject-gateways. The need for local variation was recognised. The aim of these activities is to provide interoperability between systems, and sharing of software in cases where there are shared requirements.

2.4 Content and service issues

The focus of this strand was on gateway services themselves, how they are created, managed and used. The group covered the following issues in discussion of collaborative possibilities.

2.4.1 Support and dissemination

Existing dissemination and support activities were noted. These especially included the DESIRE and ROADS projects. It is important that new subject gateway providers who wish to participate in this emerging business area have relevant information available to them. Examples of items which are available to help them are practical guidelines, tools, recommended standards and conventions, and success stories. These activities are of course only one-directional, the most advanced and experienced subject gateways educating the newcomers, but this is seen as a pre-requisite for future collaboration amongst all players involved. It leads eventually to real content exchanges between peers, such as exchanging cataloguing formats, selection criteria, subject schemes. In this context, the idea of a "shared repository" of service documentation was discussed as a means for providing best practice examples but also for promoting data interoperability.

2.4.2 Service profiles

Elaborating on the idea of a "shared repository" of service documentation, the group identified the following categories of information/data that may be useful for collaborative exchanges.

• metadata in use by subject gateways (semantic sets)
• cataloguing rules applied
• example records
• subject schemes
• selection criteria in place
• intellectual property rights
• collection scope
• collection description
• resource types (public domain only, commercial also, full-text, software, multi-media, etc.)
• update frequency
• description of contributor's network
• collection management policies
• quality assessment
• target user group
• status of service (project, operational, etc.)
• minimum requirements for collaboration

Items continued to be added to this list during the breakout, and further items could be added with technical (e.g., protocol) or business (e.g., source of funding) focus. All this information is potentially of interest for parties seeking collaborators. To actually interoperate, data about the gateway and how to communicate with it is needed in a precise way. Such "service profiles" would be useful to support collaboration between subject services. If they were applied on a large scale, they could provide a systematic overview of existing services. If they were standardised, they could even support matching functionality and data-exchange functionality. Agreed schema for service profiles were accordingly thought to be a useful development.

2.4.3 Subject indexing and access

As a matter of course, subject-indexing and -searching are crucial to subject gateways. In this area, collaboration can help to enhance multi-disciplinary access, and to realise cross-searching and browsing of different collections, within the same subject area. Cross-lingual searching is closely related to this issue.

• Inventory - The breakout group identified the need to make an inventory of existing schemes (classification, controlled vocabulary, thesauri, etc.) and tools (mapping tools and crosswalks). It was noted that service profiles could provide for the inventory.
• Mapping - Mapping different schemes and controlled lists, however, was identified as a separate activity. It was clear to everyone that this activity is still a human and time-consuming effort, at least in the world of subject gateways and more generally in the library community. Possibilities for automatic mapping of (parts of) different schemes, on the basis of collection overlap were mentioned. Some figures were mentioned about overlapping collections (SOSIG and DutchESS: 30%; EELS and EEVL: very little overlap) but very little is known. Research in this area may open new perspectives for collaboration. The group strongly recommended that existing tools and concordances should be made widely available for re-use.
• Automatic classification - Methods and techniques for automatic classification need to be researched and developed. A better insight into the state of the art was also felt to be important.

2.4.4 Exchange/re-use of descriptions

The breakout group went on to discuss the issue of creating and updating resource descriptions. Again, in practice, this is mainly a human and time-consuming activity, and there is a broad consensus that ways can and should be devised to gain more efficiency. Some subject gateways are looking at ways to minimise descriptions to fit resource changes -- such that when the resource has been updated, it is not necessary to update the description. The group discussed, at some length, the sharing of records between service providers. Here again, overlap of collections can function as an important incentive for sharing records and re-use of metadata.

• Re-use of subject labels - It was noted that subject labels and keywords may be targeted to specific audiences and that the same resource may carry different subject labels for different target groups. In these cases re-use of subject metadata is not necessarily helpful.
• Re-use of formal descriptive elements - The possibilities for re-use of formal descriptive elements, such as title, author, and creation date, are, in contrast, much more obvious. By their nature, they are more stable: they do not change as long as the resource they describe does not change, and they are not dependent on external factors such as the collection they become part of, the audience they are presented to, and/or the content interpretations made by the cataloguer. These "formal" metadata elements could be derived from the metadata provided at the publishing stage (similar to the title page of a printed book). Such a shared metadata environment with publishers is being developed now for national bibliographic agencies [BIBLINK]. These national agencies have a task to record all that is published on a national scale. Increasingly, national libraries are also including electronic publications and digital resources in the National Bibliography and their deposit systems for long-term preservation and access. The "national bibliographic record" is produced according to well-documented standards and rules, and makes use of authority control files. They can be regarded as "trusted" metadata and "quality" metadata. In the library world, much of the bibliographic record-exchange is based on the re-use of these national records. Similarly, in the future, subject gateways could make use of the national records produced by National Bibliographic Agencies as a basis for their own descriptions. At the same time, they could point to the last-resort-URL of the version preserved in the national library deposit system. The group realised this was still very much envisioning an ideal future scenario, but it recognised the possibilities for fruitful collaboration between subject gateways and NBAs. It was thought to be interesting to explore existing national bibliographic control approaches in the networked environment, what it is likely that national libraries will do, what the "national intellectual record" for digital resources will look like, etc. Some "fact-finding" activity in this area seemed useful.

2.4.5 Combine subject indexing and harvesting

Combining harvesting services and subject gateways was identified as another interesting area for collaboration. (The possibilities of combining automatic techniques and manual methods have also been researched in the DESIRE project.) The automatic harvesting/indexing approach can be used by subject gateways for alerting subject specialists about new resources. The manually selected resources can in turn be indexed by harvesting/indexing robots, providing added-value to the search environment of subject gateways. The breakout group mentioned it would be useful to perform user evaluations in order to gain more insight into the added-value of this type of combination.

2.4.6 User interface

Research in the user-interface of subject services was listed as an activity area for collaboration. It was observed that all subject gateways have their own interface, with their own design and their own functionality and features, but that, at the same time, all subject gateways provide similar functions such as search and browsing environments. Especially in cross-searching and brokering environments, such great diversity of user-interfaces is not helpful to the end-user. Diversity only serves the purpose of differentiating between different features, not similar features. Uniformity enhances the ease of use of similar features.

2.4.7 User studies and usage statistics

All established subject gateways have conducted user surveys or have online forms for user feedback. This wealth of information could also fruitfully be shared between the gateway providers in order for them to learn from survey results. The results may not always be comparable, but they may underscore certain findings or put findings in another perspective. Findings may prove to be contradictory, raising new questions and providing more insight in user reactions. Providing best practice guidelines for conducting user surveys can be very rewarding.

Monitoring actual user behaviour is another area that can provide a better understanding of the user. All subject gateways keep log files and usage statistics. Sharing this data between strategic partners (between brokers and the services brokered to, for example) is very important for a better and more complete picture of usage data. Even if the data is not fit for sharing, the methods and tools used to analyse the data and to interpret the data can be shared. Establishing some basic level for comparison of statistics would be valuable too.

2.4.8 Collaborative activities

Having identified issues in various areas, the group expressed the motivation for collaboration on content and services in more general terms. The breakout group decided to formulate the motivation for collaboration in broad terms: "the main motivation for collaboration is to improve user-services". The group then went on to specify this broadly-defined motivation from two different perspectives:

• Service provider perspective - Service providers can benefit from collaboration in many ways. By sharing best practice, workflow, content-data, service delivery data, etc. they can improve performance and minimise duplication of effort.
• User perspective - Users can benefit from subject gateway collaboration in many ways. By sharing content and by co-operating on service delivery issues, subject gateways can provide access to broader collections, achieve more consistency, provide more user-friendly interfaces, and better meet user needs and understand the user in novel ways.

3 Recommendations and outcomes

The activities suggested by the Technical, Content and Business breakout groups were considered together and clustered into the following areas under which recommendations and outcomes were considered:

• technical development
• testbed activity
• registry and profiles
• organisational processes.

It should be noted that the recommendations reflect what the group felt was reasonable to take forward given available resources and the loose, cooperative structures through which the group worked. They did not address the full range of issues discussed at the workshop, or raised by breakout sessions.

Participants also were encouraged to offer material to the journal Online Information Review: the international journal of digital information research and use (formerly Online & CD-ROM Review) for the issue to be edited by Traugott Koch which is due out in February 2000.

3.1 Technical development

The technical discussion was influenced by the IMesh Toolkit project, through which it will be possible to support a number of the recommended activities. Appendix 1 discusses how the outcomes of the project will support these and other recommendations.

• Taxonomy of current practices - A study will be done that will result in a document that captures current practice in subject-gateway software including architectural decisions that must be made and available standards.
• Interoperability requirements analysis - A study is planned to consider how systems built using different technologies can be made to interoperate in meaningful ways. An analysis of both the "interoperability points" (areas in which interoperability is desirable) and the options for interoperability at those points would be covered.
• Interoperability testbed - The aim of this activity is to produce an environment in which collaborators can test software interoperability.
• Consensus-producing workshop - Two key activities were identified:

  • Consider the options for standardising on protocols within the subject gateway community. The standardisation of search and retrieve protocols at the API-level was considered to be of great importance and could provide a focus for initial work.
  • Produce a set of recommendations for future-proofing current subject-gateway systems.

• Peer review and validation of IMesh Toolkit deliverables - The IMesh community, initially via the discussion list, should be invited to review and validate IMesh Toolkit deliverables.
• Feedback on IMesh Toolkit APIs - The IMesh community should be invited to provide feedback on the APIs produced by the IMesh Toolkit project.

3.2 Testbed activity

It was recognised that initiatives needed to be tested in operation, and several testbed activities were proposed.

• Record sharing - The time-limited bulk exchange of data was suggested -- services would only find out what issues were faced with sharing data if they went ahead and did it. SOSIG [SOSIG] and ISP [ISP] agreed to experiment with such bulk sharing.
• Cross access - Sharing could also be achieved by federating access to several gateways. The RDN and OCLC agreed to explore searching across the RDN resource and the records created under CORC, OCLC's cooperative cataloguing project for Internet resources [CORC]. There was also some discussion between subject clusters of gateways at the workshop about cross access to their databases, and discussions would be taken forward. (Immediately following the workshop, a sample agricultural cross-search gateway, GardenGate [GardenGate], using ROADS was set up. This gateway acts as a front-end to the ROADS servers running on the BIOME hub in the UK and Novagate in Denmark.)
• Interoperability - discussed in last section.

3.3 Registry and directory

The value of maintaining information about services and activities was endorsed.

• Gateways - The RDNC agreed to make the list of gateways discussed in [Kirriemuir 1999] available as a database of descriptions.
• Registry - Some level of service profile was seen as an essential prerequisite for successful interoperation. DESIRE, IMesh Toolkit, and other projects were looking at registries and registry-based software development. A registry of schemas in use by collaborators (including metadata vocabularies and service profiles) was seen as a useful development and might be taken forward within those projects.
• Survey - In the interim, a survey form was drawn up on the final day of the workshop for recording subject gateway technical details. [Survey] Results will be made available once a significant number of registrations have been received.

3.4 Organisational process

• IMesh organisation - There was little desire to pursue further formalisation at this stage. There was a view that formalisation should be seen as a desirable consequence of, rather than as a precondition for, a higher level of activity.
• Keep talking - However, even though there was little desire to pursue formalisation, the benefits of active dialogue were endorsed, and Rachael Bower agreed to facilitate some structured discussion on the IMesh discussion list [IMesh mailbase]
• Share - The IMesh website should be used as a basis for sharing relevant materials, including business models, user survey/stats, best practice, success stories [IMesh website]. Dan Brickley and Rachael Bower agreed to discuss some tactics for generating discussion and sharing of information.
• User surveys - Koninklijke Bibliotheek, National Library of the Netherlands would be doing work in the area of user surveys, and Titia Van Der Werf agreed to coordinate some activity across gateways.
• Procure expert advice - The value of procuring expert business planning advice was recognised, as were the common challenges facing many of the gateways. This was discussed, but it was not clear if it could be taken forward in a shared way.

3.5 A research agenda

A number of research issues emerged. It was agreed that one way of making progress on these issues was to maintain a "research agenda" that could be a point of reference for gateways in terms of seeking support for bids, or lobbying for particular activities. A reference to the "IMesh research agenda" would be a signal that the value of a piece of work had been "certified" by relevant peer groups. The Resource Discovery Network Centre agreed to maintain the research agenda.

The following main topics were identified as suitable for study and as suitable for the start of an IMesh research agenda:

• An investigation of the value and costs of information gateways - Surprisingly little is known about the value and costs of these information services. Gateways differ widely in aims and scope, but a better understanding of the costs and benefits of gateways would enable improvements in future decision making.
• A study of subject indexing and access - Gateways routinely provide access to catalogued resources through a browsing structure based on a subject classification scheme or thesaurus. They also add subject keywords and terms from thesauri and subject headings to help with searching. Studies could enable a clearer understanding of how these features are used in the current generation of gateways and help with the development of improvements.
• A comparison of harvest-based and manually created indexes - Information gateways add significant value to their services through the manual creation of metadata but there will still be a continued use of automatic robot-based Web indexes. It is possible to link some of the features of harvest-based systems to information gateways, but a comparison and integration of harvest based and manually based systems is an area that needs more development.
• User interfaces - Further research is needed in the development of good user interfaces.
• Studies of gateway users - An improved understanding of information gateway users should be sought, based on the collection and analysis of user statistics and the carrying out of user surveys.
• Service profiles - The content and format of gateway "service profiles" need to be assessed.

4 Acknowledgments

The organisers are pleased to acknowledge the valuable contributions and sharing of experience by the delegates, whose ideas and reflections form the core of this report.

We are pleased to acknowledge the support of JISC in funding this workshop. Its planning was assisted by a small group of involved parties, to whom thanks are due. Birgit Kongialis and Hazel Gott of UKOLN ensured the smooth running of the event.

5 References

[BIBLINK] Biblink project website <http://hosted.ukoln.ac.uk/biblink/>

[CORC] OCLC Cooperative Online Resource Catalog <http://purl.oclc.org/corc>

[DESIRE] DESIRE project website <http://www.desire.org/>

[GardenGate] <http://www.net.lut.ac.uk/GardenGATE/>

[ILRT] Institute for Learning and Research Technology, University of Bristol <http://www.ilrt.bristol.ac.uk/>

[IMesh mailbase] IMesh mailbase discussion list <http://www.mailbase.ac.uk/lists/imesh/>

[IMesh toolkit] IMesh toolkit project website <http://www.imesh.org/toolkit/>

[IMesh website] IMesh website <http://www.desire.org/html/subjectgateways/community/imesh/>

[IMesh workshop] IMesh workshop website <http://www.ukoln.ac.uk/events/imesh-workshop-jun99/>

[ISAAC] The ISAAC network <http://scout.cs.wisc.edu/research/>

[ISP] Internet Scout Project <http://scout.cs.wisc.edu/>

[JISC] Joint Information Systems Committee of the Higher Education Funding Councils website <http://www.jisc.ac.uk/>

[Kirriemuir, 1999] John Kirriemuir, "A Brief Survey of Quality Resource Discovery Systems" <http://www.rdn.ac.uk/publications/studies/survey/>

[RDN] Resource Discovery Network website <http://www.rdn.ac.uk/>

[ROADS] ROADS project website <http://www.ilrt.bristol.ac.uk/roads/>

[SOSIG] Social Science Information Gateway <http://www.sosig.ac.uk/>

[SURVEY] IMesh Subject Gateways Questionnaire <http://www.roads.lut.ac.uk/survey/>

[UKOLN] UK Office for Library and Information Networking <http://www.ukoln.ac.uk/>

[Wiseman, 1998] Norman Wiseman, "International collaboration on subject based Internet gateways", D-Lib Magazine, October, 1998. <http://www.dlib.org/dlib/october98/10clips.html#GATEWAYS>

Appendix 1 - IMesh Toolkit Project outcomes and the workshop recommendations

The IMesh Toolkit Project outcomes potentially support recommendations in several areas, notably in the technical development area, but also in registries, profiles, and testbed activities.

There was general agreement that the IMesh Toolkit project was a valuable vehicle for moving forward the identified activities. This has benefits both to partners in the IMesh Toolkit project and to the wider IMesh community. For the IMesh community, it means that some of the activities mentioned above can be partially achieved within the existing funding framework of the IMesh Toolkit project. For the Toolkit project, collaboration with the wider IMesh community means input to, and validation of, its work. It was agreed that, where appropriate, the work being carried out within the Toolkit project would be made available to the IMesh collaborators for input and for peer review.

The IMesh Toolkit has a technology review as an internal deliverable -- the review is intended to cover issues similar to the taxonomy of current practices described above; however the focus will be on identifying software that can be re-used in the context of the IMesh Toolkit. Additionally, a technical review has been commissioned by the RDN. (This will be taken into account within the IMesh Toolkit project.) These reviews, and potentially others with IMesh involvement, could do much to fulfill the requirements of the proposed study.

Interoperability requirements will also be considered within the Toolkit project during the development of the architecture. These requirements would benefit from input from the IMesh community. The IMesh project will ensure that the wider community is involved -- for instance, by sending out structured questionnaires to interested parties and by making findings available for comment.

Consensus-producing was considered to be a suitable topic for a future IMesh workshop. It was also noted that it would be useful for the technical IMesh collaborators to meet separately, perhaps in conjunction with a related workshop. A consensus-producing workshop would require considerable preparation in order to be effective, some of this preparation fits into the IMesh Toolkit activity described above, but some additional effort would need to be found.

The IMesh Toolkit project intends to develop registry software that could support IMesh registry activity. In addition, the DESIRE project is currently involved in producing a registry of schemas and profiles in use within the DESIRE project; it may also be possible to incorporate IMesh-related entries into this registry. The IMesh Toolkit registry work will build on that work carried out within the DESIRE project. The IMesh Toolkit project would also be interested in participating in an interoperability test-bed, and it may be able to contribute with respect to the protocols and APIs in use within the Toolkit project.

Further into the IMesh Toolkit project, APIs will be developed. At this point, the Toolkit project will approach the IMesh community for collaborators. Organisations or projects that are involved in subject-gateway software development activity will be encouraged to make use of the IMesh APIs and to provide feedback to the IMesh Toolkit project. This will benefit collaborating projects by providing a framework upon which to build their software and will perform a validation function for the Toolkit project.

In summary, the IMesh Toolkit project needs to establish standard protocols and APIs. The project is able to investigate and propose interoperability solutions, but recommendations validated by a larger community will have more weight than those seen to be emerging from a single project with a small number of partners.

Copyright © 1999 Lorcan Dempsey, Tracy Gardner, Michael Day, and Titia van der Werf

Top | Contents
Search | Author Index | Title Index | Monthly Issues
Previous story | Next Story
Home | E-mail the Editor

D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/december99-dempsey