the impact of cscw on database technology - CiteSeerX

THE IMPACT OF CSCW ON DATABASE TECHNOLOGY J.A.Mariani and T.A. Rodden Department of Computer Science Lancaster University Lancaster, LA1 4YR United Kingdom

Presented at the IFIP International Workshop on CSCW, April 9-11 1991, Berlin.

1. INTRODUCTION Computer Supported Cooperative Work (CSCW) has rapidly developed as a distinct research area over the last decade with the emergence of a wide variety of systems for supporting various forms of cooperation and group working [Wilson 90]. This development of CSCW systems has not only increased the range and power of computer technologies aimed at supporting group working, it has also started to bring into question some of the mechanisms and techniques of existing computer technologies. This paper examines a number of published groupware systems with the express purpose of analysing the following database issues : •

the nature of the data; how it is stored and accessed.

• the definition and support of access rights concurrency control. Having identified aspects of existing systems, we use this as a basis for a more wide-ranging examination of what CSCW systems require from database technology. This includes : •

Information modeling, in particular schema definitions access control

• Support mechanisms for database systems In brief, this paper examines the applicability of database technology in CSCW systems, indicating the strengths and weaknesses of that technology and highlighting the requirements CSCW systems will make of DB technology in the near future. It is important that these issues are addressed and incorporated within future systems and standards aimed at supporting CSCW applications. The paper begins in section 2 by examining the state of the art in CSCW technology highlighting the nature of the general classes of system which have develop to date. Section 3 examines the information usage of these systems while Section 4 discusses the issues and problems in database technology highlighted by the emergence of CSCW systems. Our initial conclusions are presented in Section 5.

2. STATE OF THE ART IN CSCW A substantial number of CSCW systems have been developed to date each of which has it’s own set of peculiarities. Before we examine the needs CSCW systems have of database systems it is worth briefly reviewing the different types of cooperative systems which currently exist. Four classes of cooperative system have emerged over the last decade. Before discussing these systems it is worth noting that like all cooperative systems they exhibit two important characteristics. The Form of interaction (synchronous versus asynchronous) Creative problems, such as those tackled by brain-storming, require group members to cooperate in a completely synchronous manner since the creative input of each group member is required in order to generate a strategy for tackling the task at hand. In contrast prescriptive tasks have a previously formulated solution strategy where group members can take on particular roles and work in an asynchronous manner often without the presence of other group members. Thus, cooperative systems are either synchronous or asynchronous.

2

The Geographical Nature of the users (remote versus co-located) Computer support for group interaction has traditionally considered the case of geographically distributed groups who work asynchronously with each other. More recent research is aimed at the support of face to face meetings. Using this classification cooperative systems can be considered as being either remote or co-located. Note that in this characteristic the division between remote and co-located is as much a logical as a physical one and is concerned with the accessibility of users to each other rather than their physical proximity. 2.1 General classes of CSCW system Four major classes of CSCW systems are briefly described in this section and the particular characteristics of each of these systems are show in figure 1. Message systems Message systems represent the most mature class of cooperative system and can be seen as descendants of early electronic mail programs which allowed a user using a central machine to send textual messages to other users on the same machine. As wide area networks designed to support computer communication became more widespread [Mortensen 85], electronic mail systems increased in complexity and functionality. This development resulted in the formation of a Message Handling System (MHS) model described in the CCITT X400 series of standards documents [CCITT 87]. The X400 standard like many others describes the message format used to transfer information in message systems. Structured message systems are based on the principle of extending the amount of machine processible semantic information available by adding syntactic structure to the existing message structures. Systems of this class include the COSMOS [Wilbur 88] and AMIGO [Danielson 86] projects and the Object Lens [Malone 88]. Computer Conferencing Traditional computer conferencing systems share many concepts with message systems however they are significantly different in that they are centralised and structure is imposed in terms of how messages (or notes) are grouped. A typical computer conferencing system consists of a number of groups called conferences, each of which has a set of members and a sequence of messages. Conferences are often arranged so that they individually address a single topic. A user subscribes to those conferences which are of interest to him. Usually, the system stores information about how far every member has read in each conference. This information is normally held with conference messages within one central database rather than the individual mailbox approach used in messaging systems. Examples of this class of systems include KOMEX [Pankoke-Babatz 85] and COM [Palme 84] The development of reliable high speed communications has lead to the emergence of new realtime conferencing systems such as RTCAL [Sarin 85]. The systems allow conference members to communicate in real-time. Similarly the emergence of more powerful systems has heralded the development of systems which integrate many forms of media including audio,text and video. These Multi-media conferencing systems represents the most modern of the conferencing systems to date and include systems such as Rapport [Ahuja 88] and the MERMAID Conferencing system [Watabe 90]. Meeting rooms A typical automated face to face meeting room consists of a conference room furnished with a large screen video projector, a computer (or network of computers), video terminals, a number of individual input/voting terminals, and a control terminal. The computer system supporting the

