These materials were assembled by the following participants in the workshop: Matthew Bietz, Daniel Cooney, Darren Gergle, Mark Handel, Larry Jacobs, Jim Myers, Huahai Yang, and Xiaolong Zhang.

The workshop on July 19-20 was the second in our series. It explored the technology underpinnings of collaboratories, bringing together researchers and developers from industry, academia, and government to identify, define, and discuss the state of collaboratory technologies and the state-of-the-art and state-of-the-practice in collaboratory technology deployment. The goals were to capture lessons-learned, identify current technology challenges, and lay the technology-related groundwork for subsequent workshops and the overall project.

Session Descriptions:

The Tools and Technologies of Collaboratories

As a pre-requisite for further discussion in the workshop, participants were asked to compile a list of tools and technologies relevant to collaboratories. The resultant list shows the breadth of applications, middleware, services, technologies, and standards in use across collaboratory efforts.

In creating these lists, the groups questioned the boundaries of collaboratories - can there be a collaboratory of one, must members be separated by distance, are shared resources (e.g. data or instruments) a requirement, is formation of a new community a defining feature (versus supporting an existing community), etc. While there was some disagreement over whether specific extreme cases should be considered to be collaboratories, there was agreement across a wide range, which participants agreed is a contributing factor to the broad range of tools in use and lack of agreement on a single set of tools across the collaboratory development community.

While a mapping was not attempted, the groups did identify several collaboratory-type-related dimensions in which specific tools could be measured, e.g. number of people who can be supported, or degree of formality in interactions. Other dimensions, related more specifically to technologies, were also identified. The combined list shows again why simple 'best of' comparisons of tools cannot be applied across all collaboratories.

Additional points discussed in this session included the concept of collaboratory developers as systems integrators. Some participants saw the inclusion of technologies such as the telephone, email, and videoconferencing in the list of collaboratory tools as evidence that collaboratories represented a specific integrated use of more general tools. Other participants emphasized the leadership role of collaboratory developers in developing new tools, defining new work processes, being early adopters of new technologies, and in innovating through integration and concluded that systems integrator did not capture the true scope. There was general agreement that we are still at a point where collaboratory development always includes elements of exploration.

(Click here for detailed notes from the Tools and Technology session)

Capabilities Needed by Collaboratory Users

Tools and technologies are deployed to provide 'capabilities' to collaborators. During the second breakout session, participants were asked to describe collaboratories in terms of the users' goals and the (technology-independent) capabilities they need to accomplish them. The motivation of this exercise was to refocus participants on the end goals of enabling collaboratory participants to work more effectively and more efficiently, and to enable the subsequent discussion of how well current and envisioned technologies map to the capabilities required.

The list participants created encompasses a wide range of functionality and shows significant diversity in the level of abstraction at which participants addressed the question, e.g. "LDAP directory services" versus "resource information services" versus "finding needed expertise". As in the previous session, collaboratories were seen as exploratory - as laboratories in which "chat" and "persistent chat" tools might be replaced by functionality for "capture and replay" of multimodal conversations and "summarization" services as developers sought better ways to meet an underlying requirement for recordable, reviewable conversations. Participants identified high-level capabilities focused on user processes (e.g. the capability to run an experiment) as well as capabilities for tasks within these processes (e.g. the capabilities to discuss experiment parameters, to tele-operate the instrument, and to access data).

Many group conversations anticipated the next breakout session and highlighted the difficulties involved in using currently available tools - from issues of communicating across firewalls and different operating systems, to the stand-alone nature of tools, which limits integration. Some groups noted a conceptual mismatch in using commodity tools, which target common tasks and often work only on the most popular computing platforms, in a scientific setting where discovery and constant evolution of resources (instruments, data types, analysis tools) and processes are fundamental to progress. Conversely, technologies being created to support e-business across organizations (e.g. XML, web services) were seen as very well aligned with the needs for flexibility, integrability, and evolvability in scientific collaboratories.

(Click here for detailed notes from the Capabilities session)

The Technology Issues Facing Collaboratories & Building a Collaboratory Technology Infrastructure: Today and Tomorrow

Using the information from the first two sessions, participants were asked to use the third session to explore the mapping between technologies and capabilities, and to make concrete recommendations for building collaboratories that would become operational today and in 3-5 years.

Continuing the discussions from the previous session, participants noted issues with specific implementations of videoconferencing, chat, document sharing, and other tools. There is clearly a need for such tools to continue to mature. However, many of the most compelling visions of new capabilities that would make distributed collaborations more natural and more productive were not related to a specific tool, but rather to the integration of many tools. Single sign-on, integrated multimedia session records, awareness, persistent workspaces, and information pedigrees were all cited as important next-generation functionality that would be difficult to create using today's collaborative tools. These in turn were seen as prerequisites for research into knowledge management, agent-based automation, etc. The development of collaboration middleware, and middleware-aware tools, was seen as a key step in this evolution, though the concern that such an approach would lead to a one-size-fits-all mentality was also voiced. The chicken-and-egg issue related to selling middleware and middleware-based tools was seen as an argument in favor of an open source effort in this area.

From their experiences building collaborative technologies and creating working collaboratories, the participants distilled a number of guiding principles, most of which might fall under the category of 'uncommon sense' - perhaps obvious, but too often overlooked. There was general consensus that current-generation collaboratories could now be built from off-the-shelf technologies, both commercial and open source. Looking into the future, web, XML, and Java technologies were seen as having increasing influence, due to both the low barrier to entry for browser-based tools and the emergence of increasingly powerful development tools (e.g. application servers). In both cases, new collaboratory developers were urged to focus on the user - address the most critical collaboration needs, provide sufficient training, take an iterative approach and evolve technologies as user expectations and practices evolve, etc. While much of the advice could apply to any software project, suggestions to provide an independent 'back-channel' for resolving technical issues with the primary communications mechanism, to emphasize simplicity and ease-of-use since collaboration may be episodic, etc. directly address unique aspects of collaboratories.

(Click here for detailed notes from the Issues and Future session)

Community and Knowledge Base Discussions

A final recommendation - to become involved in the 'collaboratory community' - addressed one of the motivating issues for the Science of Collaboratories project and workshop series. Collaboratories are being developed in a wide range of science and engineering communities (and beyond) and research into collaboratory-related technologies and work practices is similarly spread across many disciplines. The workshop participants concurred with the organizers that efforts to coordinate these activities and to share lessons-learned would be very valuable.

As part of the closing plenary session, participants discussed ways to strengthen the emerging collaboratory community - from email lists to collaboratory-focused special journal issues, standardized evaluation tools, and a community portal and knowledge base. Specific items within the discussion included a review of relevant journals and conferences and a presentation of initial work within the Science of Collaboratories project to develop a comprehensive questionnaire to capture various aspects of a collaboratory project - scope, focus, technologies, maturity, etc. - as part of an effort to build a community knowledge base.

(Click here for detailed notes from the Knowledge Base and Community sessions)