June 2-4 1999, University of Warwick
Lorcan Dempsey, Tracy Gardner, and Michael Day (UKOLN,
University of Bath, UK)
Titia
van der Werf (Koninklijke
Bibliotheek, National Library of the Netherlands, the Netherlands)
Version 0.8
Limited circulation draft for comment
The report is structured in the following main sections:
Introduction - Some background information about the Workshop and IMesh itself.
A discussion of issues - The body of this report takes the form of a discussion of issues which emerged over the three days of the workshop. These are presented here under the following heads: general issues; business issues; content and service issues; technology issues.
Recommendations and outcomes - Some specific activities were proposed.
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 which 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 99) 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 which 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 in Coventry, UK, at the University of Warwick, 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, to see what came up and could usefully be taken forward individually and collectively.
Delegates had a policy, service or technology stake in gateway activity, and were explicitly 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 interchangeably.
Details about the workshop and delegates are available from the workshop website. [IMesh workshop]
IMesh is a loose association of subject gateway activity. There is 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, 98]. 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.
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.
Several general questions were posed.
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 assumed broadly public sector involvement, while there are in fact several commercial services which match the above characteristics.
In summary, from a 'naming' point of view, it was felt that 'subject gateway' was useful in an indicative rather than a definitive way. It 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 helpfully at this early and informal stage in its life.
IMesh is conceived as a venue for collaboration. It was recognised that inter-gateway collaboration may have two distinct broad motivations: to improve the service provided to the end-user (the end user focus) and 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 categories. It was also recognised that if these benefits were to be achieved, structures and agreements for collaboration would have to be in place.
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 leading to the improved design of user interfaces and the integration of suitable subject indexing schemes and add-in 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. It also enables the sharing of best practice and the production of guidelines based on this. 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 all 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.
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 not having complete 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 all their interests and could lead to a loss of competitive advantage 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.
Business issues were conceived broadly to include sustainabilty, user responsiveness, rights issues and collaboration.
It was clear that there was a variety of funding patterns in operation across the gateways. However, reliance on 'soft money' - project or research funding which is temporary, unpredictable or fragile - was common. This 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.
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, 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.
The gateways have created resources of significant value, and are governed by different rights management frameworks. Longer term collaborative arrangements depend on appropriate agreement.
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 any very formal structures would involve. Typically, collaboration might develop on a bilateral basis or between small groups of intitiatives.
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.
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 starts 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 sharing of both software and metadata. Where possible the toolkit will build on existing and ongoing work (ROADS [ROADS], DESIRE [DESIRE], Isaac Network [ISAAC], 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 considering 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.
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 capturing 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 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. 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 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.
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.
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.
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.
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 was however, 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 important.
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 the sharing of records between service providers, at some length. 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. They are by their nature 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, 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, it not inconceivable that in the future subject gateways could make use of the national records produced by National Bibliographic Agenciess, 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 will the 'national intellectual record' for digital resources look like, etc. Some "fact-finding" activity in this area seemed useful.
Combining harvesting services and subject gateways was identified as another interesting area for collaboration. The possibilities to combine automatic techniques and manual methods, have also been researched in project DESIRE. 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 in the added-value of this type of combination.
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 a search and a browsing environment. 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 to differentiate between differing features, not similar features. Uniformity enhances the ease of use of similar features. The old metaphor with car design is applicable here.
All established subject gateways have conducted user surveys or have online forms for user feedback. This wealth of information could also be fruitfully 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 (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.
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 performances and minimise duplication of efforts.
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, more user-friendly interfaces, they can meet user-needs and understand the user in novel ways.
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 it was reasonable to take forward given available resources and the loose, cooperative structures through which it worked. They do not address the full range of issues discussed at the workshop, or raised by breakout sessions.
Participants were also encouraged to offer material to a future issue of "Online Information Review: the international journal of digital information research and use" (formerly "Online & CD-ROM Review") to be edited by Traugott Koch and due out in February 2000.
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 resulting in a document capturing current practice in subject-gateway software including architectural decisions that must be made and available standards.
Interoperability requirements analysis - A study considering 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.
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 using ROADS was set up - GardenGate. This acts as a front-end to the ROADS servers running on the BIOME hub in the UK and Novagate in Denmark. [GardenGate])
Interoperability - discussed in last section.
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.
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, 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 this area 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.
A number of research issues emerged. It was agreed that one way of progressing these was to maintain a 'research agenda' which 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 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 give 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 into the development of good user interfaces.
Studies of gateway users - An improved understanding of information gateway users, 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'.
The organisers are pleased to acknowledge the valuable contribution and sharing of experience of 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.
[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
review of international subject gateway activity"
[forthcoming]
[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>
The IMesh Toolkit Project outcomes support potentially support recommendations in several areas, notably the technical development area, but also registries and 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 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 for input and for peer review to the IMesh collaborators.
The IMesh Toolkit has a technology review as an internal deliverable - the review is intended to cover similar issues 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 Tookit 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 which 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, in may also be possible to incorporate IMesh-related entries into this registry. The IMesh Toolkit registry work will build on that 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.