3

meeting often makes use of multi-user software based on some form of analytical decision technique. Software for graphics and vote tally and display also form part of the normal meeting facility. Meetings rooms include the CoLab [Stefik 87], Project Nick [Cook 87] and the Planning Laboratory at the University of Arizona [Applegate 86] Co-Authoring and Argumentation Systems Co-Authoring and argumentation systems are a general class of system which aim to support and represent the negotiation and argumentation involved in group working. The cooperative authoring of documents is demonstrative of this class of cooperation where the final generation of a document represents the product of a process of negotiation between authors. This class of system is characterised by the widespread use of hypertext technology. Argumentation systems include gIBIS and SYBIL while authoring systems following a hypertext approach include Quilt [Fish 88] and CoAuthor [Hahn 89]. The four classes of system and how they vary in terms of the principle characteristics identified above is shown in figure 1.

Interaction

Asynch

Co-Authoring and Argumentation

Message Systems

Conferencing Systems

KEY Synch

Meeting Rooms

Multi-Media Conferencing

Real-Time Conferencing

Meeting Rooms Conferencing Co-Authoring Message Systems

Remote

Co-Located

Location Figure 1 A Classification of CSCW systems

3. INFORMATION USAGE IN CSCW SYSTEMS One of the fundamentals of cooperative working is the sharing of information. Most CSCW projects have therefore designed and implemented a data model that they believe best meets their aims. In so doing, they have failed to recognise the on-going developments in the field of database management systems and the benefits of standardisation. Traditionally, DBMS systems have been rejected as part of a project due to the imbalance of functionality required and functionality provided (which leads to greater and unacceptable costs) or perhaps because they do not provide the required functionality at all. As we shall see in our examination of CSCW systems, many of them are settling on the object model; as the provision of object DBMS continues to gain speed in both the commercial and research fields, we must ensure that any such DBMS meet the requirements of CSCW systems. Notice that it is important at this point not to show favour towards any given data model, but to

4

analyse what is required, rather than how it may be achieved. The requirements of new application areas must be taken into account by the developers of new or enhanced data systems. Hopefully, by paying such attention, the new breed of DBMS will meet the requirements (as yet undiscovered) of CSCW applications. However, what about the "cost" argument? Clearly, in an area so concerned with information sharing, the benefits of settling on a single DBMS or at least a single data model capable of storing (and therefore sharing) information among many different types of CSCW applications is undeniable; this is an argument put forward in favour of the X.500 directory service [Prinz 89]. Our starting point for considering the shortcomings of existing database systems and the requirements for future systems is to consider the information use of existing CSCW systems. Section 3.1 considers the nature of the information in existing cooperative systems. Sections 3.2 and 3.3 examine current approaches to access rights and concurrency control, two fundamental features of sharing information within CSCW systems. 3.1.What kind of data needs to be stored? Message handling systems provide a useful baseline for examining the information storage of cooperative systems. This is particularly true as message based systems and traditional asynchronous conferencing systems can be considered equivalent in their information usage. As far as information use is concerned users’ individual mail boxes exist as a collection of messages, and conferences are merely public versions of mail boxes. The KOMEX system differentiates between texts, documents and messages. Once a text is mailed it becomes a document and is given a unique document number. Unique identifiers allow references to exist between documents. A message is an enveloped document; the envelope has several attributes such as author, recipient, data of creation etc. Messages are archived in the user's mail box and can be retrieved by selection criteria with a conference being a distribution list. The COM/PortaCOM system provides a structure consisting of links between messages and sets of messages (called activities) containing lists of links to messages. Through the use of links/pointers, a message can belong to any number of activities i.e. a private mail box or a conference. There are no restrictions on the number of private activities (allowing the user to model several mail trays) and a conference is an activity with several users as members. The Cosmos Messaging System has an object server which is sufficiently general to handle different types of messages. Every object has a unique identifier; replication of objects is allowed, to enable objects-as-messages to be distributed across the system. The server must also be able to build structures such as lists (mail boxes) and trees (conferences). An object server runs on each node in the COSMOS system. Objects can be created in an ad-hoc manner; there is no notion of existing types or templates. An object is created once its first attribute is stored; subsequent attribute (name, value) pairs can be freely added, referencing the UID of an existing object. The AMIGO data model distinguished between atomic and compound objects. A message again maps onto an atomic object which has a number of attributes, one of which includes the body of the message. Objects are named in an hierarchical structure (obviating the problem of generating unique names in a flat space) similar to the X.500 directory. Clearly, sets of message objects must be supported to model conferences. This is achieved by using compound objects, which consist if two parts : a description (name of the compound object and some properties of the set as a whole) and an object set. The object set is obtained dynamically from a derivation rule which is a special attribute of the description. A derivation rule can be a simple listing of the names of the objects in the set or a selection criteria based on attribute values within objects. Using derivation rules dynamically means that objects are 5

