D-Lib Magazine
December 1999

Volume 5 Number 12

ISSN 1082-9873

International Information Gateway Collaboration

Report of the First IMesh Framework Workshop

blue line

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, [email protected])

red line


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:

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:

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:

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:

Potential costs of collaboration

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

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:

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.

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.

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.

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.

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:

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:

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.

3.2 Testbed activity

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

3.3 Registry and directory

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

3.4 Organisational process

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:

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 <>

[CORC] OCLC Cooperative Online Resource Catalog <>

[DESIRE] DESIRE project website <>

[GardenGate] <>

[ILRT] Institute for Learning and Research Technology, University of Bristol <>

[IMesh mailbase] IMesh mailbase discussion list <>

[IMesh toolkit] IMesh toolkit project website <>

[IMesh website] IMesh website <>

[IMesh workshop] IMesh workshop website <>

[ISAAC] The ISAAC network <>

[ISP] Internet Scout Project <>

[JISC] Joint Information Systems Committee of the Higher Education Funding Councils website <>

[Kirriemuir, 1999] John Kirriemuir, "A Brief Survey of Quality Resource Discovery Systems" <>

[RDN] Resource Discovery Network website <>

[ROADS] ROADS project website <>

[SOSIG] Social Science Information Gateway <>

[SURVEY] IMesh Subject Gateways Questionnaire <>

[UKOLN] UK Office for Library and Information Networking <>

[Wiseman, 1998] Norman Wiseman, "International collaboration on subject based Internet gateways", D-Lib Magazine, October, 1998. <>

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

blue line

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

blue line

D-Lib Magazine Access Terms and Conditions

DOI: 10.1045/december99-dempsey