"automatically" included in the relevant compound objects as they arrive. Search rules are also available; these are like derivation rules except that they are independent of compound objects. The multiuser message store described by [Nunez 88] also associates attributes with documents and uses the attributes as the basis for document handling, search and retrieval. Palme's distributed message database [Palme 88] takes the view that a messaging system is a distributed database application; each node's messaging system maintains its own set of messages, and the transmission of a message from one node to another is an update from the sending node to the receiving node. Palme presents two different techniques for distribution : the master-shadow and the database revision unit. The X.500 distributed directory service is examined for its potential on group communication support systems [Prinz 89]. The authors realise that a single DBMS to manage common and interrelated components of different systems avoids multiple and nonhomogeneous representations. The data model presented is similar to the AMIGO architecture and objects are again chosen. The collection of all object entries make up the directory information base (DIB). Object classes are defined and managed by the Directory Schema. To allow distributed administration of the DIB, entries are arranged in a hierarchical structure called the directory information tree (DIT), which can be fragmented and allocated to different servers. The arguments that the paper makes against standard DBMSs are strange, to say the least : "The Directory is a general and standardised repository for information. It provides all advantages of a standardised database in contrast to a normal database management system. In particular, a normal database is designed to manage its own copy of data and to use different data access services. Sharing data among different applications is often impossible. The Directory, instead, allows the use of a single, coordinated and standardised database and it provides a single set of basic services to manage that data repository. It offers, in a standardised way, the look-up, browsing and yellow pages facilities, so it can be used by any other application which requires the functionality provided by these services." The paper presents a strong argument for the use of distributed objects rather than the X.500 directory, and no good case for the directory against a more suitable DBMS. Co-authoring systems such as Quilt and KMS are often based on hypertext data models and are dependant on the properties of these models. However, KMS makes a virtue of using very basic and simple techniques. For example, there is only one kind of frame, which is "screen sized" but can hold any kind of data. Quilt, on the other hand, models a document as a base and nodes which are linked to the base. Nodes are of three kinds -- the current base document (the root), suggestions for revisions, and comments. There are three types of comments : private, public and directed messages. Of all the systems examined in this paper, Quilt is the only one which is actually based on an object-oriented DBMS, namely Orion. Quilt's data types are modeled on node and link classes. At the time of [Fish 88], Quilt was described as a centralised system that would be distributed once a distributed version of Orion was available. This is an interesting example of using and exploiting the available functionality of an existing DBMS; however, while this is a trend we would like to encourage, it will not happen unless a full requirements analysis of CSCW systems on databases has been made, and the results of the analysis fed into the development of new data models and the corresponding DBMS. An important point about the nature of information in CSCW systems is that most systems observe a direct mapping between their information needs and the facilities provided by an object model. In message and conferencing systems messages and conference entries can be modelled as objects. Mailboxes and conferences can be represented as sets of objects with their own properties. Conferences are distinguished from mailboxes by their visibility to other users. Authoring and argumentation systems generally exploit hypertext technology. As a result

6

document components are held as objects which are presented to the user as individual nodes with links between components represented by object relationships. 3.2. Access rights Access rights to shared information plays a crucial role in cooperative systems and can dictate the nature of the cooperation in CSCW systems.In AMIGO, access is controlled by associating access control lists (ACLs) with objects and attributes. The MPCAL (MultiPerson CALendar) application described in [Greif 87] uses roles to describe the access permissions of users. A role is an attribute of the user's computation which is used to determine whether or not a given operation can proceed. For example, users in some roles may see time slots marked FREE or BUSY, whereas other roles may see details of an appointment. Roles are arranged as follows : • each calendar has a collection of role definitions, a list of user names against the roles they are allowed to take, and a default role for all other users • each role has a name and a description and a set of rules determining access to each type of operation on each type of MPCAL object • each rule, for a given role and a given operation, is a specification of whether or not a user in the given role can perform the given operation Roles are also used in Quilt to differentiate the access rights of different users; here they are referred to as "social roles". For example, peers might revise each others work without discussion or permission, whereas other readers might have to send messages or annotate the text while leaving it unaltered. Social roles imply different levels of rights and responsibilities. We can envisage storing roles of this kind in a simple table structure; table-driven programming can then be used whenever an operation is requested by a user under a certain role. This table embodies the "rules". The AMIGO architecture also uses roles and rules. A group of people using regulated information exchange to achieve a target is called an activity. People within a group are called actors. Actors are characterised by the role they play within the activity. A role is characterised by the functions it can perform, the rules it must obey, and the message types it can consume and generate. Rules are given in a specific language and are of the form "condition => action". AMIGO's rules are more akin to rule bases than table-driven programming, and lead us across the boundaries between data and knowledge bases. [Pays 88] concludes by indicating the suitability of the object model for representing actors and roles; and the connection between AI research in the OO field should provide aid for the rule specifications. A strong interdependence exists between role definition and access rights. It can be argued that role definition can define access permissions and equally well access rights can delimit the nature of the role. As a consequence it is likely that the access permissions for information in CSCW systems will be closely linked to the definition of roles. 3.3. Concurrency control The control of concurrent access to shared information is particularly important in supporting group working where a number of users may need to simultaneously access information. The form of concurrency control mirrors the style of cooperative interaction being supported. It could be argued that these two styles of interaction are defined by the nature of concurrency control. In general, synchronous cooperative systems need more sophisticated concurrency techniques than their asynchronous counterparts which exploit simple locking mechanisms. A number of simple techniques have been adopted for concurrency control in existing CSCW systems. For example, the non-distributed but multi-user Quilt system maintains an activity log for each node (in a hypertext document) that keeps a record of collaborators' interaction with the document. This modification history is used to warn users if they try to change an object that another user is currently working on. The KMS system continues on its path of simplicity; while it is a distributed hypermedia system, it provides a single logical database that multiple users can see and comment on. There is no administration; a KMS database evolves as the users' common sense and group norms dictate. Because KMS' hypermedia structure is based on relatively small (screen sized) frames, and 7

updating occurs on a frame basis, the probability of a number of users accessing the same frame at the same time is minimal. An optimistic concurrency control mechanism is used for the few times when this occurs. The KMS users can place an informal "locking item" on the frame being altered. The style of locking employed in both KMS and Quilt dictates a asynchronous style of cooperation with group members working independently on particular portions of a global information space. This contrasts with the more sophisticated locking mechanisms needed in synchronous cooperative systems. For example, the CoLab meeting room system has much greater locking needs, and [Stefik 87] reports experiments with four different control regimes in an attempt to find the one best suited for their needs. Centralised With one copy of the data and conventional concurrency control is used to enforce serialisability. This approach caused serious performance problems. Centralised-lock Each workstation has a copy of the database, but it cannot changed an item until it obtains ownership of the item. To do this, it obtains a lock from a centralised lock server. Cooperative The data is replicated and there is an unsynchronised broadcast of change. This approach results in a race condition; if two participants change the same data simultaneously there is a race to see which change will take affect first. Roving-locks The roving-locks model attempts to distribute the management of locks. The idea here is that a site would gather up a "working-set" of locks that it would then manage locally, removing the need for obtaining locks from other sites. The developers of CoLab claim more experience is necessary to determine the practicality of this solution. The developers of CoLab have also used informal "voice locks" in conjunction with the cooperative model which can be issued across the meeting room and are similar to the KMS text item lock. The CES (Collaborative Document Editing System) [ Greif 87] allocates locks implicitly when an author starts editing a section of a document, and the lock is released after an idle period; this ensures lock release even if the author forgets to do so explicitly. It is felt that this lock timeout has a measure of fairness in deciding which transactions should abort. Concurrency control in groupware systems is needed to resolve conflicts and to perform tightly coupled group activities. As [Ellis 89] states, "The various approaches to resolving these situations, such as explicit locking or transaction processing, that have been developed for database applications do not appear to be suitable in this context". [Ellis 89] identifies two notions of time for a real-time groupware system : response time, which must be short to support a highly interactive system, and notification time -- the time it takes for one user's actions to be propagated to the other users. Any concurrency control used must minimise the notification time. Locking takes time; so too do transaction mechanisms. The paper goes on to develop an application-specific algorithm which does not involve the use of locks for concurrency control in real-time groupware systems. 4. CSCW and Database Technology The previous section examined information sharing in CSCW applications and highlighted the mechanisms used by a number of existing applications. However the problem of sharing information is not new and has traditionally been tackled by database systems. To complement the previous section where we examined existing practise in CSCW applications, this section examines the nature of existing database technology. The aim of the section is to discover the shortcomings of existing database systems for supporting CSCW application and the impact CSCW will have on this technology. Many of the principles underpining database systems have already been challenged by new applications resulting in significant developments in information sharing systems. For example, consider the situation that exists in design support [Skarra 86] which has resulted in significant

8

changes in the development of modern database technology. Greif [Greif 87] suggests that similarly CSCW systems place a challenging and novel set of demands on database technology. The traditional concepts of information sharing can be altered quite radically when viewed from the user perspective adopted in CSCW. Applications like electronic brainstorming and document review systems are designed to encourage users to simultaneously amend information; something that is almost completely prohibited in most database systems. The open philosophy adopted by synchronous electronic brainstorming systems where each user has equal parity, contrasts with more procedural asynchronous cooperative systems where the organizational structure of the users becomes much more important. In the asynchronous case people may be working together on a common task but not all information is shared. For example, all users within an organization would not normally be able to access the information held within the organization's personnel files. As we have seen each CSCW system developed to date has adopted its own mechanism for the creation and management of the shared information. As Jarke argues [Jarke 88], these systems concentrate on the development of a particular methodology or technique which the systems wishes to demonstrate or evaluate. There has been little concern with a general systems architecture to integrate multiple approaches. Given the wide variety of models of cooperation adopted by the range of CSCW systems integration among these models or more generally between the synchronous and asynchronous forms of cooperation is difficult. Integration across the data allowing the sharing of information between the synchronous and asynchronous components offers a mechanism for achieving this goal. This suggests that the need for a common architectural framework for the sharing of the information used within CSCW systems is essential. Once supported in this manner a number of different CSCW systems will be able to exploit the sharing of data to provide interoperabilty of the various information used in different systems. CSCW systems have an immediate impact on a number of areas of database technology; in some cases, changing the philosophies and assumptions that underpin the traditional techniques. This is compounded by the approach adopted in developing CSCW systems [Bannon 89] where the needs and the requirements of the user help shaped the technology. This section attempts to highlight the important issues which need to be addressed for the development of appropriate database technology for CSCW systems. The effects of CSCW on database technology can be divided into two distinct but nevertheless related areas • Information Modeling • Support mechanisms Each of these areas has an associated set of problems which need to be examined in order to discover the best means of meeting the requirements of CSCW systems. 4.1. Information Modeling Information modeling is dramatically affected by the concepts within CSCW systems, this is a result of the need to express much more user information within the information model than in traditional applications. An effective and usable set of mechanisms for modelling data is essential for supporting CSCW applications. However, the nature of CSCW is such that it has ramifications for a number of the concepts used in modeling information in database systems. This effect is most notable in the areas of schema definition and access control.: 4.1.1 Schema Definitions Schemas have traditionally been static data descriptions. However, with CSCW systems they will certainly need to become much more dynamic if they are to mirror the dynamic nature of the groups they are supporting. Specific issues which need to be addressed include:• Current object models offer mechanisms which support schema evolution, are these appropriate for CSCW systems? • What do users wish to represent within the schema? In particular how large a part does the dynamics and organization of the group being support play in the schema ?

9

• How much of the group organization should be represented in the schema? How should these concepts be represented within the schema definition language? • How do different modes of collaborative working effect schema evolution? • How will the schema and DB organization affect collaborative tasks? • There is a need for individually creatable views of the data. What does this mean for the schema language? Finally, the implicit assumption presented by the concept of a schema is that there is some privileged user who defines and controls the schema within the data base. Does this assumption remain valid in CSCW systems? The concept of a privileged user in some CSCW applications may be invalid with all users having the ability to alter many of the parameters within the systems. In this case schemas may be defined by the consensus of a number of cooperating entities within the database system. 4.1.2 Access Control Access control has traditionally been handled by a single database administrator. In general each user of the DBMS is considered as a singular client, and each individual client has to have permission granted or revoked to access and/or create data. In addition the querying of database systems has fallen under this concept of individual user rights. CSCW systems challenge and alter these perspectives again raising a range of issues • How can the group organization and roles be supported in access mechanisms? • Given the alteration in the concept of a schema how does the query language change? • How do we include facilities for security in CSCW? Something currently neglected by most CSCW systems? • With regard to security, people work together on a common task but not all information is shared. What user control is required? It is important that these issues are addressed by the developers of future database systems. To achieve this it is vital that CSCW and database researchers work together in order to develop appropriate mechanisms for future CSCW database support. Since it is likely that effective solutions will need to be both technically feasible and capable of supporting user requirements. 4.2. Support mechanisms In addition to the effects CSCW has on the views of information within database systems and how this information is modelled, CSCW influences and is influenced by underlying database support mechanisms. This section highlights some of these mechanisms and presents the problems posed by these mechanisms when considered along with the needs of CSCW applications : A naive and hidden view of locking In traditional database systems locking is usually the province of one client. Either the client holds the lock, or else the client is only told that the resource is locked, and must wait until the resource is freed. As we have seen this is barely adequate in CSCW systems. In cooperative systems, it may be important to know who holds the resource For example, if the client is a colleague, then you might not mind waiting.If anyone is writing, it is normally considered unwise to allow readers as they may see inconsistent data. In a CSCW system however, if your colleague is updating a section of text of interest to you, then it might make sense to "read over their shoulder". This suggests that a variety of types of locks will be required by CSCW systems. Inadequate transactions mechanisms The idea of transactions are altered significantly by the requirements of CSCW systems, which will probably include some very long transactions particularly in the case of asynchronous systems. As a result, transactions are dramatically effected [Walpole 88]. This brings to light a fundamental database question of the nature of long transactions; is it appropriate to consider them in a similar manner to "short" transactions? Certainly existing CSCW systems have failed to address the problems of transactions in any significant way. Changing views of distribution

10

Communication and distribution plays an obvious and crucial role in CSCW systems. A number of distributed information sharing models are exploited in the emerging range of distributed development systems, for example Linda [Carriero 89]. These are contrasted by the developing series of distribution standards which include information sharing mechanisms such as X500 and the work that is beginning to emerge from Open Distributed Processing (ODP). Lack of monitoring and Activity support All the mechanisms mentioned here happen silently and automatically in current database technology. By adding monitoring to these, we can move toward the more active facilities required by CSCW. Transactions no longer remain a simple roll-back mechanism but as part of the need CSCW systems have for activity monitoring [Benford 89] transactions are required to include some form of tracking. This section has attempted to briefly analyse the impact of CSCW systems on existing database technology. This brief analysis has highlighted a range of issues which need to be addressed by the developers of future information sharing systems aimed at supporting CSCW. Past experience with database support has shown that it plays a central role in the development of support architectures and it is therefore critical that these issues are addressed by future systems. 5. Conclusions and Future Goals This brief survey has examined the use CSCW systems make of techniques which currently exist in database management systems and found that existing CSCW applications make little or no use of existing database systems. However their information needs are no greater than those of modern design environments. One reason for this is the historical nature of database systems. While enabling and allowing the sharing of information, database systems ironically did not encourage the development of cooperative systems. This is reflected in the mismatch observed when we examined the use of access rights and concurrency control in sections 3.2 and 3.3. Database systems hold great promise for the development of future CSCW systems offering the important characteristics which will be needed in future systems. Most notably appropriate database support for CSCW systems will allow interoperability between CSCW systems encouraging an open approach to application development. These characteristics are particularly important for the development of future standards in the area of CSCW systems. However, a number of shortcomings exist in current database technology, these were examined in section 4. In light of these failings of traditional technology we can make a first attempt at listing the goals which need to be addressed by both CSCW and DBMS researchers . • we must be able to store objects consisting of a number of typed attributes; each object should have a unique identifier. Objects should be able to represent various kinds of information artifacts i.e. messages in MHS, frames in hypertext systems etc. Objects should be capable of storing multimedia data. • we must be able to store compound objects, in order to model items such as mail boxes. • we must be able to retrieve and organise objects by attribute values • we must be able to model links and relationships among objects. This allows the provision of tree structured conferences as required by the Cosmos Messaging System, and to provide the hypermedia-like facilities required by Quilt, and to overcome one of the shortcomings of the X.500 directory service as mentioned in [Prinz 89]. • we must provide fine-grained access control to the level of objects and individual attributes; roles and the rules that pertain to them should be stored. Ideally, such information should be declared as part of a database schema. • we must provide appropriate locking regimes. These nature of locking will have to be investigated and appropriate regimes discovered. • we must be able to provide this DBMS in a distributed manner. It is important that the goals enumerated above are born in mind in the development of future information storage systems for CSCW applications and the subsequent development of any CSCW environments and associated standards. 6. References

11

[Ahuja 88] Ahuja S.R.,Ensor J.R.,Horn D.N.' The Rapport Mulimedia Conferencing system', in Allen R.B.(ed) COIS88 Proceeding conference on Office Information Systems, March23-25,1988, Palo Alto, California,. [Applegate 86] Applegate L., Knonsynski, Nunamaker J.F. ' A Group Decision Support System for Idea Generation and Issue analysis in Organisational Planning', in proceedings of CSCW 86, Austin , Texas, December 1986. [Banerjee 87] Banerjee, J., et al. ‘Data Model Issues for Object-Oriented Applications’, ACM Trans. on Office Information Systems, Vol. 5, No. 1, pp 3-26, Jan. 1987 [Bannon 89] Bannon L., Schmidt K.’ CSCW: Four Characters in Search on context’ In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. [Benford 89] Benford S.D. ‘ Requirements of Activity Management’. In Proceeding of ECCSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. [Bonfiglio 89] Bonfiglio A, Malatesta G., Tisato F. ‘Conference Toolkit : A frame work for real time conferencing’ In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. [Brobst 86] Brobst S. A., Malone T., et al. 'Toward intelligent message routing systems' In, R Uhlig (Ed.), Computer Message systems -85. Proc. of the 2nd International Symposium on Computer Message Systems. North Holland, Amsterdam, 1986. [Carriero 89] Carriero N, Gelernter D. ‘ Linda in Context’, Comm ACM Vol. 32, No. 4, April 1989 [CCITT 87] CCITT (1987) ' Draft Recommendation on Message Handling Systems, X 400, Version 5' , November 1987. [Cook 87] Cook P., Ellis C., Graf M., et al ' Project NICK Meetings Augmentation and Analysis', ACM trans. on Office Information Systems, Vol 5, No 2, April 1987,pp 132-147. [Danielson 86] Danielson T., Panoke-Babatz U. et al ' The AMIGO project Advanced Group Communication Model for Computer-based Communication Environment', in proceedings of CSCW 86,Austin,Texas,December 1986. [De Cindio 86] De Cindio F., De Michelis G.,et al ' CHAOS as a Coordinating Technology', in proceedings of CSCW 86, Austin, Texas, December 1986. [Ellis 88] Ellis, C., Gibbs, S.J. and Rein, G., ‘ Design and Use of a Group Editor ‘, MCC Technical Report Number STP-263-88, Sept. 1988 [Ellis 89] Ellis, C.A., Gibbs, S.J., 'Concurrency Control in Groupware Systems', proceedings of the 1989 ACM SIGMOD International Conference on the Management of Data, Portland, Oregon, June 1989, pp 399-407. [Fish 88] Fish R.S., Kraut R.E., Leland M.D., Cohen M. ' Quilt: A colloborative tool for cooperative writing', in Allen R.B.(ed) COIS88 Proceeding conference on Office Information Systems, March23-25,1988, Palo Alto, California. [Flores 81] Flores C.F. and Ludlow J. 'Doing and speaking in the office', in G Fick and R. Sprague (Eds), DSS Issues and Challenges,London, Pergamon Press,1981. [Goodman 86] Goodman G. O., Abel M. J. 'Collaboration Research in SCL', in Proceedings of the CSCW 86, Austin, Texas, December 3-5, 1986. [Greif 87] Greif I., Sarin S. 'Data Sharing in Group Work', ACM trans. on Office Information Systems, Vol 5, No 2, April 1987, pp 187- 211. [Hahn 89] Hahn U., Jarke M., Kreplin K.et al. ‘ CoAuthor: A hypermedia Group Authoring Environment’ In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989. [Jarke 88] Jarke M. ‘The Design of a Database for multiperson Decision Support’, Annals of Operations Research 16(1988) 393-412. [Kreifelts 86] Kreifelts T. Woetzel ‘ Distribution and error handling in an office procedure system’ Proceedings IFIP WG 8.4 Working Conference on Office Systems Methods and Tools, Pisa, Italy, 1986, p 197-208.

12

[Malone 88] Malone T W, Lai K, ' Object Lens A Spreadsheet for Cooperative Work', in proceedings of CSCW88, Portland, Oregon, September 1988. [Oxborrow 88] Oxborrow, E.A., ‘Object-oriented Database Systems What are they and what is their future?’, Database Technology, Vol. 2, No. 1, pp 31-39, 1988 [Palme 84] Palme, J., ‘COM/PortaCOM conference system Design goals and principles’, INTERACT '84, B. Shackel (Ed.), IFIP 1985 [Prinz 89] Prinz, W., and P. Pennelli, ‘Relevance of the X.500 Directory to CSCW Applications’, In Proceeding of EC-CSCW, the 1st European Conference on CSCW, Gatwick Hilton September 13th-15th 1989, pp 289 - 302 [Skarra 86] Skarra, A.H. and S.B. Zdonik, ‘The Management of Changing Types in an Object-Oriented Database’, OOPSLA Proceedings, pp 483-495, Sept. 1986 [Skarra 87] Skarra, A.H., S.B. Zdonik and S.P. Reiss, ‘ ObServer An Object Server for an Object-Oriented Database System ’, Technical Report No. CS-88-08, Brown University, Dept. of Computer Science, July 1987 [Stefik 87] Stefik M., Foster G., et al 'Beyond the chalkboard computer support for collaboration and problem solving in Meetings', Comm ACM Vol 30, No 1, January 1987. [Walpole 88] Walpole, J., G.S. Blair, J. Malik and J.R. Nicol, ‘Maintaining Consistency in Distributed Software Engineering Environments’, Proc. IEEE 8th International Conference on Distributed Computing Systems, pp 418-425, San Jose, California, June 1988 [Watabe 90] Watabe K., Sakata S, Maeno K et al ‘ Distributed Multiparty Desktop Conferencing System: MERMAID’, in proceedings of CSCW 90, Los Angeles, CA, October 710 1990, ACM press , ISBN 0-89791-402-3. [Wilbur 88] Wilbur S.B., Young R.E. 'The COSMOS Project A Multi-Disciplinary Approach to Design of Computer Supported Group Working', in R. Speth(ed) EUTECO 88 Research into Networks and Distributed Applications, Vienna, Austria, April 20-22,1988.

13