monitoring virtual team collaboration: methods...

Monitoring Virtual Team Collaboration:

Methods, Applications, and Experiences in

Engineering Design

Dissertationzur Erlangung des akademischen Grades eines

Doktors der Ingenieurwissenschaften(Dr.-Ing.)

eingereicht an derMathematisch-Naturwissenschaftlichen Fakultat

der Universitat Potsdam

vonMatthias Uflacker, M.Sc.

Potsdam, November 2010

Abstract

What distinguishes high-performance engineering teams from lower-per-forming ones in the design of complex software, products, and services?Answering this question traditionally involves extensive protocol studiesand retrospective assessments of team effectiveness, e.g., in terms of adher-ence to budget and timelines, customer satisfaction, or innovation. Littleattention has been paid to developing applicable techniques for observ-ing performance-relevant differentiators directly in the behavioral aspectsof digitally-mediated creative teamwork. The expanding role of ‘virtualcollaboration’ in engineering projects requires new computational instru-ments to efficiently study if and how designing is reflected in the implicitprocesses, tactics, and strategies carried out over today’s dense networkof groupware, e-mail, and Web 2.0 services. This dissertation handles twoimportant aspects in the realization of such an instrument. First, it de-velops an adaptable monitoring service platform called, d.store, to captureand analyze virtual collaboration activities live, i.e., while a project is stillongoing. Secondly, it applies the services in global, small-group engineer-ing teams to identify structural differences in collaboration behavior thatcorrelate with independent team performance measures.

With the services provided by the d.store platform it is possible to tapinto heterogeneous online communication channels and to automaticallygenerate a descriptive model of how teams virtually communicate, interact,and share information over the course of a project. The semantics andtemporal attributes of the identified actors, resources, and relationshipsare represented in so-called Team Collaboration Networks. The platformis evaluated in the conceptual design phases of eleven distributed, multi-disciplinary engineering projects over a period of eight months each. Theactivities monitored in the e-mail archives, Wikis, and file sharing systemsprovide the basis for a detailed visual and quantitative examination ofdifferences and similarities in the collaboration behavior of the observedteams.

The analysis conducted on the generated Team Collaboration Networksindicates that high-performance design teams produce different collabora-tion patterns than lower-performing ones. Furthermore, the patterns that

ii Abstract

correlate with team performance suggest that an adherence to basic designprinciples has positive effects: teams who applied an ‘outside-in’ perspec-tive by emphasizing interactions with team-external stakeholders, contactsto domain experts, or group-internal knowledge sharing were generallymore satisfied with their work, explored more design alternatives, or re-ceived higher ratings from independent judges. This is relevant, because itdemonstrates that automatically collected objective real-time collaborationmetrics can provide valuable insights into performance-relevant aspects ofteamwork.

The contribution of this work is a tested, non-interfering monitoringinstrument, which establishes a technological foundation for the scientificobservation, comparison, and analysis of virtual collaboration activities asa service. A pilot application in engineering design gives first evidence thatmeaningful team performance indicators can be drawn from this approach.The results encourage a continued and intensified utilization of the instru-ment to assist in the evaluation of IT-mediated collaboration processes,ultimately promoting a new paradigm in the conduction of real-time teamdiagnostics and support in engineering design.

Acknowledgements

I am grateful for the many people who have accompanied me along thisjourney. First, I would like to thank Prof. Hasso Plattner for his inspiring,generous, and liberal guidance over the course of this dissertation. Hispassion and striking commitment for the topic encouraged me to pursuethis line of research. The experiences that I was able to gain during thistime were exceptional, invaluable, and are never forgotten.

I also would like to thank the professors of the HPI research school, es-pecially Prof. Christoph Meinel and Prof. Andreas Polze, for their valuablefeedback and guidance when it was needed. Many thanks also to AlexanderZeier, who has provided me with the environment and freedom to finishthis dissertation and to pursue my research interests in various projects.

I am deeply grateful to have met Prof. Larry Leifer and the people at theCenter for Design Research, who were an invaluable source of inspirationand the second lighthouse as I progressed through this endeavor. Manyof you have become good friends. Philipp Skogstad and Martin Steinertdeserve special recognition. Thank you for the fruitful discussions, support,and motivation that I have received from you.

I am thankful to have worked with my colleagues from the EPIC re-search group and the HPI research school, of which I can mention only fewhere: Jurgen Muller and Thomas Kowark for providing unbiased feedbackon the drafts of this dissertation; Martin Faust and David Schwalb for theirsupport during the implementation and data analysis.

My special thanks go to Vishal Sikka and Sam Yen from SAP for theirinterest in my research and for providing professional feedback and industryperspectives.

Finally, and most importantly, I would like to thank my parents, therest of my family, and especially Meike. Thank you for your patience, un-derstanding, and support while I took my time to complete this chapter ofmy life.

Potsdam, Matthias UflackerNovember 2010

Table of Contents

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Why Monitoring of Design Collaboration is Relevant . . . . . . 21.3 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Research Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 A Service Platform for Virtual CollaborationMonitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.2 Scope of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . . 81.4.3 Underlying Principles and Assumptions . . . . . . . . . . . . 9

1.5 Research Approach & Guiding Questions . . . . . . . . . . . . . . . . . 91.5.1 Step 1: Development of a Descriptive Model . . . . . . . . . 101.5.2 Step 2: System Implementation & Customization . . . . 101.5.3 Step 3: Application in Conceptual Engineering Design 11

1.6 Results and Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.7 Outline of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Part I Background & Preliminaries

2 A Review of Engineering Design Literature . . . . . . . . . . . . . 172.1 Conceptual Engineering Design . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.1 The Fuzzy Front End of Innovation . . . . . . . . . . . . . . . . 202.1.2 User-Centered Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.3 Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.1.4 Conclusions Drawn From Review . . . . . . . . . . . . . . . . . . 26

2.2 Teamwork, Information & Virtual Collaboration . . . . . . . . . . 262.2.1 Design Teams: A Working Definition . . . . . . . . . . . . . . . 272.2.2 Models of Design Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vi Table of Contents

2.2.3 Virtual Collaboration in Design . . . . . . . . . . . . . . . . . . . 312.2.4 Conclusions Drawn From Review . . . . . . . . . . . . . . . . . . 34

2.3 CSCW and Groupware in Conceptual Design . . . . . . . . . . . . . 342.3.1 Basics of CSCW in Design . . . . . . . . . . . . . . . . . . . . . . . . 342.3.2 Synchronous & Asynchronous Groupware . . . . . . . . . . . 362.3.3 Hypermedia & Web-based Collaboration Platforms . . 382.3.4 Application Lifecycle Management Platforms . . . . . . . . 412.3.5 Conclusions Drawn From Review . . . . . . . . . . . . . . . . . . 42

2.4 Instruments for Virtual Collaboration Monitoring . . . . . . . . . 422.4.1 Monitoring of Information Artifacts . . . . . . . . . . . . . . . . 432.4.2 Monitoring of Process Participants . . . . . . . . . . . . . . . . . 442.4.3 Combined Monitoring of Information and Participants 452.4.4 Derivation of System Requirements . . . . . . . . . . . . . . . . 462.4.5 Moving Beyond the Existing Literature . . . . . . . . . . . . . 48

2.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Technological Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Representational State Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 533.3 Of Resources and Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.4.1 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.2 The Resource Description Framework . . . . . . . . . . . . . . 593.4.3 The OWL Web Ontology Language . . . . . . . . . . . . . . . . 613.4.4 A Graphical Notation for RDF/OWL Ontologies . . . . 62

3.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Part II Models for Team Collaboration Capture

4 Team Collaboration Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.1 Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.2 Temporal Network Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3 Representing Team Collaboration Networks in OWL . . . . . . . 72

4.3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.3.2 Terminological Components . . . . . . . . . . . . . . . . . . . . . . . 734.3.3 Assertion Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5 An Ontology System for Team Collaboration Networks . 795.1 Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.2 Named Graph Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Table of Contents vii

5.2.1 Domain Ontologies & Rule Graphs . . . . . . . . . . . . . . . . . 825.2.2 The TCN-S Concept Graph . . . . . . . . . . . . . . . . . . . . . . . 845.2.3 The TCN-S Instance Graph . . . . . . . . . . . . . . . . . . . . . . . 845.2.4 TCN Concept Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.5 TCN Instance Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Part III System Implementation

6 d.store: A Resource-oriented Team CollaborationNetwork System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.1 Platform Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.1.1 Client Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.1.2 RDF/OWL Graph Component . . . . . . . . . . . . . . . . . . . . 906.1.3 Service Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2 The d.store Concept Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3 Processing Temporal Network Properties . . . . . . . . . . . . . . . . . 94

6.3.1 Storing Temporal RDF Statements . . . . . . . . . . . . . . . . 946.3.2 Modifying the RDF/OWL Subsystem . . . . . . . . . . . . . . 966.3.3 Modifying the Relational Storage Interface . . . . . . . . . . 976.3.4 Advantages and Disadvantages of the Approach . . . . . 100

6.4 Implementing the Service Interface . . . . . . . . . . . . . . . . . . . . . . 1016.4.1 Platform Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.4.2 Exploring Team Collaboration Network Resources . . . 1026.4.3 Manipulating Team Collaboration Network Resources 106

6.5 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

7 System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.1 Domain Ontologies for Online Collaboration . . . . . . . . . . . . . . 109

7.1.1 web: An Ontology for Hyperlinked CollaborationResources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

7.1.2 wiki : An Ontology for Wiki-based Collaboration . . . . . 1117.1.3 email : An Ontology for Email-based Messaging . . . . . . 1117.1.4 file: An Ontology for Shared Document Storages . . . . . 113

7.2 Inference Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.3 Preparing the Data Collection Process . . . . . . . . . . . . . . . . . . . 116

7.3.1 Initializing the Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.3.2 Setting up the Sensor Clients . . . . . . . . . . . . . . . . . . . . . . 1177.3.3 Specifying Participant Roles and Alias Names . . . . . . . 118

7.4 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

viii Table of Contents

Part IV Evaluation & Discussion

8 A Pilot Application in Engineering Design . . . . . . . . . . . . . . 1238.1 ME310: A Global Academic Project Testbed . . . . . . . . . . . . . . 124

8.1.1 Project & Team Setups . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.1.2 Process Participants & Team Interactions in ME310 . 1268.1.3 A Shared ICT Infrastructure for Virtual Collaboration 1278.1.4 Privacy and Confidentiality of the Observations . . . . . 1288.1.5 me310 : An Ontology for Project Roles & Participants

in ME310 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.2 A Quantitative Appraisal of the Generated Networks . . . . . . 129

8.2.1 Activities Captured From Email Lists . . . . . . . . . . . . . . 1318.2.2 Activities Captured From the Wiki System . . . . . . . . . 1358.2.3 Activities Captured From WebDAV Folders . . . . . . . . . 1368.2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

8.3 Temporal Variations & Dynamics in Team Collaboration . . . 1388.3.1 Individual Participation on Project Email Lists . . . . . . 1388.3.2 Evolution of Project Wiki Spaces . . . . . . . . . . . . . . . . . . 140

8.4 Performance Correlations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1428.4.1 How Team Performance was Measured . . . . . . . . . . . . . 1428.4.2 Finding Dependencies in the Captured Group

Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438.4.3 Correlations with External Communication Activities 1448.4.4 Correlations with the Number of Shared Resources . . . 1458.4.5 Correlations with Coach Engagement . . . . . . . . . . . . . . 147

8.5 Summary of Findings & Critical Discussion . . . . . . . . . . . . . . . 149

9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1549.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

9.1.1 Contribution to Design Practice . . . . . . . . . . . . . . . . . . . 1559.1.2 Contribution to Design Theory . . . . . . . . . . . . . . . . . . . . 156

9.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1569.3 Legal & Moral Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

9.3.1 Legislations on Monitoring Employees Communication 1589.3.2 Employee’s Privacy and Autonomy . . . . . . . . . . . . . . . . 159

9.4 Recommendations for Monitoring Virtual Team Collaboration1599.4.1 Organizations Should Implement a Monitoring

Scheme in Agreement with Employees and LegalRegulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.4.2 Organizations Should Govern a Virtual CollaborationInfrastructure To Support Monitoring Objectives . . . . 160

Table of Contents ix

9.5 Recommendations for Distributed Engineering Design Teams 1619.5.1 Teams Should Assign a Project Communication &

Information Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1619.5.2 Teams Should Engage With Domain Experts as

Quickly as Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629.6 Ongoing Research & Future Work . . . . . . . . . . . . . . . . . . . . . . . 162

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Appendix

Case Study Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182A.1 Individual Team Member Scores . . . . . . . . . . . . . . . . . . . . . . . . 182A.2 Team Level Scores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Regression Analysis Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

d.store - API Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

List of Tables

2.1 Differences between the Front End of Innovation (FEI) andNew Product & Process Development. . . . . . . . . . . . . . . . . . . . 21

2.2 Contrasting the traditional approach to design with UCD. . . 222.3 Time and space-based views of CSCW technologies. . . . . . . . 362.4 A comparison of properties met by existing instruments

for capturing and analyzing the work of engineering designteams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Statements declaring three node types Email, Person, andTeamMember. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2 Statements declaring a relationship type ‘hasSent’. . . . . . . . . 744.3 Statements declaring an attribute type ‘address’. . . . . . . . . . . 754.4 Statements declaring a network node for a resource

identified by ‘ex:email’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.5 A reified statement to define the validity interval of a

‘tcn:createdBy’ relationship. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.6 A reified statement to define the validity interval of a

‘tcn:mailbox’ attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.1 Graph names and aliases used in the following examples. . . . 825.2 Statements of a domain ontology graph to declare common

node, relationship, and attribute types for email-basedconversations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3 A TCN-S Concept Graph with basic class definitions. . . . . . . 845.4 Statements of a TCN-S Instance Graph to assign two

named graphs as concept and instance models to a TCNinstance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.5 A TCN Concept Graph with import statements and acustom node type ‘tag’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.6 A TCN Instance Model with two node instances andattributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

List of Tables xi

6.1 The 5-tuple schema assigns a validity interval to everyrecord of an RDF statement, reducing the overall numberof statements and allowing for efficient time-point queryingof TCN components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.1 Overview of ME310 projects in 2007/2008 (Skogstad et al.,2009). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.2 Key dimensions of the generated Team CollaborationNetworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8.3 Summary of findings from testing relationshipsquantitatively at the design team level. . . . . . . . . . . . . . . . . . . . 153

A.1 Individual team member attributes queried from thegenerated Team Collaboration Networks. . . . . . . . . . . . . . . . . . 182

A.2 Team-level attributes queried from the generated TeamCollaboration Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

List of Figures

1.1 The instrumentation of virtual collaboration facilitates“in-flight” monitoring of engineering design processesby means of computational capture and analysis ofcollaboration activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 A monitoring service platform provides a common interfaceto distributed clients that are specialized in the capture,analysis, and monitoring of collaboration activities. . . . . . . . . 8

2.1 A standard model in German industry for designing newproducts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 A hierarchy of requirements for system acceptability. Thepurpose of user-centered design is to achieve usability, aprerequisite for usefulness and practical system acceptability. 23

2.3 ISO 13407 - Human-Centred Design Processes forInteractive Systems, an abstraction of basic principles inUCD processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4 The “sweet spot” of good design: innovation is stimulatedby leveraging expertise in each of the interrelated areas ofhuman factors, technical factors, and business factors. . . . . . . 25

2.5 Opportunity for groupware in early design stages. Toolsto support collaboration groups in the conceptual designphase are scarce. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 Adding a semantic layer to information in a virtualcollaboration process by means of descriptive resources. . . . . 58

3.2 An example RDF graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.3 Subclass relationships between OWL and RDF/RDFS. . . . . . 623.4 A graphical notation for RDF/OWL-based ontologies. . . . . . 63

4.1 A Team Collaboration Network with different types andinstances of nodes, relationships, and attributes. . . . . . . . . . . . 69

4.2a Team Collaboration Network at time t− 1. . . . . . . . . . . . . . . . 714.2b Team Collaboration Network at time t. . . . . . . . . . . . . . . . . . . 714.2c Team Collaboration Network at time t + 1. . . . . . . . . . . . . . . . 71

List of Figures xiii

4.3 Graphical notation of node, relationship, and attributetypes that define the terminological components (TBox) ofa Team Collaboration Network. . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.1 Partitioning of a Team Collaboration Networks system intonamed graphs. Socialization of common domain conceptsand isolation of independent TCN instances is achievedthrough the transitive import of ontological fragments. . . . . . 81

6.1 The d.store platform architecture. A variable set ofclients access and modify the state of Team CollaborationNetworks via a RESTful server interface. . . . . . . . . . . . . . . . . . 90

6.2 The TCN-S Concept Graph of the d.store platform. . . . . . . . 936.3 Customized Jena types to address the n-tuple extension in

a Triple. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

7.1 Emails are a popular medium to share and point others torelevant information on the Web. . . . . . . . . . . . . . . . . . . . . . . . . 110

7.2 An ontology for hyperlink relationships between generalcollaboration resources (dstore:Resource) and Web resources. 111

7.3 wiki : An ontology for concepts and properties in Wiki-basedcollaboration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.4 email : An ontology for concepts and properties inemail-based communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.5 file: An ontology for basic collaboration activities in shareddocument storages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

7.6 d.person: A client application to manage the roles (types)and alias attributes of person nodes in Team CollaborationNetworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.1 Roles and process participants in ME310. . . . . . . . . . . . . . . . . . 1258.2 Team members and teaching team during a weekly project

meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.3 Impressions of the ME310 design space at Stanford

University. A shared ICT infrastructure supports globalcollaboration between distributed team members. . . . . . . . . . . 128

8.4 An ontology of project participants and roles in theobserved design curriculum ME310. . . . . . . . . . . . . . . . . . . . . . . 130

8.5 Weekly amounts of emails, hyperlinks, and file attachmentssent via the project lists during the observed project period. 132

8.6 Total amount of emails sent to the project lists of each team. 1338.7 This email was sent by one team member to the rest of the

global project team. The message body provides additionalcontext for attached and hyperlinked resources. . . . . . . . . . . . 134

xiv List of Figures

8.8 Representation of the relationships between email messages(green), attachments (red), and email receivers (blue)captured in one of the projects. . . . . . . . . . . . . . . . . . . . . . . . . . 134

8.9 Total amount of Wiki pages created in the projects. . . . . . . . 1358.10 Total amount of files shared in the WebDAV team folders. . . 1378.11 Snapshot of an interactive visualization of the individual

participation in email-based project communication. . . . . . . . 1398.12 Wiki spaces of projects Theta, Alpha, Gamma. . . . . . . . . . . . . 1418.13 The proportional amount of outbound emails (compared to

team-internal messages) sent by a team correlates positivelyand significantly with the average team member satisfaction. 146

8.14 The average team member satisfaction correlates positivelyand significantly with variables in the online interactionbehavior of the teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8.15 The total number of distinct URLs shared within designteams correlates positively and significantly with outputperformance, suggesting that breadth of shared informationimpacts performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

8.16 The number of coach emails correlates positively andsignificantly with the total number of prototyping activitiesundertaken by design teams, suggesting that coaches havea positive impact on prototyping. . . . . . . . . . . . . . . . . . . . . . . . . 149

Listings

5.1 A SWRL inference rule in RDF/XML syntax. . . . . . . . . . . . . . 836.1 Example of a SQL query that finds all node instance

resources valid on June 1st, 2009. . . . . . . . . . . . . . . . . . . . . . . . . 956.2 Creating a statement table for a TCN instance graph. . . . . . . 986.3 Binding a trigger function ’timetravel’ to the statement

table of a TCN instance model. . . . . . . . . . . . . . . . . . . . . . . . . . 996.4 Querying the currently valid statements from the statement

table of a TCN instance model. . . . . . . . . . . . . . . . . . . . . . . . . . 1006.5 Querying statements from a statement table that have been

valid on June 1st, 2009. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1006.6 Examples of valid d.store URL paths. . . . . . . . . . . . . . . . . . . . . 1016.7 Retrieving all nodes from the latest network representation. . 1036.8 Retrieving all nodes in the network as on June 1st, 2009. . . . 1036.9 Retrieving a list of all Email-typed nodes in the current

network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.10 Retrieving a JSON-formatted node instance. . . . . . . . . . . . . . . 1056.11 SPARQL statements to filter the list of node instances. . . . . . 1066.12 Retrieving Wiki pages that have been referenced in an email. 1066.13 Creating a Node Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.14 Removing a Node Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1087.1 Creating a TCN instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1178.1 Querying emails that have been sent from team members

to at least one team-external person. . . . . . . . . . . . . . . . . . . . . . 1448.2 Querying emails that have been sent from team members

to other team members only. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458.3 Querying Web resources referenced in at least one email

that has been sent by a team member. . . . . . . . . . . . . . . . . . . . 1478.4 Query clause to determine the emails that a team has

received from its coaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

1

Introduction to the Dissertation

1.1 Motivation

The digital revolution and the rise of information and communication tech-nology (ICT) over the last decades has had a major impact on all indus-tries, but is perhaps most visible in commercial aviation. The improve-ments in processes and equipment are apparent when comparing modernair transportation with the pioneering days of aviation. Digital sensors andon-board computer networks today provide pilots with a wealth of datathat is constantly measured, processed, and evaluated throughout a flight.Key metrics and activities are continuously recorded and communicatedto ground control stations for monitoring and guidance. Unexpected signaldeviations are indicators for potential problems, allowing pilots to respondaccordingly and in time. Clearly, the instrumentation of aircrafts has ledto a permanent control over relevant in-flight parameters and to aviationbecoming more reliable, predictable, and efficient (Spenser, 2009).

Collaboration processes in the engineering industry lack a compara-ble set of “in-flight” metrics. In the development of new products, soft-ware, and services, teams and managers rarely have objective real-timedata about the status of their projects. Numerous studies, reports, andpersonal experiences have shown that various problems may result fromthis lack of awareness: communication and information barriers, intrans-parent processes, unforeseen defects, and incorrect assessment of progressand failures (e.g., Brooks, 1995; DeMarco and Lister, 1999). Because a de-tailed overview of team activities is not available, project teams are oftenlimited to “post-mortem” metrics in judging and evaluating their collab-orative work (Sterpe et al., 2007; Tucci, 2008). Efficient instrumentationis required to better monitor engineering design processes and to achieveinsights into beneficial or detrimental activity patterns.

The improvements in computer hard- and software have created newopportunities for monitoring team collaboration. Information and commu-nication technology pervades the work infrastructure of today’s global or-ganizations. Since its public emergence in 1990s, the Internet has becomean inherent component in the work of engineering teams (cf. Mankin et al.,1996). Email and tools for computer-supported cooperative work (CSCW)

2 Introduction

gave rise to the digitalization of task coordination and knowledge exchangeacross temporal and geographical distance. This trend continues as newcommunication channels such as Wikis, social networks, and blogs are find-ing their way into the enterprise. The widespread use of digital media tocommunicate and coordinate in distributed and co-located collaborationgroups has led to a common form of teamwork collectively referred to as‘virtual collaboration’, a subject of intensive research in many disciplines(Powell et al., 2004). How the growing digital footprint of collaboration inengineering design teams can be efficiently exploited for monitoring pur-poses and what we can learn from it are questions that have not beensufficiently answered yet.

Research has begun to examine virtual collaboration in co-located anddistributed design teams. But the lack of a generally applicable instrumentfor recording and analyzing the full range of online team activities hinders abroader investigation. Existing approaches commonly rely on custom toolsthat work well in a specific scenario, collaboration system, or work environ-ment, but which can not be applied in even similar observation contexts.Transferring existing instruments into a broader set of application scenariosoften requires rewriting the software or interfering with the subjects understudy. Repetitive efforts and costs in the observation of virtual collabora-tion processes are the consequence. Furthermore, the possibility for otherresearchers to replicate or verify previous findings, an important criterionfor relevance and rigor in empirical design research (see, e.g., Dixon, 1987),is severely lowered by the use of isolated instruments and data formats.A common technological foundation for monitoring and studying virtualcollaboration in the field is needed, which minimizes the efforts for data col-lection and analysis and which facilitates comparative research in design.This work aims to contribute to this goal by providing methods, applica-tions, and experiences in the monitoring of engineering design teams.

1.2 Why Monitoring of Design Collaboration is Relevant

The need for improved instrumentation in virtual collaboration processesin engineering design is driven by the economic interests of the industry. Asargued in the following three steps, the way design teams work, communi-cate, and interact by means of ICT ultimately influences an organization’spotential to grow and innovate.

1. Economic Growth Needs Innovation. The dynamics of economiclife has always been influenced by wave-like movements, often triggeredby new technology and innovative products entering the market (Kon-dratieff and Stolper, 1935). Innovation is the motor for economic growth

1.2. Why Monitoring of Design Collaboration is Relevant 3

and is therefore to be maximized (Audretsch, 1995). Companies are con-stantly challenged with what has been termed by Schumpeter (1942) as‘creative destruction’: the incessant generation of viable products thatis imperative to stay ahead and survive in a global market. It is nec-essary to understand how innovation occurs in order to systematicallyincrease innovative potential. The foundation for innovation is laid bynew concept creation during the early stages of engineering projects.This ‘front end of innovation’ (Koen et al., 2001) is poorly understoodand presents one of the greatest opportunities for improving the innova-tion process (Reinertsen, 1999). Iterative methodologies such as User-centered Design (e.g., Nielsen, 1994; Constantine and Lockwood, 1999)and Design Thinking (e.g., Kelley and Littman, 2001; Cross, 2006) haveshown to stimulate the generation of innovative concepts (Brown, 2008;Mao et al., 2005). At the same time, there is little understanding of how‘designerly ways’ of interacting and working together can be quantita-tively measured, expressed, or analyzed.

2. Innovation Needs Collaboration. Schon (1992) describes design asa reflective conversation with the materials of a design situation. Hesketches design as an iterative process of “seeing–moving–seeing”: in-terpreting and making sense of the world (seeing), performing actionsto affect a desired change (moving), and assessing the effects in thechanged environment (seeing). Transferred into a team context, de-sign becomes an inherently social, interactive, and collaborative pro-cess. This perspective on design not only reveals the unstructured na-ture of the process, but also the importance of sharing knowledge andrelevant design information in a team. Essays such as The MythicalMan-Month (Brooks, 1995), Peopleware (DeMarco and Lister, 1999),and other more research oriented studies (e.g., Driskell et al., 2003;Thompson and Coovert, 2003) document that efficient team collabora-tion is a dominant factor for the well-being and success of engineeringprojects. Other studies of the design process further prove that com-munication within design teams is instrumental to successful designactivity (Skogstad, 2009; Cockayne, 2004; Cross and Clayburn, 1995).However, while it is generally accepted that collaboration is a criticalfactor in design, only little is known about how collaboration patternsreflect or impact qualitative aspects of the design process.

3. Collaboration Needs ICT. The proliferation of CSCW and virtualcollaboration has fundamentally changed design environments and theway teams communicate and share information (Mankin et al., 1996).Software for virtual collaboration (groupware) has moved to the In-ternet and the World Wide Web, providing an ubiquitous and effective

4 Introduction

medium for connecting people and information. In fact, communicatingover the Internet has become standard and indispensable, especially inglobal organizations. About 62% of all employed Americans have In-ternet access and virtually all of those (98%) use email on the job(Fallows, 2002). Web 2.0 services and other communication channelssuch as instant messaging and Voice over Internet Protocol (VoIP) areincreasingly moving into the workplace (Shiu and Lenhart, 2004). Any-time/anywhere access to groupware and project resources creates anunprecedented level of information availability and facilitates the col-laborative creation of a shared knowledge base. Virtual collaborationeven became common in co-located teams, as the use of groupware tech-nology permits interactions to take place within time frames that fit theconvenience and different work patterns of team members (Katzenbachand Smith, 2001).

The growing availability of online documented collaboration activitymotivates the application of computational techniques to capture, moni-tor, and analyze the collective work streams of engineering design teams.Being able to observe virtual collaboration activities on a detailed levelprovides a foundation for the scientific exploration of ICT-supported de-sign processes. Combined with traditional empirical techniques, the com-putational evaluation of team strategies promises to be a powerful methodto optimize communication and coordination in design processes and toimprove the innovative potential in organizations (Jacoby and Rodriguez,2008; Ashworth, 2007).

1.3 Problem Definition

The instrumentation of virtual collaboration processes in engineering de-sign is confronted with technical and conceptual challenges. These can begenerally related to two major factors: the complexity of design processesand the ambiguity of computationally collected data.

Process Complexity. The computational recording and analysis of vir-tual collaboration demands for a well-defined and unambiguous repre-sentation of the processes under study. Team interactions in concep-tual design, however, are highly dynamic, unstructured, and ad-hocon the level of individual process participants and activities. Dispersedteams, distributed collaboration landscapes, and concurrent interac-tions further add to this complexity. This calls for an extensible andnon-prescriptive approach to capture the ‘who’, ‘what’, and ‘when’ ofa collaboration process in a structured and meaningful way. Due to thediversity of existing and future collaboration environments, the con-structs needed for such a representation can not be statically defined.

1.3. Problem Definition 5

Also, teams generally use more than one collaboration system duringthe course of a project, depending on the prevailing task and situationat hand (Perry et al., 1999). Monitoring a single communication chan-nel can only capture fractional or isolated parts of the collaborationprocess (Olson and Teasley, 1996). To overcome this challenge, a newapproach is required, one that enables design researchers and practi-tioners to monitor collaboration activities on top of a mixed groupwareenvironment. The system must be generic and adaptable to the specifictypes, numbers, and locations of process participants and the utilizedcollaboration tools.

Data Ambiguity. With data available at little or no additional costs, thecomputational analysis of the digital footprint of team communicationpromises to be a cost-effective approach to gain insight into the workof virtually collaborating groups. In contrast to manual data collectiontechniques (cf. Baya, 1996), the automated recording of groupware ac-tivities allows to collect high volumes of data for empirical research(Liang et al., 1999). However, the quality of this data in terms of howit can be interpreted in a concrete team situation is largely unknown.The extent to which the digital representation of groupware activitycan be a surrogate for the original intent is a fundamental question thatis deeply rooted in the nature of communication itself (Shannon andWeaver, 1949). How precisely do the captured symbols convey the de-sired meaning? Recent design studies give first evidence that data at thetechnical level of communication can be an observable surrogate for thesemantic intent of a message (Milne, 2005). Still, it is unclear to whichextent the digital traces of communication reflect or indicate differencesin design team activity and performance. What are relevant patternsand metrics in technologically mediated collaboration that are worthto be observed? Correlations in the digital footprint of collaborationprocesses and independent measures of team effectiveness are relativelyunexplored. Providing evidence of their existence (or non-existence) re-quires a systematic approach to monitor virtual collaboration processeson a larger scale.

In summary, the dissertation addresses the following problems:

1. There is no common technological foundation for the computationalrecording and analysis of virtual collaboration activities, which canmeet the requirements for monitoring the early, unstructured stages ofengineering design processes in the field. This has the following effects:a) Detailed scientific investigations into the use of groupware during

the conceptualization of new products are rare and hindered by

6 Introduction

extra costs and expertise required to implement custom solutionsfor data collection and processing.

b) Existing instruments and studies are generally limited with regardto the type and number of communication channels being consid-ered, preventing a holistic view on the virtual collaboration processand transfer into different design environments.

c) Individual tools and data formats hinder a broader comparison andverification of findings by other researchers. Data samples are notaccessible or can not be reused to reproduce previous findings.

2. Due to the lack of a shareable monitoring platform, existing studiesin design research are unaligned and knowledge about relevant criteriain the technological mediation of design collaboration is fragmented.Coordinated case studies are needed to empirically explore and learnabout design team behavior and to understand how performance isreflected in or influenced by groupware use.

1.4 Research Objective

The objective of this dissertation is to contribute to a better instrumen-tation and understanding of virtual collaboration processes in engineeringdesign teams by providing a platform to systematically measure and studythe use of online communication channels. It accounts for the fact that thedigital traces of virtual collaboration, in their entirety, have up to now re-mained mostly unexploited in the context of observing concept generationduring the early stages of engineering projects. Approaching the abovementioned challenges, the work seeks to create a monitoring instrumentthat facilitates detailed studies of virtual collaboration processes, thus al-lowing design researchers to share their observations and to interconnecttheir collective analysis efforts.

As a second objective, the methods and applications developed in thiswork are evaluated in a series of engineering design projects to empiricallyshow how the virtual collaboration behavior of high-performance teamswas different to that of lower-performing ones. Thus, by contributing newtools and experiences in design team monitoring, the dissertation aims topromote the generation of new hypotheses for further research rather thanto produce generalized knowledge about the process itself.

The work articulates requirements and architectural specifications foran “in-flight” monitoring instrument that is able to serve as a technologi-cal foundation for capturing and analyzing virtual collaboration activitiesin real-time1. Common virtual collaboration activities in engineering de-1 Considering its ambivalent meaning in computer science, the notion of ‘real-time’ refers here

to the ability to monitor collaboration activities in an almost undelayed manner, i.e., withinthe range of seconds after an activity took place.

1.4. Research Objective 7

DesignProcesses

Design Research

Monitoring Instrument

Guidance

Capture Analysis

Refinement

Hypotheses,

Theories & Metrics

Figure 1.1. The instrumentation of virtual collaboration facilitates “in-flight” monitoring ofengineering design processes by means of computational capture and analysis of collaboration ac-tivities. New insights stimulate design research and may lead to the refinement of the instrumentand its application to guide the work of engineering teams.

sign include, e.g., synchronous/asynchronous messaging, or the sharing,accessing, and editing of digital documents. The instrument coordinatesthe automated capture of such activities without interfering with the de-sign process or the applied groupware tools. It establishes a central point ofaccess to detailed information and up-to-date records of how teams inter-act and communicate during their work. Simultaneously, the records canbe used to explore collaboration patterns, trends, and characteristics inthe observed activities, thus providing a basis for empirically researchingthe implicit processes in engineering design projects. New insights, the-ories, and hypotheses can be drawn from the observations and promoteconceptual design methodology as well as the identification of critical col-laboration metrics. Based on this knowledge, the instrument can be iter-atively refined and leveraged to provide engineering teams with improvedin-process support and guidance (Fig. 1.1).

1.4.1 A Service Platform for Virtual Collaboration Monitoring

From a software engineering point of view, the work addresses the challengeof creating an instrument that is applicable in a variety of different collab-oration environments without restricting or interfering with the processesunder study. The proposed monitoring system must be configurable andrespond to distributed design environments, heterogeneous collaborationtool landscapes, and concurrent team interactions.

The work aims for a service-oriented approach to design monitoringby decomposing the system into dedicated function blocks for capturingand processing virtual collaboration activities. Service-orientation definesan architectural paradigm for distributed and loosely coupled software sys-tems that promotes integrability, flexibility, and reusability (Erl, 2005). Ina service-oriented monitoring infrastructure, the capturing, organization,and processing of activity records is decoupled to achieve a high degreeof generality in terms of the observed communication channels, activities,and the intended analysis procedures.

8 Introduction

Engineers

Monitoring Service Platform

Researchers

Collaboration Tools

DashboardClients

SensorClients

AnalysisClients

ActivityRecords

Figure 1.2. A monitoring service platform provides a common interface to distributed clientsthat are specialized in the capture, analysis, and monitoring of collaboration activities.

Figure 1.2 sketches the outlined client-server architecture that is elabo-rated in this work. A central monitoring service platform provides a com-mon interface to store, read, and update a set of records to describe theactivities that have occurred in a virtual collaboration process. Client ap-plications insert or modify records or evaluate the captured activities inone or more engineering design processes: groupware-specific sensor clientscontinuously scan collaboration activities and feed the information to theplatform; analysis clients visualize, explore, and compare different patterns,trends, and characteristics in the recorded events; dashboard clients aim tosupport the work of the engineers by providing functionality to navigatethrough the records and to track relevant collaboration metrics during thedesign process.

1.4.2 Scope of the Dissertation

In the realization of the outlined monitoring infrastructure, the followingresearch tasks fall into the scope of this work: the elaboration of descrip-tive models to record and analyze collaboration activity, the design andprototypical implementation of a service-based monitoring instrument, theintegration and application of this instrument in a series of distributedengineering design projects, and the evaluation of the captured activityrecords with a view towards metrics that correlate with team performance.Research that is beyond the scope of this dissertation includes an analysisof how this instrument can be further refined and used to guide engineeringdesign teams in their processes and how the work of designers and managersis influenced by the availability of dashboards and real-time collaborationmetrics.

1.5. Research Approach & Guiding Questions 9

1.4.3 Underlying Principles and Assumptions

Several assumptions about virtual collaboration underlie this research anddetermine the scope of the work. Assumptions are made with regard tothe intent of the collaboration, the structure of the teams, and the typeof collaboration environments that are being monitored. An elaboration ofthese principles is given in Chapter 2.

Collaboration Intent: The work investigates virtual collaboration activ-ities in conceptual engineering design, i.e., the early stages of an engi-neering project, in which opportunities and innovative concepts for anew product, software, or service are ideated, (re-)designed, and con-ceptualized before the detailed production can begin. The outcome ofthese activities is initially unknown and open-ended, but intends toachieve a viable, feasible, and desirable solution to an identified marketneed. The nature of conceptual design is experimental, unstructured,difficult to plan, and involves considerable application of knowledge,judgment, and expertise in a team.

Team Setup: The team formations in engineering design follow the pat-terns of project teams often encountered in organizations ranging fromstart-ups to multi-national firms. Design teams are specifically assem-bled and usually time-limited to the duration of a project. Team mem-bers are drawn from different disciplines and/or functional units, sothat specialized expertise can be applied to the design task at hand.All members usually show a high level of commitment for the project,trust each other, and share responsibility for the result. Design teamsproduce a non-repetitive outcome, representing either an incrementalimprovement over an existing concept or a radically different new idea.

Collaboration Environment: The work further assumes that team col-laboration takes place in an organizational environment that requiresand facilitates the informal exchange of knowledge and ideas througha set of virtual collaboration tools and groupware. In such an envi-ronment, team members frequently use Internet-based media (email,World Wide Web, etc.) to communicate, document knowledge, and todisseminate information to collaboration partners separated by time orspace. Teams have ubiquitous access to a centrally managed ICT in-frastructure that fulfills basic communication and coordination needs.

1.5 Research Approach & Guiding Questions

The work takes three necessary steps in the construction, application, andevaluation of a service-based monitoring instrument for virtual collabora-

10 Introduction

tion processes. Each step is guided by and provides answers to one partic-ular research question, which are presented in the following sections.

1.5.1 Step 1: Development of a Descriptive Model

Guiding Question: How can arbitrary virtual collaboration activities ofengineering design teams be logically modeled and represented in ageneric format?

The work begins with asking for a descriptive model that is able to serveas a record for the course of virtual collaboration activities in heterogeneousteam processes. To be widely applicable, the model must not be restrictedto a predetermined set of concepts for describing activities within specificgroupware or project settings. An extensible schema is needed, which canbe customized to fit to any kind of observed collaboration process. At thesame time, the model needs to preserve previous states of the recordedprocess to allow for retrospective analyses.

In this work, a labeled graph approach to describe collaboration activ-ities as relationships between resources and/or people is proposed. TeamCollaboration Networks (TCN) define the semantics, occurrences, and tem-poral properties of the actors, resources, and relationships identified in acollaboration process. An extensible set of ontologies provide the linguis-tic constructs needed to describe the interactions with different groupwareapplications. By recording the ‘who’, ‘what’, and ‘when’ in a virtual col-laboration process, Team Collaboration Networks establish a computer-processable description of the online activities in a project and provide thebasis for an analysis of the communication and coordination behavior ofdesign teams.

1.5.2 Step 2: System Implementation & Customization

Guiding Question: What is an appropriate architectural layout for avirtual collaboration monitoring platform and what functionality doesit need to provide?

A service-based software system to capture, monitor, and analyze vir-tual collaboration activities (Fig. 1.2) presents a new approach in designresearch. What services does such a system need to provide to be seam-lessly integrable and applicable in real collaboration environments? Criticalcomponents of the system architecture and their relationships need to bedefined.

The work introduces d.store, a service platform for the computationalconstruction and analysis of Team Collaboration Networks. Applying theresource-oriented architectural style defined by Fielding (2000), a Team

1.6. Results and Contribution 11

Collaboration Network’s state is represented by a set of resources thatcan be addressed in an universal syntax and manipulated by a set ofwell-defined operations. The applicability of this platform is demonstratedin this work. The system is implemented and configured to capture dis-tributed, multi-channel collaboration activities from the groupware sys-tems utilized in different teams. It is shown how the services can be usedto inspect patterns and other characteristics in the observed collaborationprocesses.

1.5.3 Step 3: Application in Conceptual Engineering Design

Guiding Question: Can patterns in the monitored collaboration behav-ior of design teams indicate team performance?

Hypothesizing that high-performance design teams produce differentcollaboration patterns than lower-performing ones, the work continues withapplying d.store in the analysis of eleven engineering projects during aneight-month period of early stage concept creation and prototyping. Theactivities scanned from email archives, Wiki pages, and shared documentfolders are represented as Team Collaboration Networks and provide thebasis for a detailed inspection and comparison of collaboration patterns.In particular, the system is used to test whether the occurrence of spe-cific patterns correlates with independent measures of team effectiveness.Teams have been ranked based on different performance criteria: the av-erage satisfaction of team members as determined by a team diagnosticsurvey (cf. Wageman et al., 2005), judges reviewing the project outcome,and the number of explored design alternatives. Statistical correlationsbetween patterns and team effectiveness are tested by means of linear re-gression analysis (e.g., Backhaus et al., 2008).

1.6 Results and Contribution

Facing the importance of design excellence, global organizations are search-ing for new methods to monitor and evaluate factors that impact the per-formance of their engineering teams. Understanding the necessary require-ments (i.e., how to monitor) and relevant metrics (i.e., what to monitor) isa premise. This work contributes answers to both, the ‘how’ and the ‘what’.It articulates a novel approach to capturing and analyzing ICT-mediatedteam activities in the field and empirically tests observable collaborationpatterns for performance indicators. Team Collaboration Networks pro-vide a descriptive model of the semantic and temporal properties of actorsand information resources during project-based collaboration. d.store, an

12 Introduction

adaptable monitoring instrument consisting of distributed sensor and anal-ysis components, allows researchers and designers to tap into heterogeneousdata sources and to handle the increasing complexity of technology-enableddesign spaces. This way, d.store connects information silos that otherwisewould be scattered across the virtual collaboration landscape. The instru-ment automates the data collection process, provides real-time evaluationcapabilities, and establishes a technological foundation for the exploration,quantification, and comparison of collaboration processes in engineering de-sign. Details of this approach have been reviewed and published (Uflackerand Zeier, 2008a,c; Uflacker, 2007).

Findings from a pilot application give first indications that performanceconclusions can be drawn from virtual collaboration patterns. Patternsthat correlate with independent team performance metrics can be inter-preted as surrogates for ‘outside-in’-driven design and team-internal infor-mation sharing. For example, a positive and significant correlation existsbetween the self-reported satisfaction of team members and a team’s ten-dency to contact external process participants (e.g., end-users, customers,domain experts), suggesting that a close involvement of team-external pro-cess stakeholders has beneficial effects on a project. The results indicatethat high-performance design teams share different collaboration patternsthan low-performance teams, endorsing a continued utilization of the in-strument to evaluate relevant performance indicators and new opportuni-ties in the conduction of real-time team diagnostics. The application andresults of the analysis have been presented at various international con-ferences and publications (e.g., Uflacker and Zeier, 2010b, 2009; Uflackeret al., 2009).

The contribution of this dissertation is also visible in the work of otherresearchers who have applied d.store to analyze virtual team collaboration.Skogstad (2009) has developed new theory about how designers gain in-sights required to create novel solutions and how reviewers can have bothpositive and negative effects on this process. Parts of his hypothesis testingare based on data retrieved from the instrument presented in this work.

1.7 Outline of the Thesis

The document is structured into four parts.

Part I – ‘Background & Preliminaries’ introduces the research do-main, provides technical and theoretical basics, and elaborates on theneeds and gaps addressed by this dissertation. Chapter 2 – ‘A Reviewof Engineering Design Literature’ – gives an overview of existing workin the area of engineering design research, in particular of ICT systemsto support the design process and its scientific exploration. Chapter

1.7. Outline of the Thesis 13

3 – ‘Technological Foundations’ – introduces standards and technolo-gies in the background of resource-oriented architectures and knowl-edge representation, which form a foundation for the development ofthe service-based monitoring instrument.

Part II – ‘Models for Team Collaboration Capture’ introduces da-ta structures that are required to describe virtual collaboration activi-ties. Chapter 4 – ‘Team Collaboration Networks’ – defines a structureto describe the actors, resources, and relationships in a single teamor project. Chapter 5 – ‘An Ontology System for Team CollaborationNetworks’ – describes how multiple instances of Team CollaborationNetworks can be integrated to facilitate the concurrent monitoring andcomparison of different collaboration processes.

Part III – ‘System Implementation’ continues with the developmentof a service-based tool landscape for monitoring virtual collaborationactivities in teams. Based on the requirements and data models de-fined before, a system architecture and implementation is presentedin Chapter 6 – ‘d.store: A Resource-oriented Team Collaboration Net-work System’. The configurability of this system and its preparation fora specific groupware landscape is demonstrated in Chapter 7 – ‘SystemConfiguration’.

Part IV – ‘Evaluation & Discussion’ deploys the monitoring plat-form in real project environments and critically appraises the findingsand insights obtained from the application. Chapter 8 – ‘A Pilot Ap-plication in Engineering Design’ – presents the project setup and theanalysis of the collaboration behavior of eleven distributed teams overa period of eight months using d.store. Chapter 9 – ‘Conclusion’ – sum-marizes the work and discusses the contribution against the backdropof collaboration monitoring and future research in engineering design.

Part I

Background & Preliminaries

2

A Review of Engineering Design Literature

The study of collaboration processes in engineering design is not a newresearch area and has produced a substantial body of literature. In recentyears, social and cognitive viewpoints have increasingly influenced researchdirections in engineering design and opened the field to diverse disciplinesand communities. A common goal of design research is to develop a betterunderstanding of what it is that designers do when they do design (Ju et al.,2007). Design research has begun to identify critical process characteristicsand factors that affect the quality of the design outcome, influencing thedevelopment of new tools and techniques to support designers in the exe-cution and researchers in the observation of this complex activity. A reviewof influential literature in this multifaceted field is therefore expedient andnecessary, before beginning with the construction of an aligned monitoringinstrument.

The review begins with a general overview of theories in conceptualdesign, and then narrows the focus to concentrate on software systems tosupport the design process and its computational observation. The chapterintroduces technology and related work to construct a common terminologyfor the remainder of this thesis, and forms a foundation for the design ofa monitoring system. The review is structured into four interrelated fieldsof design research in order to:

• give an introduction into conceptual engineering design processes, user-centered design, and design thinking, and to explain how and why theseconcepts are understood as a driver for innovation (Sect. 2.1);

• present theories and models for information handling and coordinationin design teams, and to explain the role of ICT and virtual collaborationin engineering design processes (Sect. 2.2);

• give an overview of past and present software solutions used for computer-supported cooperative work in conceptual design (Sect. 2.3); and to

• present related work and existing software instruments to supportthe capture and analysis of team-based engineering design activities(Sect. 2.4).

The chapter concludes with a set of system requirements for a virtualcollaboration monitoring instrument that are derived from the reviewed

18 A Review of Engineering Design Literature

literature and which are used to differentiate this work from previous re-search.

2.1 Conceptual Engineering Design

Conceptual design refers to the activities that occur at the first stagesof a product life cycle. It is an iterative and incremental process and isoften considered the most critical phase of product design (Wang et al.,2002). Vosinakis et al. (2007) point out that “decisions made at this phasedetermine the rest of product development” and that “any unintended mis-takes, misconceptions and omissions have significant negative impact to theproject”.

To reflect and theorize about the design process, a diversity of pre-scriptive engineering process models have been described in the literature,generally varying in terminology, granularity, and industry focus. Prescrip-tive models suggest a systematic and algorithmic procedure that should becarried out, structuring the design process into a set of compartments withwell defined boundaries (Baya, 1996). This is very contrary to how mostdesigners work and what is often observed in empirical, descriptive stud-ies (Finger and Dixon, 1989). Nevertheless, a few shall be mentioned herebriefly to give an impression of what is considered conceptual engineeringdesign.

In general, engineering processes are triggered by a market need or anew idea and start off with the conceptualization of a solution, i.e., themental creation of a new product. However, there is dissent regarding thescope of this design phase, i.e., where conceptual design begins and where itends. For example, Ulrich and Seering (1987) define conceptual design verybroadly as the transformation of functional or behavioral requirements intostructural embodiments or descriptions. Other, more detailed and prescrip-tive models of the design process (e.g., Pahl et al., 1996, Fig. 2.1) isolatethe conceptual design phase from planning and task clarification and theembodiment design. Yet other, more design- and innovation-centric view-points explicitly count the discovery of opportunities and concepts as partof this creative process (e.g., Weiss, 2002, Sect. 2.1.3). This work adopts acomprehensive interpretation in that it understands conceptual design asoutlined in the following definition:

Definition (2.1): Conceptual design in engineering embraces the it-erative development and optimization of an innovative principle solution,comprising diverse activities such as need finding, the formulation of prod-uct proposals, task clarification, elaboration of requirements, the search forworking principles, and the evaluation against technical, economical, andhuman criteria.

2.1. Conceptual Engineering Design 19

!"#$

%"&$'()*+,-."/0)*'+,/,-0

12"/*"/3*+2"&450*(6'*("#$7

8/"20#'*(6'*-"&$'(*"/3*(6'*+,-."/0*#4(9"(4,/

:4/3*"/3*#'2'+(*.&,39+(*43'"#

:,&-92"('*"*.&,39+(*.&,.,#"2

;2"&450*(6'*("#$

<2"=,&"('*"*&'>94&'-'/(#*24#(

?'>94&'-'/(#*24#(

@A'#4B/*#.'+4!+"(4,/C

A'D'2,.*(6'*.&4/+4.2'*#,29(4,/7

E3'/(450*'##'/(4"2*.&,=2'-#

<#("=24#6*59/+(4,/*#(&9+(9&'#

F'"&+6*5,&*G,&$4/B*.&4/+4.2'#*"/3*G,&$4/B*#(&9+(9&'#

;,-=4/'*"/3*!&-*9.*4/(,*+,/+'.(*D"&4"/(#

<D"29"('*"B"4/#(*('+6/4+"2*"/3*'+,/,-4+*+&4('&4"

A'D'2,.*(6'*+,/#(&9+(4,/*#(&9+(9&'7

1&'24-4/"&0*5,&-*3'#4B/)*-"('&4"2*#'2'+(4,/*"/3*+"2+92"(4,/

F'2'+(*='#(*.&'24-4/"&0*2"0,9(#

?'!/'*"/3*4-.&,D'*2"0,9(#

<D"29"('*"B"4/#(*('+6/4+"2*"/3*'+,/,-4+*+&4('&4"

;,/+'.(

@1&4/+4.2'*F,29(4,/C

1&'24-4/"&0*H"0,9(

A'!/'*(6'*+,/#(&9+(4,/*#(&9+(9&'7

<24-4/"('*G'"$*#.,(#

;6'+$*5,&*'&&,&#)*34#(9&=4/B*4/"9'/+'#*"/3*-4/4-9-*+,#(#

1&'."&'*(6'*.&'24-4/"&0*."&(#*24#(*"/3*.&,39+(4,/*"/3*"##'-=20*

3,+9-'/(#

A'!/4(4D'*H"0,9(

1&'."&'*.&,39+(4,/*"/3*,.'&"(4/B*3,+9-'/(#7

<2"=,&"('*3'("42*3&"G4/B#*"/3*."&(#*24#(#

;,-.2'('*.&,39+(4,/)*"##'-=20)*(&"/#.,&(*"/3*,.'&"(4/B*4/#(&9+(4,/#

;6'+$*"22*3,+9-'/(#

1&,39+(*3,+9-'/("(4,/

F,29(4,/

E/5,&-

"(4,/7*83".(*(6'*&'>94&'-'/(#*24#(

I.B&"3'*"/3*4-.&,D'

A'("42*3'#4B/

<-=,34-

'/(*3'#4B/

;,/+'.(9"2*3'#4B/

12"//4/B*"/3*

+2"&4504/B*(6'*("#$

J.(4-4#"(4,/*,5*(6'*.&,39+(4,/

J.(4-4#"(4,/*,5*(6'*2"0,9()*5,&-

#*"/3*-

"('&4"2#

J.(4-4#"(4,/*,5*(6'*.&4/+4.2'

Figure 2.1. A standard model in German industry for designing new products (Pahl et al.,1996). Conceptual design is considered the process of developing a principle solution from a listof requirements.


It should be emphasized that the extent of conceptual design activitiesvaries from project to project. Situations exist in which a solution is fullyknown from the outset and direct progress to the embodiment and thedetailed engineering phase is reasonable. The focus of this work, however,is on open-ended, new product development projects, where the basic so-lution path needs to be laid down through the collaborative elaborationof an innovative principle. In such projects, conceptual design presents anecessary and essential part of the product life cycle. Gero (1998) pointsout that “in conceptual designing not all that is needed to be known tocomplete a design is known at the outset, i.e. part of the process of de-signing involves finding/determining what is needed”. This unclarity anduncertainty in the beginning of a project has motivated the scientific explo-ration of early-stage design activities, often called the “Fuzzy Front End”of innovation.

2.1.1 The Fuzzy Front End of Innovation

The term ‘Fuzzy Front End’ (FFE) has been coined by Reinertsen (1999),who describes it as the stage “between when work on a new idea could startand when it actually starts”. Kim and Wilemon (1999) adopt this notionand speak of the “period between when an opportunity is first consideredand when it is judged ready for development”. Koen et al. (2001) defineFFE as “activities that take place prior to the formal, well-structured NewProduct and Process Development”. The same authors also prefer to usethe term ‘Front End of Innovation’ (FEI) as opposed to ‘Fuzzy Front End’.They argue that the use of the term FFE incorrectly suggests that unknow-able and uncontrollable factors dominate the front end, implying that thisinitial part of the innovation process can never be managed (ibid.). For theremainder of this work, both terms are treated as equivalent.

The fuzzy front end is the beginning of an innovation process that isstructured into three distinct phases: FFE, New Product and Process De-velopment (NPPD), and commercialization (Koen et al., 2002). Severalstudies indicate that those organizations that excel in managing the fuzzyfront end are more likely to succeed in the following phases and to win theinnovation race (e.g., Cooper, 1998; Cooper and Kleinschmidt, 2000). Fur-thermore, there is broad consensus that FFE is usually full of opportunitiesfor improvement and that it presents one of the greatest opportunities forimproving the overall innovation process (Reinertsen, 1999; Koen et al.,2001). Studies of project managers in fast time-to-market industries alsoshow that the initial phase of a complex project has a disproportionatelylarge impact on the end results (Gary, 2003).

However, Kim and Wilemon (2002) note that “many firms, unfortu-nately, acknowledge serious weaknesses in the predevelopment steps of their


innovation process. In fact, data on resources spent [...] show that limitedtime and money are devoted to these early, critical steps”. A reason for thisis that FFE, as opposed to NPPD, is typically poorly understood. Manyof the practices that aid in the NPPD do not apply to the FFE. They fallshort because the nature of work, commercialization date, funding level,revenue expectations, activities and measures of progress are fundamentallydifferent (Table 2.1).

Table 2.1. Differences between the Front End of Innovation (FEI) and New Product & ProcessDevelopment (Koen et al., 2001).

Front End ofInnovation (FEI)

New Product & ProcessDevelopment (NPPD)

Nature of Work Experimental, often chaotic.Difficult to plan.

Structured, disciplined andgoal-oriented with a projectplan.

CommercializationDate

Unpredictable Definable

Funding Variable. In the beginningphases, many projects maybe “bootlegged”, while otherswill need funding to proceed.

Budgeted

RevenueExpectations

Often uncertain. Sometimesdone with a great deal ofspeculation.

Believable and with increas-ing certainty, analysis anddocumentation as the prod-uct release date gets closer.

Activity Both individual and team inareas to minimize risk andoptimize potential.

Multi-functional productand/or process developmentteam.

The differences between FEI and NPPD suggest that “a distinctly dif-ferent approach, skill-set and mindset are required to succeed in each phase”(Skogstad, 2009). Great value is therefore placed by design researchers onbetter understanding and optimizing the front end of innovation, since aproduct is more likely to be successfully developed and marketed when theFFE activities are understood and carefully managed (Kim and Wilemon,2002). Deeper insights into the critical methods by which designers negoti-ate the creative process are required in order to improve its management.Hence, efficient instruments for the observation and assessment of FFEactivities are needed.

Several methodologies and mindsets to guide designers in the organiza-tion and execution of the early design phases have been developed. Twoexamples shall be briefly presented here: user-centered design, a participa-tory approach often associated with the development of interactive softwaresystems, and design thinking, a neoteric term that comprises creativity-


enhancing methods and best practices for the front end of engineeringprojects in general.

2.1.2 User-Centered Design

User-centered design (UCD) describes a design approach that acknowl-edges the following basic principles: the active involvement of users for aclear understanding of user and task requirements, iterative design andevaluation, and a multi-disciplinary approach (Vredenburg et al., 2002b).Thus, UCD emphasizes what is often neglected in the early stages of tradi-tional product development processes: empathy for the targeted user groupand awareness of the human needs. UCD aims for a shift from traditional‘inside-out’ design that is driven by technology and engineers, to a user-driven ‘outside-in’ approach, which is grounded on information about thepeople who will use the product. Table 2.2 summarizes the key differencesto a traditional, technology-driven design approach.

Table 2.2. Contrasting the traditional approach to design with UCD (Vredenburg et al., 2002a).

Traditional Approach UCD

Technology driven User drivenComponent focus Solution FocusLimited multidisciplinary cooperation Multidisciplinary team workFocus on internals architecture Focus on externals designSome competitive focus Focus on competitionDevelopment prior to user validation Develop only user validated designsProduct defect view of quality User view of qualityLimited focus on user measurement Prime focus on user measurementFocus on current customers Focus on current and future customers

The underlying motivation for UCD is to maximize the usability of aproduct, i.e., “the extent to which a product can be used by specified usersto achieve specified goals with effectiveness, efficiency and satisfaction ina specified context of use” (ISO/IEC, 1998). Nielsen (1994) argues thatusability results from the observance of a number of quality measures thatare addressed by UCD: learnability, efficiency of use, memorability, errorrate, and subjective satisfaction. In this argumentation, UCD becomes adominant driver for the usefulness and practical acceptability of a productor system (Fig. 2.2).

Over the last two decades, UCD has received broad attention in softwaredevelopment and the design of interactive systems. User experience has be-come a dominant differentiator in markets where customers “can take theirbusiness elsewhere with just one mouse click” (Mao et al., 2005). Conse-quently, UCD has been advocated by a growing research community, result-ing in a number of prescriptive process models and tool sets to guide in the


Socialacceptability

Practicalaccepta-bility

Usefulness

Utility

Easy to learn

Efficient to use

Easy to remember

Few errors

Subjectivelypleasing

Usability

Cost

Compatibility

Reliability

Etc.

System acceptability

Figure 2.2. A hierarchy of requirements for system acceptability (Nielsen, 1994). The purposeof user-centered design is to achieve usability, a prerequisite for usefulness and practical systemacceptability.

implementation of UCD principles. The basic concepts have their originsin the seminal work of Norman and Draper (1986) on user-centered systemdesign. To endorse the proliferation of UCD best practices, an abstractionof these principles has been defined in ISO 13407: ‘Human-Centred De-sign Processes for Interactive Systems’ (Fig. 2.3). Several instantiations ofthese guidelines have been proposed in the literature: Usability Engineer-ing (Nielsen, 1994), Contextual Design (Beyer and Holtzblatt, 1998), theUsability Engineering Lifecycle (Mayhew, 1999), and others (e.g., Jokela,2002; Vredenburg et al., 2002a). However, usability is often hindered fromplaying a strategic role in organizations due to several problems in its im-plementation (Venturi and Troost, 2004). Surveys have shown that obsta-cles arise for example from resource constraints, ineffective communication

Identify need for user-centered

design

Understand and specify the context of use

Specify user and organizational requirements

Produce design solutions

Evaluate designs against requirements

System satisfies specified

requirements

Figure 2.3. ISO 13407 - Human-Centred Design Processes for Interactive Systems (ISO/IEC,1999), an abstraction of basic principles in UCD processes.


(Rosenbaum et al., 2000), and a lack of effective usability metrics (Vreden-burg et al., 2002b).

2.1.3 Design Thinking

Having received greater momentum in recent years, design thinking hasbecome an expression for a design approach that systematically draws onestablished principles and methods in the conceptualization of a product.Design thinking directs a team’s attention to the full scope of design: under-standing the design problem in a holistic context, collaborative generationof many ideas, and prototyping and testing increasingly sophisticated de-sign alternatives. A similar view on design is given in a definition from Pahlet al. (1996), in which design is described as an engineering activity that

• affects almost all areas of human life;• uses the laws and insights of science;• builds upon special expertise; and• provides the prerequisites for the physical realization of solution ideas.

Accordingly, Sheppard (2003) describes the work of engineers as to“scope, generate, evaluate, and realize ideas”. In contrast to design in thecontext of industrial or artistic design, where it refers to aesthetic form giv-ing, engineering design refers to the iterative and collaborative process ofcreating new concepts (Skogstad, 2009). Design thinking, as understood inthis work, is equivalent to design as seen in the context of engineering. It isa systematic, intelligent process in which designers generate, evaluate, andspecify concepts for devices, systems, or processes whose form and func-tion achieve clients objectives or users needs while satisfying a specified setof constraints (Dym et al., 2006). It involves all aspects of organizationalproblem solving and combines inspiration, ideation, and implementationin an iterative process of concept discovery and concept design (Brown,2008).

Three factors are driving design thinking (Fig. 2.4): desirability (thehuman factor), i.e., the understanding of how people interpret and inter-act with the things they encounter in the world, feasibility (the technicalfactor), i.e., the understanding how new technologies can be harnessed tomake a nascent product or service concept come to life in a way that ismeaningful for users, and viability (the business factor), i.e., understandingwhether embracing a new technology or supporting a particular user needis truly aligned with the organizations strategic objectives and competitivepositioning (Weiss, 2002).

In contrast to a traditional ‘technology push’ methodology, design think-ing embraces factors such as utility, costs, and social acceptability. Withthis holistic approach, it is consequently moving more and more to the


Figure 3.

Figure 2.4. The “sweet spot” of good design: innovation is stimulated by leveraging expertisein each of the interrelated areas of human factors, technical factors, and business factors (Weiss,2002). Design thinking is the iterated discovery, design, and refinement of concepts against thebackdrop of desirability, feasibility, and viability.

center of organizational strategies. Brown (2008) states that “rather thanasking designers to make an already developed idea more attractive to con-sumers, companies are [now] asking them to create ideas that better meetconsumers needs and desires”. He further points out that “the former roleis tactical, and results in limited value creation; the latter is strategic, andleads to dramatic new forms of value”. Design thinking has become a crucialbusiness asset (Jacoby and Rodriguez, 2008) and provides best practicesfor innovation by “making the clients business objectives relevant to theend user, and enabling the users needs to influence the development of theclients business objectives” (Weiss, 2002).

In this work, design thinking is further characterized by the followingthree basic design principles:

Close involvement of end-users and customers. Design thinking isradically “outside-in”. It acknowledges that user requirements and hu-man factors are often unclear and must be well understood from thebeginning. Critical needs must be identified and continuously revisedthrough observations of the use context, user tasks, and customer de-mands.

Interdisciplinary knowledge sharing. Design thinking emphasizes theformation of cross-functional teams and different disciplines in the prob-lem solving process. Intellectual diversity aims to facilitate the collab-orative exploration of “outside-the-box” opportunities through knowl-edge exchange across broad areas of expertise. As David Kelley putsit, “successful design is done by teams. Creative leaps might be takenby individuals, but design thrives on the different points of view foundin teams. You want a multidisciplinary team [...]. You want different


brains working on the problem. Otherwise, the person with the power,or the person who speaks the loudest, sets the direction for the wholedesign” (Kelley and Hartfield, 1996).

A culture of prototyping. Prototyping is an effective mechanism toevaluate (intermediary) design solutions against technical, economi-cal, and human requirements. Following the maxim of “fail early, failcheap”, prototypes in the early stages of concept creation present alow-cost technique to communicate and test design ideas and to ensurethat requirements are well-understood.

A more theoretical approach to characterize design thinking has beenpresented by Eris (2002), in which design is formulated as an alternationof divergent and convergent questioning. Eris distinguishes between gener-ative design questions, where the questioner attempts to diverge from factsto the possibilities that can be created from them, and deep reasoning ques-tions, which attempt to converge and reveal facts. Design thinking becomesa process of inquiries, which is only effective if it includes both “a convergentcomponent of building up to asking deep reasoning questions by systemat-ically asking lower-level, convergent questions, and a divergent componentin which generative design questions are asked to create the concepts onwhich the convergent component can act” (Dym et al., 2006). From thispoint of view, the above mentioned principles of user-centeredness, knowl-edge sharing, and prototyping can be understood as drivers for divergingand converging in the solution space.

2.1.4 Conclusions Drawn From Review

The early stages of engineering projects are considered the most criticalphase of a product lifecycle. Decisions made at this phase determine therest of the engineering process and any misconceptions and omissions havesignificant impact to the project outcome. Design thinking describes anapproach to facilitate the conceptualization of design solutions that meethuman, technological, and business criteria, and is considered a motor forthe “front end of innovation”. This front end must be better understood inorder to support the design process and to systematically strengthen theinnovative potential of organizations.

2.2 Teamwork, Information & Virtual Collaboration

Conceptual design is essentially a collaborative process and involves amulti-disciplinary team of engineers, domain experts, clients, and others(Vosinakis et al., 2007). Because design outcome derives from teamwork,

2.2. Teamwork, Information & Virtual Collaboration 27

any study of design produces more relevant results if it focuses on de-sign teams (Milne, 2005). This is supported by a study of Frankenbergeret al. (1997), who report cases in which designers spent 85% of their timeworking alone, but noted that 88% of the critical events took place dur-ing cooperative interactions. Hence, studying how members of a designteam work together is a necessary step towards a better understanding ofthe design process, because “both the idea and the project team are pri-mary determinants of FFE performance and, in turn, influence and shapethe development phase” (Kim and Wilemon, 2002). This section gives anoverview of concepts, models, and theories that describe the work of designteams, in particular with respect to information handling, coordination,and computer-supported tasks.

2.2.1 Design Teams: A Working Definition

Before reflecting on the work of design teams, it is worthwhile to look at thepredicates of individual designers and teams. A designer is a person who iscommitted to the identification of an engineering problem and the creativeelaboration of an innovative solution to this problem. Designers go beyondthe simple coordination of individualistic work to engage in joint activ-ity aimed at the co-construction of collective work products (Geisler andRogers, 2000). Hence, “designers contribute to finding solutions and devel-oping products in a very specific way” (Pahl et al., 1996). Their individualrole and responsibility in a project is critical, since “their ideas, knowledgeand skills determine the technical, economic and ecological properties of theproduct in a decisive way” (ibid.).

Now, a design team can be delineated by the following core character-istics:

Definition (2.2): A design team is a collection of designers who aredrawn from different disciplines and functional units, are interdependentin their tasks, and share responsibility for the design outcome. It is time-limited and set up to produce an improved or radically new concept for aproduct, software, or service being marketed.

Other typical properties of a design team include its self-managing na-ture, i.e., design teams are responsible for defining the conceptual frame-work for the project and identifying objectives and methods for accom-plishing their tasks. Their work is non-repetitive and involves considerableapplication of knowledge, judgment, and expertise (Cohen and Bailey, 1997;Mankin et al., 1996). Due to the cross-functional, multidisciplinary setup,members of a design team are often geographically distributed.


2.2.2 Models of Design Work

Several prescriptive models, i.e., models that define how a design processought to proceed, have been suggested (Sect. 2.1). It is an often implicit(and untested) assumption of this research that if designers follow the pre-scribed process, better designs will result. Prescriptive models have limitedvalue if they are not grounded on a reasonable body of empirical research(Tebay et al., 1984; Finger and Dixon, 1989). Unlike their prescriptivecounterparts, descriptive models aim to explain empirically how designprocesses really proceed. Based on formal observations and in-depth anal-ysis of design activity, descriptive models define the design process from abehavioral standpoint, forming the basis for the development of new the-ories and hypotheses and for improving design practice. Work in this areaacknowledges that design collaboration basically evolves through a processof social argumentation (Geisler and Rogers, 2000) and that the observa-tion of designers as they engage in collaborative activities can yield a muchmore nuanced comprehension of how they work than any prescriptive modelof a design process could do.

Various approaches for observing and analyzing group design activityhave been presented (e.g., Bessant, 1979; Tang and Leifer, 1991). Centralin many of those group activity studies is the investigation of how designerscommunicate and interact with information. The following sections give abrief overview.

Information Handling in Design

A majority of design activities are associated with information handlingtasks, i.e., tasks undertaken by designers which involve design information.Design information refers to all data that is generated, used, referred to, orconsulted during the design process. Information is handled by means ofcomputational and non-computational tools and exists in a variety of mediaand artifacts such as text, graphic, audio, video, technical drawings, andothers. Designers generate and share information artifacts to communicateknowledge, insights, and proposals about the design state. Each artifactconstitutes an explicit representation of facts, ideas, or emotions that arerelated to the design process.

Baya (1996) has developed an ‘Information Handling Framework’ to im-prove the understanding and support of information handling needs in de-sign. The framework provides a multi-layered classification scheme for ‘in-formation fragments’, including information activity. The framework allowsto characterize the use of design information at a fine-grained level. How-ever, the work focuses exclusively on individual engineers working aloneon design problems, so it can not identify activities that would be charac-teristic of team activity. Milne (2005) extended the framework to account


for activities that would be present in a group-user scenario. The ‘TeamHandling Framework’ provides a coding scheme that can be applied toanalyze activities of design teams during the early phases of conceptualdesign. A quantitative analysis of the design activity, based on a verbalprotocol analysis of two design teams, was conducted, but engaged in aco-located conceptual design activity and did not consider computer-basedor distributed collaboration scenarios.

Wiegers and Knoop (1998) have applied verbal protocol analysis com-bined with software techniques to capture and visualize information han-dling activities and to locate blockades and bottlenecks in conceptual designprocesses. The diagrams visualize process activities and information han-dling, depicted along a time axis, allowing to look out for points of interestsin the design process by identifying fundamental information actions withinthe timeline of a design process. Unfortunately, their model does not reflectgroup interactions and focuses on individual design subjects only.

Information Spaces & Common Ground

Designers continuously mediate between private and public informationspaces by traversing six stages of collaboration and information integra-tion Geisler et al. (1999). Members of a design team come together toshare the results of their private work, to propose, discuss, and ratify nextsteps in the design process, to update their current understanding of the de-sign work, and to disseminate the results of the collaborative conversationback to the private space. Through this repeated positioning of individ-ual viewpoints within a community, process participants construct what isoften denoted as ‘common ground’ (Clark, 1996) or ‘common informationspaces’ (Bannon and Bødker, 1997), i.e., the source of conversants’ abil-ity to coordinate and the set of knowledge, beliefs, and suppositions thatthey believe they share. Clark (1996) stresses that designers solve coordina-tion problems in undertaking a joint activity by using conversational turnsto display their understanding of the current state of activity; an under-standing that other process participants may, in subsequent turns, eitherratify or correct. Geisler and Rogers (2000) adds that “through sequencesof such conversational pairs, participants accumulate the common groundnecessary to support common goals”.

It is obvious that the generation of information spaces and of commonground is immediately affected by the way information is handled in adesign team. Information spaces are a critical source of context and formthe basis for decision making. Thus, it is critical in the empirical observa-tion of a design process to keep a record of the activities and individualcontributions to a teams’ information space.


Collaborating in a Situated Context

While design information is often represented explicitly in shared artifacts,a considerable portion of knowledge remains tacit and implicit in the de-signers’ heads. These internal conceptions are influenced by previous ex-periences and determine how the design context is perceived. From thistheoretical point of view, designing becomes a function of the internal andexternal representations of a designer, which in turn affects both of theseworlds through the actions the designer takes. Thus, the context of designchanges continuously through the recursive activities performed in a team.This concept of situatedness has been described by Schon (1992) as a reflec-tive conversation with the materials of a design situation, which he sketchesas a process of “seeing–moving–seeing” (see also Sect. 1.1, Clancey, 1997;Winograd, 1996, pp. 171).

Fischer et al. (1992) were among the first to describe the design processas a structured set of issues and responses to those issues. In their work,the authors link collaboration with individual work tasks and focus on theargumentative aspect of design. Following Schon’s understanding of situ-atedness, they introduce the concept of construction and argumentation,where construction is the process of shaping the solution (e.g, manipulatingform) and argumentation is the process of reasoning about the problem andits solution. More recently, Gero and Kannengiesser (2004) presented a gen-eral model for situatedness that makes allowance for constant modificationsof the design state, based on present knowledge and expectations of the de-signers. Design representations are distinguished by three semantic classes:function (what the object is for), behavior (what the object does), andstructure (how the object is built) (Gero, 1990). The relationship betweendesign representations and designers are expressed as interactions betweenthe mental and physical environments of the design process. An extensionto the situated function–behavior–structure framework has been proposedto integrate the notion of user needs into the model and to explicitly re-flect core elements of user-centered software design processes (Uflacker andZeier, 2008b).

Seeing design as a reflective, situated conversation in private and publicinformation spaces reveals the importance of communicating and creatingcommon ground in engineering teams. Failure to do so can negatively im-pact the design process and compromise its outcome (Layzell et al., 2000).The creation of common ground is a crucial and challenging task for designteams, but is complicated when team members are distributed in differ-ent locations or otherwise rely on technology-mediated interactions (Perryet al., 1999). The special requirements of virtually collaborating teams needthoughtful consideration and are subject of the following section.


2.2.3 Virtual Collaboration in Design

ICT is the primary enabler for organizations to quickly adapt to newand ever-changing requirements in their competitive landscapes. Hence,computer-supported and distributed collaboration has become a commonphenomenon in engineering design (Jarvenpaa and Ives, 1994). While someauthors claim that distance may no longer be a limiting factor in a group’sability to communicate and is quickly becoming irrelevant (e.g., Cairncross,2001), many researchers found that the nature of technology-enabled in-teractions differ in a number of important ways from face-to-face inter-actions, concluding that distance still matters (Olson and Olson, 2000).Group members who use computer-based tools to coordinate their groupeffort are more likely to face obstacles in the collaboration process (Driskellet al., 2003). We will explore some of the reasons in more detail.

Virtual Teams

The effects of global collaboration in design are often discussed in research.One notion that is frequently used in this context is that of virtual teams.Driskell et al. (2003) gives a short but precise definition for a virtual team:

Definition (2.3): A virtual team is a group of collaborating individualswhose members are mediated by time, distance, or technology.

Because of the distributed nature of their work unit, members of a vir-tual team are brought together by information and communication tech-nologies to accomplish one or more common tasks. Hence, the distinctivefeature of a virtual team is that people rely frequently – and sometimes ex-clusively – on ICT systems to communicate and work together while theyare often dispersed across space, time, and/or organizational boundaries(Powell et al., 2004; DeSanctis and Poole, 1994; Lurey and Raisinghani,2001). As a result of these characteristics, virtual teams are more likely tosuffer from problems of information distribution (Cramton, 1997), face dif-ficulties in creating and maintaining good working relationships (Johnson,1999), and are more likely to have problems in developing mutual trust(Jarvenpaa and Leidner, 1999).

Virtual teams collaborate by means of groupware systems (Sect. 2.3),which establish different kinds of communication channels to support teammembers in their information handling tasks. To study how these systemsare utilized by virtual teams in distributed and co-located team settingspresents a relatively new subject in design research. Olson and Teasley(1996) criticize empirical observations that target only one specific collab-oration tool, such as email, video conferencing, or workflow systems, con-


cluding that it is necessary to study teams with a full set of collaborativetools to comprise all modes of work.

Digital Information Spaces

While the information spaces of traditional co-located engineering teamsare formed by physical artifacts and design representations, virtual teamscreate information spaces that increasingly consist of digital communica-tion and information artifacts. With the proliferation of virtual collabora-tion, the problem of achieving “common ground” has received new atten-tion and influenced the development of collaboration tools to support theorganization of digital information spaces. Schmidt and Bannon (1992) ar-gue that the construction and management of common information spaceshas been somewhat neglected in tool implementations, despite its criticalimportance for the accomplishment of many distributed work activities.Early work investigated how people in a distributed setting can work co-operatively in a digital information space by maintaining a central archiveof information with some level of shared agreement. Such archives are gen-erally constituted and maintained by different actors, who employ differentconceptualizations and multiple decision making strategies, supported bytechnology. However, digital information spaces do not simply consist ofobjects and events, but also crucially involve the joint interpretation ofthese objects and events by the actors involved: “Cooperative work is notfacilitated simply by the provision of a shared database, but requires the ac-tive construction by the participants of a common information space wherethe meanings of the shared objects are debated and resolved” (ibid.). Ac-cordingly, Fischer et al. (1992) suggest that virtual spaces need to providefor the integration of private and public work.

The properties of “virtual” objects shared in a digital information spacehave been investigated by Geisler and Rogers (2000), who identified threecharacteristics shared by such artifacts. They are mutable, meaning theirfunctions and features change during the development process; they aretranslucent, i.e., the knowledge of their functions and features is unevenlydistributed on the project team; and they are considered under construc-tion, i.e., taken by participants to be modifiable rather than done.

Considering the diversity of prevailing collaboration tools and platforms,it becomes apparent that the problem of organizing and sharing commoninformation spaces is still relevant in modern collaboration landscapes. Dig-ital information spaces are clustered and distributed across different teammembers, formats, and communication channels. Communicating and co-ordinating along these heterogeneous sources of information is therefore acritical component in the work of virtual teams that must be better under-stood.


Communication & Coordination Challenges

Communication and coordination defects in virtual teams are one of themajor issues to impact team performance (Powell et al., 2004). Commu-nication comprises meetings, email conversations, file exchanges, etc., thatteams use to share information, negotiate their goals, and make decisions.Coordination is mediated through explicit messages sent at definite timesto specified recipients, or by creating shared information spaces contain-ing versions of the design artifact, argumentation structures, and designrationale (Fischer et al., 1992). The challenges to effective communicationand coordination are manifold. They include the failure to retain contex-tual information, unevenly distributed information, time delays in sendingfeedback, disagreement in the salience of information, differences in speedof access to information, and difficulty interpreting the participation of re-mote team members (Johansson et al., 1999; Lurey and Raisinghani, 2001;Cramton, 2001; McGrath and Hollingshead, 1994). Compared with theirface-to-face counterparts, computer-mediated teams viewed their discus-sions as more confusing and less satisfying, spent more time devising deci-sions, and felt less content with their outcomes (Thompson and Coovert,2003). Furthermore, dispersed members often assume that co-located teammembers are talking and sharing information that is not communicated tothem (Sarker and Sahay, 2002).

The lack of social context and mutual knowledge in virtual teams is afundamental, overarching problem created by text-based and other onlinecommunication channels (Cramton, 2001; Steinfield et al., 2002). Nonver-bal communication, an important component of team communication, isusually reduced in virtual teams because electronic media is intrinsicallyleaner than face-to-face communication and conveys a limited set of com-munication cues (Sproull and Kiesler, 1986, 1992). Thus, teams operatingin a virtual environment face greater obstacles to information exchangethan their traditional counterparts, especially when the virtual team isphysically distributed (Hightower et al., 1998; McDonough et al., 2001).

Empirical studies of how communication and coordination is quantita-tively associated with team performance are relatively rare. Fussell et al.(1998) found that how much teams communicated, what they communi-cated about, and the technologies they used to communicate predicted co-ordination, which in turn predicted team success. Powell et al. (2004) men-tions similar studies, which suggest that the frequency and predictabilityof communication and the extent to which feedback is provided on a regu-lar basis improves communication effectiveness, leading to higher trust andperformance (e.g., Jarvenpaa and Leidner, 1999; Maznevski and Chudoba,2000). Conversely, unpredictable communication patterns have been foundto undermine the coordination and success of virtual teams (Johansson


et al., 1999; Cramton, 2001). With respect to the extent of communica-tion, virtual teams have been found to communicate more frequently thantraditional teams (Eveland and Bikson, 1988; Galegher and Kraut, 1994).


At the core of any design process is communication. Monitoring the workof design teams means to observe argumentative and multidisciplinary in-teractions that are taking place in private and public information spaces.Basis and result of these interactions is information in form of resourcesthat encode facts, ideas, or emotions relevant to the process participants.The virtualization of collaboration processes through computer-based toolsimplicates that the work of design teams is being reflected in the way howdigital information resources are created, shared, and involved in the com-munication process. This motivates a computational monitoring instru-ment to simplify and to extend the scope of empirical design studies. Theautomated creation of a descriptive representation of team activities, dis-tributed design work, and temporal aspects of online information handlingcreates new opportunities for researching performance-relevant collabora-tion patterns on a larger scale. Distributed team structures and virtualcollaboration environments call for a scalable and flexible approach to ob-serve design interactions on multiple communication channels.

2.3 CSCW and Groupware in Conceptual Design

This section highlights existing technology and tools to support virtualdesign teams in the coordination and communication of their efforts. Itoutlines the evolution of design support systems and collaboration plat-forms up to the point of Internet- and Web-based technologies. The reviewshall give an overall picture of computer support systems in conceptualdesign and work out the requirements for a generic monitoring instrumentto observe the utilization of these systems in engineering teams.

2.3.1 Basics of CSCW in Design

The notion of CSCW has been coined by Greif (1988) and others in the1980s to describe computer-assisted coordinated activity that is carried outby groups of collaborating individuals (Baecker et al., 1995, p. 741). Ac-cording to Jabi (2003), the basic principles of CSCW can be traced backto the work of Engelbart (1962), who envisions that computers could helpa design team to solve problems and make decisions. Engelbart states that“there proves to be a really phenomenal boost in group effectiveness over any

2.3. CSCW and Groupware in Conceptual Design 35

previous form of cooperation” and argues: “The whole team can join forcesat a moment’s notice to ‘pull together’ on some stubborn little problem,or to make group decision.” Shortly after, Coons (1963) outlines require-ments for a computer-aided design system: “The Computer-Aided DesignSystem should be capable of carrying on conversations with, and perform-ing computations for several designers at several consoles substantially allat once. In this way each designer can be immediately aware of what theother designers are doing, and thus avoid one of the truly severe problems ofintercommunication that designers face today.” Obviously, achieving com-mon ground and mutual knowledge has been early identified as a subjectof critical importance in CSCW research.

The pioneering visions of Engelbart and Coons set the research agendatone for the next forty years (Jabi, 2003). However, their oversimplified as-sumptions about computer-supported work could not withstand the chal-lenges that reality brings: “Engelbart believes that merging different so-lutions is an easy task and resolving conflicts can occur naturally. Sim-ilarly, Coons falsely believes that synchronicity and social awareness arethe only needed features in addressing the problems that designers face”(ibid.). It took more than two decades before CSCW was understood as amulti-disciplinary research discipline, which needs to combine“the under-standing of the way people work in groups with the enabling technologies ofcomputer networking and associated hardware, software, services and tech-niques” (Wilson, 1991). Around that time, the term groupware has beencoined. The following definition for groupware has been adopted from Elliset al. (1991):

Definition (2.4): Groupware denotes computer-based systems that sup-port groups of people engaged in a common task or goal and that providean interface to a shared environment.

Early research on groupware systems focused on capturing design ra-tionale and organizational memory to support decision making. Prominentwork in this field includes experimental software systems such as gIBIS(Conklin and Begeman, 1989) or Answer Garden (Ackerman and Malone,1990). A second stream of activities was aiming towards the visibility ofconcurrent design activities over distance in time or space (e.g., Ishii, 1990).However, most of the early research-driven efforts to leverage informationsystems in cooperative design practice have consistently fallen short ofexpectations. Grudin (1988) has identified low benefits of use and largeoverhead introduced to the collaboration process to be common challengesfor the development of CSCW applications.


Table 2.3. Time and space-based views of CSCW technologies (Baecker et al., 1995, p. 742).

Same Place Different Places

SameTime

Face to Face Interactions

• Public computer displays

• Electronic meeting rooms

• Group decision support

Remote Interactions

• Shared desktop systems

• Video conferencing

• Media spaces

DifferentTimes

Ongoing Tasks

• Team rooms

• Group displays

• Shift work groupware

• Project management

Communication & Coordination

• Email

• Bulletin boards

• Structured messaging systems

• Workflow management

• Version control

• Cooperative hypertext

2.3.2 Synchronous & Asynchronous Groupware

With the beginning of the 1990s, the maturing and convergence of telecom-munications and personal computing technology has led to an explodingnumber of groupware solutions. Especially in the field of cooperative de-sign, researchers and practitioners started early to adopt and experimentwith groupware (Schmidt, 1998). In fact, the idea of leveraging techno-logical apparatus to support collaborative design dates back to the earlydays of computers and is considered “an inherent human objective” (Kvan,2000; Vosinakis et al., 2008). To categorize the different research streamsin CSCW, DeSanctis and Gallupe (1987) presented a typology of groupsupport systems, subsequently refined by Johansen (1988) to become thewell-known 2-by-2 matrix as seen in Table 2.3. Groupware applications arestructured in terms of their ability to alleviate temporal and geograph-ical distance. Group members may work synchronously (same time) inface-to-face meetings or remote in multiple meeting sites. Asynchronouscollaboration (different times) is taking place on-site or across differentfloors, buildings, cities, or continents. Although a number of extensions forthis taxonomy have been proposed over the years (e.g., Nunamaker et al.,1991; Grudin, 1994), this basic differentiation on a time and space dimen-sion presents a suitable schema for groupware categorization. However, assystems become more functional and grow in complexity, the classificationof groupware is often ambiguous and can not be based on a single category.

Synchronous Collaboration

Synchronous groupware assists a group of individuals in working togetherat the same time. Electronic meeting rooms or remote interactions via


shared desktop or video conferencing systems are examples for ICT-enabledsynchronous collaboration. A central theme in computer-mediated syn-chronous collaboration is ‘WYSIWIS’ (What You See Is What I See),an “idealization of multiuser interfaces in which everyone sees exactly thesame image of the shared meeting workspace and can see where everyoneelse is pointing” (Baecker et al., 1995, p. 745). A pioneering project in thisfield is the ‘Colab’ system, an experimental meeting room designed de-signed at Xerox PARC to support collaborative brainstorming, argumentdevelopment, and freestyle sketching in face-to-face meetings (Stefik et al.,1987). The WYSIWIS paradigm quickly led to various research efforts inthe field of ‘desktop conferencing’. Desktop conferencing describes real-time, computer-based conferences in which users may share data throughtheir personal computers (Ahuja et al., 1990). One early example is the‘Rapport’ system built at AT&T Bell Laboratories, a “multimedia con-ferencing system that allows a group of people, using the computers andphones in their offices, to hold real-time discussions sharing voice, data,and images” (Ahuja et al., 1988).

Systems such as Colab and Rapport represent the starting points forsynchronous collaboration activities mediated over computer networks.With the invention of wide area networks and the Internet, the usage ofthose systems within one single room or building was no longer a restric-tion. Synchronous remote collaboration became technically feasible and dis-persed work groups, who were interacting across longer distances, becamecommonplace in organizations. However, research-driven progress in elec-tronic meeting support did not meet expectations because of shortcomingswith available technology, poor integration, and incomplete understand-ing of the nature of group decision making (Kraemer and King, 1988). Inthe meantime, lightweight general-purpose utilities found their way intodistributed workspaces, supporting ad-hoc communication between two ormore participants via text-based instant messaging or audio/video con-ferencing. Today, instant messaging, video telephony, or desktop sharingapplications are standard tools on personal computers, workstations, andin the daily business of virtual teams (Shiu and Lenhart, 2004).

Asynchronous Collaboration

Asynchronous groupware supports communication and problem solvingamong groups of individuals who contribute at different times (Baeckeret al., 1995, p. 743). Dennis and Valacich (1999) has elaborated severaladvantageous properties that are linked to this type of groupware. Asyn-chronous communication allows team members more time to fine-tune oredit messages in order to establish the reasoning behind it. The communi-cation process is staggered and can proceed independently from the avail-


ability and individual schedule of communication partners. Participantscan post or reply to shared information when they have time to deal withit, making it a convenient tool for teams distributed across time zones.Parallelism in the course of communication allows for the simultaneousinput of information that mitigates blocks in the collaboration process.Finally, messages can be reexamined and processed again later in the pro-cess. Thus, asynchronous groupware facilitates the creation of an electronicteam memory and shared information spaces (Schmidt et al., 2001).

The most successful asynchronous coordination tool to date is electronicmail. Since 1998, the number of email mailboxes has grown from 253 millionto nearly 1.6 billion in 2006, and is growing further (Gantz et al., 2007).Email is fast, easy to use, can address one or multiple receivers, and incor-porates file transfer of, e.g., text, images, audio, video content. 77% of emailworkers say email helps them keep up with events at work and 63% findemail more effective than using the phone or talking in person for makingarrangements and appointments (Fallows, 2002). Loftus et al. (2008) reporton a recent study in which 35% of participating engineers spend on aver-age over two hours a day reading and answering emails. Perry et al. (1999)observed that email was used by distributed design teams to communicatenon-urgent messages, allowing the sender to manage their time resourcesmore flexibly. They report that “email was used as a means of distributingcollaborative work over time so that shared work could be carried out whenconvenient to its recipients. Email could be tightly targeted at particularpeople and did not take up ‘group time’, which was a valuable commodity”.In other cases, email was also used as a means of reminding the othersto perform tasks at the appropriate time. “This function of email as a‘demon’ was used by the team whenever they updated information in theirgroup space that they felt the others would need to know about” (ibid.).

Several extensions to electronic mail have been proposed, includingWinograd’s work on the theory of conversation (Winograd, 1986) and Mal-one’s semistructured messaging systems (Malone et al., 1987). Structuraland semantic frameworks (e.g., McDowell et al., 2004), and other methodsof improvement imposed to email systems, were expected to bring addi-tional benefits in the coordination of processes and information (Fischeret al., 1992). However, most of these systems failed to receive broader at-tention in practice.

2.3.3 Hypermedia & Web-based Collaboration Platforms

Hypermedia systems have been recognized in engineering design even be-fore the World Wide Web became popular (e.g., Conklin and Begeman,1987; McCall et al., 1990). The value that hypermedia brings to engineer-ing teams essentially results from two inherent characteristics: (a) the mul-


tiplicity of connections between media fragments as opposed to the linearstructure of traditional text, and (b) the availability of media other thantext (Fischer et al., 1992). Hyperlinked documents establish relationshipsbetween explanatory, elaborative, and other correlated information, creat-ing multimedia information spaces beyond the text-based level. Graphics,animation, and sound are more effective than text in conveying certainkinds of information such as two- and three-dimensional spatial relation-ships as well as processes, behaviors, and the evolution of a designed prod-uct (ibid.). However, it was not before the vast proliferation of the WorldWide Web that this concept broadly influenced design collaboration. TheWeb has simplified the platform-independent integration, combination, anddissemination of distributed information resources. With the new centuryapproaching, the Internet has become a unique infrastructure for resourceintegration, data sharing, and design collaboration and constitutes a de-signer’s reference library (Wang et al., 2002). Distributed design processeshave been physically enabled by the Internet and are functionally supportedby numerous types of applications and services provided on the Web.

Wang et al. (2002) remarks that mature groupware has found its wayespecially into areas such as simulation, analysis, and optimization. Later-stage engineering activities such as detailed design and production receiveintensive tool support, for example through professional computer-aideddesign (CAD) solutions. But relatively few applications exist at the con-ceptual design stage, where the impact of decisions is still high (Fig. 2.5).Many approaches to support the early-stage conceptual design processfailed to gain foothold, “because knowledge of the design requirements andconstraints during this early phase of a product’s lifecycle is usually impre-cise and incomplete, making it difficult to utilise computer-based systemsor prototypes” (ibid.).

� ��) �� .�� ) �� 0��

�� %B3B� ,��

.�� /

"�,�� ) �� 8��

�� +2� 9�) � +-�

2�� :� �2� 9�� 2�� :�

�� #2. 9#�� 2�� .��:� ��

�� >��

��= �� -��/ � �� .��

��

�� ) �� )/ � ��;��)�

�� 8�� 8

�� ) �� /

+� �� )��)

�� ) �� .�� 8

��) �� ) �� ;��

�� )� ��,�� 8

�� ,��8�� )�� / +��

�� ,��

�� ,��/

� �� -�� &

$''' 6E7� �� <��8

�� ) ��

�� )

�� 8

�� ;��) �� ) �� /

2�� 3' !�� $'

��!�� ,� �� )

�� / +� �� ,��

�� 8

�� )� �� ) ��

�� / +� �� !�� 8

�� ) ��

�� /

� ��

)*+* ��

�� ,�� 8�� 8

�� <�� ,��

�� 6D7/ ��

�� )�� ,��

�� ,� �� 8

�� 6A7/ .� �� ,��

� ��-�� 6G7/ +� ��) ��

�� ) ��

�� ,�� <��) ��

�� <��= ��/ +�� ,� �

�� ,��) �� ,��

�� ,� ��

�� 637/

+� �� )� ,��

�� , �� ,��

� �� ) �, �� -�� / .� ��

�� ,�� !��) ��

�� ) ��

6B�%'7/ � �� ) ��II) �� 8

�� ,�� <�� ;��

��/ .� ��

�� / ��

�� 6%%7� ��

�� 6%$7 �� ,/ ��, �� =�

�� / J�� / ��

�� =� ��

�� ) ��

$& �� 6%*7/ �� $&

��!�� !�� *& ��/

2�� <��

��

��8�� )/ �� /

� �� & 4# 9��8��)��8��8��:

�� 8

�� ,�� )�� 6%7/ �� / 6%A7 ��,�8

�� ,��

�� ) ��

�� 8�)�� 8

�� )� �� 8

�� / +�� <�� ,��

��)� �) ��8&�� 6%E7� ��

�� <��

��!�� / ��8@��I �� 6%D7

�� 9@ : ��

��

�� ,��

�� / 2�� 8

;� �) �� ( ��) �� -��

�� / +� �� 8

�� ;�� /

#�� ,�� ) ��

�� ,��/ K��)� ��

��) �� /

K��)� �� ,��

��;� �� ;��/ .� �� ,� �)

�� ) ��

�� ,�� 8

�� ) ��

�� / L) ��

�* ,�� * - ��%��'. �� /�� 0� 1)��)2 3�+433�B3$

?��/ %/ M ��) �� ) �� /Figure 2.5. Opportunity for groupware in early design stages (Wang et al., 2002). Tools tosupport collaboration groups in the conceptual design phase are scarce.


Leifer et al. (2002) stress the importance of user-editable Web pagesystems in conceptual engineering design. Early systems such as Sparrows(Chang, 1998) and the subsequent popular Wiki applications lower thebarrier-to-entry for Web content producers by providing means to con-tribute and edit content directly in a Web browser. Chen et al. (2005) havehighlighted Weblogs (blogs) and Wikis as valuable knowledge managementand group communication tools in engineering communities. They pointout that “the rapid rise of interest in software to support group interactioncan be attributed to an emerging Web-based platform based on blogs, Wikis,and RSS feeds, on ease of use, and on the ubiquity of web access. In theprofessional and personal worlds, social interactions increasingly occur andmove fluidly between virtual and face-to-face environments”. Standardizedformats and protocols further promoted this trend and led to a richnessof convenient, interactive, and interconnected online services collectivelytermed the ‘Web 2.0’ (O’Reilly, 2005).

Several other tools and frameworks to support conceptual design havebeen presented (for a comprehensive review see Wang et al., 2002). Thevariety of work modes in engineering collaboration led to a trend towardsfunctionally-rich platforms that integrate synchronous and asynchronoustool sets under one user interface and administration. One example isBSCW1 (Basic Support for Cooperative Work). BSCW was the first fullyWeb-based integrated groupware system without need for special clientsoftware (Appelt, 1999). It is a shared workspace system, where authenti-cated members own and manage hierarchically structured document repos-itories stored on a central server. BSCW features distributed documentsharing, group discussions, workflow management, mail lists, polls, andawareness mechanisms such as a daily report, information on currentlyonline members, or history of workspace events (Fischer, 2007). Over theyears a large number of such versatile solutions have entered the market, of-tentimes referred to as group decision support systems. Younger examplesinclude enterprise collaboration platforms such as WebSpace2 (formerlyipTeam), a content management system offering a suite of tools for sup-porting collaborative product development, and SAP StreamWork3, a flex-ible and modular Web application for project planning and management.Microsofts product portfolio features several solutions to support asyn-chronous collaboration and information handling in virtual teams. Share-Point4, e.g., is an application that provides a Web-compatible interface forsharing, editing, annotation, and searching documents and information in

1 http://www.bscw.de/2 http://www.nexprise.com/3 http://www.sapstreamwork.com4 http://sharepoint.microsoft.com


a central project repository. It is extensible, integrable into other Microsoftproducts, and has basic support for workflow management.

Systems such as BSCW and other tools for virtual collaboration man-agement were the precursors for a special branch of groupware solutions,which have specialized on the improvement and support of software engi-neering processes.

2.3.4 Application Lifecycle Management Platforms

The term Application Lifecycle Management (ALM) denotes the coordi-nation of activities to produce software applications, i.e., the managementof their development, deployment, and maintenance phases. An ALM solu-tion is the integration (or connection) of different lifecycle tools to supportin this process (Schwaber et al., 2006). Several of those solutions – com-mercial and non-commercial – are available to provide teams with an usu-ally exhaustive number of integrated lifecycle components, e.g., for projectmanagement, modeling and design, requirements analysis, change and con-figuration management, testing, and deployment. More recent ALM toolsalso increasingly support the monitoring of software development metrics.

A few examples of ALM solutions shall be briefly mentioned. Team-Forge5 offers project management and collaboration support for softwaredevelopment teams, integrating issue tracker tools, source code version con-trol, discussion forums, Wikis, release management, project dashboards,and much more in a Web-based interface. Microsofts Team FoundationServer6 (TFS) provides a rich ALM platform designed to support largesoftware development teams. It offers typical application lifecycle manage-ment functionality and allows to combine version control, build manage-ment, and other tools in an integrated development environment. TFS alsosupports the automated creation of reports to inform stakeholders, devel-opers, and managers about software metrics, issue tracking, or the status ofthe project in general. Borland Management Solutions7 connect a modularand extensible ALM tool infrastructure on top of an open ALM platform.An integrated data warehouse allows the generation of reports to analyzethe software development process from different angles.

ALM solutions do not only focus the early project stages of conceptualdesign activities, but aim to support the software development and deliv-ery process from a holistic standpoint. Hence, the monitoring capabilitiesprovided by some of the solutions primarily address the observation andanalysis of typical software development metrics usually concerned with

5 http://www.collab.net/6 http://www.microsoft.com/visualstudio/en-us/products/2010-editions/team-foundation-

server7 http://www.borland.com/de/solutions/software-delivery-management/index.html


source code measures, requirement coverage, performance checks, etc. So-cial factors, such as the communication and interactions between involvedstakeholders are usually not considered or captured.


Having come a long way from the early days of the Internet and before,CSCW in design has reached the World Wide Web in an era where thehandling and exchange of multimedia documents, messages, social bonds,expert knowledge, and community-generated content is omnipresent. TheWeb has become an universal platform for versatile groupware applicationsand for synchronous, asynchronous, remote, and co-located design collab-oration. While it can be assumed that the Web will retain its central roleas a technological platform for virtual collaboration, it is apparent thatgroupware applications will continue to evolve and improve. Functionallycomprehensive, yet domain-specific collaboration platforms such as TFSor TeamForge can cover most of the basic information handling needs ofspecific virtual teams. But especially in the early stages of idea genera-tion and conceptualization in cross-disciplinary projects, large integratedtoolsets may prove to be too inflexible and are likely to be replaced ortemporally complemented by other, more appropriate services. Monitoringvirtual collaboration activities therefore requires to consider heterogeneousgroupware landscapes, and an external instrument that is largely indepen-dent of the utilized tools and platforms. The resource-oriented client-serverarchitecture of the Web represents the common denominator of moderngroupware solutions and forms a stable basis for the design of such aninstrument.

2.4 Instruments for Virtual Collaboration Monitoring

The final section of this chapter summarizes work that was conducted onsoftware instruments to capture, monitor, and analyze collaboration activi-ties in engineering design teams. The purpose of this review is to learn fromprevious approaches and to understand basic needs in the instrumentationof design processes. A set of system requirements for a virtual collaborationmonitoring instrument is derived from the reviewed literature and used todifferentiate this work from previous research.

The review considers work that comprises software instruments to cap-ture data about the communication and coordination behavior in collabo-ration process with the goal to document and study this process and/or tosupport the work of the collaborating group. Particular attention is givento those approaches that focus on the application in engineering design pro-cesses. Three different categories of instruments are distinguished: 1) those

2.4. Instruments for Virtual Collaboration Monitoring 43

that concentrate on information artifacts and the temporal and semanticrelationships between those artifacts, 2) those that concentrate on the ac-tors and participants in the collaboration process and their relationshipsthat evolve through communication, and 3) those that apply a combinedview that addresses both the information artifacts and the involved stake-holders. Existing work from each of these three categories is presented inthe following sections.

2.4.1 Monitoring of Information Artifacts

The tracking of documents and other information resources created in adesign process has a rather long history and represents the beginning ofcomputational monitoring instruments in this field. In general, the goal ofsuch instruments is to capture syntactic or semantic relationships betweenartifacts that have been created by the designers or the design tools duringthe course of a design process. The information is used, e.g., to retracethe design evolution and rationale, or to make the structural and temporaldependencies between relevant information resources more transparent.

One of the first approaches to supervise the use of design tools is asystem presented by Di Janni (1986). The ‘Monitor’ system is based onan extended Petri Net model and handles the interactions among a set oftools for designing integrated circuits. The places of the Petri Net representinput and output files and the transitions represent tools. The focus of thesystem is on design automation. It aims to support users in the execution oftool chains and to provide updated documentation for individual subpartsof the development process. The rigidity of the underlying Petri Net modeland the absence of a mechanism to maintain a history of the design aremajor deficiencies of this approach.

Casotto et al. (1990) presented an automatic design manager (ADM)based on design traces. A design trace is a directed and acyclic graph,in which nodes represent either design data or CAD transactions. Thetrace is a syntactic and historical model of the design activity that is builtautomatically and non-intrusively by the design tools. A client-server ar-chitecture supports the integration of tools that inform the server abouttheir execution and other programs that query the server for informationabout design activity. Despite many innovative features, the ADM systemgenerates a rather abstract representation of transactions initiated from aUNIX shell that are using some data objects as inputs and produce otherdata objects as outputs. Non-linear and parallel activities in team-baseddesign processes, as understood in this work, can not be addressed by thissolution.

SHARE (Toye et al., 1994) is an open, heterogeneous, network-orientedenvironment for concurrent engineering, particularly for design informa-


tion and data capturing and sharing through asynchronous communica-tion. SHARE enables engineers to participate in a distributed team, allow-ing them to achieve a shared understanding of their processes and artifactsusing email, Web-based tools, and agent-based services.

A method to visualize the progress of engineering design processes hasbeen developed by Wiegers and Knoop (1998). The process is depicted asa series of activity boxes and information events that are aligned along atime line. Information events are either requests for information, answersto requests (information inputs), or results produced by the designer (in-formation outputs). While the visualizations are generated by a softwaretool, the approach relies on data that is manually assembled during the ob-servation. The presented information handling process model is simplisticand does not reflect complex relationships in realistic, team-based designlandscapes.

Yen (2000) has analyzed the relationship between verbal communica-tion and sketch activity in conceptual design with a tool called ‘Recall’.The system has been applied in a number of short-term design sessions tosimultaneously capture audio and video along with sketching activity ona digital whiteboard. His analysis shows that sketch activities serve as aprecise and relevant index into the conversation of a design session, sug-gesting that a time-stamped sketch archive might be an effective techniquefor retrieving design information.

Lim and Sato (2001) developed a Design Information Framework (DIF)to support work among multi-disciplinary team members during the designof interactive software systems. DIF establishes an evolutionary ontologyfor design information consisting of general and project-specific elements.Based on their work, Jung et al. (2005) describe a knowledge managementsystem that organizes distributed multi-media information resources to fa-cilitate knowledge sharing and reuse in the creation of user scenarios. Thesystem focuses on automating the evaluation of different design aspectsand does not consider design history, nor does it capture the process ofdesigning itself.

2.4.2 Monitoring of Process Participants

The idea to track the activities of individual actors in the design processis relatively young. Most of the existing work has been influenced by thegrowing research interest in the area of social networks and social networkanalysis. A common goal of these studies is to identify relationships betweenactors in the design process that result from interactions or informationthat has been exchanged between two or more participants. The resultingstructural properties of a team can be used to analyze, e.g., the impact


of social factors, team setup, or specific communication patterns on thedesign process.

Wong and Burton (2000) presented a comprehensive study of the char-acteristics of virtual teams and the impact of distributed collaboration onteam performance. Using a discrete event simulation model, the authorssimulated different virtual team models and examined their impact on var-ious team performance dimensions. Task structures and the description ofactors were the input variables for the simulation. Their results describedifferent effects that virtual team characteristics can have on team perfor-mance.

Bird et al. (2006) studied the relationship of communication and coor-dination activities of open-source software developers, as revealed in theemail archives, to their software development activities documented in thesource code repository log files. By collecting data from the Apache HTTPserver project, the authors applied social network measures to identify sig-nificant roles and actors in the generated communication structures. Thework does not go into details about the underlying data model and theapplicability to other projects and groupware.

‘TeCFlow’ (Gloor and Zhao, 2004) is a tool to generate interactivemovies of communication flows among individuals by mining email logfiles. It visualizes the social bonds between email senders and receivers ina graph and allows to explore its evolution over time. The TeCFlow sys-tem has been applied in open-source communities and different studentgroups to identify correlations between the temporal communication pat-terns and different measures of team performance (Kidane and Gloor, 2007;Gloor et al., 2008). The ‘iQuest’ system (Gloor and Zhao, 2006) extendsthe TeCFlow concept by adding support for multiple data sources andfunctionality to explore related communication resources based on termfrequency.

2.4.3 Combined Monitoring of Information and Participants

Few approaches exist that monitor the design process in terms of the in-formation resources and the actors that are involved in the handling ofthose resources. The benefit of such a holistic view on the design processis that it combines the analytical potential of the two previous categories.By recording the relationships between captured activities, information re-sources, and the participants involved, the instruments are able to establisha detailed description of the collaboration process.

Ramesh and Tiwana (1999) have developed a system to support knowl-edge management tasks in collaborative new product development. Thesystem allows a group of distributed users to co-create a semantic networkof design concepts, issues, alternatives, assumptions, or any other ontologi-


cal component for classifying their design knowledge. Web resources can belinked to the nodes in the network to provide supporting documents. Basicfunctionality for semantic integrity checks and deductive rules is provided.Using this facility, team members conduct conversations via a graphicalinterface to generate a structured representation in terms of the primitivesspecified in the ontology. The users can communicate their viewpoints andexpertise and map their views of the problem with those of others. Howthe generation of these models can be automated and linked to other com-munication channels is not reported.

Milne (2005) presented an information-theoretic approach to study theuse of ubiquitous computing workspaces in distributed engineering designteams. The study is based on a groupware system called ‘GroupBoard’,which supports distributed engineering design teams in synchronous col-laboration tasks. GroupBoard integrates different communication channelssuch as audio, video, sketching, text messaging, and application sharing inmultiple physical workspaces. In the analysis, event messages that are ex-changed between connected workspaces to synchronize remote interactionsare captured to provide a high-resolution record of pen strokes, keyboardentries, etc., per individual participant. Thus, the instrument is well suitedto efficiently examine how the nature of the developed collaboration tool in-fluenced design activities in detail. The exploration of long-term conceptualdesign processes, in which asynchronous information handling on differentcommunication channels considerably determines the tenor of communica-tion in virtual teams, has not been addressed.

2.4.4 Derivation of System Requirements

From the above review of conceptual engineering design, information han-dling, and virtual collaboration in design teams, it is apparent that themonitoring of groupware use ‘in the field’ is a complex objective to achieve.Due to the number of activities to observe at multiple sites, the wide vari-ability that may be found in tools and group composition, and the rangeof environmental factors, the demands for an applicable monitoring sys-tem are challenging. Based on the reviewed literature and the researchobjectives defined before (Sect. 1.4), the following section lists five basicproperties P1 – P5 that have been identified to be relevant in the contextof observing virtual collaboration processes. Hence, the properties defineimportant requirements for the monitoring system presented in this work.

P1: Extensibility in Terms of Data Collection. The software land-scape in creative collaboration processes like engineering design willremain heterogeneous. The unstructured and varying nature of teaminteractions in the early stages of design demands for diverse sets of


support tools with different strengths and characteristics. Extensibilitywith regard to data collection ensures that a monitoring system can beeasily configured to incorporate new types of communication channelsand groupware activities without the need to modify the underlyingstructure of the system. This property reinforces the need for a flexibleand generic data model to consolidate different collaboration activi-ties, and for a uniform interface to access and store information aboutheterogeneous communication artifacts.

P2: Extensibility in Terms of Data Analysis. Extensibility in termsof data analysis provides for the possibility to implement custom pro-cedures for the evaluation of the collaboration activities being recordedby the instrument. The analytical extensions may comprise, e.g., newforms of visualizations, statistical evaluations, or collaboration dash-boards. To allow for a variety of analytical procedures to be applied, themonitoring system must provide an appropriate interface to a canoni-cal data model through which attributes and patterns of the monitoredcollaboration process can be queried.

P3: Automated, Non-Interfering Data Collection. The automatedcollection of collaboration data should not interfere with or hinder thework of the observed process participants. Hence, it must not rely onor be manually triggered by explicit actions being introduced into thecollaboration process. Any additional efforts required will interfere withthe natural behavior of the process participants and lead to changedbehavior and a low acceptance of the system.

P4: Real-Time Analysis. The term ‘monitoring’ denotes the inspectionof the current conditions of a system under observation. Hence, themonitoring of team collaboration requires the immediate processing ofcollaboration activities in order to allow for real-time inspection andanalysis routines. Only if the system provides an up-to-date view onthe status-quo of the collaboration process, researchers and practition-ers can respond to a given situation in a timely manner. Although theutilization for the purpose of guidance and team support is not ex-plicitly addressed in this research, the basic capabilities for real-timeprocess diagnoses need to be provided by a monitoring system.

P5: History & Backtracking Support. Cooperative work in engineer-ing design is situated in social and historical activities, which are influ-enced by former practice, experiences, and information shared in theteam. The study of groupware use in engineering projects should there-fore be able to extend over a longer period of time, in order to addresstemporal and causal dependencies in the analysis. For this reason, amonitoring instrument should be able to reproduce previous states ofthe communication structures to allow for the backtracking of collabo-ration activities and the exploration of trends and prior conditions.


The following section summarizes the shortcomings of current solutionsand argues that meeting all of the above properties marks an importantstep towards a better instrumentation of virtual collaboration processes.

2.4.5 Moving Beyond the Existing Literature

New tools are required to advance design research in the age of the Inter-net and the World Wide Web. A flexible approach is needed, which lowersthe technical monitoring barriers for researchers and practitioners by beingapplicable in various collaboration environments. Only by decoupling thedata collection process from the data modeling and analysis, a reusable ob-servation platform can be created that is able to adapt to different scenariosat a time and which is not restricted to a specific CSCW environment. Thefive general system properties listed above set the framework for the designof such a monitoring instrument that is extensible in terms of data collec-tion and analysis, non-interfering, and essential for the evaluation of virtualcollaboration processes. Table 2.4 gives a subjective summary of how wellthese properties are met by existing monitoring approaches presented inthe reviewed research work.

The table shows that some of the more recent approaches are movingin a promising direction. Especially the work of Milne (2005) has set anew benchmark for a versatile monitoring instrument that allows to ob-serve how teams interact with synchronous groupware on a fine-grainedlevel. Unfortunately, the instrument is tightly integrated into a prescribedsolution for “shared desktop” design sessions and seems not to work wellwith the long-term, asynchronous collaboration structures of email andWeb-based groupware systems.

Other monitoring approaches that are not often discussed in this line ofresearch are those that are integrated into commercial ALM platforms suchas Microsoft’s TFS and Borland Management Suite. While these solutionscan offer advanced reporting functionality with a wide range of predefinedand extensible project metrics, the scope and focus of such systems gener-ally does not conform well with the needs of early-stage conceptual designteams. Status reports and team statistics integrated into single CSCW toolsor collaboration platforms can only address part of the information spaceand hence capture fractions of the communication structures in a team.

Thus, in order to make progress with the broad instrumentation of vir-tual collaboration processes, a technological foundation for monitoring ar-bitrary collaboration activities must be created that is stand-alone and in-dependent of existing collaboration tools. This forms a basis for providingmonitoring functionality as a lightweight service to teams and observers,who can tailor the system to their specific environments, compare their

2.5. Chapter Summary 49

Table 2.4. A comparison of properties met by existing instruments for capturing and analyzingthe work of engineering design teams.

P1 P2 P3 P4 P5

Focus on Information Artifacts

Di Janni (1986) + ◦ ◦ + ◦Casotto et al. (1990) + + + + +Toye et al. (1994) + + + ◦ ◦Wiegers and Knoop (1998) + ◦ ◦ ◦ ++Yen (2000) ◦ ◦ + ◦ ++Jung et al. (2005) + + ◦ ◦ ◦

Focus on Process Participants

Wong and Burton (2000) + + ◦ ◦ ◦Bird et al. (2006) ◦ ◦ ++ ◦ ◦Gloor and Zhao (2004) ◦ ◦ ++ ◦ ++

Combined View

Ramesh and Tiwana (1999) ◦ ◦ ◦ + +Milne (2005) + + + + +Gloor and Zhao (2006) + ◦ ++ ◦ ++

Legend: P1 Extensibility in Terms of Data CollectionP2 Extensibility in Terms of Data AnalysisP3 Automated, Non-Interfering Data CollectionP4 Real-Time AnalysisP5 History & Backtracking Support++ fully meets property+ mostly meets property◦ doesn’t have property, or limited

findings, and reduce the overall efforts caused by setting up a custom in-frastructure. The instrument developed in this work realizes this approach.

2.5 Chapter Summary

The chapter has introduced engineering design as a core discipline of orga-nizations involved in the creation of new products, systems, and services.Design comprises the iterative team-based generation of concepts, fueledby intense collaboration and information handling, and aiming to achievean innovative concept solution to be productized. Ad-hoc communicationand coordination of information resources is at the heart of engineeringdesign, resulting in mostly unstructured and unpredictable workflows. ICTis playing a major role in supporting these workflows. Different types ofgroupware applications and communication channels determine today’s vir-tual collaboration environments. With the digital footprint of design work


growing, new opportunities for the instrumentation of the design processarise.

To better understand and optimize engineering design collaboration,means to efficiently monitor and analyze ICT-mediated team activities arerequired. Existing instruments have been presented to support the obser-vation of virtual collaboration activities in research and praxis. They havebeen compared on the basis of key properties found to be relevant in thecomputational monitoring of engineering design and a need for an exten-sible approach has been identified. The new system has to respond to therequirements of online, Web-based team collaboration, and facilitate non-interfering data aggregation, processing, and real-time analysis. Flexiblestandards and a sound technological foundation are required to establishsuch a technique. The following chapter introduces concepts and technol-ogy that provide the basis for the development of an applicable monitoringinstrument.

3

Technological Foundations

The design and implementation of a service platform for virtual collab-oration monitoring is tightly linked with the service-oriented computingand architecture paradigm in software engineering. This chapter gives anintroduction into relevant concepts and standards to provide a commonunderstanding of the underlying design principles that influence the devel-opment of the instrument.

3.1 Definitions

A number of basic terms need to be clarified before continuing with anelaboration on service engineering principles and Web technology. Some ofthem have already been used in this work sporadically, but have not beenprecisely defined yet. To start with, the notion of a system is introduced.

Definition (3.1): A system is something of interest as a whole or ascomprised parts. Therefore a system may be referred to as an entity. Acomponent of a system may itself be a system, in which case it may becalled a subsystem (ISO/IEC, 1996).

For the scope of this work, two types of systems can be differentiated.One are the instances of engineering design processes that we want tobetter understand and that comprise complex subsystems such as involvedstakeholders and software tools to support these processes (Chap. 2). Theother type of systems treated in this work are monitoring systems, whichgive insight into the current state of another (monitored) system.

Definition (3.2): A monitoring system is a system that continuouslyrecords, processes, and reacts to observable changes in the state of one ormore monitored systems with the goal to provide feedback about activitiesand to assist in the understanding and control of these systems.

In particular, a monitoring system for virtual collaboration processesobserves group interactions carried by means of digital media. One ele-ment of this research work is to describe the internal structure of such a

52 Technological Foundations

monitoring system, i.e, its components and subsystems, by means of defin-ing an eligible system architecture.

Definition (3.3): The architecture of a system is the fundamental or-ganization of a system embodied in its components, their relationships toeach other and to the environment and the principles guiding its designand evolution (IEEE, 2000).

Over the last decades, the software engineering discipline has suggestedseveral styles of system architectures, each one responding to specific re-quirements and environmental constraints of the system under develop-ment.

Definition (3.4): An architectural style is a coordinated set of ar-chitectural constraints that restricts the roles/features of architecturalelements and the allowed relationships among those elements within anyarchitecture that conforms to that style (Fielding, 2000).

One style that has recently gained extensive momentum in industryand academia is that of service-oriented architectures (SOA, Erl, 2005).Service orientation realizes the design of distributed, loosely-coupled sys-tems, whose core architectural elements are services and service consumers(Matthew et al., 2006). Hence, SOA as an architectural style can be brieflydefined as follows.

Definition (3.5): A service-oriented architectural style is a coor-dinated set of constraints that restricts the roles, features and allowedrelationships of services and service consumers (Uslander, 2010).

The most predominant architectural element in a SOA is the “service”.A very broad and abstract definition of this overloaded notion is given byPreist (2004), who defines a service as “the provision of something of value,in the context of some domain of application, by one party to another”. Weadopt a more precise, but still generic definition that highlights the role ofa service in the specification of a software system.

Definition (3.6): A service is a distinct part of the functionality that isprovided by an entity through interfaces, whereby an interface is a namedset of operations that characterize the behavior of an entity (ISO/IEC,2005; Uslander, 2010)

Note that the definition of a service does not imply technical require-ments of its implementation. Several strategies have been developed to im-plement services and service-oriented architectures, ranging from message-oriented and object-oriented middleware (e.g., Mowbray and Ruh, 1998)

3.2. Representational State Transfer 53

up to Web service standards and protocols (Erl, 2005). Hence, the imple-mentation of a service and the way it is described, provided, and consumedvery much depends on the characteristics of the computational environment(Uslander, 2010). Independent of that, a service platform can be definedas follows.

Definition (3.7): A service platform is a software system that providesa set of distinct, but logically related services that adhere to the architec-tural rules and restrictions defined by the system’s architectural style.

Hence, a service platform becomes a critical component (subsystem)in the design of software systems that directly or indirectly consume theprovided services. A monitoring service platform can now be defined usingthe terminology introduced above.

Definition (3.8): A monitoring service platform is a service platformfor monitoring systems that enables the recording, access, management,and processing of information about one or more monitored systems bymeans of the provided set of services.

In particular, a monitoring service platform for virtual collaborationprocesses enables the recording, access, management, and processing of in-formation about virtual collaboration activities carried out through email,groupware, or other ICT-based collaboration tools.

3.2 Representational State Transfer

The fundamental architectural style of resource-oriented systems has beenidentified and described by Roy Fielding as ”Representational State Trans-fer”, or REST (Fielding, 2000; Fielding and Taylor, 2002). The term em-phasizes one of the key characteristics of that architectural style: the trans-fer of application state between components by means of resources and theirrepresentations.

Definition (3.9): A resource-oriented architectural style is a co-ordinated set of architectural constraints that restricts the identification,characteristics and allowed links and methods of resources and their rep-resentations (Uslander, 2010).

The REST architectural style evolved during work on HTTP (Field-ing et al., 1999a) – the HyperText Transfer Protocol. It was formalizedas a guideline to the transition from HTTP/1.0 to HTTP/1.1 and thusHTTP is the dominant implementation of the resource-oriented architec-tural style (Overdick, 2007). In many ways, REST provides an idealized,


abstract view of the architectural goals of HTTP and describes a style thatis well-suited to very large scale distributed hypermedia applications. RESTconforms with the client-server architectural style (Sommerville, 2006, pp.270), advocating separation of concerns across multiple platforms. Anotherimportant restriction in a RESTful architecture is that communication be-tween its components is stateless. This means that each client request mustcontain all of the information necessary to understand the request on theserver side. The advantage of stateless message exchange is that clientsand servers do not need to store context information, which simplifies thedesign of a resource-oriented software system (Dunkel et al., 2008).

As already mentioned, the key abstraction of information in REST isa resource. So, what is a resource? According to Fielding (2000), any in-formation that can be named can be a resource: a document or image, atemporal service, a collection of other resources, or a non-virtual objectsuch as a person.

Definition (3.10): A resource is anything that is important enough tobe referenced as a thing itself. Resources have a globally shared requestmessage classification system called uniform interface and are addressablevia uniform resource identifiers.

REST components perform actions on a resource by using a represen-tation to capture the current or intended state of that resource and trans-ferring that representation between components (Fielding, 2000). Thus,the application state in a resource-oriented architecture is manipulatedthrough the stateless exchange of resource representations between clientsand servers.

Definition (3.11): The representation of a resource comprises any use-ful information about the current state of a resource. A resource may have(and usually has) several representations. A representation of a resourcemay contain one or more links to another representation of the same oranother resource (Uslander, 2010).

A key component of the REST architectural style is the uniform inter-face between server and clients. A uniform interface has commonly agreed,well-defined semantics and allows access to and the manipulation of re-sources. The advantage of generic interaction semantics is that componentsare able to create, update, read, and delete resources, regardless of the un-derlying implementation of resources and communication mechanisms. Allthat is needed to interact with a resource is its resource identifier.

In order to obtain a uniform interface, REST is defined by four interfaceconstraints: identification of resources, manipulation of resources throughrepresentations, self-descriptive messages, and hypermedia as the engine

3.2. Representational State Transfer 55

of application state (Fielding, 2000). The most successful application ofresource orientation today is the World Wide Web. Here, resources areidentified by Universal Resource Identifiers (URI, Berners-Lee et al., 1998)and a common data format for the representations of Web resources isthe Hypertext Markup Language (HTML, Connolly and Masinter, 2000).HTTP is the protocol standard of the Web and, as such, it is apparent inthe daily use of Web browsers, where it mostly controls hyperlink traversaland form-based data submission. However, the uniform resource interfaceof HTTP allows for a larger set of operations than the use of GET torecover the representation of a resource and the use of POST to send datato a web application. The basic HTTP methods for fully managing the lifecycle and state of resources through representation interchange are:

GET – Request a representation of the resource state: Messages labeledas GET have an empty service request and are guaranteed to have nosubstantial effect within the receiver of such a request, i.e. they are safeto call. GET responses are expected to be a description of the currentstate of the targeted resource. These attributes allow GET to act asa universal reflection mechanism: it can be issued without any priorknowledge of the resource (Overdick, 2007).

PUT – Update the state of the resource: Messages labeled as PUT docause an effect in the targeted resource, but do so in an idempotentfashion. An idempotent interaction is defined as replayable, i.e., theeffect of n messages is the same as that of 1. In a distributed system,where transactions may not be readily available, this is a great help toerror recovery. Again, this assumption can be made without any priorsemantic knowledge of the resource involved (ibid.).

DELETE – Remove the resource: Messages labeled as DELETE do causean effect in the targeted resource, where that effect has a negativeconnotation. Just as PUT, DELETE is defined as idempotent. However,as with all messages, the interpretation is solely the responsibility ofthe receiver, i.e. a DELETE has to be regarded as “please terminate”(ibid.).

POST – Create a child resource: The POST method is used to requestthat the origin server accepts the entity enclosed in the request as anew subordinate of the resource identified by a URI enclosed in therequest (Fielding et al., 1999a). Thus, POST messages cause an effectin the receiver and are not safe to replay.

This limited set of well-defined operations distinguishes REST fromother distributed computing paradigms such as remote procedure calls(RPCs), in which resources can be the target of arbitrary operations. WhileREST is often criticized for this architectural restriction, the simple inter-


face design has the potential to afford large-scale distributed applicationdevelopment by means of loosely-coupled, late-binding service components.

The resource-oriented architectural style, as it has been summarized inthis section, defines the principle design patterns for the implementationof a monitoring service platform later in this work.

Definition (3.12): A resource-oriented monitoring service plat-form is a monitoring service platform that enables the recording, access,management, and processing of information about one or more monitoredsystems by means of resources and their representations.

Thus, in the case of monitoring virtual team collaboration, such a ser-vice platform provides a set of resources that are necessary to representinformation about the entities and activities in (for example) engineeringdesign processes.

3.3 Of Resources and Semantics

Virtual collaboration, as it is practiced today, comprises team activitiesthat in most instances involve services and information provided over theInternet and the World Wide Web. As described above, Web technologydefines the standard for providing and updating information in a hyper-media environment, in which addressable resources are the basic logicalentities for information representation. In the context of conceptual de-sign collaboration, a resource can represent, e.g., product requirementscollected on a Wiki page, a prototype sketch, the video of a user observa-tion, the discussion on a design decision, source code, a calendar, etc. Inaddition, while online tools and services to support knowledge exchangeby means of hyperlinked resources have become commonplace, the Webhas further evolved to a platform for representing and providing meta-information about such resources. Several extensions and Web standardssummarized under the term ‘Semantic Web’ provide a basis for definingcomputer-understandable descriptive properties and relationships that canbe assigned to any resource.

Arguing that virtual collaboration is reflected in the way how resourcesare handled (i.e, created, shared, manipulated, etc.) and hyperlinked ina team process, it is reasonable to represent collected meta-informationabout the handling of these resources again in terms of resources and rela-tionships. We define resources that represent meta-information about otherresources as descriptive resources.

3.3. Of Resources and Semantics 57

Definition (3.13): A descriptive resource dr defines properties of aresource r and its relationships to other resources. In particular, represen-tations of dr link to r and to any related resource r′, respectively dr′ .

The properties of a resource are associated with concepts taken froma semantic model, e.g., an ontology specified in a formal language (Sect.3.4.1). In the context of describing resources that play role in virtual col-laboration, the set of properties comprises thematic properties (i.e., “whatinformation does it represent?”, “what are the relationships?”), as well astemporal properties (i.e., “when has the resource been introduced?”, “whenhave relationships been established to another resource?”). For example, letus assume a descriptive resource dr that defines an ‘is topic of ’ relationshipbetween r (e.g., a sketch or technical drawing) and r′ (e.g., a forum topicor blog entry). A representation of dr would contain temporal informationand references to the drawing, its discussion, and to d′r, thus supporting thetraversal and exploration of meta-information about semantically relatedresources.

Figure 3.1 visualizes the interplay between resources and descriptive re-sources with another example. Here, let us consider the Web-based informa-tion space of a collaboration team as a directed, not necessarily connectedgraph of resources and hyperlinks and let us further assume a collabora-tion scenario comprising of four distinct resources (Fig. 3.1a). The resourcesare not further classified and may represent elements of different groupwaretools and arbitrary Web applications. While hyperlinks in a resource repre-sentation indicate some unidirectional dependencies between the resourceand another, the actual but implicit contextual relationships of a resourceare usually more comprehensive and not specified. Figure 3.1b gives anexample of how these relationships might look like for the previous fourresources. Note that their relationships extend to nodes that were not partof the original graph. These can represent, e.g., non-virtual entities such aspersons that are involved in the handling of the other resources. Also notethe bi-directional nature of the edges due to the general invertibility of thiskind of relationships (e.g., ‘is topic of ’ vs. ‘has topic’). Given such implicitproperties of an information space, descriptive resources can now be usedto create an explicit representation of these properties, thus establishing asemantic layer on top of existing information without altering the originalresources (Fig. 3.1c).

The representation of additional context information in a semantic layerof descriptive resources is a feasible way to define the thematic and tempo-ral properties for arbitrary resources. The representations and the under-lying implementations of the to-be-described resources remain unaffected,a bonus, especially when resources are provided by closed or 3rd-partysystems. Given a service platform that coordinates the generation of de-


(a) Four resources represent-ing (hyperlinked) informationbeing handled in a collabora-tion process.

(b) Semantic relationships ofcollaboration resources are of-ten complex and implicit.

(c) Descriptive resources estab-lish a semantic layer without al-tering the existing resources.

Figure 3.1. Adding a semantic layer to information in a virtual collaboration process by meansof descriptive resources.

scriptive resources, a central source and broker for describing or retrievingthe semantic annotations for any type of collaboration resources can be es-tablished. All that is needed are the identifiers of the described resources.

Several efforts to formally describe meta-information about resources ina computer-understandable format have been made and came to popularattention in recent years. The notion of the ‘Semantic Web’ combines de-facto standards and formats to define and computationally reason aboutconcepts and situations in a resource environment. The basic principles ofthe Semantic Web shall be presented in the following section.

3.4 Semantic Web

The basic idea behind the Semantic Web is to provide information aboutresources in a format that allows machines to handle this information ina meaningful and serviceable way (Hitzler et al., 2008). A prerequisite forthis are open and interoperable standards that allow to describe and ex-change this information on different applications and platforms. To achievethis goal, the Semantic Web technology has been grounded on a numberof well-defined and extensible standards recommended by the World WideWeb Consortium (W3C), the most relevant being XML, the Resource De-scription Framework (RDF), RDF Schema (RDFS), and the OWL WebOntology Language. Thus, the Semantic Web can be understood as an ex-tension to the ‘traditional’ Web and its fundamental technologies such asUniform Resource Identifiers (URIs).

In computer science, the term semantics generally denotes the meaningof literal strings and their interrelationships. Given a formal language todescribe this meaning, computational methods can be applied to derive(infer) “new” information out of specified axioms and already inferred the-orems. The Semantic Web constitutes such a formal system by establishing

3.4. Semantic Web 59

means to define well-defined premises that are linked to resources and aset of inference rules to define possible conclusions.

3.4.1 Ontologies

Central to semantic technologies is the notion of ontologies. Many attemptsto define what constitutes an ontology have been made. A popular, yetbroad definition is given by Gruber (1993), stating that an ontology is “anexplicit specification of a conceptualization”. In this context, a concep-tualization means “an abstract model of some aspect of the world, takingthe form of a definition of the properties of important concepts and rela-tionships” (Baader et al., 2004). An explicit specification means that theconcepts and relationships are represented in an well-defined format, al-lowing humans and machines to unambiguously interpret and reason aboutthe model. Thus, we specifically refer to an ontology also as an informa-tion object and engineering artifact. The W3C has defined standard mod-els and logic-based representation languages for dealing with ontologies.Those languages allow to write explicit, formal conceptualizations of do-main models by means of well-defined, unambiguous syntax and semantics,efficient reasoning support, and sufficient expressive power (Antoniou andVan Harmelen, 2004). The standard languages RDF/RDFS and OWL arebriefly introduced below.

The primary goal of ontologies is to enable agreement on the meaningof specific vocabulary terms and, thus, to facilitate information integrationacross individual applications (Cimpian et al., 2008). They are used toformally specify concepts and their relationships and provide the meansto create semantic metadata for any kind of object. In database terms, wecan divide an ontology into two parts: a schema and instance data (Perry,2008). The schema models a domain by defining class types (e.g., Institute,City) and relationship types (e.g., located in). The schema is populatedwith instances of classes and relationships (e.g., Hasso Plattner Institutelocated in Potsdam) to create facts representing knowledge of the domain.

3.4.2 The Resource Description Framework

The Resource Description Framework (RDF) has been adopted by the W3Cas a standard for representing decentralized metadata on the Web (W3C,2004b,f). It defines a language for describing arbitrary Web resources andany other (physical or virtual) entities that are globally identified by anURI, which, in fact, can be anything. The language allows to freely de-fine properties and to use these properties to describe resources by meansof binary relationships to other resources or to literals such as strings or


numbers. The binary relationships are encoded as triples of the form (sub-ject, predicate, object). Each triple denotes that a resource – the subject– has a property, called the predicate, with a value, the object. Triples arealso referred to as statements, corresponding to the notion of statementsformed by simple sentences in a natural language. For example, the follow-ing statement could assert that an entity named John is the creator of aparticular resource identified as UIConcept.

John has created UIConcept

‘John’ is the subject of the statement, ‘has created’ is the predicate, and‘UIConcept’ is the object. Transferred to RDF, i.e. statements about re-sources identified by URIs, the entity ‘John’ could, e.g., be referenced by theURI ‘http://example.org/John’, which could point to a resource represent-ing the identity of a person named John. A common and convenient formof writing long URIs is to define a prefix for frequently used namespaces.Assuming that ‘ex’ is the preface for the namespace ‘http://example.org/’,the above resource can be rewritten as ‘ex:John’. Likewise, the propertyand object of the RDF triple could be uniquely identified by the URIs‘ex:hasCreated’ and ‘ex:UIConcept’, yielding the following RDF triple:

(ex:John, ex:hasCreated, ex:UIConcept)

A set of RDF triples is called an RDF graph, as triples can be repre-sented as a directed, labeled graph with labels on both edges and nodes.A directed edge labeled with the property identifier connects a subject tothe object of a triple. An example graph is shown in Fig. 3.2.

ex:John ex:UIConceptex:hasCreated

[email protected]

vcard:email

ex:Gallery

rdf:type

Figure 3.2. An example RDF graph.

In this notation adopted from (W3C, 2004b), elliptical nodes representresources and rectangular nodes represent literal values. The example graphshows three triples, one of which being the above statement. A second tripleassigns an email address to ‘ex:John’ using a property from the vCard


vocabulary (Halpin et al., 2010). The third triple states that the resourcebeing created is a member of the class (i.e. “of type”) ‘ex:Gallery’ using thebuilt-in RDF property ‘rdf:type’. A class represents a collection of resources,for example, the class of image galleries. A member of a class is said to bean instance of the class. The set of members of a class is called the classextension of the class.

The fact that classes and properties in RDF are themselves resourcesand identified by URIs provides the basis for constructing ontologies bymeans of RDF graphs. The standard vocabulary that is required to de-scribe ontological relationships between classes and properties used in RDFgraphs is provided by the RDF Schema vocabulary (RDFS, W3C, 2004d).RDFS offers a set of built-in concepts that can be used to define hierarchiesor arbitrary graphs of classes (as instances of ‘rdfs:Class’ ) and properties(as instances of ‘rdf:Property’ ). The ‘rdfs:subClassOf’ property is used tostate that one class is a subclass of another, i.e. that the class extensionof the subject class is a subset of the object class extension (McBride,2004). RDFS also allows to state that the subjects and objects of a prop-erty belong to a certain class. The triple (S, rdfs:domain, O) states that allsubjects of a property S are members of the class O. Likewise, the triple(S, rdfs:range, O) states that all objects of a property S are members of O.For a more detailed introduction into RDF and RDFS see, e.g., McBride(2004).

The W3C has further defined a set of entailment rules for RDF andRDFS (W3C, 2004c). Conceptually, these rules specify that an additionaltriple can be added to an RDF graph if the graph contains triples of a spe-cific pattern (Perry, 2008). Such rules describe, for example, the transitivityof the ‘rdfs:subClassOf’ property: if ‘A subClassOf B ’ and ‘B subClassOfC’ then ‘A subClassOf C’.

Thus, in summary, the unique aspects of RDF, when compared to otherdata models, are demonstrated by the following characteristics: (1) rela-tionships that are represented as first class objects rather than representedimplicitly with, e.g., foreign key constraints in the relational model, and (2)formal semantics, which are specified according to the defined entailmentrules for RDF and RDFS entities (ibid.).

3.4.3 The OWL Web Ontology Language

The OWL Web Ontology Language is a formal language developed by theW3C for representing ontologies in the Semantic Web (W3C, 2004a). OWLis heavily based on Description Logics and is designed to facilitate greatermachine interpretability of data (i.e., more logical reasoning) than what iscapable with RDF and RDFS (Perry, 2008).


It extends the basic fact-stating ability of RDF and the class- andproperty-structuring capabilities of RDF Schema in several important ways(Horrocks et al., 2003). OWL classes can be specified as logical combina-tions (intersections, unions, or complements) of other classes, or as enumer-ations of specified objects. OWL properties can be specified as transitive,symmetric, functional, or as the inverse of another property. Additionally,with OWL one is able to define restrictions on how properties behave thatare local to a class. For example, we can state that the class ‘Canadian’ isdefined precisely as those members of the class ‘Person’ that have ‘Canada’as a value of the property ‘Nationality’ (ibid.).

OWL provides three increasingly expressive sublanguages: OWL-Lite,OWL-DL and OWL-Full. Every legal OWL-Lite ontology is a legal OWL-DL ontology, and every legal OWL-DL ontology is a legal OWL-Full ontol-ogy. OWL-DL – the Description Logic style of using OWL – allows maxi-mum expressiveness while permitting efficient reasoning support and guar-anteeing decidable inference. OWL-Lite consists of a subset of the OWL-DL constructors that eliminates some computational complexity problemsduring the inferencing process, but which has restricted expressivity. OWL-Full provides maximum expressiveness with no computational guarantees(Perry, 2008).

Classes in OWL are defined using the ‘owl:Class’ element, which is asubclass of ‘rdfs:Class’ (Fig. 3.3). Properties are distinguished between ob-ject properties, which relate objects to other objects, and datatype proper-ties, which relate objects to datatype values (Antoniou and Van Harmelen,2004). For a detailed overview of the design of OWL and its constructs seeHorrocks et al. (2003).

rdfs:Resource

rdfs:Class rdf:Property

owl:Class owl:ObjectProperty owl:DatatypeProperty

Figure 3.3. Subclass relationships between OWL and RDF/RDFS.

3.4.4 A Graphical Notation for RDF/OWL Ontologies

Lacking standards for the graphical notation of RDF/OWL-based ontol-ogy models, a custom presentation language to describe the elements of


the platform ontologies is presented and used throughout this thesis. Thenotation is borrowing concepts from DLG21, a graphical presentation lan-guage for RDF and OWL, but has been tailored and extended to addressthe requirements in the context of this work. To give a short introductionto the notation, Fig. 3.4 shows a simple ontology model.

http://hpi-web.de/ns/dstore/example/

@prefix xsd: http://www.w3.org/2001/XMLSchema#@prefix ext: http://www.example.com/namespace#

Domain

ext:ParentClass

Rangeowl:ObjectProperty

relation

xsd:intowl:DatatypeProperty

attribute ParentClass

Figure 3.4. A graphical notation for RDF/OWL-based ontologies.

In this notation, the ontology namespace along with a number of prefixdefinitions for reused ontologies is stated on top of the graphical representa-tion. Class definitions are represented as boxes and property types are rep-resented as flat, acuminated shapes. Associated superordinates for classesand properties are listed above the particular definition, while additionaltype allocations are appended below. The example ontology in Fig. 3.4 fea-tures a class ‘Domain’, which is a subclass of a class ‘ParentClass’ definedin the ‘ext’ namespace. Note that internal superclass/subclass relationshipswithin a namespace can also be expressed by a connecting arrow as shownfor the classes ‘ParentClass’ and ‘Range’ in the ontology namespace. Theontology also defines two properties, a data property ‘attribute’ and an ob-ject property ‘relation’. The latter defines a relationship type between tworesource classes. The domain and range types of a property are indicatedby inbound and outbound connections to the associated resources. In thisexample, the ontology specifies that all instances are of type ‘Domain’ ifthey are subject of a property ‘relation’. Likewise, the range of ‘relation’asserts that targeted node instances of that relationship are of type ‘Range’(and hence of type ‘ParentClass’ ). In the case of data-valued properties,the type of the value range is stated on the outbound side of the property(e.g., ‘xsd:int’ for property ‘attribute’ ).

With these graphical primitives, an adequate overview of the ontologyspecifications that form the foundation of Team Collaboration Networkscan be provided. The following sections make use of this notation in the

1 Directed Labeled Graph 2: http://www.charlestoncore.org/dlg2/


introduction of ontologies for virtual collaboration activities and their or-ganization in a monitoring instrument.

3.5 Chapter Summary

The chapter has given basic definitions for the terms and technical conceptsrelevant for the remainder of this work. REST has been introduced as aresource-oriented architectural style that facilitates lightweight integrationof loosely-coupled services (resources) through an unified resource inter-face and stateless client-server communication. The abstract concept of adescriptive resource has been introduced as an approach to provide meta-information about any other resource, e.g., about its history and handlingin a collaboration process.

It has been further explained how the Web, as an incarnation of aresource-oriented system, has been enriched with formal languages andsemantics that allow to specify information about resources and their re-lationships in form of ontologies. RDF and OWL define the current stan-dards for this Semantic Web. A graphical notation for the description ofRDF/OWL-based ontologies has been presented.

Part II

Models for Team Collaboration Capture

4

Team Collaboration Networks

This chapter introduces Team Collaboration Networks (TCN), a graph-based model to describe the relationships between heterogeneous informa-tion resources and actors during a collaboration process1. A TCN comprisesa concerted vocabulary of node and relationship types and the individualinstantiations of these concepts as they appear over time. The model is cu-mulative, meaning that the temporal evolution of a network is reproducedin the model by the incremental recording of any changes in the set ofnodes and edges, while maintaining historical information about precedingnetwork states.

With the structural and temporal properties of Team Collaboration Net-works defined in this chapter, a medium for capturing unstructured teaminteractions in virtual collaboration environments is presented. A map-ping between TCN representations and the OWL Web Ontology Languageestablishes a computer-processable representation of chronological collab-oration activities in distributed teams. This is the basis for the analysis ofvirtual team collaboration as outlined later in this work.

4.1 Foundations

Team Collaboration Networks describe a graph structure to express di-rected relationships (edges) between persons and/or information resources(nodes). Nodes and edges can be assigned with an arbitrary number ofproperties in form of literal attribute values. Nodes, edges, and attributesrepresent the basic building blocks of a network. Every instance of a node,edge, or attribute is typed, i.e., semantically classified by one or more ter-minological concepts. For example, a node can be defined to be of the type‘Person’, ‘Email’, or ‘Wiki page’. A relationship between nodes might beclassified by the types ‘has sent’, ‘is replying to’, or ‘is author of’. At-tributes, e.g., represent literal properties such as an ‘email address’, or a‘username’.

1 Initially termed Team Communication Networks in previous publications (Uflacker and Zeier,2008c; Uflacker, 2009), I decided to amend the notion to Team Collaboration Networks toavoid ambiguity in the area of tele-communication networks.

68 Team Collaboration Networks

In order to maintain historical information about the temporal evolutionof a network, the model implements a no-overwrite strategy by accumu-lating changes to the network structure and preserving the original state.For this reason, two timestamps are associated with every instance of anode, relationship, or attribute. This way, Team Collaboration Networkskeep track of each element’s validity, i.e., the interval a node, relationship,or attribute value holds true for the depicted collaboration space.

Definition (4.1): Let the validity interval of a node, edge, or attributein a Team Collaboration Network be determined by two time values tstart ∈N and tend ∈ N ∪∞ with tend > tstart. The entity is considered valid at agiven point t, if tstart ≤ t < tend. In particular, tend =∞, if the end of thevalidity is undefined, i.e., if the entity has not (yet) been invalidated.

Thus, a Team Collaboration Network is defined by a set of type def-initions for nodes, relations, and attributes, and a set of according typeinstantiations, whose validity intervals specify the temporal dimension ofthe network structure:

Definition (4.2): A Team Collaboration Network is a directed la-beled graph TCN := (Tv, Te, Ta, V, E, A), where

• Tv is a set of node types to define the semantic classes of network ver-tices.

• Te is a set of relationship types to define the semantic classes of networkedges.

• Ta is a set of attribute types to define the semantic classes of attributes,that can be assigned to node and relationships.

• V is a set of labeled network nodes. Each node v ∈ V is a 4-tuple〈id, types, tstart, tend〉 with id being the unique label of the node andtypes being a list of assigned node types t ∈ Tv. tstart and tend definethe validity interval of the node in the network.

• E is a set of directed edges. Every edge connects any of two nodesvi, vj ∈ V to express a relationship of type r ∈ Te between vi and vj .Hence, every edge e ∈ E is a 5-tuple 〈s, r, o, tstart, tend〉, where s ∈ Vis a source node, r ∈ Te is a relationship type, and o ∈ V is a targetnode. tstart and tend define the validity interval of the relationship inthe network.

• A is a set of attributes. An attribute a ∈ A is a 5-tuple 〈s, p, val, tstart, tend〉where s is either a node v ∈ V or an edge e ∈ E and represents thenode or edge to which a is assigned to. p ∈ Ta represents the type ofthe attribute. val is the literal value of a. tstart, tend define the validityinterval of the attribute in the network.

4.2. Temporal Network Properties 69

The elements Tv, Te, and Ta define the conceptual level of a Team Col-laboration Network. They describe its terminology in terms of a controlledvocabulary of node, relationship, and attribute types. V , E, and A de-fine the individual instantiations of the terminological constructs as theyappear over time in a particular collaboration context.

To give an example, Fig. 4.1 shows a Team Collaboration Network con-sisting of a set of four nodes (V := {1, 2, 3, 4}). Nodes 1 and 4 each rep-resent a person that is participating in the collaboration process. Node 2depicts a Wiki page that has been created by node 1. Node 3 represents anemail that has been sent by node 1 to node 4 and which is holding a refer-ence to the Wiki page. The terminology of this network is defined by Tv :={Person, Email, WikiPage}, Te := {hasSent, hasReceived, linkedFrom, cre-atedBy} and Ta := {mailbox, wikiuser, from, to, create user }. For the sakeof clarity, the temporal properties of the displayed nodes, relationships,and attribute instances have been omitted from the figure. Details on thetemporal aspects and the evolution of Team Collaboration Networks areprovided in the next section.

4

wikiuser: johnmailbox: [email protected]

3

from: [email protected]: [email protected]

hasReceived

1

wikiuser: paulmailbox: [email protected]

hasSent

2create_user: paul

createdBy

VPerson VWikiPage

VEmail

linkedFrom

Figure 4.1. A Team Collaboration Network with different types and instances of nodes, rela-tionships, and attributes.

4.2 Temporal Network Properties

Team Collaboration Networks store the validity intervals of nodes, rela-tionships, and attributes by associating two timestamps tstart and tend with


every instance. The interpretation of these values depends on the actualtype of instance and the way a TCN is prepared in a particular collabora-tion process. For a node of type ‘Email’, e.g., tstart can denote the momentat which the message has been sent. For a ‘Person’ node, it delineates thepoint in time an actor has joined the project or first appeared in the collab-oration process. For a relationship of type ‘editedBy’ between a ‘WikiPage’and a ‘Person’, the value could indicate the time at which the page hasbeen edited, etc.

The end of a node’s validity (tend) implies that an object does no longerappear in the collaboration process. While this is unusual for ‘persistent’objects such as archived emails, tend could for example define the time atwhich a file has been deleted from a shared storage drive. Likewise, anattribute is invalidated when its value has been changed and replaced by anew attributed instance. By definition, tend = ∞ as long as an entity hasnot been invalidated.

With the validity intervals specified, a cumulative, non-overwritingmodel behavior can be established. If an entity is updated or removedfrom a network, the original instance is retained but marked as invalid bysetting tend to the time of its modification. Accordingly, the actual repre-sentation of a Team Collaboration Network at a given point t is limitedto those instances whose validity interval falls into t. With this approach,the model preserves the history of previous network states and maintainsthe traceability of changes in the network structure. The exploration oftrends and the evolution of collaboration behavior over the course of along-running project becomes feasible.

The following directives outline a procedure to handle temporal networkproperties when a node, relationship, or attribute instance is inserted, up-dated, or removed from a Team Collaboration Network:

• If instance a is inserted in a network at time t, then a is initialized withtstart = t and tend =∞.

• If instance a is changed to a′ at time t, then a is marked as invalid withtend = t and a new instance a′ is created with tstart = t and tend =∞.

• If instance a is to be removed from a network at time t, then a is retainedbut marked as invalid with tend set to t.

A basic example to demonstrate the temporal aspects of a Team Collab-oration Network is given by the series of three succeeding representationsshown in Figs. 4.2a – 4.2c. The series starts with an earlier version of theexample network presented in the last section (Fig. 4.2a). The networkcomprises a person (node 1) and a Wiki page (node 2), and asserts thatthe Wiki page has been created by the person. In the next iteration (Fig.4.2b), the same person has sent an email (node 3) to a second person iden-tified by node 4. The email further contains a reference to the initially

4.2. Temporal Network Properties 71

1


2create_user: paul

createdBy

VPerson VWikiPagefrom: [email protected]

Figure 4.2a. Team Collaboration Network at time t− 1.

4


3


hasReceived

1


hasSent

2create_user: paul

createdBy

VPerson VWikiPage

VEmail

linkedFrom

Figure 4.2b. Team Collaboration Network at time t.

4


3


hasReceived

1


hasSent

2

create_user: pauledit_user: john

createdBy

VPerson VWikiPage

VEmail

linkedFromeditedBy

Figure 4.2c. Team Collaboration Network at time t + 1.


created Wiki page. Apparently, the creator of the Wiki page wants to dis-seminate the provided information by sharing the URL of the resource. Inthe final iteration (Fig. 4.2c), the Wiki page has been edited by the receiverof the email, which becomes evident in a new ‘editedBy’ relationship and‘edit user’ attribute.

A general mechanism to represent versioning information about the ac-tual content of collaboration resources has intentionally been excluded fromthe model. This is grounded on the position that the management of re-source revisions in a collaborative process falls within the responsibility ofthe providing application. Information about the delta between two revi-sions should be provided by the collaboration software (e.g., as it is thecase for many Wiki systems). Ideally, every revision of a resource is ex-posed by the application as a dedicated URI and hence would become anode in its own right. Revisions can then be associated to previous versionsthrough according relationships, resulting in a more explicit representationof content changes in the Team Collaboration Networks.

Through the selective exclusion of nodes, relationships, and attributeswhose validity interval is outside of a given time point, a reconstruction ofhistorical network states can be established. Later in Chap. 6, it is demon-strated how time point queries on TCN models can be efficiently realizedon database level.

4.3 Representing Team Collaboration Networks in OWL

The Web Ontology Language OWL (cf. Sect. 3.4.3) defines a constrainedvocabulary of classes, properties, and instances that can be used to describeTeam Collaboration Networks. This section motivates OWL as an eligibleTCN representation format and exemplifies the serialization of networks inthe form of language-compliant ‘subject – predicate – object’ statements.

4.3.1 Motivation

A mapping between Team Collaboration Networks and OWL establishes acomputer-processable description of actors, resources and relationships indistributed collaboration activities. Choosing OWL as the target represen-tation for TCNs can be justified by several reasons:

Resource-Orientation: The purpose of Team Collaboration Networks is tomake statements about the resources in a collaboration process. OWLis a vocabulary extension to the Resource Description Framework andis intended to define ontological statements about resources by means ofclass and property assertions. The underlying URI addressing scheme

4.3. Representing Team Collaboration Networks in OWL 73

fits naturally into the application context of describing online, Web-based team collaboration.

Ontological Extensions: OWL ontologies are serialized as RDF graphs con-sisting of RDF triples. The triples present an universal linguistic con-struct to express arbitrary TCN properties in a generic format. Hence,the semantics that can be expressed in a TCN are decoupled from anapplication-specific data schema. The extension and adaptation of TCNterminology is simplified, which presents an advantage in versatile ap-plication domains such as engineering design.

Description Logic Satisfiability: By limiting the vocabulary of TCN mod-els to the OWL-DL subset, the mapping is restricted to classes, dataranges, and facts, which are analogues of concepts, concrete datatypes,and axioms in description logics (Horrocks and Patel-Schneider, 2004).Therefore, the well-understood computational properties of descriptionlogics also apply to Team Collaboration Networks, allowing the appli-cation of formal reasoning and decision procedures.

Tool Availability: OWL is widely recognized as a Semantic Web standardand supported by various tool implementations that provide efficientontology handling and storage services. Sound, complete, and efficientreasoner modules are available to computationally infer consequencesfrom TCN knowledge bases.

The effect of resource-orientation is that resources become the primaryentity in the OWL-based TCN representation. Every type and every in-stance defined in a TCN is represented by a resource and identified by anURI. Decomposed into a set of RDF/OWL statements, a Team Collabo-ration Network G := (Tv, Te, Ta, V, E, A) is described by a set of ‘subject– predicate – object’ triples. Each triple asserts an atomic fact about asubject resource, expressing a particular role or relationship to an objectresource. The set of triples of a Team Collaboration Network define theknowledge base (KB) of a TCN. A knowledge base contains a set of termi-nological statements – called TBox – that define the conceptual networkvocabulary, and a set of assertional statements – called ABox – that definethe individual instances of nodes, relationships, and attributes (cf. Baaderet al., 2003). Hence, statements defining elements Tv, Te, and Ta are partof TBox. Statements that specify the sets of instances (V , E, A) are partof ABox.

4.3.2 Terminological Components

The terminological part of a TCN knowledge base (TBox) defines the ex-isting types of nodes (Tv), relationships (Te), and attributes (Ta). Thefollowing examples make use of the standard namespace aliases for RDF


(‘rdf ’ ), RDF Schema (‘rdfs’ ), OWL (‘owl’ ), and XML Schema (‘xsd’ ). The‘tcn’ prefix is used as a shorthand alias for an example Team CollaborationNetwork namespace.

Node Types

Node types provide semantic value to the nodes of a Team Collabora-tion Network, representing concepts for information classification and ac-tor roles on different levels of abstraction. The specification of the nodetype collection (Tv) is realized through the instantiation of OWL classes(‘owl:Class’ ), which are hierarchically ordered in subordinate / superor-dinate relationships. The root node type, and hence superordinate of allother node types is represented by the abstract class ‘tcn:Resource’, whichis an implicit element in Tv. Subclass relationships are expressed by the‘rdfs:subClassOf’ property. To give an example, the statements listed inTable 4.1 define two node types ‘tcn:Email’ and ‘tcn:Person’, as well as aspecial class of person identified as ‘tcn:TeamMember’.

Table 4.1. Statements declaring three node types Email, Person, and TeamMember.

Subject Predicate Object

tcn:Resource rdf:type owl:Classtcn:Email rdf:type owl:Classtcn:Person rdf:type owl:Classtcn:TeamMember rdf:type owl:Classtcn:Email rdfs:subClassOf tcn:Resourcetcn:Person rdfs:subClassOf tcn:Resourcetcn:TeamMember rdfs:subClassOf tcn:Person

Relationship Types

The collection of relationship types (Te) describes the classes of associa-tions that can be defined between any two nodes of a Team CollaborationNetwork. One example is a ‘hasSent’ relationship that can exist betweena person and an email node (Table 4.2). The ‘tcn:Relation’ concept serves

Table 4.2. Statements declaring a relationship type ‘hasSent’.


tcn:Relation rdf:type owl:Classtcn:Relation rdfs:subClassOf owl:ObjectPropertytcn:hasSent rdf:type tcn:Relationtcn:hasSent rdfs:domain tcn:Persontcn:hasSent rdfs:range tcn:Email


as a parent class for all relationship types and is a specialization of theobject property class defined in OWL. Using the properties ‘rdfs:domain’and ‘rdfs:range’, the types of the source and target nodes are appointed.In this case, the source node of the ‘hasSent’ relationship is defined to beof type ‘tcn:Person’ and the target node is of type ‘tcn:Email’.

Attribute Types

The set of attribute types (Ta) describes the classes of literal attribute val-ues that can be assigned to the nodes and edges of a Team CollaborationNetwork. To give an example, we consider the attribute type ‘mailbox’,which is used to assign email addresses to persons (Table 4.3). Attributetypes are defined as instances of the class ‘tcn:Attribute’, a subclass of‘owl:DatatypeProperty’. Datatype properties link individuals to data val-ues. The value range of an attribute type is specified by the ‘rdfs:range’property.

Table 4.3. Statements declaring an attribute type ‘address’.


tcn:Attribute rdf:type owl:Classtcn:Attribute rdfs:subClassOf owl:DatatypePropertytcn:mailbox rdf:type tcn:Attributetcn:mailbox rdfs:domain tcn:Persontcn:mailbox rdfs:range xsd:string

Using the graphical notation introduced in Sect. 3.4.4, the type decla-rations of the previous examples (Tables 4.1 – 4.3) are summarized in Fig.4.3.

http://hpi-web.de/ns/tcn/

@prefix xsd: http://www.w3.org/2001/XMLSchema#

Email

Resource

RelationhasSentPerson

Resource

TeamMember

xsd:stringAttribute

mailbox

Figure 4.3. Graphical notation of node, relationship, and attribute types that define the ter-minological components (TBox) of a Team Collaboration Network.


4.3.3 Assertion Components

The second category of OWL statements defines the assertional compo-nents in a TCN knowledge base (ABox) and completes the ontologicalspecification of a Team Collaboration Network. The individual nodes (V ),relationships (E), and attributes (A) represent instantiations of the termi-nological concepts in TBox. In the following examples, the ‘ex’ prefix isused to denote a fictitious namespace for collaboration resources.

Node Instances

Every node v := 〈id, types, tstart, tend〉 ∈ V in a Team Collaboration Net-work is a proxy for a distinct resource that is part of a collaboration process.Nodes provide semantic meta-information about resources by determininga set of associated node types types ⊆ Tv. In an OWL-based representa-tion, collaboration resources are identified by an URI, so that a surjectivemapping exists between the set of node instances (node labels) and the setof resource URIs. The surjection implies that two different node instanceswith distinct labels id1 and id2 can map to the same URI. However, in thiscase the validity intervals of the two nodes must not overlap in order toprevent ambiguous meta-information about a resource at a given point intime.

A node is instantiated by stating that a resource is of the predefinedtype ‘tcn:Resource’. For every node type t ∈ types, a further ‘rdf:type’association between the resource and t is inserted into the knowledge base.Table 4.4 gives an example: a fictitious resource ‘ex:email’ is associatedwith the node type ‘tcn:Email’ (a subclass of ‘tcn:Resource’ ). Note thatthe URI of the email resource does not necessarily need to point to anactual representation of the message. However, it can, for example, pointto the resource of a Web-based email client or archive, through which thecontent of the email is accessible. The network-internal unique label of anode is assigned through the ‘tcn:instanceId’ property.

Table 4.4. Statements declaring a network node for a resource identified by ‘ex:email’.


ex:email rdf:type tcn:Resourceex:email rdf:type tcn:Emailex:email tcn:instanceId “3”ex:email tcn:validFrom “2009-06-03T11:31:22”ex:email tcn:validTo “INF”

The validity interval of a node is asserted by two properties ‘tcn:validFrom’and ‘tcn:validTo’ to define tstart and tend, respectively. The time values are


encoded in a standardized date string format. In case of tend = ∞, thespecial string ‘INF’ is used to indicate that a node has not been removedfrom the network. If a node is eventually invalidated at all largely dependson the nature of the resource it is representing. Archived emails, e.g., havea persistent characteristic and usually ‘stay’ in the information space oncethey have been sent or received. Other collaboration resources are morevolatile. For example, Web resources or shared files in public team foldershappen to be more frequently replaced or removed.

Relationship Instances

A relationship instance of type P between two resources S and O is ex-pressed in RDF/OWL through a single statement (S,P ,O). For example,to state that the resource ‘ex:wikipage’ has been created by a person de-picted by the resource ‘ex:Paul’, one can insert the triple ‘ex:wikipage –tcn:createdBy – ex:Paul’ to the knowledge base. However, a TCN relation-ship e := 〈s, r, o, tstart, tend〉 ∈ E requires two additional values tstart andtend to be associated with the statement. To support statements aboutstatements, RDF provides a mechanism called ‘reification’ (W3C, 2004b).Reification is a technique that can be used in order to represent relationswith arity greater than two (Andronikos et al., 2009). The principle behindreification is that statements themselves become a resource. A statementis decomposed (‘reified’ ) into a set of four cohering replacement triples,the so called ‘reification quad’. A reified statement becomes itself a re-source and is identified by a dedicated URI. This resource is the subjectof the four triples. The first triple identifies the new resource to be of type‘rdf:Statement’. The three other triples express the original statement via‘rdf:subject’, ‘rdf:predicate’, and ‘rdf:object’ properties. The same subjectURI can then be used to specify additional statement properties such astemporal dimensions.

Table 4.5 shows a reified statement that is identified by the URI‘tcn:relation 1’. The first four statements represent the reification quad,which asserts that a resource ‘ex:wikipage’ holds a ‘tcn:createdBy’ rela-tionship to the resource ‘ex:Paul’. The example implies that the source,predicate, and object resources are defined as network nodes and relation-ship types. To specify the validity interval of the relationship, two addi-tional properties ‘tcn:validFrom’ and ‘tcn:validTo’ have been appended tothe knowledge base.

Attribute Instances

The specification of TCN attribute instances in OWL is analogue to that ofrelationships. The last example shows the specification of an attribute that


Table 4.5. A reified statement to define the validity interval of a ‘tcn:createdBy’ relationshipbetween two resources ‘ex:wikipage’ and ‘ex:Paul’.


tcn:relation 1 rdf:type rdf:Statementtcn:relation 1 rdf:subject ex:wikipagetcn:relation 1 rdf:predicate tcn:createdBytcn:relation 1 rdf:object ex:Paultcn:relation 1 tcn:validFrom “2009-06-01T09:15:59”tcn:relation 1 tcn:validTo “INF”

is identified by the URI ‘tcn:attribute 1’ and which is of type ‘tcn:mailbox’(Table 4.6). Like relationships, attributes are expressed in form of reifiedstatements in order to support the annotation of temporal information.However, attributes are datatype properties in OWL, meaning that the ob-ject of the statement is a literal value rather than another node instance. Inthis case, the literal “[email protected]” is assigned to a resource identifiedas ‘ex:Paul’. Again, the example assumes that ‘ex:Paul’ is the identifier ofa network node and that ‘tcn:mailbox’ represents an attribute type definedin TBox.

Table 4.6. A reified statement to define the validity interval of a ‘tcn:mailbox’ attribute.


tcn:attribute 1 rdf:type rdf:Statementtcn:attribute 1 rdf:subject ex:Paultcn:attribute 1 rdf:predicate tcn:mailboxtcn:attribute 1 rdf:object “[email protected]”tcn:attribute 1 tcn:validFrom “2009-06-01T08:00:00”tcn:attribute 1 tcn:validTo “INF”

4.4 Chapter Summary

This chapter has introduced Team Collaboration Networks, a flexible datastructure to describe the classes, occurrences, and relationships of sharedinformation resources and actors during a collaboration process. It hasfurther demonstrated how TCNs can be represented as a set of RDF/OWLtriples. The next chapter is dealing with the organization of these triplesin a system that facilitates the concurrent management of multiple TCNinstances and the reuse of common terminology in different collaborationenvironments. It provides a blueprint for an adaptable and configurableTCN implementation, in particular for the software platform presentedlater in this work.

5

An Ontology System for Team CollaborationNetworks

A mapping for Team Collaboration Networks has been demonstrated, inwhich temporal collaboration activities are represented as RDF graphs.Multiple of such graphs need to be concurrently organized and maintainedif the activities of different project teams are to be captured and evalu-ated in parallel. Furthermore, projects within the same organization oftenshare collaboration infrastructure and use similar groupware. This createsdemand for an integrated system of TCN instances, which is able to set upand handle multiple independent knowledge bases and to reuse commonterminological concepts across different networks. In this chapter, I intro-duce a generic structure for such a system that facilitates flexibility and alow configuration footprint for individual network instances.

5.1 Foundations

A Team Collaboration Network system (TCN-S) manages a collection ofindividual Team Collaboration Networks (Uflacker, 2009). It contains aconfigurable set of ‘domain ontologies’, which provide a vocabulary forthe description of common collaboration activities. A domain ontology en-capsulates node, relationship, and attribute types that apply to a specificcommunication channel, groupware, or collaboration platform. For exam-ple, an ‘email’ domain ontology would specify a vocabulary to describethe structure of email-based conversations. The types defined in a domainontology can be dynamically mapped into the graphs of Team Collabora-tion Networks and become available to describe the individual instances ofthese concepts in a concrete project scenario.

A TCN-S further consists of a set of inference rules, which define logicto derive implicit facts from the knowledge bases of Team CollaborationNetworks. Inference rules represent a formal specification of universal if– then dependencies among domain-specific concepts. For example, if thevalue of an attribute ‘from’ of a node with type ‘Email’ matches the valueof another node’s ‘mailbox’ attribute, then a ‘hasSent’ relationship can beinferred between the latter node and the email node.

80 An Ontology System for Team Collaboration Networks

Definition (5.1): A Team Collaboration Network System is a 4-tuple TCN-S := (graphs, domains, rules, map), where

• graphs is a set of Team Collaboration Networks {TCN1, ..., TCNi}.• domains is a set of domain ontologies {Dom1, ..., Domj}. Each ontology

describes node, relationship, and attribute types that apply to a specificdomain of collaboration channels.

• rules is a set of inference rules {r1, ..., rk}.• map is a set of tuples {m1, ...,ml} with m1..l ∈ (domains × graphs) ∪

(rules× graphs). Each tuple (a, b) introduces domain ontology or rulea to network b.

In the remainder of this chapter, a template for the organization ofthe TCN-S components graphs, domains, rules, and map by means ofdiscrete named ontology graphs is introduced. It is demonstrated how acollection of independent TCN instances can be assembled through thedynamic composition of such graphs. This suggests a data layout for TCN-Simplementations that facilitate configurability and the re-use of commondomain vocabulary across independent Team Collaboration Networks.

5.2 Named Graph Partitioning

Mapped to a set of OWL statements, a Team Collaboration Network con-stitutes an RDF graph that fully describes the configuration (conceptsand instances) of a network. In the following realization of a TCN-S, theelements of a TCN are decomposed into a set of discrete ontological frag-ments, which separate general concepts from specific network properties.Each fragment is a ‘named graph’ (Carroll et al., 2005), an RDF graphwhich has a name assigned in the form of an URI reference, and whichcomprises a logically coherent set of either terminological or assertionalfacts. Accordingly, the graphs are categorized into different groups. Con-cept graphs contain terminological components, i.e., a vocabulary of classes,properties, and rules. Instance graphs define assertion components, i.e., theinstantiations of classes and properties. On an orthogonal dimension, thegraphs are further classified into system graphs with system-wide conceptsor instances, and network graphs, which comprise facts specific to a partic-ular TCN (Fig. 5.1).

The named graphs of a TCN system are hierarchically organized andcomposed through import operations. Imports merge the elements of onegraph into another. More precisely, let imports(A,B) be defined as a tran-sitive operation that introduces the ontological statements in B to those inA. The transitivity of imports implies that if A imports B, and B importsC, then A imports the statements of both B and C.

5.2. Named Graph Partitioning 81

Domain-specificTCN Ontology

Domain-specificTCN Ontology

TCN-SConcept Graph

TCN-SInstance Graph

Domain Ontologies & Rule Graphs

TCN1Instance Graph

Domain Ontologies & Rule Graphs

TCN1Concept Graph

TCNnConcept Graph

TCNnInstance Graph

Domain Ontologies& Rule Graphs

.

.

.

imports

Concept Graphs (TBox)

Instance Graphs(ABox)

.

.

.

.

.

.

SystemGraphs

NetworkGraphs

TCN 1

TCN n

Figure 5.1. Partitioning of a Team Collaboration Networks system into named graphs. So-cialization of common domain concepts and isolation of independent TCN instances is achievedthrough the transitive import of ontological fragments.

A dynamic composition of individual TCN knowledge bases accordingto map can now be achieved with the provided graph layout (Fig. 5.1).A set of global Domain Ontologies and Rule Graphs provides conceptsand terminology that is available to all TCN instances. The collection es-tablishes a shared vocabulary and foundation for the description of com-mon collaboration activities across all networks. The global componentsare complemented by network-specific instances of domain ontologies andrules, that are mapped into the conceptual specification of single networks.A TCN-S Concept Graph provides general and recurring type definitionsthat are needed to describe a system of Team Collaboration Networks.Additional information about the concrete state and configuration of thesystem is defined in a TCN-S Instance Graph.

For each instance TCN1...TCNn ∈ graphs, the system allots twonetwork-specific graphs. A TCN Concept Graph imports the global typedefinitions and domain ontologies. Network-specific domain ontologies andrules can be imported into the conceptual domain of a network withoutaffecting the individual state and type configuration of other networks. ATCN Instance Graph imports the terminological specifications and addsassertional facts to complete the specification of the network.

In the following sections, the different graphs are explored in more de-tail. Short examples demonstrate how a TCN is composed from general


and network-specific ontological fragments maintained in the system. Theexamples make use of graph names and aliases listed in Table 5.1.

Table 5.1. Graph names and aliases used in the following examples.

Alias Graph Name Description

tcns-c http://hpi-web.de/ns/tcns-c/ TCN-S Concept Graphtcns-i http://hpi-web.de/ns/tcns-i/ TCN-S Instance Graphdomain1 http://hpi-web.de/ns/domains/1/ Domain & Rule Graph 1domain2 http://hpi-web.de/ns/domains/2/ Domain & Rule Graph 2tcn1-c http://hpi-web.de/ns/tcn1-c TCN1 Concept Graphtcn1-i http://hpi-web.de/ns/tcn1-i TCN1 Instance Graph

5.2.1 Domain Ontologies & Rule Graphs

Domain ontologies define node, relationship, and attribute types that canbe imported into one or more Team Collaboration Networks. Each ontol-ogy describes a vocabulary specific to a certain communication channel orproject setting. For example, a domain ontology for email-based conversa-tions would define a node type ‘Email’, a relationship type ‘hasSent’, andan attribute type ‘mailbox’, among others. Table 5.2 adopts this exam-ple and shows definitions of email-related node, relationship, and attributetypes as a set of RDF/OWL triples in the domain1 ontology.

Table 5.2. Statements of a domain ontology graph ‘domain1’ to declare common node, rela-tionship, and attribute types for email-based conversations.


http://hpi-web.de/ns/domains/1/ rdf:type owl:Ontologydomain1:Email rdfs:subClassOf tcns-c:Resourcedomain1:sender rdf:type tcns-c:Relationdomain1:sender rdfs:domain domain1:Emaildomain1:sender rdfs:range tcns-c:Persondomain1:sender owl:inverseOf dom1:hasSentdomain1:mailbox rdf:type tcns-c:Attributedomain1:mailbox rdfs:domain tcns-c:Persondomain1:mailbox rdfs:range xsd:stringdomain1:from rdf:type tcns-c:Attributedomain1:from rdfs:domain domain1:Emaildomain1:from rdfs:range xsd:string

With the terminological definitions provided in domain ontologies, ashared vocabulary of common network building blocks is established inthe system. Domain ontologies can extend and build up on each other,thereby creating rich semantic descriptions of concepts and relationships ina collaboration process. The description of domain-specific properties and


conditions can be further supported by means of inference rules, providedin form of antecedent ⇒ consequent statements. E.g., given the abovedomain model, the existence of a ‘domain1:sender’ relationship betweenany two nodes ‘a’ and ‘b’ can be computationally inferred, if the value ofa’s ‘domain1:from’ attribute matches the value of b’s ‘domain1:mailbox’attribute. This is expressed by the following rule statement:

domain1:from(a,x) ∧ domain1:mailbox(b,x) ⇒ domain1:sender(a,b)

It states that for any node a with an attribute of type domain1:fromand value x and any node b with an attribute of type domain1:mailboxand the same value x, there exists a domain1:sender relationship betweena and b. In this case, a would be a node of type ‘domain1:Email’ and bwould be of type ‘tcns-c:Person’.

Rules can be formulated as a graph through an RDF-compliant rep-resentation format defined by the Semantic Web Rule Language (SWRL)(W3C, 2004g). The classes and properties defined in the SWRL namespacesupport the specification of rules in the form of implications (‘swrl:Imp’ )resulting from an antecedent (‘swrl:body ’) and consequent (‘swrl:head ’). Togive an example, Listing 5.1 shows the above rule expressed in SWRL. Theinterested reader is referred to the RDF/XML syntax specification (W3C,2004e) for detailed information on how to map this rule definition to a setof RDF triples.

1 <swr l : Var iab le rd f : about=”#a” />2 <swr l : Var iab le rd f : about=”#b” />3 <swr l : Var iab le rd f : about=”#x” />4

5 <swr l : Imp rd f : about=”&domain1 ; SenderRule”>6 <swr l : head rd f : parseType=”C o l l e c t i o n”>7 <swr l : IndividualPropertyAtom>8 <swr l : p roper tyPred i ca te rd f : r e s ou r c e=”&domain1 ; sender ” />9 <swr l : argument1 rd f : r e s ou r c e=”#a” />

10 <swr l : argument2 rd f : r e s ou r c e=”#b” />11 </swr l : IndividualPropertyAtom>12 </swr l : head>13 <swr l : body rd f : parseType=”C o l l e c t i o n”>14 <swr l : DatavaluedPropertyAtom>15 <swr l : p roper tyPred i ca te rd f : r e s ou r c e=”&domain1 ; from” />16 <swr l : argument1 rd f : r e s ou r c e=”#a” />17 <swr l : argument2 rd f : r e s ou r c e=”#x” />18 </swr l : DatavaluedPropertyAtom>19 <swr l : DatavaluedPropertyAtom>20 <swr l : p roper tyPred i ca te rd f : r e s ou r c e=”&domain1 ; mailbox ” />21 <swr l : argument1 rd f : r e s ou r c e=”#b” />22 <swr l : argument2 rd f : r e s ou r c e=”#x” />23 </swr l : DatavaluedPropertyAtom>24 </swr l : body>25 </swr l : Imp>

Listing 5.1. A SWRL inference rule in RDF/XML syntax.


5.2.2 The TCN-S Concept Graph

The TCN-S Concept Graph is a central component in the hierarchy ofnamed graphs. General terminology to define a collection of Team Collab-oration Networks and their structure is defined here and imported into theknowledge bases of all TCN instances. It imports the global domain ontolo-gies and rules in order to pass a shared vocabulary down to the Team Col-laboration Networks. In the example shown in Table 5.3, one domain ontol-ogy is imported via the transitive ‘owl:import’ property provided by OWL.The graph further defines a class ‘tcns-c:TCNGraph’ to represent TCN in-stances in the system. The classes ‘tcns-c:Resource’, ‘tcns-c:Relation’, and‘tcns-c:Attribute’ are defined to provide global, abstract parent classes forall types that are specified in domain ontologies or individual networks.The graph further defines a standard node type ‘tcns-c:Person’ to denoteresources representing human actors.

Table 5.3. A TCN-S Concept Graph with basic class definitions.


http://hpi-web.de/ns/tcns-c/ rdf:type owl:Ontologyhttp://hpi-web.de/ns/tcns-c/ owl:imports http://hpi-web.de/ns/dom1/tcns-c:TCNGraph rdf:type owl:Classtcns-c:Resource rdf:type owl:Classtcns-c:Relation rdfs:subClassOf owl:ObjectPropertytcns-c:Attribute rdfs:subClassOf owl:DatatypePropertytcns-c:Person rdfs:subClassOf tcns-c:Resource

5.2.3 The TCN-S Instance Graph

The TCN-S Instance Graph asserts the individual state of the system andthe composition of TCN instances. The necessary terminological constructsare defined in and imported from the TCN-S Concept Graph. The kind ofinformation that is specified in the TCN-S Instance Graph depends on theactual implementation and functionality of the system. It may address,e.g., general aspects of the system state, such as user accounts and accessrights for individual networks. In the example below, the graph instantiatesa Team Collaboration Network (identified as ‘http://hpi-web.de/ns/tcn1’ )and assigns two graphs as the network-specific concept and instance models(Table 5.4). With that, the statements assert that the two named graphsidentified by the given URIs represent the terminological and assertionalcomponents of the TCN instance.


Table 5.4. Statements of a TCN-S Instance Graph to assign two named graphs as concept andinstance models to a TCN instance.


http://hpi-web.de/ns/tcns-i/ rdf:type owl:Ontologyhttp://hpi-web.de/ns/tcns-i/ owl:imports http://hpi-web.de/ns/tcns-c/http://hpi-web.de/ns/tcn1 rdf:type tcns-c:TCNGraphhttp://hpi-web.de/ns/tcn1 tcns-c:conceptGraph http://hpi-web.de/ns/tcn1-chttp://hpi-web.de/ns/tcn1 tcns-c:instanceGraph http://hpi-web.de/ns/tcn1-i

5.2.4 TCN Concept Graphs

The concept graph of an individual TCN instance represents the termi-nological components Tv, Te, and Ta that are available to describe theoccurrences and relationships of people and information in a collaborationprocess. It forms an ontology that is composed of the system-wide buildingblocks imported from the TCN-S Concept Graph, individually importeddomain and rule models, as well as internal, network-specific type defini-tions (cf. Fig. 5.1). The example shown in Table 5.5 imports the obligatoryTCN-S Concept Graph to receive the global type definitions, as well asone additional domain ontology to further extend the network vocabulary.A private node type ‘tag’ is defined on network level for the individualannotation of resources.

Table 5.5. A TCN Concept Graph with import statements and a custom node type ‘tag’.


http://hpi-web.de/ns/tcn1-c rdf:type owl:Ontologyhttp://hpi-web.de/ns/tcn1-c owl:imports http://hpi-web.de/ns/tcns-c/http://hpi-web.de/ns/tcn1-c owl:imports http://hpi-web.de/ns/dom2/http://hpi-web.de/ns/tcn1-c#tag rdfs:subClassOf tcns-c:Resource

5.2.5 TCN Instance Graphs

The instance graph of a Team Collaboration Network completes the knowl-edge base by specifying the sets of individual instances V , E, and A. Usingthe type vocabulary imported from the associated TCN concept graph,it defines nodes, relationships, and attributes to form a network of col-laboration resources. Table 5.6 gives an example. The described TCN in-stance contains two nodes: a resource ‘ex:Paul’ of type ‘tcns-c:Person’,and a resource ‘ex:wikipage’, which is of type ‘domain2:WikiPage’. Thegraph further defines two attribute instances ‘domain2:wikiuser’ and ‘do-main2:create user’ for the two nodes, respectively.

Though not explicitly asserted in the table, one can derive from thematching attribute values that the person identified as ‘ex:Paul’ is the


Table 5.6. A TCN Instance Model with two node instances and attributes.


http://hpi-web.de/ns/tcn1-i rdf:type owl:Ontologyhttp://hpi-web.de/ns/tcn1-i owl:imports http://hpi-web.de/ns/tcn1-c/ex:Paul rdf:type tcns-c:Personex:Paul tcns-c:instanceId “1”ex:Paul tcns-c:validFrom “2009-06-01T08:00:00”ex:Paul tcns-c:validTo “INF”tcn1-i:attribute 1 rdf:type rdf:Statementtcn1-i:attribute 1 rdf:subject ex:Paultcn1-i:attribute 1 rdf:predicate domain2:wikiusertcn1-i:attribute 1 rdf:object “paul”tcn1-i:attribute 1 tcn:validFrom “2009-06-01T08:00:00”tcn1-i:attribute 1 tcn:validTo “INF”ex:wikipage rdf:type domain2:WikiPageex:wikipage tcns-c:validFrom “2009-06-01T09:15:59”ex:wikipage tcns-c:validTo “2009-06-04T16:14:27”ex:wikipage tcns-c:instanceId “2”tcn1-i:attribute 2 rdf:type rdf:Statementtcn1-i:attribute 2 rdf:subject ex:wikipagetcn1-i:attribute 2 rdf:predicate domain2:create usertcn1-i:attribute 2 rdf:object “paul”tcn1-i:attribute 2 tcn:validFrom “2009-06-01T09:15:59”tcn1-i:attribute 2 tcn:validTo “2009-06-04T16:14:27”

creator of the Wiki page. In order to express this association in the net-work, an according relationship must be added to the graph. This can berealized by adding a reified relationship to the instance graph or throughthe application of an inference rule, analog to the one presented for senderrelationships in Sect. 5.2.1. For example, assuming that such a rule is im-ported into the instance graph, a ‘domain2:createdBy’ relationship betweenthe resource ‘ex:wikipage’ and the resource ‘ex:Paul’ can be computation-ally derived from the knowledge base. The resulting graph resembles theTeam Collaboration Network that is depicted in Fig. 4.2a.

5.3 Chapter Summary

With the flexible composition of named graphs as outlined in the aboveexamples, a system of independent Team Collaboration Networks can bemaintained and organized. The outlined structure of a TCN-S presents aflexible approach to the concurrent monitoring, comparison, and analy-sis of different project teams by means of individually configured networkinstances. In order to transfer the concept of a TCN-S into a realistic ap-plication scenario, a prototypical implementation of a service-based TeamCollaboration Network system has been implemented and is presented inthe next chapter.

Part III

System Implementation

6

d.store: A Resource-oriented Team CollaborationNetwork System

This chapter presents the d.store platform (Uflacker and Zeier, 2008a), aJava-based implementation of a Team Collaboration Network system. Thesoftware provides a service interface to continuously capture heterogeneousonline collaboration activities via distributed sensor clients. At the sametime, the services can be leveraged for immediate real-time monitoring andthe historical analysis of complex characteristics in the virtual collaborationbehavior of project teams. This software implementation is a foundationfor the temporal evaluation of collaborative team activities, in particularfor the pilot application in engineering design processes that I present laterin this work.

6.1 Platform Architecture Overview

The chapter begins with an overview of the software architecture of thed.store platform. It describes its central components and assigns the func-tionality of the system to these components. The technical structure anddynamic characteristics are outlined to create a template for the prototyp-ical implementation of a resource-oriented Team Collaboration Networksystem.

The system design of the d.store platform embodies a client-server ar-chitecture. Communication between clients and server is regulated by aresource-oriented service interface that adheres to REST principles (Sect.3.2). Clients retrieve or manipulate the state of the resources provided bythe platform to access, create, and manipulate Team Collaboration Net-works. Figure 6.1 gives an overview of the architecture and the differentcomponents, which are described in more detail below.

6.1.1 Client Applications

The system classifies three types of client applications according to theirprimary purpose. ‘Sensor Clients’ continuously scan heterogeneous datasources in the collaboration infrastructure for events and feed informationto the server. An event, in this case, is the occurrence of a specific col-laborative activity at a specific point in time, such as, e.g., ‘A sends an

90 d.store: A Resource-oriented Team Collaboration Network System

d.store

HTMLRDF

JSONGraphML

JSON

Customized RDF/OWL Framework

RDBMS(n-tuple Store)

R

Resource Controllers / REST API

Reasoner

SensorClients

CollaborationEvents

Collaboration Infrastructure

Project Team

AnalysisClients

R R

RulesDomain

Ontologies& Rules

ConceptModels

TCNConceptGraphs

InstanceModels

TCNInstanceGraphs

TCN-SConceptGraph

TCN-SInstanceGraph

NavigationClients

Figure 6.1. The d.store platform architecture. A variable set of clients access and modify thestate of Team Collaboration Networks via a RESTful server interface.

email to B’ or ‘A updates document C’. The events are computationallycaptured by the clients, e.g., by processing server log files, archives, or dataprovided by collaboration tool APIs. ‘Navigation Clients’ support brows-ing and exploring Team Collaboration Networks. They provide a centralpoint of access to resources, relationships, and attributes and give users acontextual understanding about the concurrent and distributed activitiesin the process. ‘Analysis Clients’ query existing TCN structures to processand quantify complex network properties during and after data collection.This allows the observation of specific aspects in the collaboration behav-ior and the evaluation of network properties to support different use cases(e.g., monitoring, notifications, or statistics).

6.1.2 RDF/OWL Graph Component

Chapter 5 has demonstrated how a system of Team Collaboration Net-works can be represented as a composition of modular RDF/OWL graphs.The d.store platform adopts this strategy and utilizes the ‘Jena Seman-tic Web Framework’ (henceforth ‘Jena’) to programmatically handle andorganize collections of RDF triples. Jena is a Java-based implementationof standards and recommendations for the Semantic Web, including RDF,RDF Schema, and OWL. The framework provides a comprehensive API

6.1. Platform Architecture Overview 91

for storing and querying RDF/OWL-based graph models and for the in-tegration of decision procedures and rule processors via external reasonercomponents. (cf. Carroll et al., 2004; Wilkinson et al., 2003). Reasoners ap-ply graph-to-graph transformations on TCN instance models to computeenriched knowledge bases that include logically derived statements. By re-stricting the asserted graphs to OWL-DL compliant statements, the classof computationally decidable facts in a TCN knowledge base comprisesuseful derivations such as type hierarchies (is ‘A’ a subclass/subpropertyof ‘B’?), instance checking (is resource ‘A’ of type ‘B’?), or inverse rela-tionships (for more details about decidability in OWL see Horrocks et al.,2003).

TCN instances keep track of the moment an element has been added orremoved from a Team Collaboration Network in order to maintain temporalaspects of the model. The necessary association of an validity interval toany network node, relationship, and attribute creates room for optimizingthe storage of RDF data. To improve the query performance, the d.storeplatform continuously keeps a copy of the momentarily valid network statein memory (instances with tend =∞). The historical graph structures arejournalized in a non-overwriting, relational database management system(RDBMS). This enables the efficient answering of common read requestsdirectly from data that is resident in main memory, while previous statesof the networks are restored from the persistent storage on demand. Inaddition, the following preparations have been carried out to support thehandling and practicable exploration of temporal characteristics in TCNdata structures.

• Modification of the relational triple schema to allot two additionalcolumns ‘ValidFrom’ and ‘ValidTo’ to every RDF statement.

• Modification of the Jena Semantic Web framework to consider validityintervals in the implementation of RDF triples and to support timepoint queries into the relational data storage to recover historical TCNrepresentations.

• Implementation of stored procedures to effect a non-overwriting andauto-journaling execution of graph operations on database level.

Detailed presentations of these modifications to the RDF/OWL sub-component and the database layer are given in Sect. 6.3.

6.1.3 Service Interface

A resource-oriented service interface gives client applications access to thefunctionality that is needed to create, read, update, and delete elements ofa Team Collaboration Network system. Requests are dispatched to URI-referenced resources, representing logical entities such as, e.g., a Team Col-


laboration Network, a type, a set of nodes, or a single node instance. Eachresource provides a uniform set of operations that can be used to retrieveor manipulate its state by means of exchanging resource representationsbetween clients and server (REST, cf. Fielding, 2000). The underlyingcomponents for the implementation of this architectural style in d.storeis the Hypertext Transfer Protocol (HTTP/1.1, Fielding et al., 1999b) andplatform-independent representation formats such as the JavaScript Ob-ject Notation (JSON). The decision to use HTTP/1.1 as the applicationprotocol for d.store is obvious: The protocol provides a basis for large-scaledistributed hypermedia applications and is the foundation of the WorldWide Web as it is experienced today. Hence, the integration of the plat-form into a wide range of Web-based collaboration landscapes is facilitated.

Section 6.4 gives an overview of the different d.store resources and showsexamples for the utilization of the interface. A complete reference of theplatform API, the provided resources, and their representations is listed inAppendix C.

6.2 The d.store Concept Graph

The concept graph of a TCN-S defines general concepts and propertiesthat are required to describe a system of Team Collaboration Networks(cf. Sect. 5.2.2). This section presents the TCN-S Concept Graph as it hasbeen specified in the d.store platform, providing a terminological basis forother network components that are introduced later.

Figure 6.2 visualizes the ontological concepts and relationships in thefamiliar graphical notation (Sect. 3.4.4). The classes ‘TCNConceptGraph’,‘TCNInstanceGraph’, and ‘DomainGraph’ represent the set of namedgraphs as introduced in Sect. 5.2. A Team Collaboration Network is rep-resented by the ‘TCNGraph’ concept. Together with the three properties‘conceptGraph’, ‘instanceGraph’, and ‘domainGraph’, the occurrence of aTCN and its individual composition of concept and instance graphs can bedescribed. The platform also establishes a basis for a simple user accountand authorization management by introducing the notion of a ‘TCNSUser’.

The ‘Resource’ class provides an abstract root class for all node typesthat are defined in a Team Collaboration Network. The platform distin-guishes between ‘DomainResource’ types that are defined by domain on-tologies, and ‘CustomResource’ types, which are specified on network levelto extend the vocabulary of single networks. The concept graph also definesthe global node type ‘Person’, which represents the set of individual humanactors in the collaboration process. The numerical ‘instanceId’ property re-flects the node identifier id that is assigned to every node instance (Def. 4.2,p. 68).

6.2. The d.store Concept Graph 93

http://hpi-web.de/ns/dstore/

@prefix owl: http://www.w3.org/2002/07/owl#@prefix xsd: http://www.w3.org/2001/XMLSchema#@prefix foaf: http://xmlns.com/foaf/0.1/

xsd:positiveInteger

owl:DatatypePropertyowl:FunctionalProperty

instanceId

ResourceDomainResource CustomResource

DomainAttribute CustomAttribute

Graph

owl:Ontology

DomainGraph

TCNConceptGraph

TCNInstanceGraph

Attribute

owl:DatatypeProperty

DomainRelation CustomRelationRelation

owl:ObjectProperty

AliasAttribute AliasReferenceAttributealiasAttribute

owl:ObjectPropertyconceptGraphTCNGraph

owl:ObjectPropertyinstanceGraph

owl:ObjectPropertydomainGraph

Person

foaf:Person

TCNSUser

foaf:Person

owl:ObjectPropertyuser

Figure 6.2. The TCN-S Concept Graph of the d.store platform.

The same differentiation that applies to node types (domain vs. customresources) also applies to relationship and attribute types. For the lat-ter, two additional classes are introduced to further characterize attributetypes. An ‘AliasAttribute’ is an attribute that defines a personal namealias for a resource, e.g., a user account name or email address assignedto a person. Complementary, the ‘AliasReferenceAttribute’ is an attributethat gives a literal reference to an alias, e.g., the ‘to:’ -field of an emailor a user name that appears in the list of editors for a particular Wikipage. Matching AliasAttributes and AliasReferenceAttributes are specifiedby the ‘aliasAttribute’ property. Having this knowledge explicitly encodedin domain ontologies allows to optimize the processing of network opera-tions at run-time. For example, when adding a new email resource withan AliasReferenceAttribute ‘to’, whose value cannot be matched with thatof an according AliasAttribute ‘mailbox’ of any other resource, a second


resource can automatically be created to represent the previously unknownreceiver.

6.3 Processing Temporal Network Properties

This section describes the necessary actions to realize an efficient repro-duction of temporal TCN properties in an RDF-based data model.

By definition, Team Collaboration Networks keep historical audit trailinformation about when a particular node, relationship, or attribute hasbeen added to or removed from the network. With this temporal informa-tion preserved in the data structure, the evaluation and reconstruction ofhistorical network properties via time-point queries becomes feasible. Theconsequence of this temporal annotation is that, when mapping Team Col-laboration Networks to RDF-based triple sets, statements about the pointin time other statements have become valid or invalid must be made. Werefer to this meta-information as the ‘temporal provenance’ of a statement.An RDF-compliant way to make a statement itself the subject of anotherstatement is given through reification (Sect. 4.3.3). Temporal provenancedata can be associated to a reified statement using its URI as the subjectand time values as the object of validity properties. Introducing the notionof time to RDF graphs via reification is a common approach and has beenthe subject of recent studies (e.g., Andronikos et al., 2009; Gutierrez et al.,2007).

However, reification is inefficient to implement, because it multiplies thenumber of triples that must be processed and requires the generation andmanagement of a globally unique ID for each triple (Futrelle, 2006). Sinceall nodes, relationships, and attributes stored in a TCN instance modelrequire the determination of a validity interval, a considerable overheadintroduced through the handling of temporal provenance can be expected.Therefore, an alternative solution has been chosen to bypass the explodingnumber of reified triple statements and to optimize the execution of time-point queries. The following sections describe the necessary adaptationsand show how common classes of problems can be resolved by using SQLas an abstraction.

6.3.1 Storing Temporal RDF Statements

Collections of RDF statements are commonly stored in a relational databaseto provide a persistency layer for applications processing the knowledgebase. A widely-used schema for this is the triple store. In its simplest form,the triple store schema is a 3-tuple, resembling the structure of the exam-ple statements presented in the previous chapters. Each RDF statement is

6.3. Processing Temporal Network Properties 95

stored as a single record in a three-column statement table. Each columnholds the character string of an URI, identifying the subject, predicate,and object resources of an RDF triple. Several extensions such as normal-ized and denormalized triple stores have been proposed and implementedto improve the scalability of this approach (e.g., Wilkinson et al., 2003).

The comprehensive audit trail that is established by recording the tem-poral provenance of all elements in a TCN multiplies the number of RDFstatements required to describe the state of each network. In a standardtriple store, each node requires at least three triples to define its type andthe two timestamps tstart and tend. For the relationships and attributes ofa TCN, the number of necessary triples is multiplied by a factor of six:the reification quad plus two triples for the start and end of the validityinterval. Additional overhead is generated by the management of URIs as-sociated with the reified statements. Relational schemas exist to optimizethe storing of reified statements (e.g., Carroll et al., 2004), but can onlypartially diminish these costs.

The validity intervals of nodes, relationships, and attributes do not onlyaffect the storage volume of a triple store. At run-time, the values determinewhether an element matches a given time-point query, thus requiring theexecution of self-join operations on the statement table (Listing 6.1). Pre-senting an inherent characteristic of searching RDF data, join operationspose a performance challenge already for medium-sized datasets (Abadiet al., 2007). However, time-point queries are expected to be commonplacein the context of Team Collaboration Networks, as read requests eithertarget the current state of the network or some historical snapshot.

While recent studies already present efficient optimizations for join op-erations in RDF datasets (Neumann and Weikum, 2009), the approachchosen in the implementation of d.store aims for a general avoidance ofself-joins in the execution of time-point queries. For this purpose, the triplestore schema used in d.store has been extended with two additional columns‘ValidFrom’ and ‘ValidTo’, resulting in a 5-tuple schema for storing the va-

1 SELECT p1 . s u b j e c t2 FROM tcn AS p1 , tcn AS p2 , tcn AS p33 WHERE p1 . Pred i cate = ’ rd f : type ’4 AND p1 . Object = ’ ds to r e : Resource ’5 AND p1 . Subject = p2 . Subject6 AND p2 . Pred i cate = ’ ds to r e : validFrom ’7 AND p2 . Object <= ’2009−06−01 ’8 AND p1 . Subject = p3 . Subject9 AND p3 . Pred i cate = ’ ds to r e : validTo ’

10 AND p3 . Object >= ’2009−06−01 ’;

Listing 6.1. The standard triple store schema imposes self-join operations on time-point queries:Example of a SQL query that finds all node instance resources valid on June 1st, 2009.


lidity interval of every node, relationship, or attribute directly on statementlevel. Having two time values explicitly stored with the subject, predicate,and object identifiers in one single record not only reduces the numberof statements and alleviates the need for reification in a TCN knowledgebase. The schema also eliminates join operations when filtering by valid-ity and supports the implementation of efficient journaling mechanisms ondatabase level, as the next sections will show. Table 6.1 depicts the modifiedschema and gives an example for three time-annotated RDF statements.Note that the semantic content of this table is virtually identical to thatof Tables 4.4 – 4.6.

Table 6.1. The 5-tuple schema assigns a validity interval to every record of an RDF statement,reducing the overall number of statements and allowing for efficient time-point querying of TCNcomponents.

Subject Predicate Object ValidFrom ValidTo

ex:email rdf:type tcn:Email 2009-06-02T11:31:22 infinityex:wikipage tcn:createdBy ex:Paul 2009-06-01T09:15:59 infinityex:Paul tcn:mailbox ”[email protected]” 2009-06-01T08:00:00 infinity

A consequence of this 5-tuple schema extension is that the validity in-tervals of nodes, relationships, and attributes are no longer representedas discrete RDF statements. The schema deviates from RDF-conformablerepresentations and entails the need to modify the underlying semanticframework. These modifications are topic of the following sections.

6.3.2 Modifying the RDF/OWL Subsystem

To appropriately reflect and leverage the two time properties of each state-ment in the Jena subsystem, some modifications to the core data structuresof the framework are necessary. The following gives a short overview of therelevant changes in the code.

Modifications to the class structures primarily affect the Jena types‘Graph’ and ‘Triple’. Graphs represent collections of Triple instances anddefine operations on these collections. Each triple comprises three ‘Node’properties for the subject, predicate, and object of a statement. Two ad-ditional timestamp properties have been added to a ‘Triple’ to specify thebeginning and the end of a statement’s validity interval. The original inter-face of a ‘Graph’ supports modification (add and delete triples) and access(test if a triple is present or list all triples matching some pattern). For ex-ample, the method find(Node S,Node P,Node O) returns an iterator over allthe triples of the graph which match the triple (S, P, O). To ‘match’ meansto be equal to or for the S, P, or O node to be a wildcard that matches anynode. This allows the graph to be queried for all the properties of some


Node subjectNode predicateNode objectTimestamp validFromTimestamp validTo

Triple

Model

1

*

find(Node, Node, Node)find(Node, Node, Node, Date)

Graph

Figure 6.3. Customized Jena types to address the n-tuple extension in a Triple.

particular subject, all the predicates with some particular object, or allthe triples in the graph (Carroll et al., 2004). These graph operations werecomplemented with time-parameterized versions that take the validity ofa triple into account. The find operation has been overloaded to accept anextra match condition of type ‘Date’, specifying a point in time at which atriple must be valid in order to match. Figure 6.3 shows an excerpt of theextended class properties.

6.3.3 Modifying the Relational Storage Interface

Jena supports the dynamic creation of RDF models in a relational databasesystem and interfaces the triples through a set of SQL commands. Thedatabase provides a persistent backend for the RDF models that are dy-namically loaded and processed into the internal data structures of theframework. To comprise the temporal validity properties of the modifiedTriple class, a number of preparations in the relational storage subsystem ofthe Jena framework are necessary. This includes (1) the modification of therelational database schema, (2) the implementation of stored procedures toorganize validity intervals on database level, and (3) query modificationsto be able to select those statements that are valid at a given point in time.

Preparing the Triple Store Schema

The d.store graph models are organized in a denormalized triple storeschema (Wilkinson et al., 2003): depending on the length of an URI orliteral value, the data is either stored directly in the statement table orreferenced via foreign key relationships from dedicated literal and resource


tables. This hybrid approach presents a trade-off between a relatively slow,but storage-efficient normalized approach (requiring a 3-way join of state-ment, literals, and resources tables) and a plain triple store schema, inwhich all values are directly stored in the statement table.

To give room for the schema extension presented above, Jena’s state-ment tables need to be extended with two time values that define the startand end of a statement’s validity interval. Listing 6.2 presents the modi-fied SQL command as it is dispatched by the framework to a PostgreSQLdatabase to create the statement table for a TCN instance model. Two ad-ditional columns ‘ValidFrom’ and ‘ValidTo’ are introduced to specify thevalidity of a statement in the TCN knowledge base. A statement is consid-ered to be valid at a given time t if t >= V alidFrom and t <= V alidTo.By definition, the special value ’infinity’ is the largest value in the rangeof the PostgreSQL data type ‘abstime’.

1 CREATE TABLE t c n 1 i n s t a n c e (2 Subj cha rac t e r vary ing (250) NOT NULL,3 Pred charac t e r vary ing (250) NOT NULL,4 Obj charac t e r vary ing (250) NOT NULL,5 ValidFrom abstime ,6 ValidTo abstime DEFAULT ” i n f i n i t y ” ) ;

Listing 6.2. Creating a statement table for a TCN instance graph.

Database-level Management of Time Properties

One of the underlying design decisions in the architecture of the d.storesystem was to decouple the platform as much as possible from the datamanagement overhead introduced by the temporal TCN properties. Theincrease in complexity is caused by additional functionality, which is re-quired to define and update the validity intervals of added, updated, orremoved instances. In d.store, this functionality has been delegated to therelational database system, where stored procedures implement the tem-poral network properties that have been described in Sect. 4.2.

The recording of changes to data records directly in the relational ta-ble structure rather than in external system log files has its origin in thedesign of a no-overwrite storage manager (Stonebraker et al., 1990). Thisshould be contrasted with a conventional approach where the update of aprevious record in a table results in overwriting it with a new one. With a‘no-overwrite’ strategy the old record remains in the database whenever anupdate occurs and serves the purpose normally performed by a write-aheadlog. This creates the possibility to implement ‘time travel’ : a feature thatallows a user to perform a historical query and the database will automat-ically return information from the record valid at the correct time (ibid.).


This functionality has been integrated into d.store’s PostgreSQL databaseby registering a stored procedure, which is triggered before any insert, up-date, or delete operation is executed on the statement table of a TCNinstance graph. Accordingly, the Jena framework has been customized tobind the trigger function ‘timetravel’ to created graph models (Listing 6.3).

1 CREATE TRIGGER t i me t r av e l2 be f o r e INSERT or UPDATE or DELETE on t c n 1 i n s t a n c e3 f o r each row4 execute procedure5 t i m e t r av e l ( ValidFrom , ValidTo ) ;

Listing 6.3. Binding a trigger function ’timetravel’ to the statement table of a TCN instancemodel.

Any update of a TCN instance graph results in the execution of accord-ing INSERT, UPDATE, or DELETE commands dispatched by the Jenaframework. The ‘timetravel’ procedure is triggered before any of these com-mands is committed to the rows of a statement table. The algorithm of theprocedure is outlined below, assuming the execution on a row tuple (s, p,o, V alidFrom, V alidTo):

• Before INSERT, if V alidFrom is NULL then set V alidFrom to currentdate. If V alidTo is NULL then set V alidTo to ’infinity’. Insert the tuple.

• Before UPDATE, if V alidTo of original tuple is ’infinity’ then setV alidTo to current date and insert new tuple with update values s′,p′, o′ and V alidFrom′ set to current date and V alidTo′ set to ’infin-ity’. Skip update.

• Before DELETE, if V alidTo is ’infinity’ then set V alidTo to currentdate. Skip deletion.

Querying the Statement Tables

The previous sections have outlined the preparations of Jena’s data struc-ture and the relational database backend to accept time-point queries andto manage the temporal properties of TCN statements. In a final step,the SQL commands that are dispatched by the framework to load validnetwork elements from the modified statement tables need to be alignedaccordingly. A differentiation can be made between graph model operationsthat query the network for elements that are valid at a given time point (viathe newly-added methods in the graph interface) and those where a timepoint is omitted (i.e., via standard Jena calls). In the latter case, the state-ment table is queried for the latest and current description of the network,i.e., those records where ValidTo = ’infinity’. Listing 6.4 gives an examplefor a query that returns all statements that have not been invalidated.


1 SELECT S . Subj , S . Pred , S . Obj , S . ValidFrom , S . ValidTo2 FROM t c n 1 i n s t a n c e S3 WHERE S . ValidTo = ’ i n f i n i t y ’ ;

Listing 6.4. Querying the currently valid statements from the statement table of a TCN instancemodel.

Historical time-point queries can be realized by parameterizing theSELECT statement with conditions for the fields ValidFrom and ValidTo.In other words, the Jena framework retrieves and processes only thosestatements from the knowledge base, whose validity intervals fall within agiven time frame or date. Listing 6.5 shows how a date parameter that ispassed to the find(S,P,O,Date) method of a graph determines the filteringof records according to the validity intervals specified in the ‘ValidFrom’and ‘ValidTo’ fields.

1 SELECT S . Subj , S . Pred , S . Obj , S . ValidFrom , S . ValidTo2 FROM t c n 1 i n s t a n c e S3 WHERE S . ValidFrom <= ’2009−06−01 ’ AND S . ValidTo >= ’2009−06−01 ’;

Listing 6.5. Querying statements from a statement table that have been valid on June 1st,2009.

As visible in these examples, the temporal filtering of TCN knowledgebases no longer requires the execution of self-join operations (cf. Sect.6.3.1). Retrieving a valid snapshot of a Team Collaboration Network for agiven point in time can be achieved in a single table scan.

6.3.4 Advantages and Disadvantages of the Approach

With two extra time fields appended to the triple store schema, the pre-sented 5-tuple approach breaks out of the standard RDF representationmodel. The temporal provenance of network nodes, relationships, or at-tributes is no longer expressed through explicit semantic facts within theRDF knowledge base. In other words, time is not a semantic element inthe network representation. This makes logical reasoning on temporal at-tributes complicated and can be considered a disadvantage of this approach.

In return, the 5-tuple schema facilitates the time-based slicing of TCNinstance models on database level. The join complexity of interval andtime point queries (e.g., “What was the state of the network on June 1st,2009?”) is reduced compared to a conventional triple store. The neces-sary no-overwrite storage behavior and time travel functionality can beefficiently implemented by means of stored procedures. At the same time,the schema extension significantly reduces the need for statement reifica-tion and thus decreases the total number of statements stored in the tables.

6.4. Implementing the Service Interface 101

The integration of this approach into an existing RDF/OWL software com-ponent has been demonstrated. In the next section, it is shown how thenon-graph-based determination of temporal network properties is realizedin d.store via an URI-based filtering of network instances.

6.4 Implementing the Service Interface

This section introduces the resource-oriented service interface of the d.storeplatform. Short examples indicate how client applications can leverage thefunctionality of the system to query and manipulate Team CollaborationNetworks. A complete reference of the d.store API can be found in Ap-pendix C.

6.4.1 Platform Resources

The resources provided by the d.store platform can be generally classifiedinto system resources, i.e. resources that represent basic aspects of the sys-tem state (e.g., the collection of all networks), and network resources, whichrepresent one or more logical entities of a TCN instance. The latter couldbe, e.g., a network type, a collection of nodes, relationships, or attributesthat satisfy certain characteristics, or an individual instance. Hence, theset of resources provided by the platform is not statically quantifiable, butdepends on the system configuration and state of the networks at run-time.However, the collection of available resources can be defined by describingthe syntax of valid URL paths, as presented in Listing 6.6.

1 path = ’/ ’ [ ’ l og in ’ | ’ l o g o f f ’ | ( ’ graphs ’ [ tcn ] ) ] ;2 tcn = ’/ ’ t c n i d ’/ ’ ( date | ’now ’ ) ’/ ’ [ t cn e l ement ] ;3 tcn e lement = ( nodes | node types | r e l a t i o n t y p e s |4 a t t r i b u t e t y p e s ) ;5 nodes = ’ r e source s ’ [ node | f i l t e r ] ;6 node = ’/ ’ node id [ n o d e r e l a t i o n s | n o d e a t t r i b u t e s ] ;

Listing 6.6. Examples of valid d.store URL paths (syntax in extended Backus-Naur form).

Besides general system resources for session and graph management(which are not discussed in detail) the provided excerpt of the grammar alsodescribes paths of network-specific resources, such as node collections andinstances. Every instance of a Team Collaboration Network is identified bya unique label, usually a short identifier for the associated project or teamname (‘tcn id’, line 2). This is followed by a date identifier that asserts thevalidity of the represented network entity for the specified point in time. Aspecial identifier ‘now’ can be used to retrieve the latest and current version


of a network. This mechanism allows clients to select between up-to-datenetwork representations or historical data and triggers the execution ofaccording time-point queries as sketched out in the previous section.

The nodes of a network are combined under the ‘resources’ keyword(line 4). A numerical identifier ‘node id’ can be appended to identify aparticular instance by its ’instanceId’ property (Sect. 4.3.3). Alternatively,a list of node type identifiers (Sect. 4.3.2) may act as a filter on the setof nodes. Hence, a node with label ‘1’ of a TCN ‘tcn1’ is referenced bythe path ‘/graphs/tcn1/resources/1’, whereas the set of all nodes of type‘Email’ is referenced by ‘/graphs/tcn1/resources/Email’. The following ex-amples explain the run-time behavior of the d.store platform in more detailand show how the resources can be leveraged to explore and manipulateTeam Collaboration Networks.

6.4.2 Exploring Team Collaboration Network Resources

The primary function of navigation and analysis clients is to read andprocess the state of Team Collaboration Networks. The state is providedby network-specific resources, which represent one or more entities (e.g.,nodes) of a TCN. Client applications, which seek to explore the stateof those entities, are requesting representations of the resources from theserver via HTTP/1.1 GET operations. The sections below give some exam-ples and assume HTTP connectivity between a client and a d.store serverrunning at dstore.hpi-web.de. Furthermore, the examples do not considerany user identification and authorization aspects.

Retrieving All Nodes in a Network

Clients can request a list of all nodes in a Team Collaboration Network toprovide browsing functionality or to analyze the topology of a network. Theaccording node collection is identified by the ‘resources’ keyword in theURL path. The following interaction between client and server shown inListing 6.7 demonstrates the according request and response, using sampledata similar to the previous examples.

Client Request:

1 GET / graphs / tcn1 /now/ r e s o u r c e s HTTP/1 .12 Host : d s to r e . hpi−web . de3 Accept : a p p l i c a t i o n / j son

Server Response:

4 HTTP/1.1 200 OK5 Content−Type : a p p l i c a t i o n / j son6

7 {” totalCount ” : 2057 ,


8 ” r e s o u r c e s ” : [9 {” id ” : 1 ,

10 ” u r l ” : ” http ://www. example . com/ p r o f i l e s /Paul ” ,11 ” l a b e l ” : ” Paul ” ,12 ”validFrom ”:”2009−06−01 08 : 00 : 00”} ,13 {” id ” : 3 ,14 ” u r l ” : ” http :// mail . example . com/ arch ive /0001 . html ” ,15 ” l a b e l ” : ” Meeting ” ,16 ”validFrom ”:”2009−06−03 11 :31 :22”}

...17 ] }

Listing 6.7. Retrieving all nodes from the latest network representation.

Clients can make use of the ‘Accept’ field transmitted in the HTTPrequest header to negotiate the representation format that is returned fromthe server. The d.store platform supports different standard representationformats such as JSON or HTML to facilitate easy client integration anddata accessibility. In the above example, the client has requested to receivea JSON representation of the list of all node instances in a TCN that arecurrently valid (‘/now/resources’, line 1).

If a historical view on a TCN is required, the now keyword in the URLcan be replaced by the date of interest. This is demonstrated in the fol-lowing example (Listing 6.8). The result set contains two node instance asindicated by the ‘totalCount’ attribute. The second instance is an examplefor a node that has been invalidated during the course of the collaborationprocess, caused for example by the deletion of this Wiki page.

Client Request:

1 GET / graphs / tcn1 /2009−06−02/ r e s o u r c e s HTTP/1 .12 Host : d s to r e . hpi−web . de3 Accept : a p p l i c a t i o n / j son

Server Response:


7 {” totalCount ” : 2 ,8 ” r e s o u r c e s ” : [9 {” id ” : 1 ,

10 ” u r l ” : ” http ://www. example . com/ p r o f i l e s /Paul ” ,11 ” l a b e l ” : ” Paul ” ,12 ”validFrom ”:”2009−06−01 08 : 00 : 00”} ,13 {” id ” : 2 ,14 ” u r l ” : ” http ://www. example . com/ wik i /ToDoList ” ,15 ” l a b e l ” : ” Wiki − ToDoList ” ,16 ”validFrom ”:”2009−06−01 0 9 : 1 5 : 59 ” ,17 ” val idTo ”:”2009−06−04 16 :14 :27”}18 ] }

Listing 6.8. Retrieving all nodes in the network as on June 1st, 2009.


Retrieving Node Collections by Type

The list of nodes returned from the server can be filtered by node types,thus containing only those resources that satisfy certain type restrictionsexpressed in the URL. By appending one or more ‘+’-separated type iden-tifiers, the result set is restricted to those nodes that exhibit all of thelisted types. Listing 6.9 gives an example for retrieving all ‘Email’ -typednodes from a network. Here, the server responses with a HTML-formattedrepresentation of the resource, as requested by the client in line 3. Thisstripped-down version of a HTML-formatted representation demonstrateshow the exploration of TCN data is directly supported in the Web browser.With the links provided, users can easily navigate back and forth to relatednode instances and collaboration resources.

Client Request:

1 GET / graphs / tcn1 /now/ r e s o u r c e s /Email HTTP/1 .12 Host : d s to r e . hpi−web . de3 Accept : t ex t /html

Server Response:

4 HTTP/1.1 200 OK5 Content−Type : t ex t /html6

7 <html>8 <head><t i t l e >d . s t o r e − Nodes : Email</ t i t l e ></head>9 <body>

10 <ul>11 < l i >12 <a h r e f =”/graphs / tcn1 /now/ r e s o u r c e s /3”>ID 3</a>:13 <a h r e f=”http :// mail . example . com/ arch ive /0001 . html”>Meeting</a

>,14 June 3rd , 2009 , 11 : 31 : 2215 </ l i >

...16 </ul>17 </body>18 </html>

Listing 6.9. Retrieving a list of all Email-typed nodes in the current network. HTML has beennegotiated as the representation format.

Retrieving a Node Instance

A node instance in d.store materializes what has been introduced inSect. 3.3 as a descriptive resource. It describes meta-information abouta collaboration resource, its semantic types, relationships, and associatedattribute values. Descriptive resources are identified by the distinct node


instance ID. In the following example, a client requests the state of a nodewith instance ID ‘3’ as it was valid on June 4th, 2009 (Listing 6.10).

Client Request:

1 GET / graphs / tcn1 /2009−06−04/ r e s o u r c e s /3 HTTP/1 .12 Host : d s to r e . hpi−web . de3 Accept : a p p l i c a t i o n / j son

Server Response:


7 {” id ” : 3 ,8 ” u r l ” : ” http :// mail . example . com/ arch ive /0001 . html ” ,9 ” l a b e l ” : ”Meeting ” ,

10 ”validFrom ”:”2009−06−03 1 1 : 3 1 : 22 ” ,11 ” types ” : [12 {”name ” :” Email ” , ” type ” :” domain ” ,13 ”validFrom ”:”2009−06−03 11 :31 :22”} ] ,14 ” a t t r i b u t e s ” : [15 {”name ” :” from ” , ” type ” :” domain ” , ” value ” :” paul@example . com” ,16 ”validFrom ”:”2009−06−03 11 : 31 : 22”} ,17 {”name ” :” to ” , ” type ” :” domain ” , ” value ” :” john@example . com” ,18 ”validFrom ”:”2009−06−03 11 :31 :22”} ] ,19 ” r e l a t i o n s ” : [20 {”name ” :” sender ” , ” type ” :” domain ” , ” t a r g e t ” :{” id ” : 1 ,21 ” u r l ” : ” http :// example . org / p r o f i l e s /Paul ”} , ” i n f e r r e d ” : t rue } ,22 {”name ” :” r e c i p i e n t ” , ” type ” :” domain ” , ” t a r g e t ” :{” id ” : 4 ,23 ” u r l ” : ” http :// example . org / p r o f i l e s /John ”} , ” i n f e r r e d ” : t rue } ,24 {”name ” :” hyper l ink ” , ” type ” :” domain ” , ” t a r g e t ” :{” id ” : 2 ,25 ” u r l ” : ” http ://www. example . com/ wik i /ToDoList ”} ,26 ”validFrom ”:”2009−06−03 11 :31 :22”} ]27 }

Listing 6.10. Retrieving a JSON-formatted node instance.

The representation returned from the server describes basic node infor-mation along with associated types, attributes, and relationships. In theexample above, the described collaboration resource is of the requested type‘Email’. Two attributes list the mailboxes of the sender and a recipient.The node also has three relationships to other resources of the network.The relationships to sender and recipient are marked as inferred, e.g., byan inference rule checking for matching ‘mailbox’ attributes of persons inthe TCN. Note that this instance closely resembles node 3 in the examplenetwork shown in Fig. 4.1.

Complex Queries

To provide more powerful filtering mechanisms to the clients, the d.storeplatform supports URL-encoded SPARQL queries (W3C, 2008) to be ex-ecuted on the TCN knowledge bases. The conditions of the nodes are for-mulated in the URL, while the rest of the SPARQL query, such as prefixes


and select clauses, is completed by the platform before being dispatchedto the RDF layer. This simplifies the formulation of queries for the clientsand keeps the request short. For example, the following three conditionsproduce the list of all Wiki pages that have been referenced in at least oneemail (Listing 6.11).

1 ? r e sou r c e rd f : type ex : WikiPage .2 ? r e sou r c e ex : linkedFrom ?x .3 ?x rd f : type ex : Email

Listing 6.11. SPARQL statements to filter the list of node instances.

By appending this query fragment as an URL-encoded parameter tothe URL of a node collection, the result list is filtered down to resourcesthat satisfy the constraints of the ‘?resource’ variable (Listing 6.12). Thisexample also illustrates the combination of SQL-based time point queriesand the graph-based filtering on non-temporal network properties. Withthe time point restriction provided in the URL, the SPARQL query oper-ates on a historical representation of the network, which is recovered fromthe relational storage layer as described in Sect. 6.3. In plain language,this query can be expressed as “Give me a list of all Wiki pages that werereferenced in at least one email at June 4th, 2009.”

Client Request:

1 GET / graphs / tcn1 /2009−06−04/ r e s o u r c e s /? query=%3Fresource+rd f%3Atype+ex%3AWikiPage.%3 Fresource+ex%3AlinkedFrom+%3Fx.%3Fx+rd f%3Atype+ex%3AEmail

2 Host : d s to r e . hpi−web . de3 Accept : a p p l i c a t i o n / j son

Server Response:


7 {” totalCount ” : 1 ,8 ” r e s o u r c e s ” : [9 {” id ” : 2 ,

10 ” u r l ” : ” http ://www. example . com/ wik i /ToDoList ” ,11 ” l a b e l ” : ” Wiki − ToDoList ” ,12 ”validFrom ”:”2009−06−01 0 9 : 1 5 : 59 ” ,13 ” val idTo ”:”2009−06−04 16 :14 :27”}14 ] }

Listing 6.12. Retrieving Wiki pages that have been referenced in an email.

6.4.3 Manipulating Team Collaboration Network Resources

Sensor clients constantly manipulate the state of Team Collaboration Net-works by requesting the d.store server to adapt the structure of the net-


works according to the captured collaboration events. The following exam-ples show how basic operations for the creation and deletion of node in-stances are implemented. For a comprehensive documentation of networkoperations including node updates and the manipulation of attributes andrelationships, please refer to Appendix C.

Creating a Node Instance

The creation of a node instance denotes the occurrence of a new actor orresource in the collaboration process of a team. A sensor client informs thed.store server about the additional resource by posting according meta-information to the network. The entity transmitted by the client includesthe URL of the collaboration resource and optional parameters for at-tributes and relationships to other resources. In the following example, asensor client is posting a new email resource with two attributes and onerelationship (Listing 6.13).

Client Request:

1 POST / graphs / tcn1 /now/ r e s o u r c e s HTTP/1 .12 Host : d s to r e . hpi−web . de3 User−Agent : email−s enso r /1 .04 Accept : a p p l i c a t i o n / j son5 Content−Type : a p p l i c a t i o n / j son6

7 {” u r l ” : ” http :// mail . example . com/ arch ive /0001 . html”8 ” l a b e l ” : ” Meeting”9 ” types ” :” Email ” ,

10 ” a t t r i b u t e s ” : [11 {”name ” :” from” , ” value ” :” paul@example . com”} ,12 {”name ” :” to ” , ” va lue ” :” john@example . com”} ] ,13 ” r e l a t i o n s ” : [14 {”name ” :” hyper l ink ” , ” t a r g e t ” :” http ://www. example . com/ wik i /

Idea l og ”} ]15 }

Server Response:

16 HTTP/1.1 201 CREATED17 Locat ion : http :// ds to r e . hpi−web . de/ graphs / tcn1 /now/ r e s o u r c e s /318 Content−Type : a p p l i c a t i o n / j son19

20 {” id ” : 3 ,21 ” s t a t u s ” :” c rea ted ” ,22 ”validFrom ”:”2009−06−02 12 : 12 : 29 +0100” }

Listing 6.13. Creating a Node Instance.

If the node has been successfully created in the network, the d.storeserver assigns a distinct ID and points the client to the URL of the newinstance (line 19).


Removing a Node Instance

Nodes are removed from a network to indicate the deletion of a collabora-tion resource, such as s shared file or a Wiki page. Sensor clients detectingthat a resource has been removed from the team’s information space cannotify the d.store server by requesting the removal of the according nodeinstance via HTTP DELETE (Listing 6.14). The operation effects the in-validation of the node instance in the current network representation atthe time point specified in the URL.

Client Request:

1 DELETE / graphs / tcn1 /now/ r e s o u r c e s /2 HTTP/1 .12 Host : d s to r e . hpi−web . de3 User−Agent : wiki−s enso r /1 .04 Accept : a p p l i c a t i o n / j son

Server Response:


8 {” id ” : 2 ,9 ” s t a t u s ” :” de l e t ed ” ,

10 ” val idTo ”:”2009−06−02 10 : 17 : 00 +0100”}

Listing 6.14. Removing a Node Instance.

Note that subsequent requests to this URL will result in a ‘404 NOTFOUND’ server response. To receive the invalidated node at a later point,the URL path needs to be altered to refer to a network state before thedeletion of the node.

6.5 Chapter Summary

In this chapter, the d.store platform and its architectural components havebeen introduced. The platform implements a Team Collaboration Networksystem, which can be independently utilized by client applications throughits resource-oriented service interface. The system constitutes an instru-ment for the computational observation and analysis of virtual collabo-ration groups and is applied in a pilot application presented later in thiswork. With the specification of domain ontologies, the platform can beflexibly tailored to the different groupware environments and teams underobservation. This customization process is subject of the next chapter. Itintroduces a set of domain ontologies to prepare for the pilot applicationpresented later in the work.

7

System Configuration

The d.store platform introduced in the previous chapter presents a genericsolution for capturing the heterogeneous information sharing activities inonline collaboration. This chapter illustrates the flexibility of the systemby demonstrating how it is configured to integrate with actual groupwareand team landscapes. It presents domain ontologies and rules, which pro-vide common TCN terminology for widespread application scenarios suchas email communication and collaborative Wikis. With those ontologiesdefined, the platform is customized and prepared for the application in acollaboration testbed presented in the final part of this dissertation.

7.1 Domain Ontologies for Online Collaboration

Domain ontologies define common and shared vocabularies to be used in aTeam Collaboration Network system (Sect. 5.2.1). Through the configura-tion and adaptation of the ontology descriptions, the system is tailored tothe specific requirements and setup of the observed collaboration process.The modeling of domain ontologies is driven by the groupware systemsthat are applied in the process, as well as prevailing goals, legal aspects,and technical restrictions in the monitoring of online team activities.

This sections introduces an initial collection of domain ontologies, eachone defining common semantic concepts encountered in online team collab-oration. The ontologies cover basic collaboration aspects of Wiki systems,email messaging, and shared file systems. Due to the proliferation of thesegroupware applications, the collection present a practical starting point fora wide range of virtual collaboration studies. For this work, the ontologiesprovide the vocabulary that is used to describe online activities in the anal-ysis of eleven engineering design projects (Chap. 8). The domain ontologiesbuild on the core definitions of the d.store concept graph (Sect. 6.2) andare represented in the graphical notation introduced in Sect. 3.4.4.

110 System Configuration

7.1.1 web: An Ontology for Hyperlinked CollaborationResources

The World Wide Web has evolved to a multi-facetted collaboration plat-form for team-based interactions and information sharing activities. Partof this success is attributable to the simplicity in referencing and hyper-linking arbitrary media via URLs. Information on the Web can easily beconnected and disseminated by pointing others to its resource location.This may happen in various ways, e.g., verbally or by embedding hyper-links in other Web resources. It is also very common among team membersto share information by sending text messages or emails containing URLsto the resources of interest. The following email snippet from one of theobserved teams gives an example (Fig. 7.1).

From: <removed>

Sent: Thu Mar 06 2008 - 10:30:40 PST

To: <removed>

Subject: [<removed>] Notes online

Hey gang,

that was a nice, quick meeting this morning. The notes are online:

http://wikibox.stanford.edu/07-08/index.php/<removed>/Minutes3608

[...]

Here is a link to the infrared ranging sensors I mentioned:

http://www.phidgets.com/products.php?product_id=1103

Remember: Skype this Sunday, 12:30PM PST

Figure 7.1. Emails are a popular medium to share and point others to relevant information onthe Web.

Apparently, Web resources are not only referenced from other Web re-sources, but are also semantically connected to information assets, whichare not necessarily located on the Web per se (e.g., emails or attacheddocuments). This relationship is reflected in the web ontology shown inFig. 7.2.

The ontology specifies a node type ‘WebResource’ to classify informa-tion resources in the Web. Note that this type is a specialization of the mostgeneral class of information objects in d.store, the ‘Resource’. By definingtwo inverse relationship types ‘hyperlink’ and ‘linked from’, bi-directionalassociations between the referenced and the referencing resources are es-tablished.

7.1. Domain Ontologies for Online Collaboration 111

http://hpi-web.de/ns/dstore/web/0.1/

@prefix dstore: http://hpi-web.de/ns/dstore/0.1

dstore:DomainRelationlinkedFrom

WebResource

dstore:DomainResource

inversedstore:Resource

dstore:DomainRelationhyperlink

Figure 7.2. An ontology for hyperlink relationships between general collaboration resources(dstore:Resource) and Web resources.

7.1.2 wiki : An Ontology for Wiki-based Collaboration

Wikis have been widely adopted in professional scenarios and project-basedcollaboration to support teams in documentation and organizational tasks.The content is contributed, accessed, and incrementally revised by a com-munity of registered users. Depending on the configuration of the Wiki,users must log in to the system in order to modify or access its content.Wiki systems generally keep log files of page visits and content revisionsmade by authenticated users, a fact which renders this medium applicablefor the computational analysis of collaboration practices. It allows the ex-amination of relationships between (the content of) individual Wiki pagesand their contributors (cf., e.g., Mueller, 2008).

Figure 7.3 shows an ontology for Wiki-related concepts and associa-tions that are used in the description of Team Collaboration Networks. A‘WikiPage’ is a specialization of a Web resource and represents an indi-vidual, editable topic in a Wiki. Wiki pages are authored by users of thesystem (‘dstore:Person’ ), who are identified by a ‘username’. The ontol-ogy further defines two attribute types ‘create user’ and ‘edit user’, whichappoint the usernames of the creator and the editors of a Wiki page.

Modern Wiki systems also support file attachments that can be up-loaded to a topic. This can be, e.g., images or documents that are relatedto the information on a page. Attachments are reflected in the ontologyby the node type ‘WikiAttachment’ and the two inverse relationship types‘attachment’ and ‘attachedTo’.

7.1.3 email : An Ontology for Email-based Messaging

Email messaging is the most common technology used today to digitally ex-change information in an asynchronous and reliable manner. Studies pointout that global virtual teams largely rely on day-to-day email communi-cation (Lurey and Raisinghani, 2001). The characteristic features of email


http://hpi-web.de/ns/dstore/wiki/0.1/

@prefix dstore: http://hpi-web.de/ns/dstore/0.1/@prefix web: http://hpi-web.de/ns/dstore/web/0.1@prefix xsd: http://www.w3.org/2001/XMLSchema#

dstore:DomainRelationauthor

WikiPage

web:WebResource

dstore:Person

xsd:string

dstore:DomainAttributedstore:AliasReferenceAttribute

create_user

xsd:string


edit_user

xsd:string

dstore:DomainAttributedstore:AliasAttribute

username

WikiAttachment

web:WebResource

dstore:DomainRelationattachment

dstore:DomainRelationattachedTo

inverse

dstore:DomainRelationcontributedTo

inverse

Figure 7.3. wiki : An ontology for concepts and properties in Wiki-based collaboration.

systems have led to a strong pervasiveness of this medium in virtual collab-oration. Access to email systems is available almost anytime and anywhere,allowing asynchronous, ad-hoc transmission and retrieval of messages with-out needing to organize and participate in synchronous interactions.

Figure 7.4 shows the ontology of node, relationship, and attributetypes that have been used in the formalization of email communicationactivities in Team Collaboration Networks. The node type ‘Email’ rep-resents messages that have been sent and received by node instances oftype ‘dstore:Person’. The coherences between emails, sender, and receiverare described by the four relationship types ‘sender’/‘hasSent’ and ‘re-ceiver’/‘hasReceived’. Emails are further characterized by a number of at-tributes. The ontology defines attribute types for the mailbox addressesof the sender (‘from’ ) and recipients (‘to’, ‘cc’ ), the unique message ID,and the optional ID of a preceding email to which a message replies (‘re-ply to id’ ). The semantic association between a message and a response isexplicitly articulated by the inverse relationships ‘reply’ and ‘repliesTo’.

The email attributes ‘from’, ‘to’, and ‘cc’ are specified as references tothe alias attribute ‘mailbox’, which in turn assigns an email address to a

7.1. Domain Ontologies for Online Collaboration 113

http://hpi-web.de/ns/dstore/email/0.1/

@prefix dstore: http://hpi-web.de/ns/dstore/0.1@prefix xsd: http://www.w3.org/2001/XMLSchema#

dstore:DomainRelationrepliesTo

Email


inverse

inverse

dstore:DomainRelationreply

xsd:string


from

xsd:stringdstore:DomainAttribute

message_id

xsd:stringdstore:DomainAttribute

reply_to_id

dstore:DomainRelationsender

dstore:DomainRelationrecipient

dstore:Persondstore:DomainRelation

hasSent

dstore:DomainRelationhasReceived

Attachment


dstore:DomainRelationattachment

inverse

xsd:stringdstore:DomainAttributesubscriber_mailboxEmailList


xsd:string


mailbox

xsd:string


to

xsd:string


cc

dstore:DomainRelationattachedTo

inverse

Figure 7.4. email : An ontology for concepts and properties in email-based communication.

person. The ontology also considers file attachments (‘Attachment’ ), andprovides the relationship types ‘attachment’ and ‘attachedTo’ to expressthe association with an email. The concept of an ‘EmailList’ representsa distribution list that can have an arbitrary number of email recipientssigned up to it, as indicated by the ‘subscriber mailbox’ attribute.

7.1.4 file: An Ontology for Shared Document Storages

A shared document storage is a system that allows users to access, edit, andmanage files collaboratively on remote servers. WebDAV (Goland et al.,1999) is an open standard and extension to HTTP, which implements ashared document storage on the Web. Files and folders can be accessedand modified by users directly in the Web browser or virtually mountedinto the local file system. This turns WebDAV-enabled storage systems to


http://hpi-web.de/ns/dstore/webdav/0.1/

@prefix dstore: http://hpi-web.de/ns/dstore/0.1/@prefix xsd: http://www.w3.org/2001/XMLSchema#

dstore:DomainRelationsharedBy

File

web:DomainResource

dstore:Person

xsd:stringdstore:DomainAttributedstore:AliasReferenceAttribute

create_user

xsd:string


username

dstore:DomainRelationhasShared

inverse


read_user


edit_user


delete_user

dstore:DomainRelationaccessedBy

dstore:DomainRelationhasAccessed

inverse

Figure 7.5. file: An ontology for basic collaboration activities in shared document storages.

a convenient tool for the collaborative sharing, editing, and archiving ofproject-relevant documents in distributed teams.

A minimal ontology for shared document storages defines basic asso-ciations between people and the shared files (Fig. 7.5). It considers fouroperations on a file that are carried out by users. The ‘username’ aliasesresponsible for creating, reading, editing, and deleting a file during its life-time are assigned to a ‘File’ instance by means of the attribute types ‘cre-ate user’, ‘read user’, ‘edit user’, and ‘delete user’. The relationship typesprovided by the ontology are less distinctive. Persons access files for reading(‘hasAccessed’/‘accessedBy’ ) or publish information by creating or modi-fying a file (‘hasShared’/‘sharedBy’ ).

7.2. Inference Rules 115

7.2 Inference Rules

Based on the introduced domain ontologies, additional inference rules arespecified in the platform to computationally derive relationships in TeamCollaboration Networks. The rules are defined as pairs of preconditions andimplied postconditions, presented in the form antecedent ⇒ consequentas in Sect. 5.2.1. Please refer to the specifications of SWRL (W3C, 2004g)and RDF/XML (W3C, 2004e) for a mapping of these rules to a set of RDFtriples.

The logical inference of relationships lowers the number of relationsthat are explicitly stored in the graph. At the same time, the rules simplifythe data entry and update process by reducing the semantic associationsthat need to be determined and uploaded by sensor clients. To give a firstexample, the following rule is specified to infer ‘email:sender’ relationships,using the ontological concepts defined in the email ontology:

email:from(x,y) ∧ email:mailbox(z,y) ⇒ email:sender(x,z)

The rule states that an ‘email:sender’ relationship exists between anytwo nodes x and z, if x has an ‘email:from’ attribute of value y and zhas an ‘email:mailbox’ attribute of the same value y. Note that, with thespecification of an inverse relationship for ‘email:sender’ in the domainontology, an OWL-DL reasoner would simultaneously assert an according‘email:hasSent’ relationship between z and x.

Analog rules are provided to calculate relationships between email mes-sages and their recipient nodes:

email:to(x,y) ∧ email:mailbox(z,y) ⇒ email:recipient(x,z),email:cc(x,y) ∧ email:mailbox(z,y) ⇒ email:recipient(x,z)

Corresponding to the sender and receiver relationships of emails, rela-tionships between Wiki resources and people who have created or edited apage are inferred based on the according attribute values ‘wiki:username’,‘wiki:create user’, and ‘wiki:edit user’.

wiki:create user(x,y) ∧ wiki:username(z,y) ⇒ wiki:author(x,z),wiki:edit user(x,y) ∧ wiki:username(z,y) ⇒ wiki:author(x,z)

The same approach is practiced for file associations between the usersand documents of an online shared storage:

file:read user(x,y) ∧ file:username(z,y) ⇒ file:accessedBy(x,z),file:create user(x,y) ∧ file:username(z,y) ⇒ file:sharedBy(x,z),

file:edit user(x,y) ∧ file:username(z,y) ⇒ file:sharedBy(x,z)


The determination of bidirectional relationships between emails andtheir associated replies (‘email:reply’/‘email:repliesTo’ ) is governed by thefollowing rule. Sensor clients only need to specify the unique message IDand the value of the ‘reply-to’ field from the email header as attributes inthe posting of a new email instance. Based on these values, the rule infersaccording relationships between two email nodes with matching attributesvalues:

email:reply to id(x,y) ∧ email:message id(z,y) ⇒ email:repliesTo(x,z)

Distribution lists conceal the list of people who receive the messagessent to it. However, the email addresses of the subscribers are often knownfor project-internal distribution lists and explicit relationships between themessages and the recipients are wanted. In this case, the following ruledetermines such relationships between emails sent to a list and persons,whose mailbox address is subscribed.

email:hasReceived(w,x) ∧ email:subscriber mailbox(w,y) ∧email:mailbox(z,y) ⇒ email:hasReceived(z,x)

With these inference rules defined in a TCN-S, a client’s effort of post-ing captured resources to a network is reduced. More concrete, clients arerelieved from resolving corresponding actor nodes from the captured aliaseslike email addresses and usernames. Based on the above rules, the servercan take care of identifying the according target nodes for sender and re-ceiver relationships based on the alias attributes assigned to person andresource nodes.

7.3 Preparing the Data Collection Process

With the domain ontologies and rules being defined in the d.store server,the platform is readily configured for one or more targeted collaborationenvironment. The following preparatory activities complete the setup ofthe system and initialize it for the actual data collection process and thegeneration of Team Collaboration Networks.

7.3.1 Initializing the Networks

A new TCN instance is created for each team that is to be observed inits collaboration activities. For this purpose, the platform API acceptspostings to the graph collection resource, in which a client specifies keyattributes for the new network. This includes a shorthand network identifieras well as a list of ontology and rule identifiers that should be mapped intothe TCN knowledge base (Listing 7.1).

7.3. Preparing the Data Collection Process 117

Client Request:

1 POST / graphs HTTP/1 .12 Host : d s to r e . hpi−web . de3 Accept : a p p l i c a t i o n / j son4 Content−Type : a p p l i c a t i o n / j son5

6 {” id ” :” alpha ” ,7 ” l a b e l ” : ” Pro j e c t Alpha ” ,8 ” d e s c r i p t i o n ” : ”” ,9 ”domains ” : [

10 {” ns ” :” http :// hpi−web . de/ns/ ds to r e /web /0 .1/” , ” p r e f i x ” :” web”} ,11 {” ns ” :” http :// hpi−web . de/ns/ ds to r e / emai l /0 .1/” , ” p r e f i x ” : ” emai l ”}

]12 }

Server Response:

13 HTTP/1.1 201 CREATED14 Locat ion : http :// ds to r e . hpi−web . de/ graphs / alpha15 Content−Type : a p p l i c a t i o n / j son16

17 {” s t a t u s ” :” c rea ted ” , ” id ” :” alpha ”}

Listing 7.1. Creating a TCN instance.

In this example, a Team Collaboration Network ‘alpha’ is initializedwith two network-specific domain ontologies ‘web’ and ‘email’.

7.3.2 Setting up the Sensor Clients

The way sensor clients are implemented and integrated into the collab-oration infrastructure determines how detailed and up-to-date the TeamCollaboration Networks are. Consequently, the real-time monitoring andanalysis of a collaboration process depends on sensor clients that continu-ously detect collaboration events as they occur and incrementally uploadaccording meta-information to the server. In the case of an ex post analysis,the clients could be programmed to process recorded log files or archivesand upload the time-stamped activities at once.

A number of sensor clients have been prototypically implemented for thepilot application conducted later in this work. A feeder application for emailactivities scans the messages sent to the distribution lists of teams, eitherby scanning the message log provided by the list server in the InternetMessage Format (Resnick, 2001), or by parsing the Web archive that iscreated with the Hypermail1 tool. A sensor client for Wiki activities hasbeen developed, which is parsing the server-side file structure generatedby a TWiki2 system. A third sensor client processes the event logs of aWebDAV-server to upload information about file-related online activitiesinto the networks.1 Hypermail: http://www.hypermail-project.org/, accessed Oct. 19th, 20102 TWiki: http://twiki.org/, accessed Oct. 19th, 2010


With the communication between clients and server established byHTTP and standard representation formats, the implementation of sen-sor clients has proven to be relatively inexpensive and unrestricted withregard to development and runtime environments. The resource-orientedsystem design promotes the straightforward integration of heterogeneousand distributed data sources for collaborative activities and makes thed.store platform a flexible and extensible monitoring instrument for di-verse application scenarios.

7.3.3 Specifying Participant Roles and Alias Names

The stakeholders in a collaboration process can be generally classified intodifferent roles that they fulfill in a project: team members, consultants,managers, etc. In addition, the individual actors are represented by meansof virtual identities or aliases and usernames. Participants use multipleemail addresses and user accounts for different collaboration platforms, bywhich they are identified and which serve as surrogates in the accomplish-ment and logging of virtual activities.

For this reason, a client application d.person has been implemented tosupport in the assignment of role types and alias attributes (Fig. 7.6). Hu-man actors are represented as individual node instances in a TCN, whichraises the need to consolidate the different virtual surrogates of a per-son and to map user accounts to the representing nodes. Different emailaddresses and usernames in the communication process can then be at-tributed to the responsible person. Roles are assigned as node types, whichare either defined by imported domain ontologies or which are created inthe network-internal concept graph. An example for a project-specific roleontology is given in the next chapter, where the testbed and team config-uration for the pilot application is introduced.

7.4 Chapter Summary

With the introduction of concrete domain ontologies, the customizationof the d.store platform has been exemplified. Each ontology defines node,relationship, and attribute types that are used in TCN instances to describethe collaboration activities related to a particular domain of groupwareapplications. Sensor applications make use of this terminology to notify theserver about collaboration structures that have been captured from digitalevent traces such as logs, archives, etc. With that, Team CollaborationNetworks are gradually constructed and can be leveraged in the real-timemonitoring and analysis of complex online collaboration processes.

In the final part of this dissertation, the platform is taken to evaluationin an industry-oriented project testbed. The Team Collaboration Networks

7.4. Chapter Summary 119

Figure 7.6. d.person: A client application to manage the roles (types) and alias attributes ofperson nodes in Team Collaboration Networks.

of eleven distributed engineering design teams are analyzed and comparedto demonstrate the application of this approach. Qualitative insights andstatistical evidence underpin the value of computational monitoring byrevealing meaningful and performance-relevant characteristics in the col-laboration behavior of the observed teams.

Part IV

Evaluation & Discussion

8

A Pilot Application in Engineering Design

The most exciting phrase to hear in science, the one thatheralds new discoveries, is not ‘Eureka!’ (I found it!) but‘That’s funny ...’.

– Isaac Asimov

In the previous chapters, the work has introduced Team CollaborationNetworks as a model to describe the evolving relationships between infor-mation resources and stakeholders in a virtual collaboration process. It hasfurther introduced d.store, a configurable, service-based software systemthat enables the instantiation of such networks and the automated cap-ture of collaboration activities in diverse team and project settings. Theseconcepts are now put into praxis by applying the d.store platform in thecollaboration processes of eleven globally distributed engineering designteams. This chapter summarizes the first application of d.store in a realis-tic project scenario and presents the results of an explorative analysis thathas been conducted on the collected data.

The eleven Team Collaboration Networks, each one generated over aproject period of eight months, provide extensive opportunities for thestructured exploration of online communication behavior during the earlystages of conceptual design. Specific analysis clients have been implementedto process, visualize, and compare the TCN instances from different angles.This chapter documents the insights and findings that could be gained fromthese observations. At the same time, it demonstrates the potential rangeand informational value of observing real-time collaboration metrics in thecontext of project management and design research.

After introducing the pilot testbed in Sect. 8.1, the chapter highlightsthree major blocks of investigations, each one motivated by distinct goalsand research questions:

• The work begins with a quantitative investigation of the captured designteam activities to appraise the scope of the generated Team Collabora-tion Networks. What was the volume and the structure of the collectedactivity data and how does it vary between different teams? (Sect. 8.2)

• Explorations into the temporal network characteristics visualize the evo-lution and variation of collaborative activities over time. How does col-laboration behavior evolve differently in the teams? (Sect. 8.3)

124 A Pilot Application in Engineering Design

• A statistical analysis seeks to identify correlations between specific net-work patterns and independently surveyed team performance measures.Can we predict team performance from objectively measured collabo-ration structures? (Sect. 8.4)

The chapter finishes with a summary of the analysis results and dis-cusses the limitations and applicability of the findings in Sect. 8.5.

8.1 ME310: A Global Academic Project Testbed

A project-based engineering design curriculum serves as a testbed forthe d.store platform. Stanford University’s ‘Mechanical Engineering 310– Project-Based Engineering Design, Innovation & Development’ (hence-forth ‘ME310’) is a nine-month graduate level engineering course in whichStanford students collaborate with students at other universities aroundthe world to develop innovative solutions to open-ended problems. Smalldistributed teams work on real-world engineering design challenges posedby industry partners. The design tasks given out to the teams are pur-posely phrased broadly to challenge the students to determine, isolate, andpursue a particular opportunity for innovation. Skogstad (2009) comparesthe nature of the projects and the structure of the teams in ME310 withthe working mode of start-ups in industry: “like many Silicon Valley ini-tiatives, design teams start with a vague idea of an area that allows for thecreation of innovation” in a new or existing market.

8.1.1 Project & Team Setups

Eleven distributed teams were jointly formed of students from Stanford andsix partner institutions. Stanford’s engineering graduates were partneringwith students in product design, industrial design, or computer science, tofoster inter-disciplinary teamwork and problem solving. The desired teamsize was six to eight students, with three or more students representinga co-located sub-team on both partner sides. All teams had an equallysized budget at their disposal, which could be spend for the acquisition ofmaterials, services, and prototype development.

Figure 8.1 summarizes the general setup and the participating roles inME310 for the academic term 2007/2008. Each of the global teams hasbeen given a realistic engineering design challenge by a corporate liaison.The challenge grounds on a relevant, but open-ended design problem fromone of diverse industries such as automotive, consumer products, telecom-munications, or information technology. Over the course of the projects,the teams had to identify needs, generate concepts, and create fully func-tional prototypes to show a potential path to innovation to the corporate

8.1. ME310: A Global Academic Project Testbed 125

Industry Partners

Global Partner InstitutionsCenter for Design ResearchStanford University

Team 1LocalSub-team

GlobalSub-team

Teac

hing

Tea

m

Team nLocalSub-team

GlobalSub-team

Corporate Liaison 1

Corporate Liaison n

Teaching Team

Coaches Coaches...

Figure 8.1. Roles and process participants in the project-based engineering design curriculumME310.

sponsor. A teaching team and a group of coaches supports and guides thestudents at the participating institutions. Table 8.1 summarizes the designchallenges that were given to the student design teams:

Table 8.1. Overview of ME310 projects in 2007/2008 (Skogstad et al., 2009).

Team Task

Alpha Design an intelligent system to assist driversBeta Design a tool that facilitates distant design collaborationDelta Design a system to store small items in a carEpsilon Design a tool to support maintenance personnel in the fieldGamma Design a new automotive center stackIota Design a device that extracts drinking water from ambient airKappa Design a new digital cameraLambda Design a method to control wearable electronic devicesOmega Design a new way to use RFID in a retail environmentPi Design an industrial controller based on gesture technologyTheta Design a virtual convertible

The project timelines are structured into three major phases with aduration of two to three months each. The first phase (‘make it up’) includesteam building (local and global sub-teams come together for a short kick-off workshop) and is characterized by frequent benchmarking, fact finding,and brainstorming, and prototyping activities. The second phase (‘makeit real ’) aims towards the technological feasibility of the student’s vision,


Figure 8.2. Team members and teaching team during a weekly project meeting. The ME310design space provides an open environment for collocated sub-teams at Stanford University.Remote team interactions are supported by a shared ICT infrastructure for virtual collaboration.

refining concepts, and the implementation of their ideas. The third phase(‘make it happen’) is about getting things done, making final decisions andpresenting a fully functional solution at the end of the projects. The ME310course framework stipulates a constant evaluation of the teams’ progressthrough weekly meetings with the teaching teams and prototype reviewsat the end of each phase.

8.1.2 Process Participants & Team Interactions in ME310

The student team members used local face-to-face meetings, email, instantmessaging, phone, video conferencing, and other communication channelsto interact and share information with their partners and other stakehold-ers. All teams had access to a uniform groupware infrastructure to facil-itate and organize their remote collaboration activities (more details be-low). This large number of channels allowed the teams to interact at anytime and from almost anywhere, similar to distributed project teams inglobal industries. Besides the interaction in and between local or remotesub-teams, Skogstad (2009) describes the following modes of interaction inME310 and highlights parallels to industrial project setups:

Interactions between team and corporate liaison: “The project-basednature of the course requires the student teams to interact with liaisons

8.1. ME310: A Global Academic Project Testbed 127

from the company sponsoring their projects. These liaisons typicallymeet with the students once per week in meetings or conference calls.The liaisons are equivalent to a design consultancy’s customer. Theyare external to the team and not included in the intra team communi-cation.”

Interactions between team and teaching team: “The teaching teammeets weekly with each design team to discuss project progress andfuture steps” (see Fig. 8.2). “These small group meetings [...] are char-acterized by a high level of interaction, open exchange of ideas, sugges-tions and critique from multiple viewpoints. Comments often includereferrals to experts outside the curriculum’s community for help on par-ticular problems. This mode of interaction resembles that of review byproject management and company-internal executives in industry.”

Interactions between team and coach: “Each team also receives sup-port and guidance from a design process coach who has professional in-dustry experience but is not part of the review or grading process. Thecoach helps the students with expert subject knowledge and projectand team management. Coaching is seldom found in industry at theproject level, but regularly at the individual level. Companies oftenhave ‘mentorship programs’ to support so-called ‘high-potentials’ intheir development within the company.”

The general setup and the interactions in ME310 projects describedabove show that the observed design teams share similar characteristicswith those found in industry. Continuous communication among teammembers and with external process stakeholders presents a core facet in thecourse work. Unlike industry, however, ME310 is uniquely suitable for re-search studies as the milestones, deadlines, and project breadth and depthare common between teams. These commonalities make ME310 “a con-trolled environment compared to industry settings, which makes the effectof team circumstances on design performance observable in ways not pos-sible elsewhere” (ibid.).

8.1.3 A Shared ICT Infrastructure for Virtual Collaboration

A centrally managed ICT infrastructure for virtual collaboration supportis provided to the student teams. The design spaces at Stanford and theglobal academic partner institutions are equipped with workstations thatgive access to the Internet and groupware systems. Three email distribu-tion lists are set up for each team to simplify the sending of messages toeither one of the two sub-groups or to the whole team. Every email sentto a list is instantly archived and published in a set of cross-referencedHTML documents, which are accessible to other course participants. A


(a) Workstations provide access to the Internetand central groupware systems.

(b) Video conferencing systems establish re-mote interactions between local team membersand their distant project partners.

Figure 8.3. Impressions of the ME310 design space at Stanford University. A shared ICTinfrastructure supports global collaboration between distributed team members.

central Wiki installation serves as a portal to all course-relevant infor-mation and to individual collaboration rooms of the eleven projects. Theteams leverage and organize the Wiki as they please, e.g., for documentingproject-relevant knowledge or disseminating information to other processstakeholders. To establish a common file space and to ease the exchange oflarge files (e.g., audio and video recordings), all team members have accessto a WebDAV-based file storage. Video conferencing systems for distributedgroup meetings are available at all team locations worldwide to establishsynchronous conversations among the students (see Fig. 8.3).

The centrally managed groupware infrastructure satisfied the most el-ementary needs in establishing global collaboration between distributedsub-teams. This has led to a relatively large coverage of online team inter-actions on the ME310 servers and simplified the implementation of sensorclients for team communication capture.

8.1.4 Privacy and Confidentiality of the Observations

The issue of information privacy becomes increasingly important as moreinformation about collaboration activities is recorded and made available.The computational processing and analysis of team interactions necessi-tates the strict observance of research ethics and the protection of humanresearch subjects. The studies connected to this pilot application protectthe privacy of the ME310 participants and take measures to prevent unau-thorized access to private or confidential information. Only data that isvoluntarily provided through the shared ICT landscape in ME310 has beenused in the exemplary application of the d.store platform. All team mem-bers have been informed about and agreed to the scientific exploitation of

8.2. A Quantitative Appraisal of the Generated Networks 129

this data. Any references to real persons, project partners, and externalparties have been anonymized.

8.1.5 me310 : An Ontology for Project Roles & Participants inME310

The four domain ontologies presented in Sect. 7.1 provide a basic termi-nology for the creation of Team Collaboration Networks in the context ofthe groupware utilized in ME310. The ontologies are deliberately genericin the sense that they do not comprise any concepts that are specific toa particular project setup. However, a project-specific taxonomy of par-ticipant roles can improve the interpretability of captured activities andallows for a finer-grained specification of collaboration relationships. Forthis reason, a ME310-specific domain ontology is introduced and used inthis pilot application to mark the roles of process participants.

The ontology shown in Fig. 8.4 defines roles and stakeholders in theME310 community. On top level, the ontology distinguishes between rolemembers that are located at the Stanford design space (‘Local’ ) and theirglobal counterparts at the academic partner institutions (‘GlobalPartner’ ).A second differentiation classifies the participants into a ‘Student’ groupand a ‘Non-Student’ group. From a single project point-of-view, the setof students is formed those that are members of the team (‘Team’ ) andthose that are not (‘Non-Team’ ). The team itself consists of local students(‘LO Team’ ) and the global partner students (‘GP Team’ ). Non-studentcourse stakeholders include the members of the teaching teams (‘Teach-ingTeam’ ), coaches (‘Coach’ ), the corporate liaisons (‘CorporateContact’ ),and administrative personnel (‘Administrative’ ).

This application-specific ontology of role concepts identified in ME310completes the terminological definition of Team Collaboration Networksin the pilot scenario. Using the d.person tool (Sect. 7.3.3), the individualactors in the observed processes have been assigned with the according roletypes, allowing for a fine-grained, group-based filtering and analysis of theteam activities.

8.2 A Quantitative Appraisal of the Generated Networks

For each of the eleven teams in ME310, a Team Collaboration Networkhas been generated by processing the email archives, Wiki logs, and Web-DAV activities of the global projects. This section explores the volume andcomprehensiveness of the data that has been collected by three accordingsensor clients over the course of the nine-month projects. Quantitative net-work properties between the different teams are compared to indicate theresultant proportions of the eleven network instances Alpha to Theta.


http://hpi-web.de/ns/dstore/me310/

@prefix dstore: http://hpi-web.de/ns/dstore/0.1@prefix owl: http://www.w3.org/2002/07/owl#

TeachingTeam

LO_TeachingTeam

CorporateContact

Coach

Team Student

LO_Coach GP_Coach

GP_Team

Administrative

Non-Team Non-Student

Local GlobalPartner

owl:com

plem

entOf

LO_StudentLO_Team

GP_Student

owl:disjointWith

GP_TeachingTeam

dstore:Person dstore:Person

Figure 8.4. me310 : A classification of project participants and roles in the observed designcurriculum ME310. The ontology defines role hierarchies for course stakeholders on local andglobal partner side.

Table 8.2 gives an overview of the network dimensions after the datacollection process. It shows the total number of network nodes, as wellas the amount of nodes of type ‘dstore:Person’ and ‘me310:Team’. Thetotal number of relationships results from the asserted relations explicitlystored in a network’s ABox plus those being inferred by the OWL-DLreasoner and rule engine used in d.store (Chap. 6). Over the course ofnine month project-based team work and remote collaboration, the sensorclients captured approx. 10,000 email messages, 814 Wiki pages with morethan 4,000 editing events, and approx. 9,000 write activities in the project


Table 8.2. Key dimensions of the generated Team Collaboration Networks.

Team Nodes Relationships Attributes(Total / Person / Team) (Total / Inferred)

Alpha 2,622 / 109 / 6 14,323 / 13,605 9,412Beta 3,496 / 116 / 6 16,797 / 15,166 10,113Delta 2,517 / 109 / 7 13,059 / 12,192 8,347Epsilon 1,653 / 75 / 7 7,401 / 6,724 4,583Gamma 1,968 / 113 / 7 11,068 / 10,447 6,631Iota 4,807 / 81 / 11 22,309 / 21,680 14,890Kappa 2,058 / 137 / 6 9,844 / 8,689 5,796Lambda 2,817 / 98 / 7 14,538 / 13,546 8,758Omega 2,352 / 107 / 7 10,158 / 9,341 6,564Pi 1,905 / 83 / 7 10,125 / 8,998 6,117Theta 666 / 108 / 7 3,426 / 3,163 2,331

WebDAV folders. The resulting TCN knowledge bases comprise approx.240,000 semantic statements and associated validity intervals.

In the following sections, a more detailed appraisal of the Team Collab-oration Networks focuses on aspects specific to one of the three differentdomain ontologies email, wiki, and webdav.

8.2.1 Activities Captured From Email Lists

The email distribution lists provided to the teams have been frequently usedby the students and other course stakeholders to broadcast messages to themembers of a project team. A survey carried out with the students afterthe projects estimates that an average of two third (66.64%) of all project-related email traffic has been sent or copied to one of the email lists. Therest of the email traffic was sent point-to-point between individual projectparticipants and has therefore not been considered in this study. Anyhow,this ratio supports the assumption that the emails that have been capturedfrom the email archives constitute a relevant and representative amount ofthe overall exchanged messages, making the archives a valuable source foranalysis.

The sensor client that was responsible for scanning the Web-based emailarchives identified basic attributes of an email such as sender and recipients,as well as the occurrence of attachments and hyperlinks in the email body.To demonstrate the fine-grained exploration capabilities established by thegenerated TCN structures, Fig. 8.5 quantifies the weekly email traffic inME310 along three dimensions: 1) the total number of email messages sentto the lists, 2) the number of resources referenced in the message bodies,and 3) the number of file attachments transmitted.

The graph shows that email lists as a communication medium wereused at a relatively constant rate throughout the course period, disruptedonly by two breaks in week 8 – 9 and week 21 due to school terms ending


0

50

100

150

200

250

300

350

400

450

500

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Weekly Amount of Emails, Hyperlinks, and A7achments sent via Email Lists

Email Hyperlinks A7achments

Project Week

Figure 8.5. Weekly amounts of emails, hyperlinks, and file attachments sent via the projectlists during the observed project period.

and public holidays. Breaking the amount of weekly emails down to theindividual project lists reveals that all teams frequently use the email listsfor information distribution, with the total number of emails is varyingbetween 268 and 1526 (Fig. 8.6).

The individual values can be queried from the network resources viasimple URL patterns. For example, the number of email messages sentto the distribution lists of project Alpha until a specified point in time(<date>) is determined by the size of the ‘Email’ node collection:

GET / graphs / alpha/<date>/r e s o u r c e s / emai l . Email

Parallel to that, the number of email attachments is determined by thesize of the according node collection:

GET / graphs / alpha/<date>/r e s o u r c e s / emai l . EmailAttachment

The number of distinct URLs being shared via emails is determinedby querying the networks for all resources that have a ‘web:linkedFrom’relationship to an email node. Passed as the query parameter to the nodecollection of a network (cf. Sect. 6.4.2), the following SPARQL clause causesd.store to return the corresponding list of nodes:

? r e sou r c e web : linkedFrom ?x .?x rd f : type emai l : Email

Aggregating the email traffic captured in 35 weeks of project collabora-tion results in a total number of 10,486 emails sent to the ME310 team lists,2,389 disseminated hyperlinks, and 1,956 file attachments. The weekly dis-tribution shown in Fig. 8.5 reveals a relatively constant usage of the email


0

200

400

600

800

1000

1200

1400

1600

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Total Amount of Emails on Distribu2on Lists per Team

Alpha Beta Delta Epsilon Gamma Iota Kappa Lambda Omega Pi Theta

Project Week

Figure 8.6. Total amount of emails sent to the project lists of each team.

lists with a few noteworthy peaks and lows. Mapping project milestonesand delivery deadlines onto the graph reveals an increased level of infor-mation transfer directly before the approach of a due date (week 6, 11,20). Interestingly, the usage of email lists declines shortly after a milestonedeadline or at the beginning of a new project phase (week 8, 13, 21). Themarginal project activities in week 9, 10, and 21 are attributed to publicholidays at the end of an academic quarter. The decrease of email traf-fic shortly before the end of the projects (week 33) is based on the factthat all members of the global teams were meeting face-to-face in Stan-ford to finalize their prototypes, largely eliminating the need for electroniccommunication.

Another insight into the usage of email as a medium for informationsharing comes from the frequency of transmitted file attachments and ref-erences to arbitrary resources via URLs provided in the email body. Com-paring the total amount of emails sent to the global team lists with thenumber of attachments and hyperlinks documents the important role thatemail lists play in the distribution of project-relevant information. The av-erage ratio between the number of emails and the number of informationsubmitted in the form of attachments and URLs is approx. 1 to 0.6. Obvi-ously, email lists provide a service to transfer information that is not onlyencoded in the message itself, but is often conveyed by means of multimediaattachments or pointers to resources found in the Web. The message bodyprevalently provides additional context for the attached or hyperlinked in-formation, as demonstrated in the following email (Fig. 8.7).

A visual network representation of selected nodes and relationships ina TCN is suitable for picturing the complexity of the email-based com-


From: <removed>

Sent: Thu Jan 26 2008 - 00:28:46 PST

To: <removed>

Subject: [<removed>] Sound Guidance Video!

Attachments: PIC00010.JPG

Hey Team,

We built a prototype for the sound guidance with the theremin!

(proximity sensing of hand to car controls) Check out the videos on

the fileserver:

http://wikibox.stanford.edu/<removed>/Sound%20Guidance%20Prototype/

We’ll be doing some more testing on monday. Let us know what you

think.

Figure 8.7. This email was sent by one team member to the rest of the global project team.The message body provides additional context for attached and hyperlinked resources.

Figure 8.8. Representation of the relationships between email messages (green), attachments(red), and email receivers (blue) captured in one of the projects.

munication structures. Figure 8.8 shows a high-level visualization of therelationships between email messages, receiving stakeholders, and file at-tachments, which has been generated from one of the Team CollaborationNetworks approximately half way into the project. Devoid of any details,


0

20

40

60

80

100

120

140

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Wiki Pages per Team


Project Week

Figure 8.9. Total amount of Wiki pages created in the projects.

the representation gives a bird’s eye view on the global email communi-cation structure, showcasing the complexity of the captured data and theunderlying team interactions. While the interpretation of such visual net-work patterns is still unclear, an increased degree of node connectednesscan already be an early indicator for an active involvement in the communi-cation process or identify communication hubs, which might have relevancefor the assessment of the collaboration activities or for the organization ofthe team as a whole. The ability to quickly generate such kinds of insightsinto the virtual collaboration process ad-hoc and at project runtime givesan impression of the platform’s potential to support the evaluation of dis-tributed collaboration processes.

8.2.2 Activities Captured From the Wiki System

A second sensor client observed the participant’s activities in the providedWiki system. The server-side files maintained by the system have beenprocessed to notify the d.store platform about the creation, update, anddeletion of Wiki pages. The client also scanned the content of the pages forfile attachments and hyperlinks to other Web resources in order to createaccording relationships in the TCN. The user accounts logged by the Wikisystem allow to link an activity to the responsible person node. This way,the TCN instances preserve information on who has created, edited, anddeleted a page.

A first quantification of the Wiki pages that have been created in thedifferent projects reveals an active and continuous usage of the Wiki sys-tem throughout all teams. The Wiki system has been employed from dayone on to collect and provide basic information about the projects. It also


frequently served as a repository for team-internal notes, meeting min-utes, and documentation. Figure 8.9 visualizes the monotone growth ofthe individual project Wiki spaces. This data is retrieved from the TeamCollaboration Networks by requesting the collection of ‘wiki:WikiPage’ -typed nodes over the course of a project, represented by the following URLpattern:

GET / graphs/<tcn−id>/<date>/r e s o u r c e s / wik i . WikiPage

A total number of 191 file attachments has been counted in the elevenWiki spaces. However, the numbers deviate strongly between the differentprojects. While two teams have not used the attachment functionality atall (0 attachments), the TCN of a third team lists 138 attachments for itsWiki pages. A potential reason for this variance is that some teams werenot familiar with this functionality or preferred different ways of organizingpage-related documents.

8.2.3 Activities Captured From WebDAV Folders

Serving as a third data source, a WebDAV sensor client reported file han-dling activities in the shared project folders. The client processed the serverlog files for read, create, update, and delete events that have been effectedby process participants uploading and downloading files to and from theWebDAV storage. The WebDAV account names assigned to every courseparticipant allowed the d.store system to relate the file handling activitiesto the responsible person node. Only certain file types were considered bythe sensor client. A whitelist included common file extensions for multi-media formats such as, e.g., images, videos, audio files, animations, CADdrawings, text, and spreadsheets. Other file types such as system files,logs, and program source code have been intentionally excluded from thedata acquisition in order to reduce the total number of uploaded files to acomparable set of relatively self-contained sources of human-interpretableinformation.

At the end of the project phases, the eleven Team Collaboration Net-works contained a total number of 9,039 nodes that represented shared filesin the public team folders. Figure 8.10 shows the number of resources iden-tified in the WebDAV repositories over the course of the eleven projects.As with the previous domain concepts, the amount of resources provided inWebDAV folders at a given point in time is queried from a TCN instancevia the following URL pattern:

GET / graphs/<tcn−id>/<date>/r e s o u r c e s / f i l e . F i l e


0

200

400

600

800

1000

1200

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Files in WebDAV Folders per Team


Project Week

Figure 8.10. Total amount of files shared in the WebDAV team folders.

While all teams utilized the project file storage to a certain extent, theamount of uploaded resources in a team differs strongly. The disparity be-tween the lowest and highest number of file nodes per TCN instance (77vs. 3,611) indicates that WebDAV-related usage patterns were extremelyincoherent across the teams and may not be meaningful on a mere quanti-tative level. One potential reason for this heterogeneity is grounded in thegeneral applicability and utilization of online document storages in manydifferent project situations (short-term file storage, file transfer, backup andarchiving, revision management, etc.). A semantic analysis of the shareddocuments could support the structural TCN properties with additionalinformation about the intent and the meaning of the files in the process,allowing for a more precise interpretation of the activities. However, thisis often expensive and difficult to accomplish. For this reason, this workabstains from drawing conclusions from the captured WebDAV activities.

8.2.4 Summary

This first quantitative appraisal of selected network dimensions gives ageneral idea of the captured data and the volume of the generated TeamCollaboration Networks. It presents a starting point for a more detailedanalysis of the eleven TCN instances. Besides the set of selected networkattributes presented in this section, a comprehensive collection of collabo-ration metrics has been quantified on a per-team level, as well as on individ-ual team member level. The results of these detailed network measurementscan be found in Appendix A.

The diversity of network properties queried from d.store demonstratesthe platform’s ability to support investigations into complex team collabo-


ration structures. It also reflects the researcher’s curiosity to uncover newdata, exploring hidden dependencies, trends, similarities, or correlations inthe collaboration behavior of engineering project teams. d.store facilitatesquestion-asking and provides access to non-predefined, objectively mea-sured collaboration metrics on demand. With its help, the characteristicsof virtual collaboration structures can be compared and contrasted withother empirical data over time on a fine-grained level.

In the remaining sections, I will give examples for a purposive evaluationof the presented Team Collaboration Network instances. I will first showhow the temporal dynamics of virtual collaboration practices in a TCNcan be visualized and leveraged to uncover insightful structural conditionsin a design process. Secondly, I will identify correlations between patternsin the captured collaboration activities and empirically measured designteam performance variables.

8.3 Temporal Variations & Dynamics in TeamCollaboration

Central in the design of Team Collaboration Networks and the d.storesystem is the ability to capture and monitor the dynamics of virtual col-laboration processes. How do specific aspects in the virtual collaborationbehavior of a team evolve over the course of a project? This section will pro-vide examples that show how the temporal dimension captured in a TCNcan be leveraged by client applications to visualize and observe significantcharacteristics in a collaboration process over time.

8.3.1 Individual Participation on Project Email Lists

The email lists of the eleven ME310 teams have not only been used forteam-internal message exchange, but have also been utilized by externalstakeholders to introduce project-related information to a selected group ofstudents. At the same time, team members commonly put their project liston the list of email recipients when communicating with external processparticipants, which further increased the amount of conversations capturedfrom the archives.

The resulting communication patterns give detailed insights into howgroups and individuals participate in the email-based information sharingprocess within and outside team boundaries. In this example, an analysisclient has been developed to measure email-related TCN properties ona daily basis. For each person participating in the email communicationof a project it determines the total number of emails sent and received,the number of replies (emails sent in response to another), the number

8.3. Temporal Variations & Dynamics in Team Collaboration 139

Figure 8.11. Snapshot of an interactive visualization of the individual participation in email-based project communication. A time slider allows to track the evolution of emailing parametersalong multiple dimensions. Each sphere represents a process participant; colors denote partici-pant roles.

of shared hyperlinks, and other emailing-related variables. The generatedtime series is visualized in an interactive bubble chart, representing everyproject stakeholder as a sphere positioned along two adjustable dimensions(Fig. 8.11).

Based on the role types assigned to every person node (cf. ‘me310’ on-tology, pp. 129), the spheres are color-coded to easily distinguish betweenstudents, members of the teaching team, or external contributors such ascorporate liaisons. A time slider at the bottom of the chart allows to traceback and to track the evolution of each participant’s emailing statisticsover the course of the project. The graph in Fig. 8.11 demonstrates thesituation for project Theta at the end of the course period. The numberof received emails is compared to the number of email replies each indi-vidual has sent back to the project lists. Obviously, local and remote teammembers hold the lead in the number of received emails (x -axis), but showdifferent behavior in message replying (y-axis). In this case, the local sub-team outperforms the remote peer students, at least for the set of emailscaptured on the distribution lists.

Noteworthy is the outstanding responsive behavior of one of the corpo-rate contacts highlighted in the upper right section of the chart (‘Br 512’).The relatively high number of emails received (29) and sent to the list (27total / 23 replies) towards the end of the project indicates a close and steadyinvolvement of this person in the design process. Findings presented laterin this chapter suggest that such active involvement of external domain


experts can have beneficial impact on the overall performance of a designteam. This renders the ability to identify the existence or absence of ac-cording collaboration structures desirable and supportive in the evaluationof such processes.

This example has demonstrated how hidden aspects in a collaborationprocess can be uncovered, processed, and visualized in an interactive andeasy to consume manner. Using d.store services, the analysis client ex-tracted and aggregated complex properties of a TCN to provide instantaccess to meaningful collaboration metrics. Enriched with historical data,the client allows to look back in time in order to better assess the cur-rent situation and to identify desired or undesired trends in long-runningprocesses.

8.3.2 Evolution of Project Wiki Spaces

A second example for the temporal inspection of knowledge sharing be-havior addresses the Wiki spaces of the eleven observed projects. With asensor client processing the file structures of the Wiki system, the gener-ated Team Collaboration Networks hold information about the point intime Wiki pages have been created, edited, and hyperlinked to other re-sources of a project. This data allows insights into the structuring andcoherence of information stored in the Wiki system.

Graphical animations of the evolving project Wiki spaces have been cre-ated with this data gathered from the d.store services. The animations visu-alize the chronological appearance of Wiki pages and hyperlinked resourcesas nodes and edges in a network representation, giving a fast-forward im-pression of the creation and organization of the Wiki spaces. Three exam-ples are shown in Fig. 8.12, illustrating the final network topologies for theWiki spaces of projects Theta, Alpha, and Gamma.

This form of visualization reveals different patterns of how design teamsutilize and organize their Wiki spaces over the course of a project. The net-works of the three teams exhibit distinct structures in the way resourcesare created and related with each other. Theta and Alpha feature a rela-tively large number of Wiki pages; isolated, i.e., disconnected topic pagesare scarce or do not exist. Nodes with a large number of outgoing hyper-links obviously represent indices to a collection of other resources, formingclusters of related nodes and serving as hubs to other Wiki pages or exter-nal information resources. In contrast, the Wiki topology of team Gammais relatively sparse. The total number of pages is considerably small, theconnectedness of the resources is less pronounced. Central hubs to simplifyaccess to related information are largely missing. Several Wiki pages aredisconnected from the rest of the resources, making it difficult for the teamto find or recover information. Comparing the animated evolution of the

8.3. Temporal Variations & Dynamics in Team Collaboration 141

three Wiki spaces shows a relatively balanced and continuous creation andre-organization of the pages for teams Theta and Alpha, while changes tothe Wiki topology of team Gamma occur in bursts.

Significant correlations with the performance of the teams could not berevealed in the analysis of the Wiki spaces. However, selected criteria ofa team diagnostic survey conducted after the projects do indicate a rela-tionship between team effectiveness and the observed Wiki structures. Theapplied survey instrument (based on Wageman et al. (2005), see also nextsection) determined the degree to which the team used the full comple-ment of member knowledge and skill. The self-reflecting assessment of thefollowing two statements contributed to the overall measure of the processquality: 1) “Members of our team actively share their special knowledge andexpertise with one another”, and 2) “Our team is quite skilled at capturingthe lessons that can be learned from our work experiences”. The averageresults for this part of the survey correlate with the visual impression thatthe breadth of information shared in a Wiki system and increased connect-edness of the resources may contribute to the quality of a knowledge sharingprocess (the results on a 5-point scale: Theta 4.857; Alpha 4.625; Gamma3.917). Clearly, the numbers do not allow for generalization, nor are theystatistically significant. However, they can serve as an early indication thata well-organized and steadily used system can facilitate information shar-ing and increase the overall satisfaction in a collaborative learning process.The visualization of clusters and connections further supports the assump-tion that Wiki structures can reveal meaningful insights into knowledgesharing behavior in a design team and suggests a continued observation ofWiki activities.

a) Theta b) Alpha c) Gamma

Topologies of Project Wiki Spaces

Wiki Page Web Resource Wiki A1achment WebDAV Resource

Figure 8.12. Wiki spaces of projects Theta, Alpha, Gamma. Clustering and general connect-edness of wiki pages can be an indicator for the quality of knowledge- and skill-related processcriteria.


8.4 Performance Correlations

Central in the evaluation of virtual design collaboration is the questionwhether objectively measurable collaboration metrics support conclusionsabout the performance of a team or its process. Do the characteristics of thecaptured group activities provide indicators for the quality of the projectoutcome? Finding appropriate correlations in the structure of the elevenTeam Collaboration Networks would further prove the value of the pre-sented monitoring approach and provide first evidence for computationallymeasurable team performance indicators. This section presents the resultsof statistical analyses, which have been performed to identify such corre-lations between the online communication behavior of the observed designteams and independently surveyed team performance variables.

8.4.1 How Team Performance was Measured

Objective measurements of team performance are particularly difficult toachieve in a design context, because the “definition and measurement ofdesign performance is elusive, analogous to the adage, ‘beauty is in theeye of the beholder’; solutions that might seem trivial to one person couldappear profound to another.” Skogstad (2009). Performance can also re-late not only to the outcome of the design process, but also to the processitself. Team members can have drastically different estimations of the per-formance than their managers.

Currently there is no agreement on a general construct or variable thatdefines and measures the success of design projects (Skogstad et al., 2009).However, measuring design performance is a key and ongoing issue for de-sign researchers, whose approach is based on empirical research comparingdifferent projects. While traditional metrics such as costs (budget, time,resources, etc.), viability, or customer satisfaction can be applied to assessthe performance of a single team or to compare projects of identical nature,the comparison between substantially different design tasks lacks a commondenominating measure. To overcome this design researchers’ dilemma, thisstudy considers multiple indicators of performance that were tracked fromthe perspectives of different stakeholders. Skogstad (2009) has collecteddifferent performance measures in the observed ME310 teams, which areused in this work as dependent variables in the testing of correlations withpatterns in the Team Collaboration Networks. The author describes thedifferent performance indicators and what they measure as follows:

Self-reported Design Process Performance: A survey was conductedwith the students after the completion of the projects to provide ameasurement of the design process quality from the designers point ofview. Building on an established team diagnostic instrument (Wageman

8.4. Performance Correlations 143

et al., 2005), the questions “provide a measure of three performance-relevant aspects of teamwork, which are controlled by the team andits members. The aspects are a) the quality of team task processes –a measure of team effectiveness, b) the satisfaction with within-teamrelationships – a measure of the willingness to work together again inthe future, and c) the individual affective reactions to the team and itswork – a measure of the individuals learning and well-being” (Skogstad,2009). The survey accounts for the fact that “design performance mustinclude more than just the project result, because no organization willsurvive if the designers are consistently unsatisfied” (ibid.). An averageof the students’ scores was calculated for each team to get a measurefor the overall team satisfaction.

External Judges Assessing Output Performance: An evaluation ses-sion was conducted with domain experts who “reviewed two-pageproject summaries created by the designers and assessed the designsfrom the perspectives of a) an investor, b) a user, and c) a gadget lover.[...] The judges were selected based on familiarity with the structure andgoals of the course to ensure that they could evaluate the designs basedon the organizational circumstances under which they were created”.It was further ensured that “the judges did not have prior knowledgeof the details of the projects or the design teams so that they were notbiased by the evolution of the design” (ibid.).

Number of Prototyping Activities by the Team: All design teamsare required by the ME310 curriculum to document their design processand findings in three cumulative reports. “The documents show the evo-lution of the design from the initial problem brief to the final functionalprototype. They include descriptions of the ideas considered, prototypesbuilt and tested, and the decisions made by the design team” (ibid.).These documents were analyzed and coded quantitatively by multiplereviewers, who independently reviewed the design development sectionsof the eleven final project reports to call out instances of prototypingactivity by the team. It can be expected that the reports are compara-ble because “all documents are written based on the same instructionsand template and the designers receive intermediate feedback from thesame graders” (ibid.). The counting of prototyping activities accountsfor the generally accepted hypothesis that teams who explore and testmore design alternatives are more likely to yield better results.

8.4.2 Finding Dependencies in the Captured Group Activities

Using the described performance ratings for the eleven teams, the studynow begins to exhibit correlations in the captured collaboration activitiesby means of linear regression (for linear regression analysis see, e.g., Back-


haus et al. (2008), pp. 51). Statistical dependency is tested for the elevencases between one of the performance measures (as the dependent variable)and the occurrences of specific patterns in the set of Team CollaborationNetworks (as an independent variable). The analysis considers network pat-terns, which can be interpreted as potential indicators for applied designthinking principles or ‘designerly ways of interacting’ in a virtual collabo-ration environment. These principles comprise a) the constant involvementof end-users and customers, b) interdisciplinary teamwork and knowledgesharing, and c) a culture of prototyping (cf. Sect. 2.1.3). Directed by thesecore values, the study diagnoses patterns in the networks that may reflectaccording behavior in virtual design collaboration. These are in respectiveorder: email conversations between the team and external process partici-pants (Sect. 8.4.3), the number of URLs shared via team lists (Sect. 8.4.4),and email conversations between the team and a coach (Sect. 8.4.5).

8.4.3 Correlations with External Communication Activities

There is general consensus that a user-centric and ‘outside-in’-driven designapproach can be conducive to the creation of new and innovative concepts.Teams are good advised to become adept in project-relevant fields of ex-pertise by internalizing external knowledge, i.e, by talking to customers,end-users, and domain experts. Therefore, the degree to which a team in-volves and interacts with team-external stakeholders presents an interest-ing aspect in the observation of design processes. The Team CollaborationNetworks created in this pilot application allow to monitor this type ofinteractions in email-based communication activities.

Which patterns in the network structures allow to suspect that a teamtends towards a close involvement of external contacts as insightful sourcesof information? A good starting point is the number of external emailsthat were captured in the email archives of the eleven teams. Externalemails are those messages that have been sent by one of the team membersto at least one recipient, who is not part of the local or global sub-team(i.e. team-external). The collection of external emails can be requestedfrom a TCN instance passing the following SPARQL clause as the queryparameter to the d.store server (Listing 8.1, cf. Sect. 6.4.2). Note that the?resource variable has been predefined by the d.store platform to matchthose resources that are of type ‘dstore:Resource’.

1 ? r e sou r c e emai l : sender ?x .2 ?x rd f : type me310 : Team .3 ? r e sou r c e emai l : r e c i p i e n t ?y .4 ?y rd f : type me310 : Non−Team

Listing 8.1. Querying emails that have been sent from team members to at least one team-external person.


To put the number of external email messages that left team boundariesin relation to the overall email traffic produced by a team, it is comparedto the total amount of internal messages. Internal messages are those thatare sent by one team member to other team members only, i.e., those thatdo not address any person outside the team boundaries. The followingSPARQL clause defines an according filter to retrieve all internal emailsfrom the set of network nodes (Listing 8.2).

1 ? r e sou r c e emai l : sender ?x .2 ?x rd f : type me310 : Team .3 OPTIONAL {4 ? r e sou r c e emai l : r e c i p i e n t ?y .5 ?y rd f : type me310 : Non−Team } .6 FILTER ( ! bound (? y ) )

Listing 8.2. Querying emails that have been sent from team members to other team membersonly.

The ratio of a team’s external emails to it’s internal emails defines ourfirst independent variable in testing the correlation with the average sat-isfaction of the team members. The results of a linear regression analysisshow that a positive dependency exists between these two values. The ra-tio of external to internal emails correlates positively (Beta = 0.534) andsignificantly (R2 = 0.285, p = 0.09) with the average team membersatisfaction. This suggests that the accentuation of interactions with peo-ple outside the team boundaries (in contrast to team-internal discourse)is likely to produce greater satisfaction with the final project outcome.The correlation plot is visualized in Figure 8.13. Details of the this linearregression analysis can be found in Appendix B.

The quality of the prediction can be further increased when additionalindependent variables in the communication behavior are incorporated intothe model. In a second analysis, the number of emails a project team has re-ceived from the teaching team is factored into the regression. With this sec-ond dimension added to the model, the coefficient of determination growsnoticeably (R2 = 0.479, p = 0.07). The negative standardized coeffi-cient for the new variable (Beta = −0.481) indicates that ME310 teamswho receive more emails from the teaching team are statistically less sat-isfied with their project. A reasonable interpretation of this phenomenonis grounded on the remediating intervention of the teaching team in caseof defects or conflicts in the collaboration process. The accuracy of theperformance values predicted by this model is illustrated in Fig. 8.14.

8.4.4 Correlations with the Number of Shared Resources

The segmented and concurrent nature of engineering design tasks requirethat knowledge generated in one part of the team gets documented and


R² = 0,285

2,5

3

3,5

4

4,5

5

0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9

Average Team M

embe

r Sa-sfac-on

Ra-o External to Internal Email Messages

Outbound Email Messaging (Propor-onal) vs. Team Sa-sfac-on

Figure 8.13. The proportional amount of outbound emails (compared to team-internal mes-sages) sent by a team correlates positively (Beta = 0.534) and significantly (R2 = 0.285,p = 0.09) with the average team member satisfaction.

shared with the rest of the group. Distributed teams need to form consensusand a common understanding during the collaborative creation of newconcepts. This even more applies to interdisciplinary team collaborationand a user-centered, ‘outside-in’ design thinking approach, which is onlypossible if an active dissemination of insights, opinions, and different ideasis taking place in the team.

The available Team Collaboration Networks reflect certain aspects ofhow a group interacts, shares information, or calls attention to relevantresources using email, Wikis, or shared folders. In the following analysis, thestudy explores how email distribution lists are used by the teams to identifyand distribute relevant resources of information in the Web. Hyperlinks(i.e., URLs) included in the body of an email message serve as indicatorsfor the author’ intent to brief the rest of the design team on a pertinentpiece of information contained in the referenced document (cf. examplesin Sect. 7.1.1 and 8.2.1). The amount of references a team has sent to thelist provides a rough measure for the breadth of investigation, fact finding,idea generation, or solutions being documented and shared with others.

To test the effects of resource sharing in a team, the number of nodes ina TCN that have a ‘web:linkedFrom’ relationship (cf. Sect. 7.1.1) to at leastone email sent by a team member is determined as an independent variable.The following query statement was executed to request these resources fromthe d.store networks (Listing 8.3).


2,5

3

3,5

4

4,5

5

Kappa Beta Lambda Gamma Delta Alpha Epsilon Iota Pi Omega Theta

Average Team M

embe

r Sa-sfac-on

Project Teams (Sorted by Predicted Value)

Actual vs. Predicted Team Sa-sfac-on

Actual

Predicted

Figure 8.14. The average team member satisfaction correlates positively and significantly withvariables in the online interaction behavior of the teams. A positive tendency towards email-based interaction with team-external process participants in comparison to internal discoursecan partially predict performance (R2 = 0.479, p = 0.07).

1 ? r e sou r c e web : linkedFrom ? emai l .2 ? emai l emai l : sender ?x .3 ?x rd f : type me310 : Team

Listing 8.3. Querying Web resources referenced in at least one email that has been sent by ateam member.

It turns out that the number of referenced resources in a team canbe linearly regressed on the output performance measured by the judges(Skogstad, 2009). The number of distinct URLs shared on the distributionlists correlates positively (Beta = 0.514) and significantly (R2 = 0.265,p = 0.1) in the available data set (Fig. 8.15). This dependency supportsthe assumption that a larger breadth of information considered in a teamhas beneficial impact on the design output quality.

8.4.5 Correlations with Coach Engagement

The coaches that have been assigned to each team are not involved inthe grading and review process, hence, providing a trusted and unbiasedsource of advice and domain knowledge to the designers. Their primarytask is to support and to help the teams find a solution to the given designproblem. Their feedback can bring new impetus and offer new perspectivesand alternatives to the design process.


R² = 0.265

2,2

2,3

2,4

2,5

2,6

2,7

2,8

2,9

3

3,1

3,2

0 50 100 150 200 250 300 350 400

Design Outpu

t Perform

ance m

easured by Externa

l Jud

ges

Total Number of Unique URLs shared within Design Team via Email

Unique URLs Shared Within Design Team vs. Output Performance

Figure 8.15. The total number of distinct URLs shared within design teams correlates positively(Beta = 0.514) and significantly (R2 = 0.265, p = 0.1) with output performance, suggesting thatbreadth of shared information impacts performance (Skogstad, 2009).

Therefore, the involvement of coaches in the virtual interactions of theME310 teams presents an interesting subject for investigation. In the fol-lowing study, the number of emails a team has received from its coachesis considered as an indicator for the level of support the designers receivedalong their path. Coach emails were retrieved from a Team CollaborationNetwork through the following query (Listing 8.4).

1 ? r e sou r c e emai l : sender ?x .2 ?x rd f : type me310 : Coach

Listing 8.4. Query clause to determine the emails that a team has received from its coaches.

Given the amount of coach emails as an independent variable in thenetwork instances, it has been tested whether this number correlates withthe number of prototyping activities identified in the final project reports.Prototyping is a sign of testing design alternatives and the explorationof a solution space. Each prototype brings new insights and lowers theprobability for costly failures identified too late in the engineering process.Prototyping indicates design progress and a continued exploration of thesolution space, and should therefore be maximized.

Linear regression analysis shows that the level of coach engagementcaptured on the email lists is significant for the creation of prototypes (Fig.8.16). The number of coach emails correlates positively (Beta = 0.816) andsignificantly (R2 = 0.666, p = 0.01) with the total number of prototyping

8.5. Summary of Findings & Critical Discussion 149

activities undertaken by design teams, suggesting that interactions withthe coaches stimulate the development of new prototypes.

R² = 0.666

20

25

30

35

40

45

50

55

60

65

70

0 5 10 15 20 25 30 35 40 45 50

Num

ber of Prototyping Ac3vi3es

Number of Emails from Team Coaches

Emails from Coaches vs. Prototyping Ac3vi3es

Figure 8.16. The number of coach emails correlates positively (Beta = 0.816) and significantly(R2 = 0.666, p = 0.01) with the total number of prototyping activities undertaken by designteams, suggesting that coaches have a positive impact on prototyping (Skogstad, 2009).

8.5 Summary of Findings & Critical Discussion

This chapter presented a pilot application of the d.store platform, in whichthe virtual collaboration activities of eleven distributed teams in a project-based engineering design curriculum were captured. The Team Collabora-tion Networks generated in this study have been evaluated from differentperspectives to demonstrate how the system can be exploited to unveilhidden traits in the monitored collaboration processes.

The chapter started with an introduction of the ME310 testbed and themonitored groupware infrastructure. A quantitative appraisal of the col-lected data looked at the general usage patterns of the three observed com-munication channels (email lists, Wiki, WebDAV folders) from a high-levelperspective. Exploring the temporal variations and dynamics in the onlineactivities has given further examples for the visualization of trends and theevolution of the collaboration structures over the course of a project. Fi-nally, a statistical analysis was conducted to identify correlations betweenthe Team Collaboration Networks and performance measures collected in


the eleven groups. The different insights and findings that could be gainedfrom this application are summarized below.

1. Ease of Implementation. Though being subjective, the effort re-quired to setup the d.store platform in the ME310 testbed and to answera diverse set of questions in the analysis of the generated networks canbe considered relatively low. The development of the client applicationswas straightforward and accelerated by the resource-oriented nature ofthe platform and standard Web technologies such as HTTP and JSON.The d.store services decouple the clients from data management tasksand allow to select the programming languages and environments thatsuit best to the prevailing data collection or analysis task. The experi-ences collected in this pilot application support the desirability of thepresented monitoring approach and suggest the d.store platform as apromising tool in the observation of virtual collaboration practices.

2. Significance of Email Lists. The amount of email messages capturedin the TCNs documents the popularity and usefulness of distributionlists in separated groups. Despite of the large number of alternativecommunication channels and the designers’ awareness that archivesare being monitored for scientific evaluation, a total number of 10,486emails could be captured from the project lists. According to estimatesfrom the team members, this corresponds to approx. 66.64% of the over-all amount of email messages that were sent in the projects. Obviously,email distribution lists provide an applicable medium to facilitate in-formation sharing and the computational monitoring of collaborationprocesses.

3. Shared Resource Context is Lost in Email Archives. The signi-ficant impact of email lists on a groups’ information sharing behav-ior becomes apparent in the interconnectedness of email nodes in theTCNs. Due to the broadcasting of attachments and hyperlinks, theamount of captured email messages that show direct relationships toother information resources was in a ratio of approx. 1 to 0.6. With morethan every second email providing supportive context for a shared doc-ument, Web page, etc., it is reasonable to assume that the email listswere among the most critical tools for the ad-hoc dissemination of con-text and project-relevant resources. However, their utilization raisesconcerns about the designer’s ability to recall that context informationlater on. Information often gets lost in personal mailboxes or archiveswhen hyperlinked resources are accessed in isolation of the message.Without back-references to referring resources or persons, the compre-hension and understanding of shared material and its history can behindered at a later stage due to missing context information. This re-veals the potential and benefit that d.store services can bring to next-


generation groupware systems. These can be used to retrieve contextualinformation, in particular referencing resources, related persons, andtemporal attributes, thus helping to preserve context and to achievecommon ground.

4. Information Spaces Quickly Grow in Size and Complexity. Thequantification of Wiki pages and WebDAV files (Figs. 8.9 and 8.10)bared a gradual increase of the number of digital information resourcesthat are propagated in a project. Obviously, resources are only rarelydeleted or removed from a public location once they have been shared.It can be concluded that online information spaces tend to continuouslygrow in size and become increasingly complex as a project progresses.Appropriate tools are needed to support in the organization and uti-lization of the available information load. The d.store platform can besupportive in this task by capturing, processing, and providing seman-tic annotation to the shared resources, thus helping to keep track ofteam activities and progress.

5. Wiki Structures may Indicate Effective Team Learning. A visu-alization of the emerging structures in the Wiki spaces highlighted dif-ferences in the way teams organize and utilize their Wiki over the courseof the projects. Although no statistically relevant conclusions about thequality of the collaboration process could yet be derived from thesestructures, measures of a team diagnostic survey conducted afterwardssupport the visual impression that an interlinked and constantly up-dated Wiki space has beneficial impact on the team member’s satis-faction with knowledge and skill-related criteria of their work. Thissuggests the the Wiki structures formed by the teams may indicatewhether members effectively share their special knowledge and exper-tise with one another and motivates continuing research in this area.

6. Indicators for Problems in Groupware Use. The total number ofWiki page attachments counted in the eleven TCN instances differedstrongly between the teams. While some teams made use of this func-tionality extensively (138 attachments), others have not used it at all(0). It is unclear whether the partial omission is due to page attachmentsnot being considered useful in some projects, or because students weresimply not familiar with this feature. In either case, the strong varianceindicates that a widespread utilization of certain groupware services ishindered or undesirable. Hence, in order to eliminate the risk of draw-ing incorrect conclusions, process participants should be appropriatelytrained in using the monitored collaboration infrastructure.

7. Low Interpretability of Multi-Purpose Groupware Activities.The WebDAV folders have proven to be a helpful medium to share,archive, and access various kinds of electronic documents. But the gen-eral applicability and utilization of online storages presents a draw-


back in the interpretation of the captured folder activities. Not everyWebDAV operation is necessarily a sign of interaction with other pro-cess participants or part of a collaborative process. A differentiationbetween activities that conduce to information sharing and those thatresult from rather personal and isolated file handling tasks (e.g., tem-porary storage or file transfer) is necessary, but was not practicablein this study. Future investigations should take this potential lack ofresolution into account when monitoring the collaborative use of suchversatile applications in a design context.

8. Online Collaboration Metrics Indicate Team Performance. Astatistical analysis of the generated Team Collaboration Networks re-vealed dependencies between the captured online activities and empiri-cally surveyed team performance measures. Correlations in the networkstructures were found with respect to the average satisfaction of the de-signers, the output performance assessed by external judges, and thenumber of performed prototyping activities. The results of the regres-sion tests are summarized in Table 8.3.

The pilot application has demonstrated the feasibility and desirabilityof utilizing the d.store services in a distributed project environment. Thepresented evaluations have exemplified how concurrent design processescan be compared to produce quantifiable results on the usage of the group-ware infrastructure and the information sharing behavior. Of course, thefindings do not allow for generalization, because external validity of thedata is not given. Especially the lack of a common and universal measurefor team performance hinders a generalization of the correlations identifiedabove. Also, the application was performed in the context of an engineeringcurriculum, which further questions the validity of the results outside ofeducation, i.e., in an industrial setting.

Nevertheless, the ME310 projects closely resemble industry processesand are working on challenges given by real industry partners. In this set-ting, the d.store platform has provided objective and comparable measuresfor how teams interacted through virtual collaboration channels in a non-artificial engineering design setup. The results are encouraging in that theyhighlight interpretable characteristics in the collaboration behavior of thedistributed teams. More applications of this kind are needed to test thevalidity of the findings and to better understand the meaning behind ob-jective, virtual collaboration patterns.


Table 8.3. Summary of findings from testing relationships quantitatively at the design teamlevel.

DependentVariable

IndependentVariable

Finding Interpretation

Avg. Team-Member Satis-faction

Ratio of ext.to int. emails

The proportional amount ofexternal emails sent by ateam correlates positivelyand significantly with theaverage team member sat-isfaction (Beta = 0.53,Sig. = 91%, R2 = 0.29).

Teams who frequently en-gage with external contacts(outside-in) are more satis-fied with their projects.

Avg. Team-Member Satis-faction

1) Ratio of ext.to int. emails2) emails fromteaching team

The proportional amountof external emails combinedwith the number of teachingteam emails correlates evenmore significantly with theaverage team member satis-faction (Sig. = 93%, R2 =0, 48).

Teams who frequently en-gage with external contacts(outside-in) and minimizeintervention from the teach-ing team are more satisfiedwith their projects.

OutputPerformance

Resources refer-enced on emaillists

The total number of URLsshared by team memberscorrelates positively withthe output performance(Beta = 0.51, Sig. = 90%,R2 = 0.27).

Teams whose membersactively share informationwith each other generatebetter output.

PrototypingActivities

Emails fromcoaches

The number of emails ateam has received fromcoaches correlates positivelywith the counted prototyp-ing activities (Beta = 0.82,Sig. = 99%, R2 = 0.67).

Frequent engagement withdomain experts encouragesteams to explore more de-sign alternatives.

9

Conclusion

The monitoring of collaboration activities, resources, and participants invirtual team environments such as distributed engineering design presentsboth a challenge and opportunity in research and industry. This work sug-gests and presents a common foundation for computer-supported designobservations that facilitates the collection, processing, and analysis of vir-tual team collaboration. Allowing for more efficient data collection andanalysis tools, the work positions itself as a gateway to a deeper under-standing of collaboration practice in ICT-enabled design teams.

In particular, the work has presented new methods: Team CollaborationNetworks allow to describe collaborative activities in form of relationshipsbetween members and resources over time. Secondly, the work has devel-oped new monitoring applications: the d.store platform establishes an ex-tensible, resource-based client-server system to capture and explore onlinecollaboration activities at project-time and on a fine-grained level. Finally,the work has documented and shared experiences gained from monitoringindustry-like design processes: an analysis of the early-stage collaborationactivities captured in the Team Collaboration Networks of eleven engi-neering design teams highlighted differences and similarities in groupwareuse and identified certain collaboration patterns to be potential perfor-mance indicators. In this concluding chapter, the contribution of this workis summarized and discussed. The thesis closes with a consideration of legalaspects and recommendations for monitoring and conducting distributedengineering design processes in organizations.

9.1 Contribution

The contribution of this dissertation is twofold. In the first place, the re-search presents an adaptive, service-based solution for monitoring multi-channeled online collaboration activities of project teams in near-realtime.The system is based on Team Collaboration Networks, a data model to de-scribe semantic relationships between participants and resources over thecourse of a collaboration process. Second, the dissertation generates newinsights into the work of virtual teams by analyzing Team Collaboration

9.1. Contribution 155

Networks that were generated during the collaborative efforts of elevendistributed engineering design projects. Hence, the results of this researchwork can be categorized into stimulating input to both, design practice anddesign theory.

9.1.1 Contribution to Design Practice: A System for VirtualTeam Monitoring

The work presents a solution to a problem rooted in the discrepancy be-tween the informality of early-stage engineering processes and the formal-ity requirements in their computational analysis. The tools and techniquesintroduced in this work support design researchers and practitioners instudying the ever-widening variety of technology use in distributed projectteams. With Team Collaboration Networks introduced in Chapter 4, theinteractions, resources, and activities during project-based collaborationare represented in a formalized, unambiguous, and chronological manner.It has been further shown how a system of Team Collaboration Networksis formulated to concurrently organize the temporal and semantic proper-ties of actors and information resources in multiple design projects at atime (Chapter 5). A prototypical tool implementation of this concept, thed.store platform, decouples the data collection process from the analysisand allows for automated and non-interfering team observations (Chapter6).

Several properties distinguish the d.store architecture from previouswork. The system is extensible with regard to groupware and communi-cation channels being monitored and the analysis procedures being per-formed on the collected records. The platform supports both, the ex-postanalysis of historical facts and trends in the collaboration, as well as a liveobservation of ongoing collaboration activities as they are captured by thesystem. The resource-oriented service interface simplifies the distributedand automated recording of multi-channeled activities and expedites theunobtrusive integration of collaboration monitoring into existing and futureproject settings. Building on open Web standards, the system integrateswell into existing work environments and provides low-barrier access tostructured information about how teams interact and share information.As such, the system establishes a new, applicable, and customizable foun-dation for real-time team diagnostics and the systematical exploration,quantification, and comparison of virtual collaboration processes. The gen-eral idea of a resource-oriented monitoring system as well as details of itsimplementation have been published (Uflacker and Zeier, 2008a,c; Uflacker,2007).

156 Conclusion

9.1.2 Contribution to Design Theory: Findings from ConceptualDesign Team Observations

The work has demonstrated that the d.store system is customizable andadaptable to realistic environments in order to capture virtual team activi-ties in distributed collaboration (Chapter 7). Domain ontologies have beenprovided that define a set of concepts, relationships, and logical constraintsfor common groupware settings, including email, shared folders, and Wiki-based information sharing. Future research can make use of and extendthese ontologies in the continuative analysis of collaboration activities.

The data that has been collected during the d.store pilot applicationgives new insights into the collaboration practices of engineering teamsin the early stages of conceptual design. Based on this data, the workhas identified quantifiable indicators that high-performance design teamsshare significantly different interaction signatures than lower-performingteams (Chapter 8). The findings suggest that those teams generally per-form better, which put emphasis on the involvement of team-external par-ticipants (e.g., end-users, customers, coaches) and the sharing of informa-tion and knowledge. This supports two fundamental assumptions in designresearch: first, that performance-relevant process characteristics reside inthe way distributed teams communicate and share information, and sec-ond, that the application of fundamental design thinking principles in theearly stages of engineering projects has beneficial impact on the designoutcome. With this first application of a computational monitoring sys-tem and the evaluation of objective collaboration metrics with regard todesign team performance, the work initiates further investigations to vali-date the findings and provides a basis for future design research activities.The pilot application and the results of the analysis have been presentedand published in a journal article (Uflacker and Zeier, 2010b), internationalconferences (e.g., Uflacker and Zeier, 2009; Uflacker et al., 2009), and in abook chapter on design thinking research (Uflacker and Zeier, 2010a).

9.2 Discussion

Virtual collaboration monitoring promises to deliver new insights intoperformance-relevant aspects of complex design processes, eventually lead-ing to increased awareness of team activities and improved project outcome.However, the observation of long-running and especially distributed collab-oration processes in ICT-enabled team landscapes is a challenging task. Theacquisition of realistic data for research purposes is often not only hinderedby costs and the complexities of today’s collaboration environments, butalso by strict regulations that are prevalent in many industrial settings.With the developed monitoring instrument, this work has made a first

9.2. Discussion 157

step to lower the barriers for researching digitally-enabled design teams. Itpresents a generic approach and a technological foundation to concurrentlycapture and analyze multiple streams of communication and interactions inICT-mediated groups. The approach is fully transparent in the sense that itdoes not impact the normal workflow of process participants. The resource-oriented architecture aligns well with today’s and tomorrows collaborationenvironments that shift more and more into the World Wide Web. Withthe social and collaborative components of Web 2.0, and the increasinglypopular formal description of resource semantics in the so called SemanticWeb, a computer-processable description of collaboration activities in formof Team Collaboration Networks and OWL presents a logical next step.

A pilot application in engineering design has served as a first exam-ple for the integration of this approach into a realistic project setting. Ithas demonstrated the use of the d.store platform as a real-time diagno-sis instrument and how it can be leveraged to retrieve statistics, to ex-tract contextual and temporal information, and to generate charts andvisualizations. The ability to quickly answer very specific questions aboutdistributed, multi-channel collaboration activities displays the great valuethat the generated semantic layer in form of Team Collaboration Networkscan bring to existing and future design observations.

The project teams observed in this pilot application were settled in anacademic testbed curriculum. However, the structure of the teams closelyresembled real-world projects and can be considered as very similar to thosefound in the industry. Even though the teams were working on differentprojects, they are comparable in terms of size, distribution, budget, andtimelines: a situation that is rarely found in professional settings. Still, inorder to collect data and to validate findings externally, the implementationof the d.store platform in real industrial settings is suggested and necessary.

With the real-time monitoring capabilities of the d.store platform andthe results from its pilot application, the instrument establishes new possi-bilities to support design teams and managers, completing the symbiosis ofdesign practice and design research outlined in Fig. 1.1. With a more pre-cise understanding of performance-relevant indicators, a better awarenessof the current design situation can be achieved. This creates new startingpoints for the development of improved management tools and dashboardsin conceptual design practice.

Recent studies already build on the results of this dissertation. Skogstad(2009) has developed new theory about how designers gain insights neededto create novel solutions and how reviewers can have both positive andnegative effects on the design process. Parts of his hypothesis testing aregrounded on design team interactions that have been captured and ana-lyzed with the help of d.store. This shows that the developed instrumentprovides a useful basis for achieving insights into performance-relevant

158 Conclusion

properties of virtual collaboration processes. Future research may buildup on this technological foundation and contribute new findings throughadditional case studies and improved system implementations.

9.3 Legal & Moral Aspects

This work has demonstrated that monitoring a team’s online activitiescan provide valuable input for researching and controlling communicationpatterns, resources, and participants’ involvement over the course of aproject. However, the automated capture and analysis of employees’ ac-tivities touches legal and moral aspects, as public discussions and promi-nent law cases illustrate. Especially the emergence of new communicationchannels, such as social networks, Wikis, and forums, have reactivated thedebate on monitoring online communication inside an organization. To con-trol this debate, several laws have been enacted within the USA and theEU.

9.3.1 Legislations on Monitoring Employees Communication

The monitoring of employee activities and stored materials is subject ofintense legal scrutiny. Specifically, Title III of the US American OmnibusCrime Control and Safe Streets Act of 1968 and the Electronic Communi-cations Privacy Act of 1986 (ECPA) outlaw the interception, use, or disclo-sure of protected wire, oral, and electronic communications. However, thelaws generally indicate that monitoring of business communications sys-tems may be accomplished if necessary for the continuing operations of thebusiness, and if the employees and other exposed parties are made awareof the extent of the observations. The consent must be clear and more thanmere knowledge of the employers ability to monitor. This underscores theneed to not only create an effective telecommunications policy, but to alsoinsure that it is distributed and agreed to (by signature) by all employees(Whitman et al., 1999).

The “Directive 95/46/EC on the protection of individuals with regardto the processing of personal data and on the free movement of such data”(Europ. Commission, 1995) is a European Union directive implemented in1995 to regulate the processing of personal data. According to this directive,personal data should not be processed at all, except when certain conditionsare met. These conditions ensure that data processing is transparent to thedata subject and that it is limited to a specified and legitimate purpose.For example, the directive states that personal data must be “collectedfor specified, explicit and legitimate purposes and not further processedin a way incompatible with those purposes. Further processing of data for

9.4. Recommendations for Monitoring Virtual Team Collaboration 159

historical, statistical or scientific purposes shall not be considered as in-compatible provided that Member States provide appropriate safeguards”.The directive further postulates that every person shall be granted the right“not to be subject to a decision [...] which is based solely on automatedprocessing of data intended to evaluate certain personal aspects relating tohim, such as his performance at work [...]”.

9.3.2 Employee’s Privacy and Autonomy

While employers consider communication monitoring an essential asset forretaining process excellence, employees typically try to retain a convenientwork environment where their privacy and autonomy is protected. Em-ployers aim for different objectives when monitoring online communicationinside companies. Besides security-related aspects such as theft and fraudprotection, expected benefits include the overall increase of performance bydecreasing employees lost productivity, optimizing the sharing of resourcesand information, and the analysis of human resources. On the other side,employees fear restrictions on their freedom, privacy and convenient work-ing environments. Some go further in this debate by claiming that watchingemployees online communication is a violation of human rights. Govern-ments have already responded by stating that watching online communi-cation is not allowed except under certain exceptions, such as consent andbusiness extensions (Dempsey and Petschie, 2006a). Therefore, in orderto achieve support for online collaboration monitoring, employers shouldmake it clear to all employees that a monitoring policy is applied and ex-plain why and what kind of communication is being watched. The policyhas to state exactly what is and what is not allowed in terms of the useof company equipment, and also to what extent communications can bemonitored. Employees should be forewarned whenever a form of monitor-ing is taking place. Employers should also preserve some privacy options,such as providing communication tools that are not watched.

9.4 Recommendations for Monitoring Virtual TeamCollaboration

The following recommendations should be considered by organizations,which plan to implement a monitoring strategy for virtual collaborationactivities.

9.4.1 Organizations Should Implement a Monitoring Scheme inAgreement with Employees and Legal Regulations

An acceptable monitoring scheme should be achieved in agreement with theaffected personnel inside an organization. The controlling policy should be

160 Conclusion

clear and known to all employees. Furthermore, employers should gain thesupport of their employees in performing such scheme. Ensuring anonymitywhile analyzing communication activities can be useful from both a moraland legal perspective, e.g., by mapping employees or team members to IDsand perform all analysis on the ID level instead of the original identities.Nevertheless, monitoring schemes have the challenge of identifying andfiltering work-related information from personal or private information thatis exchanged between employees.

Therefore, organizations should implement an appropriate use policy,and make sure that all employees have signed a written declaration thatthey understand this policy and that they agree on it. This policy should(Dempsey and Petschie, 2006b):

• specifically address the monitoring of employee communications• require that employees are fully educated about the reasons for the

policy,• limit monitoring to work-related concerns as much as possible, and• permit employees to make reasonable personal use of the communication

systems at work.

When the observation of communication activities may affect externalprocess participants, those parties should also be notified of being poten-tially subject to monitoring (Whitman et al., 1999). Additionally, organiza-tions should gain employees support for the applied online communicationmonitoring scheme. Such a support can be achieved, e.g., by giving theemployees access to the tools and captured data or by educating employeesabout the monitoring scheme and its benefits to the organization.

9.4.2 Organizations Should Govern a Virtual CollaborationInfrastructure To Support Monitoring Objectives

The setup of a monitoring platform for virtual collaboration can be simpli-fied if the applied groupware systems are run by the observing authority.Access to server-side system and log files can potentially provide moredetailed information about groupware use and can speed up the implemen-tation of sensor components. The experiences in ME310 show that a basicgroupware infrastructure to address the most urgent communication needsof distributed teams is achievable and manageable with relatively low costsand efforts.

In the process of setting up and organizing the monitoring of groupwaresystems, organizations should take account of the following considerations:

• All users should be appropriately trained and familiarized with the func-tionality of the provided groupware.

9.5. Recommendations for Distributed Engineering Design Teams 161

• The integration of monitoring capabilities into the groupware landscapeshould not change the normal user experience with the applications orenforce additional data entry and workflows.

• External (i.e., unmonitored) collaboration tools should not be banned,as far as their usage complies with the organizational rules and condi-tions. Team productivity should always outrank observation capabili-ties.

• The use of monitored groupware should be restricted to project-relatedactivities.

9.5 Recommendations for Distributed Engineering DesignTeams

The findings drawn from the analysis of the Team Collaboration Networksin ME310 also support the following recommendations for the conductionof distributed engineering projects.

9.5.1 Teams Should Assign a Project Communication &Information Manager

The achievement of common ground and task synchronization in globalteams is challenging and requires guidance. The observations in the ME310teams underpin the need for a coordinated knowledge sharing strategy (cf.Sects. 8.4.4, 8.3.2). This is even more important as designers have to dealwith a continuously growing amount of online information, which becomesincreasingly complex as the project progresses.

Therefore, distributed design projects should appoint a team memberwho is responsible for overseeing the communication and documentationof project-related information in the team. The tasks of this manager is

• to establish information sharing as a top priority task and an explicitteam activity.

• to ensure appropriate documentation and dissemination of findings, de-cisions, and results.

• to create awareness among team members about each others activities,problems, and progress.

• to identify problems and urgent needs in the collaboration infrastructureand communicate them to the management for correction.

Established team-building methods can help to identify the right per-sonality for this critical team role (e.g., Belbin, 1996). The communication& information manager should have a good overview on the collaborationactivities, the tasks, and the information that is generated in the team. The

162 Conclusion

services of the d.store platform can be a valuable support for informationmanagement tasks by providing up-to-date views on distributed groupwareactivities, shared resources, relationships, role participation, and individualinvolvement.

9.5.2 Teams Should Engage With Domain Experts as Quickly asPossible

The positive impact of interactions with team-external process stakeholderson the performance of the ME310 teams (Sect. 8.4) is in line with the dogmathat design processes benefit from applying an “outside-in” perspective.The results indicate a higher degree of satisfaction and an increased numberof explored design alternatives for teams who emphasize interactions withcoaches and other external contacts. This suggests that designers shouldstart early to gather information and feedback from people who are expertsin a particular field of knowledge relevant to the project. This includes, e.g.,:

Key Users: Users know best what works for them and what not. Design-ers should identify and involve targeted user groups early to obtainfeedback and to iterate over prototyped ideas and concepts until a de-sirable solution is identified.

Customers: Customers specify general requirements and guidelines forthe design outcome, which need to be communicated to, requested from,and scrutinized by the design team in order to be able to respond tothe client’s request.

Practitioners: Designers should seek technical advice from experiencedpractitioners in order to maximize the number of explored design solu-tions, ensure feasibility of the approach, and to speed up the prototyp-ing process.

A close involvement of external stakeholders increases the chance thata team has access to critical knowledge and expertise right on time, whichagain lowers the likelihood of misleading decision making.

9.6 Ongoing Research & Future Work

The results and experiences drawn from the pilot application suggest acontinuance and intensification of research in virtual collaboration moni-toring. Additional applications with the d.store platform have started andare planned to capture and compare online interactions in other projectsettings. Latest platform extensions address the monitoring of additionalgroupware for software engineering teams, such as revision control systemsor ticketing systems. Recent work also started to increase the granularity

9.6. Ongoing Research & Future Work 163

of semantic annotations by applying natural language processing on thebody of captured information resources (Ulferts, 2009; Bluher, 2009). Be-ing able to extract the meaning or intent of a shared resource, email, etc.would enable a more detailed analysis of the communication between pro-cess stakeholders. The content of a resource can then be expressed in TeamCollaboration Networks by means of appropriate ontologies, supporting thecomputational analysis of information clusters and semantical coherence inan online information space.

Other activities steps involve the distribution of the platform to makeits monitoring capabilities available to a broader research community. Theprototypical implementation of d.store is to be extended in order to serveas an publicly available on-demand platform for virtual collaboration mon-itoring and data sharing. Appropriate mechanisms for anonymization, ac-cess control, etc., must be found. Additional ontologies need to be definedin order to analyze activities in different project settings such as CAD-based engineering processes. Researchers at the Hasso Plattner Instituteand Stanford University have already started in this direction. In future,independent design team observations and the exchange of data and find-ings gained in objective measurements will deepen the scientific discourseand stimulate new hypothesis development and testing in the field of virtualcollaboration in engineering design.

References

Abadi, D. J., Marcus, A., Madden, S. R., and Hollenbach, K. (2007).Scalable semantic web data management using vertical partitioning. InVLDB ’07: Proceedings of the 33rd international conference on Very largedata bases, pages 411–422. VLDB Endowment.

Ackerman, M. and Malone, T. (1990). Answer garden: A tool for growingorganizational memory. In Proceedings of the ACM SIGOIS and IEEECS TC-OA conference on Office information systems, pages 31–39. ACMNew York, NY, USA.

Ahuja, S., Ensor, J., and Horn, D. (1988). The rapport multimedia confer-encing system. In Proceedings of the ACM SIGOIS and IEEECS TC-OA1988 conference on Office information systems, pages 1–8. ACM NewYork, NY, USA.

Ahuja, S., Ensor, J., and Lucco, S. (1990). A comparison of applicationsharing mechanisms in real-time desktop conferencing systems. ACMSIGOIS Bulletin, 11(2-3):248.

Andronikos, T., Stefanidakis, M., and Papadakis, I. (2009). Adding tempo-ral dimension to ontologies via owl reification. Informatics, PanhellenicConference on, 0:19–22.

Antoniou, G. and Van Harmelen, F. (2004). Web Ontology Language:OWL. In Staab, S. and Studer, R., editors, Handbook on Ontologies,chapter 4, pages 67–92. Springer Verlag.

Appelt, W. (1999). WWW Based Collaboration with the BSCW System.In Proceedings of the 26th Conference on Current Trends in Theory andPractice of Informatics, page 78. Springer-Verlag.

Ashworth, M. J. (2007). Computational and Empirical Explorations ofWork Group Performance. PhD thesis, Carnegie Mellon University,,Pittsburgh, Pennsylvania.

Audretsch, D. (1995). Innovation, growth and survival. International Jour-nal of Industrial Organization, 13(4):441–457.

Baader, F., Calvanese, D., McGuinness, D., Nardi, D., and Patel-Schneider,P. (2003). The description logic handbook: theory, implementation, andapplications. Cambridge University Press.

166 References

Baader, F., Horrocks, I., and Sattler, U. (2004). Description Logics. InStaab, S. and Studer, R., editors, Handbook on Ontologies, chapter 1,pages 3–28. Springer Verlag.

Backhaus, K., Erichson, B., Plinke, W., and Weiber, R. (2008). Multivari-ate Analysemethoden: Eine anwendungsorientierte Einfuhrung. Springer,Berlin, 12. edition.

Baecker, R., Grudin, J., Buxton, W., and Greenberg, S. (1995). Read-ings in Human-Computer Interaction: Toward the Year 2000. MorganKaufmann.

Bannon, L. and Bødker, S. (1997). Constructing common informationspaces. In Proceedings of the fifth conference on European Conference onComputer-Supported Cooperative Work, pages 81–96. Kluwer AcademicPublishers Norwell, MA, USA.

Baya, V. (1996). Information handling behavior of designers during concep-tual design: Three experiments. PhD thesis, Stanford University, Stan-ford, CA.

Belbin, M. (1996). Team Roles at Work. Butterworth-Heinemann.Berners-Lee, T., Fielding, R., and Masinter, L. (1998). Uniform Resource

Identifiers (URI): Generic Syntax. The Internet Engineering Task Force,http://www.ietf.org/rfc/rfc2396.txt.

Bessant, J. (1979). Preparing for design studies: ways of watching. notestowards appropriate methodology for studying functional specialists. De-sign Studies, 1(2):77–83.

Beyer, H. and Holtzblatt, K. (1998). Contextual design: defining customer-centered systems. Morgan Kaufmann Publishers Inc., San Francisco, CA,USA.

Bird, C., Gourley, A., Devanbu, P., Gertz, M., and Swaminathan, A. (2006).Mining email social networks. In Proceedings of the 2006 internationalworkshop on Mining software repositories, page 143. ACM.

Bluher, A. (2009). Computergestutzte Verfahren zur Extraktion und Un-tersuchung von Nominalphrasen in der Email-Kommunikation verteilterDesignteams. Master’s thesis, Hasso Plattner Institute fur Softwaresys-temtechnik, Universitat Potsdam, Germany.

Brooks, F. (1995). The Mythical Man-Month: Essays on Software Engi-neering. Addison-Wesley Reading, MA;.

Brown, T. (2008). Design thinking. Harvard Business Review, pages 85–92.Cairncross, F. (2001). The death of distance. How the communications

revolution is changing our lives. Harvard Business Press.Carroll, J. J., Bizer, C., Hayes, P., and Stickler, P. (2005). Named graphs,

provenance and trust. In WWW ’05: Proceedings of the 14th interna-tional conference on World Wide Web, pages 613–622, New York, NY,USA. ACM.

References 167

Carroll, J. J., Dickinson, I., Dollin, C., Reynolds, D., Seaborne, A., andWilkinson, K. (2004). Jena: implementing the semantic web recommen-dations. In WWW Alt. ’04: Proceedings of the 13th international WorldWide Web conference on Alternate track papers & posters, pages 74–83,New York, NY, USA. ACM.

Casotto, A., Newton, A. R., and Sangiovanni-Vincentelli, A. (1990). DesignManagement based on Design Traces. In DAC ’90: Proceedings of the27th ACM/IEEE Design Automation Conference, pages 136–141, NewYork, NY, USA. ACM.

Chang, B. (1998). In-place editing of web pages: Sparrow community-shared documents. Computer Networks and ISDN Systems, 30(1-7):489–498.

Chen, H., Cannon, D., Gabrio, J., Leifer, L., Toye, G., and Bailey, T.(2005). Using wikis and weblogs to support reflective learning in an in-troductory engineering design course. In Human Behaviour in Design’05:Preprints of the International Workshop on Human Behaviour, page 95,Melbourne, Australia.

Cimpian, E., Meyer, H., Roman, D., Sirbu, A., Steinmetz, N., Staab, S., andToma, I. (2008). Ontologies and Matchmaking. In Kuropka, D., Troger,P., Staab, S., and Weske, M., editors, Semantic Service Provisioning,chapter 3, pages 19–54. Springer.

Clancey, W. (1997). Situated cognition: On human knowledge and computerrepresentations. Cambridge University Press.

Clark, H. (1996). Using language. Computational Linguistics, 23(4).Cockayne, W. R. (2004). A Study of the Formation of Innovation Ideas in

Informal Networks. PhD thesis, Stanford University, Stanford, CA.Cohen, S. G. and Bailey, D. E. (1997). What makes teams work: Group

effectiveness research from the shop floor to the executive suite. Journalof Management, 23(3):239–290.

Conklin, J. and Begeman, M. (1987). gIBIS: A Hypertext Tool for TeamDesign Deliberation. In Proceedings of the ACM conference on Hypertext,pages 247–251. ACM New York, NY, USA.

Conklin, J. and Begeman, M. (1989). gIBIS: A Tool for all Reasons. Journalof the American Society for Information Science, 40(3).

Connolly, D. and Masinter, L. (2000). The ’text/html’ Media Type. TheInternet Engineering Task Force, http://www.ietf.org/rfc/rfc2854.txt.

Constantine, L. and Lockwood, L. (1999). Software for use: a practi-cal guide to the models and methods of usage-centered design. ACMPress/Addison-Wesley Publishing Co. New York, NY, USA.

Coons, S. (1963). An outline of the requirements for a computer-aideddesign system. In Proceedings of the May 21-23, 1963, spring joint com-puter conference, pages 299–304. ACM New York, NY, USA.

168 References

Cooper, R. (1998). Benchmarking new product performance: results of thebest practices study. European Management Journal, 16(1):1–17.

Cooper, R. and Kleinschmidt, E. (2000). New product performance: Whatdistinguishes the star products. Australian Journal of Management,25(1).

Cramton, C. D. (1997). Information Problems in Dispersed Teams. InAcademy of Management Best Paper Proceedings, volume 1997, pages298–302, Georgia, Southern University.

Cramton, C. D. (2001). The Mutual Knowledge Problem and Its Conse-quences for Dispersed Collaboration. Organization Science, 12(3):346–371.

Cross, N. (2006). Designerly Ways of Knowing. Springer.Cross, N. and Clayburn, A. (1995). Observations of teamwork and social

processes in design. Design Studies, 16(2):143–170.DeMarco, T. and Lister, T. (1999). Peopleware: Productive Projects and

Teams. Dorset House, 2 edition.Dempsey, G. E. and Petschie, J. N. (2006a). Library Law:

Monitoring Employee Electronic Communications, Part I.http://www.nsls.info/articles/detail.aspx?articleID=54, retrievedSep. 17, 2010.

Dempsey, G. E. and Petschie, J. N. (2006b). Library Law:Monitoring Employee Electronic Communications, Part II.http://www.nsls.info/articles/detail.aspx?articleID=55, retrievedSep. 17, 2010.

Dennis, A. and Valacich, J. (1999). Rethinking media richness: Towardsa theory of media synchronicity. In Proceedings of the 32nd HawaiiInternational Conference on System Sciences, volume 1.

DeSanctis, G. and Gallupe, R. (1987). A foundation for the study of groupdecision support systems. Management science, pages 589–609.

DeSanctis, G. and Poole, M. S. (1994). Capturing the Complexity in Ad-vanced Technology Use: Adaptive Structuration Theory. OrganizationScience, 5(2):121–147.

Di Janni, A. (1986). A monitor for complex CAD systems. In DAC’86: Proceedings of the 23rd ACM/IEEE Design Automation Conference,pages 145–151, Piscataway, NJ, USA. IEEE Press.

Dixon, J. R. (1987). On research methodology towards a scientific theoryof engineering design. AI EDAM, 1(03):145–157.

Driskell, J., Radtke, P., and Salas, E. (2003). Virtual teams: Effects oftechnological mediation on team performance. Group Dynamics: Theory,Research, and Practice, 7(4):297–323.

Dunkel, J., Eberhart, A., Fischer, S., Kleiner, C., and Koschel, A. (2008).Systemarchitekturen fur verteilte Anwendungen. Client-Server, Multi-

References 169

Tier, SOA, Event Driven Architecture, P2P, Grid, Web 2.0. HanserFachbuch.

Dym, C., Agogino, A., Eris, O., Frey, D., and Leifer, L. (2006). Engi-neering Design Thinking, Teaching, and Learning. IEEE EngineeringManagement Review, 34(1):65–92.

Ellis, C., Gibbs, S., and Rein, G. (1991). Groupware: some issues andexperiences. Communications of the ACM, 34(1):39–58.

Engelbart, D. (1962). Augmenting human intellect: A conceptual frame-work. Stanford Research Institute Technical Report AFOSR-3223, Con-tract AF, 49(638):1024.

Eris, O. (2002). Perceiving, Comprehending, and Measuring Design Activ-ity Through the Questions Asked while Designing. PhD thesis, StanfordUniversity, Stanford, CA.

Erl, T. (2005). Service-oriented architecture: concepts, technology, and de-sign. Prentice Hall PTR, Upper Saddle River, NJ, USA.

Europ. Commission (1995). Directive 95/46/EC of the European Parlia-ment and of the Council of 24 October 1995 on the protection of indi-viduals with regard to the processing of personal data and on the freemovement of such data. http://ec.europa.eu/justice home/fsj/privacy/.

Eveland, J. D. and Bikson, T. K. (1988). Work group structures andcomputer support: A field experiment. ACM Transactions on OfficeInformation Systems, 6:354–379.

Fallows, D. (2002). Email at work. Pew Internet & Americal Life Project.Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and

Berners-Lee, T. (1999a). Hypertext Transfer Protocol – HTTP/1.1. TheInternet Engineering Task Force, http://www.ietf.org/rfc/rfc2616.txt.

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach,P., and Berners-Lee, T. (1999b). RFC 2616 - Hypertext Trans-fer Protocol – HTTP/1.1. Internet Engineering Task Force,http://tools.ietf.org/html/rfc2616.

Fielding, R. and Taylor, R. (2002). Principled design of the modern web ar-chitecture. ACM Transactions on Internet Technology (TOIT), 2(2):115–150.

Fielding, R. T. (2000). Architectural styles and the design of network-basedsoftware architectures. PhD thesis, University of California, Irvine.

Finger, S. and Dixon, J. (1989). A review of research in mechanical en-gineering design. part i: Descriptive, prescriptive, and computer-basedmodels of design processes. Research in Engineering Design, 1(1):51–67.

Fischer, G., Grudin, J., Lemke, A., McCall, R., Ostwald, J., Reeves, B.,and Shipman, F. (1992). Supporting indirect collaborative design withintegrated knowledge-based design environments. Human-Computer In-teraction, 7(3):281–314.

170 References

Fischer, J. (2007). Identifying, Visualizing and Supporting Social Net-works for Collaborative Work in a CSCW-System. Master’s thesis,http://www.mrl.nott.ac.uk/˜jef/thesis jef.pdf.

Frankenberger, E., Badke-Schaub, P., and Birkhofer, H. (1997). Factorsinfluencing design work, empirical investigations of teamwork in engi-neering design practice. International Conference on Engineering Design(ICED’97), pages 387–392.

Fussell, S., Kraut, R., Lerch, F., Scherlis, W., McNally, M., and Cadiz, J.(1998). Coordination, overload and team performance: effects of teamcommunication strategies. In Proceedings of the 1998 ACM conference onComputer supported cooperative work, pages 275–284. ACM New York,NY, USA.

Futrelle, J. (2006). Harvesting RDF Triples. Lecture Notes in ComputerScience: Provenance and Annotation of Data, 4145:64–72.

Galegher, J. and Kraut, R. (1994). Computer-mediated communicationfor intellectual teamwork: An experiment in group writing. InformationSystems Research, 5(2):110.

Gantz, J., Reinsel, D., Chute, C., Schlichting, W., McArthur, J., Minton,S., Xheneti, I., Toncheva, A., and Manfrediz, A. (2007). The expandingdigital universe: A forecast of worldwide information growth through2010. EMC Corporation.

Gary, L. (2003). Dealing with a Project’s “Fuzzy Front End”. HarvardManagement Update.

Geisler, C. and Rogers, E. (2000). Technological mediation for design col-laboration. In Proceedings of IEEE professional communication societyinternational professional communication conference and Proceedings ofthe 18th annual ACM international conference on Computer documen-tation: technology & teamwork, pages 395–405. IEEE Educational Activ-ities Department Piscataway, NJ, USA.

Geisler, C., Rogers, E., and Tobin, J. (1999). Going public: Collabora-tive systems design for multidisciplinary conversations. Lecture notes incomputer science, pages 89–100.

Gero, J. (1990). Design prototypes: a knowledge representation schema fordesign. AI magazine, 11(4):26.

Gero, J. (1998). Conceptual designing as a sequence of situated acts. Lec-ture Notes in Computer Science, 1454:165–177.

Gero, J. and Kannengiesser, U. (2004). The situated function–behaviour–structure framework. Design Studies, 25(4):373–391.

Gloor, P., Paasivaara, M., Schoder, D., and Willems, P. (2008). Findingcollaborative innovation networks through correlating performance withsocial network structure. International Journal of Production Research,46(5):1357.

References 171

Gloor, P. and Zhao, Y. (2004). TeCFlow – A Temporal CommunicationFlow Analyzer for Social Network Analysis. In Workshop on Social Net-works for Design and Analysis: Using Network Information in CSCW.

Gloor, P. and Zhao, Y. (2006). Analyzing Actors and Their DiscussionTopics by Semantic Social Network Analysis. In Proceedings of the TenthInternational Conference on Information Visualization, IV 2006, pages130–135.

Goland, Y., Whitehead, E., Faizi, A., Carter, S., and Jensen, D. (1999).RFC 2518 - HTTP Extensions for Distributed Authoring – WEBDAV.Internet Engineering Task Force, http://tools.ietf.org/html/rfc2518.

Greif, I. (1988). Computer-supported cooperative work: A book of readings.Morgan Kaufmann.

Gruber, T. R. (1993). A translation approach to portable ontology speci-fications. Knowl. Acquis., 5(2):199–220.

Grudin, J. (1988). Why cscw applications fail: problems in the design andevaluationof organizational interfaces. In Proceedings of the 1988 ACMconference on Computer-supported cooperative work, pages 85–93. ACMNew York, NY, USA.

Grudin, J. (1994). CSCW: History and focus. IEEE Computer, 27(5):19–26.

Gutierrez, C., Hurtado, C., and Vaisman, A. (2007). Introducing time intordf. IEEE Transactions on Knowledge and Data Engineering, 19(2):207.

Halpin, H., Iannella, R., Suda, B., and Walsh, N. (2010). Rep-resenting vCard Objects in RDF. W3C Member Submission,http://www.w3.org/TR/vcard-rdf/.

Hightower, R. T., Warkentin, M. E., Sayeed, L., and McHaney, R. (1998).Information Exchange in Virtual Work Groups. pages 199–216.

Hitzler, P., Kr”otzsch, M., Rudolph, S., and Sure, Y. (2008). Semantic Web: Grundla-gen. Springer.

Horrocks, I. and Patel-Schneider, P. (2004). Reducing owl entailment todescription logic satisfiability. Web Semantics: Science, Services andAgents on the World Wide Web, 1(4):345–357.

Horrocks, I., Patel-Schneider, P., and Van Harmelen, F. (2003). From shiqand rdf to owl: The making of a web ontology language. Web semantics:science, services and agents on the World Wide Web, 1(1):7–26.

IEEE (2000). IEEE Std 1471-2000, Recommended Practice for Architec-tural Description of Software-Intensive Systems. Technical report, IEEEArchitecture Working Group.

Ishii, H. (1990). TeamWorkStation: towards a seamless shared workspace.In Proceedings of the 1990 ACM conference on Computer-supported co-operative work, pages 13–26. ACM New York, NY, USA.

172 References

ISO/IEC (1996). ISO 10746-2: Information Technology – Open DistributedProcessing – Reference Model: Foundations. International Organizationfor Standardization, http://www.iso.org/.

ISO/IEC (1998). ISO 9241-11: Ergonomic requirements for office workwith visual display terminals (VDT) – Part 11: Guidance on usability.International Organization for Standardization, http://www.iso.org/.

ISO/IEC (1999). ISO 13407: Human-Centred Design Processes for In-teractive Systems. International Organization for Standardization,http://www.iso.org/.

ISO/IEC (2005). ISO 19199: Geographic Information – Services. Interna-tional Organization for Standardization, http://www.iso.org/.

Jabi, W. (2003). Reflections on computer-supported cooperative designsystems. In Digital design: research and practice: proceedings of the 10thInternational Conference on Computer Aided Architectural Design Fu-tures, pages 169–180. Springer.

Jacoby, R. and Rodriguez, D. (2008). Innovation, growth, and getting towhere you want to go. Building Design Strategy: Using Design to AchieveKey Business Objectives, pages 43–51.

Jarvenpaa, S. and Leidner, D. (1999). Communication and Trust in GlobalVirtual Teams. Organization Science, 10(6):791–815.

Jarvenpaa, S. L. and Ives, B. (1994). The global network organization ofthe future: information management opportunities and challenges. J.Manage. Inf. Syst., 10(4):25–57.

Johansen, R. (1988). Groupware: Computer support for business teams.The Free Press, New York, NY, USA.

Johansson, C., Dittrich, Y., and Juustila, A. (1999). Software EngineeringAcross Boundaries Student Project in Distributed Collaboration. IEEETransaction on Professional Communication, 42(4):286–296.

Johnson, J. (1999). A field study of partially distributed group support.In Proceedings of the 32nd Hawaii International Conference on SystemSciences, Hawaii.

Jokela, T. (2002). Making user-centred design common sense: striving foran unambiguous and communicative UCD process model. In NordiCHI’02: Proceedings of the second Nordic conference on Human-computerinteraction, pages 19–26, New York, NY, USA. ACM Press.

Ju, W., Neeley, L., and Leifer, L. (2007). Design, Design, and Design:An Overview of Stanford’s Center for Design Research. Workshop onExploring Design as a Research Activity, CHI 2007.

Jung, E. C., Sato, K., Chen, Y., He, X., MacTavish, T., and Cracchiolo, D.(2005). DIF Knowledge Management System: Bridging Viewpoints forInteractive System Design. In Proc. of 11th International Conference onHuman-Computer Interaction (HCI’05), Las Vegas.

References 173

Katzenbach, J. R. and Smith, D. K. (2001). The discipline of teams: amindbook-workbook for delivering small group performance. Wiley, NewYork, NY.

Kelley, D. and Hartfield, B. (1996). The Designer’s Stance. In Winograd,T., editor, Bringing Design To Software, pages 151–164. ACM New York,NY, USA.

Kelley, T. and Littman, J. (2001). The Art of Innovation: Lessons in Cre-ativity from IDEO, America’s Leading Design Firm. Broadway Business.

Kidane, Y. and Gloor, P. (2007). Correlating temporal communication pat-terns of the Eclipse open source community with performance and cre-ativity. Computational & Mathematical Organization Theory, 13(1):17–27.

Kim, J. and Wilemon, D. (1999). Managing the fuzzy front-end of the newproduct development process. In Management of Engineering and Tech-nology, 1999. Technology and Innovation Management. PICMET’99.Portland International Conference on, volume 1.

Kim, J. and Wilemon, D. (2002). Strategic issues in managing innovation’sfuzzy front-end. European Journal of Innovation Management, 5(1):27–39.

Koen, P., Ajamian, G., Boyce, S., Clamen, A., Fisher, E., Fountoulakis, S.,Johnson, A., Puri, P., and Seibert, R. (2002). Fuzzy front end: Effectivemethods, tools, and techniques. The PDMA toolbook for new productdevelopment.

Koen, P., Ajamian, G., Burkart, R., Clamen, A., Davidson, J., D’Amore,R., Elkins, C., Herald, K., Incorvia, M., Johnson, A., et al. (2001). Pro-viding clarity and a common language to the” fuzzy front end”. Research-Technology Management, 44(2):46–55.

Kondratieff, N. and Stolper, W. (1935). The Long Waves in Economic Life.The Review of Economics and Statistics, 17(6):105–115.

Kraemer, K. and King, J. (1988). Computer-based systems for cooperativework and group decision making. ACM Computing Surveys (CSUR),20(2):115–146.

Kvan, T. (2000). Collaborative design: what is it? Automation in construc-tion, 9(4):409–415.

Layzell, P., Brereton, O., and French, A. (2000). Supporting collaborationin distributed software engineering teams. In Seventh Asia-Pacific Soft-ware Engineering Conference, 2000. APSEC 2000. Proceedings., pages38–45.

Leifer, L., Culpepper, W., Cannon, D., Eris, O., Liang, T., Bell, D., Bier,E., and Pier, K. (2002). Measuring the performance of online distributedteam innovation (learning) services. Proceedings of the e-Technologies inEngineering Education: Learning Outcomes Providing Future Possibili-ties.

174 References

Liang, T., Cannon, D., Feland, J., Mabogunje, A., Yen, S., Yang, M., andLeifer, L. (1999). New dimensions in internet-based design capture andreuse. In proceedings of the International Conference on EngineeringDesign, Munich, Germany, August, pages 24–26.

Lim, Y. and Sato, K. (2001). Development of design information frame-work for interactive systems design. In Proceedings of the 5th AsianInternational Symposium on Design Research.

Loftus, C., McMahon, C., and Hicks, B. (2008). Issues and challenges forimproving email use in engineering design. In NordDesign 2008, Univer-sity of Technology, Tallinn, Estonia.

Lurey, J. and Raisinghani, M. (2001). An Empirical Study of Best Practicesin Virtual Teams. Information & Management, 38(8):523–544.

Malone, T., Grant, K., Lai, K., Rao, R., and Rosenblitt, D. (1987).Semistructured messages are surprisingly useful for computer-supportedcoordination. ACM Transactions on Information Systems (TOIS),5(2):115–131.

Mankin, D. A., Bikson, T. K., and Cohen, S. G. (1996). Teams and technol-ogy : fulfilling the promise of the new organization / Don Mankin, SusanG. Cohen, Tora K. Bikson. Harvard Business School Press, Boston,Mass.

Mao, J., Vredenburg, K., Smith, P., and Carey, T. (2005). The state ofuser-centered design practice. Communications of the ACM, 48(3):105–109.

Matthew, C., Laskey, K., McCabe, F., Brown, P. F., and Metz, R.(2006). Reference Model for Service Oriented Architecture 1.0. OASIS,http://www.oasis-open.org/committees/tc home.php?wg abbrev=soa-rm.

Mayhew, D. J. (1999). The usability engineering lifecycle: a practitioner’shandbook for user interface design. Morgan Kaufmann Publishers Inc.,San Francisco, CA, USA.

Maznevski, M. L. and Chudoba, K. M. (2000). Bridging Space Over Time:Global Virtual Team Dynamics and Effectiveness. Organization Science,11(5):473–492.

McBride, B. (2004). The Resource Description Framework (RDF) and itsVocabulary Description Language RDFS. In Staab, S. and Studer, R.,editors, Handbook on Ontologies, chapter 3, pages 51–66. Springer Verlag.

McCall, R., Bennett, P., D’Oronzio, P., Ostwald, J., Shipman, F., and Wal-lace, N. (1990). PHIDIAS: Integrating CAD Graphics into Dynamic Hy-pertext. In Hypertext: Concepts, Systems and Applications: Proceedingsof the First European Conference on Hypertext, pages 152–165. Cam-bridge University Press.

McDonough, E. F., Kahnb, K. B., and Barczaka, G. (2001). An investiga-tion of the use of global, virtual, and colocated new product developmentteams. Journal of Product Innovation Management, 18(2):110–120.

References 175

McDowell, L., Etzioni, O., and Halevy, A. (2004). Semantic Email: Theoryand Applications. Web Semantics: Science, Services and Agents on theWorld Wide Web, 2(2):153–183.

McGrath, J. and Hollingshead, A. (1994). Groups interacting with tech-nology: Ideas, evidence, issues, and an agenda. Sage Thousand Oaks,Calif.

Milne, A. J. (2005). An Information-theoretic Approach to the Study ofUbiquitous Computing Workspaces Supporting Geographically DistributedEngineering Design Teams as Goup-users. PhD thesis, Stanford Univer-sity, Stanford, CA.

Mowbray, T. J. and Ruh, W. (1998). Inside CORBA: Distributed ObjectStandards and Applications. Addison-Wesley Longman Publishing Co.,Inc., Boston, MA, USA.

Mueller, C. (2008). Graphentheoretische Analyse der Evolution von Wiki-basierten Netzwerken fur selbstorganisiertes Wissensmanagement. Gito.

Neumann, T. and Weikum, G. (2009). Scalable join processing on verylarge rdf graphs. In SIGMOD ’09: Proceedings of the 35th SIGMODinternational conference on Management of data, pages 627–640, NewYork, NY, USA. ACM.

Nielsen, J. (1994). Usability Engineering. Morgan Kaufmann.Norman, D. and Draper, S., editors (1986). User Centered System Design:

New Perspectives on Human-Computer Interaction. Lawrence ErlbaumAssociates, Hillsdale, NJ.

Nunamaker, J. F., Dennis, A. R., Valacich, J. S., Vogel, D., and George,J. F. (1991). Electronic meeting systems to support group work. Com-mun. ACM, 34(7):40–61.

Olson, G. and Olson, J. (2000). Distance matters. Human-computer inter-action, 15(2):139–178.

Olson, J. and Teasley, S. (1996). Groupware in the wild: lessons learnedfrom a year of virtual collocation. In Proceedings of the 1996 ACM con-ference on Computer supported cooperative work, pages 419–427. ACM.

O’Reilly, T. (2005). What Is Web 2.0 – Design Patterns and Busi-ness Models for the Next Generation of Software. O’Reilly Media,http://oreilly.com/web2/archive/what-is-web-20.html, Accessed Jan. 12,2010.

Overdick, H. (2007). The resource-oriented architecture. IEEE Congresson Services, pages 340–347.

Pahl, G., Beitz, W., Wallace, K., Blessing, L., and Bauert, F. (1996). En-gineering design: a systematic approach. Springer Verlag.

Perry, M. (2008). A Framework to Support Spatial, Temporal and ThematicAnalytics over Semantic Web Data. PhD thesis, Wright State University.

176 References

Perry, M., Fruchter, R., and Rosenberg, D. (1999). Co-ordinating dis-tributed knowledge: A study into the use of an organisational memory.Cognition, Technology & Work, 1(3):142–152.

Powell, A., Piccoli, G., and Ives, B. (2004). Virtual teams: a review ofcurrent literature and directions for future research. The DATA BASEfor Advances in Information Systems, 35(1):7.

Preist, C. (2004). A Conceptual Architecture for Semantic Web Services.The Semantic Web–ISWC 2004, pages 395–409.

Ramesh, B. and Tiwana, A. (1999). Supporting collaborative processknowledge management in new product development teams. DecisionSupport Systems, 27(1-2):213–235.

Reinertsen, D. (1999). Taking the fuzziness out of the fuzzy front end.Research technology management, 42(6):25–31.

Resnick, P. (2001). RFC 2822 - Internet Message Format. Internet Engi-neering Task Force, http://tools.ietf.org/html/rfc2822.

Rosenbaum, S., Rohn, J., and Humburg, J. (2000). A toolkit for strategicusability: results from workshops, panels, and surveys. In Proceedings ofthe SIGCHI conference on Human factors in computing systems, page344. ACM.

Sarker, S. and Sahay, S. (2002). Information Systems Development byUS-Norwegian Virtual Teams: Implications of Time and Space. In Pro-ceedings of the 35th Annual Hawaii International Conference on SystemSciences (HICSS’02)-Volume 1-Volume 1, page 18. IEEE Computer So-ciety.

Schmidt, J., Montoya-Weiss, M., and Massey, A. (2001). New Product De-velopment Decision-Making Effectiveness: Comparing Individuals, Face-To-Face Teams, and Virtual Teams*. Decision Sciences, 32(4):575–600.

Schmidt, K. (1998). Cooperative design: Prospects for CSCW in design.Design Sciences and Technology, 6(2):5–18.

Schmidt, K. and Bannon, L. (1992). Taking cscw seriously. ComputerSupported Cooperative Work (CSCW), 1(1):7–40.

Schon, D. (1992). Designing as reflective conversation with the materialsof a design situation. Research in Engineering Design, 3(3):131–147.

Schumpeter, J. A. (1942). Capitalism, Socialism, and Democracy. Harperand Brothers, New York.

Schwaber, C., Rymer, J. R., and Stone, J. (2006). The Changing Face OfApplication Life-Cycle Management. Forrester Research.

Shannon, C. and Weaver, W. (1949). The mathematical theory of infor-mation. Urbana: University of Illinois Press, 97.

Sheppard, S. (2003). A Description of Engineering: An Essential Backdropfor Interpreting Engineering Education. In Proceedings (CD), Mudd De-sign Workshop IV, Harvey Mudd College, Claremont, Cal.

References 177

Shiu, E. and Lenhart, A. (2004). How Americans use instant messaging.Pew Internet & Americal Life Project.

Skogstad, P. (2009). A Unified Innovation Process Model For EngineeringDesigners and Managers. PhD thesis, Stanford University, Stanford, CA.

Skogstad, P., Steinert, M., Gumerlock, K., and Leifer, L. (2009). We needa universal design project outcome performance measurement metric: adiscussion based on empirical research. In Bergendahl, M. N., Grimhe-den, M., Leifer, L., Skogstad, P., and Seering, W., editors, Proceedingsof ICED’09, Design Methods and Tools, volume 6, pages 473–484. TheDesign Society.

Sommerville, I. (2006). Software Engineering. Addison Wesley, 8th edition.Spenser, J. (2009). The Airplane: How Ideas Gave Us Wings. Harper

Paperbacks.Sproull, L. and Kiesler, S. (1986). Reducing social context cues: Elec-

tronic mail in organizational communications. Management Science,32(11):1492–1512.

Sproull, L. and Kiesler, S. (1992). Connections: New Ways of Working inthe Networked Organization. MIT Press.

Stefik, M., Foster, G., Bobrow, D., Kahn, K., Lanning, S., and Suchman, L.(1987). Beyond the chalkboard: computer support for collaboration andproblem solving in meetings. Communications of the ACM, 30(1):47.

Steinfield, C., Jang, C., Huysman, M., David, K., Lloyd, J., Goodman, E.,Hinds, T., and Andriessen, E. (2002). Communication and collaborationprocesses in global virtual teams. Unpublished INTEnD report, MichiganState University. East Lansing, Michigan.

Sterpe, P., Cullen, A., Gilpin, M., Schwaber, C., and Ranade, K. (2007).App Dev Managers Should Measure Team Productivity. Forrester Re-search.

Stonebraker, M., Rowe, L. A., and Hirohama, M. (1990). The implemen-tation of postgres. In IEEE Transactions on Knowledge and Data Engi-neering, pages 340–355.

Tang, J. and Leifer, L. (1991). An observational methodology for studyinggroup design activity. Research in engineering design, 2(4):209–219.

Tebay, R., Atherton, J., and Wearne, S. (1984). Mechanical engineeringdesign decisions: instances of practice compared with theory. Proceedingsof the Institution of Mechanical Engineers. Part B. Management andengineering manufacture, 198(6):87–96.

Thompson, L. and Coovert, M. (2003). Teamwork online: The effects ofcomputer conferencing on perceived confusion, satisfaction, and post-discussion accuracy. Group Dynamics: Theory, Research, and Practice,7(2):135–151.

Toye, G., Cutkosky, M., Leifer, L. J., Tenenbaum, J. M., and Glicksman,J. (1994). SHARE: A Methodology and Environment for Collaborative

178 References

Product Development. International Journal of Intelligent and Cooper-ative Information Systems, 3(2):129–153.

Tucci, L. (2008). Managing the application development lifecy-cle requires solid metrics. http://searchcio.techtarget.com/news/arti-cle/0,289142,sid182 gci1293866,00, retrieved Jul. 16, 2010.

Uflacker, M. (2007). Resource-oriented knowledge sharing in user-centereddesign communities. In Proceedings of the 10th IFAC/IFIP/IFORS/IEASymposium on Analysis, Design, and Evaluation of Human-Machine Sys-tems.

Uflacker, M. (2009). Implementation of a service platform to evaluatevirtual team communication. Proceedings of the 3rd Ph.D. Retreat ofthe HPI Research School on Service-oriented Systems Engineering 27,Hasso-Plattner-Institut fur Softwaresystemtechnik.

Uflacker, M., Skogstad, P., Zeier, A., and Leifer, L. (2009). Analysis ofvirtual design collaboration with team communication networks. In 17thInternational Conference on Engineering Design (ICED’09), Stanford,CA.

Uflacker, M. and Zeier, A. (2008a). d.store: Capturing team informationspaces with resource-based information networks. In IADIS InternationalConference WWW/Internet 2008, Freiburg, Germany.

Uflacker, M. and Zeier, A. (2008b). Extending the situated function-behaviour-structure framework for user-centered software design. In Pro-ceedings of the Third Internation Conference on Design Computing andCognition, DCC’08.

Uflacker, M. and Zeier, A. (2008c). A graph-based approach to assess-ing multi-modal team communication in global organizations. In IEEESymposium on Advanced Management of Information for Globalized En-terprises.

Uflacker, M. and Zeier, A. (2009). A platform for the temporal evalua-tion of team communication in distributed design environments. In 13thInternational Conference on Computer-Supported Cooperative Work inDesign (CSCWD’09), Santiago, Chile.

Uflacker, M. and Zeier, A. (2010a). An Instrument for Real-Time DesignInteraction Capture and Analysis. In Meinel, C. and Leifer, L., editors,Design Thinking: Understand – Improve – Apply. Springer (in print).

Uflacker, M. and Zeier, A. (2010b). A semantic network approach to ana-lyzing virtual team interactions in the early stages of conceptual design.Future Generation Computer Systems, 27(1):88–99.

Ulferts, J. (2009). Strukturelle und inhaltliche Analyse der E-Mail-Kommunikation in global verteilten Designprojekten. Master’s thesis,Hasso Plattner Institute fur Softwaresystemtechnik, Universitat Pots-dam, Germany.

References 179

Ulrich, K. and Seering, W. (1987). A computational approach to concep-tual design. In Proceedings of ICED’87, International Conference onEngineering Design.

Uslander, T. (2010). Service-oriented design of environmental informationsystems. PhD thesis.

Venturi, G. and Troost, J. (2004). Survey on the ucd integration in the in-dustry. In Proceedings of the third Nordic conference on Human-computerinteraction, page 452. ACM.

Vosinakis, S., Koutsabasis, P., Stavrakis, M., Viorres, N., and Darzentas,J. (2007). Supporting conceptual design in collaborative virtual envi-ronments. In Proc. of 11th Panhellenic Conference on Informatics, PCI2007.

Vosinakis, S., Koutsabasis, P., Stavrakis, M., Viorres, N., and Darzentas,J. (2008). Virtual environments for collaborative design: requirementsand guidelines from a social action perspective. CoDesign, 4(3):133–150.

Vredenburg, K., Isensee, S., and Righi, C. (2002a). User Centered Design:An integrated approach. PTR Prentice Hall, Indianapolis.

Vredenburg, K., Mao, J., Smith, P., and Carey, T. (2002b). A survey ofuser-centered design practice. In Proceedings of the SIGCHI conferenceon Human factors in computing systems: Changing our world, changingourselves, pages 471–478. ACM New York, NY, USA.

W3C (2004a). OWL Web Ontology Language Reference. W3C Recom-mendation, http://www.w3.org/TR/owl-ref/.

W3C (2004b). RDF Primer. W3C Recommendation,http://www.w3.org/TR/rdf-primer/.

W3C (2004c). RDF Semantics. W3C Recommendation,http://www.w3.org/TR/rdf-mt/.

W3C (2004d). RDF Vocabulary Description Language 1.0: RDF Schema.W3C Recommendation, http://www.w3.org/TR/rdf-schema/.

W3C (2004e). RDF/XML Syntax Specification (Revised). W3C Recom-mendation, http://www.w3.org/TR/rdf-syntax-grammar/.

W3C (2004f). Resource Description Framework (RDF): Concepts andAbstract Syntax. W3C Recommendation, http://www.w3.org/TR/rdf-concepts/.

W3C (2004g). SWRL: A Semantic Web Rule Language Com-bining OWL and RuleML. W3C Member Submission,http://www.w3.org/Submission/SWRL/.

W3C (2008). SPARQL Query Language for RDF. W3C Recommendation,http://www.w3.org/TR/rdf-sparql-query/.

Wageman, R., Hackman, J. R., and Lehman, E. V. (2005). Team diag-nostic survey: Development of an instrument. The Journal of AppliedBehavioral Science, 41(4):373.

180 References

Wang, L., Shen, W., Xie, H., Neelamkavil, J., and Pardasani, A. (2002).Collaborative conceptual design—state of the art and future trends.Computer-Aided Design, 34(13):981–996.

Weiss, L. (2002). Developing Tangible Strategies. Design ManagementJournal, 13(1):33–38.

Whitman, M. E., Townsend, A. M., and Aalberts, R. J. (1999). Consider-ations for an effective telecommunications-use policy. Commun. ACM,42(6):101–108.

Wiegers, T. and Knoop, W. (1998). Visualisation of engineering processto support monitoring and control of design processes. In Proceedings ofTMCE ’98 Tools and Methods of Concurrent Engineering Symposium,pages 360–367, Manchester, England.

Wilkinson, K., Sayers, C., Kuno, H., Reynolds, D., and Ding, L. (2003).Supporting scalable, persistent semantic web applications. Data Engi-neering, 51:33.

Wilson, P. (1991). Computer supported cooperative work: an introduction.Springer.

Winograd, T. (1986). A language/action perspective on the design of coop-erative work. In Proceedings of the 1986 ACM conference on Computer-supported cooperative work, pages 203–220. ACM New York, NY, USA.

Winograd, T. (1996). Bringing design to software. ACM New York, NY,USA.

Wong, S. and Burton, R. (2000). Virtual teams: what are their characteris-tics, and impact on team performance? Computational & MathematicalOrganization Theory, 6(4):339–360.

Yen, S. J. (2000). Capturing Multimodal Design Activities in Support ofInformation Retrieval and Process Analysis. PhD thesis, Stanford Uni-versity, Stanford, CA.

Appendix

A

Case Study Data

A.1 Individual Team Member Scores

The following pages provide raw data of the individual team member in-teractions in the testbed projects, as queried from the d.store platform.The values have been measured at the end of the three project phases (i.e.,academic quarters, approx. three month each). The three tables on thefollowing pages show the non-aggregated query results.

Table A.1. Individual team member attributes queried from the generated Team CollaborationNetworks. The ID serves as a reference for the data table entries on the following pages.

ID Description

I01-d Number of distinct emails sentI02-d Number of distinct initiating emails sentI03-d Number of distinct email repliesI04-d Number of attachments sent with distinct emailsI05-d Number of URLs in distinct emailsI06-b Number of wiki pages createdI07-b Number of distinct wiki pages editedI08-b Number of total page edits and creationsI09-b Number of new files uploaded to shared folderI10-b Number of distinct revised files uploaded to shared folderI11-b Number of total file uploads and creationsI12-b Number of distinct files viewed in shared folderI13-b Number of total file views in shared folderI14-d Number of distinct emails sent to team-externalsI15-d Number of distinct emails sent internally only

I01-d I02-d I03-d I04-d I05-d I06-b I07-b I08-b I09-b I10-b I11-b I12-b I13-b I14-d I15-d1.1 34 14 20 1 12 6 7 24 163 136 300 206 252 2 321.2 34 24 10 6 4 5 6 16 15 1 16 122 124 2 321.3 21 12 9 1 10 22 9 61 8 2 10 33 37 5 162.1 12 0 12 0 4 0 3 3 8 4 12 19 23 0 122.2 16 9 7 1 3 1 5 8 4 4 8 77 79 2 142.3 12 7 5 0 0 3 5 11 7 2 9 11 15 0 121.1 55 26 29 3 17 6 8 31 13 0 13 42 44 8 471.2 64 31 33 15 19 20 10 54 1 0 1 14 15 14 501.3 45 14 31 6 10 4 7 25 28 1 29 11 15 4 412.1 26 13 13 17 15 1 1 5 17 1 18 20 31 1 252.2 5 0 5 2 1 3 4 9 6 0 6 13 21 0 52.3 20 7 13 17 2 1 3 1 0 0 0 9 14 0 201.1 28 10 18 2 7 31 11 73 14 0 14 9 19 9 191.2 6 0 6 0 2 0 3 3 0 0 0 0 0 2 41.3 14 4 10 2 4 5 2 9 0 0 0 0 0 9 52.1 18 2 16 1 9 1 2 4 0 0 0 7 9 5 132.2 22 6 16 5 11 1 5 9 0 0 0 1 2 8 142.3 14 3 11 0 4 0 0 0 1 0 1 0 0 4 102.4 11 6 5 1 4 0 2 2 0 0 0 3 4 3 81.1 21 10 11 3 6 1 5 8 0 0 0 11 11 0 211.2 12 4 8 9 2 3 6 21 3 0 3 2 2 1 111.3 26 15 11 5 2 3 7 23 11 1 13 43 45 0 261.4 5 1 4 1 1 2 2 4 0 0 0 5 5 1 42.1 21 16 5 8 9 8 11 49 48 48 105 81 111 2 192.2 19 10 9 5 12 1 6 26 14 2 16 37 46 4 152.3 22 18 4 10 12 2 6 20 1 0 1 20 22 1 211.1 17 7 10 3 3 0 5 6 0 0 0 0 0 5 121.2 51 14 37 7 6 4 7 17 0 0 0 3 5 14 371.3 38 16 22 13 15 17 8 53 0 0 0 3 3 15 232.1 0 0 0 0 0 1 3 12 0 0 0 0 0 0 02.2 6 3 3 0 0 1 6 17 2 0 2 1 3 1 52.3 0 0 0 0 0 1 6 11 0 0 0 1 2 0 02.4 14 7 7 0 0 5 10 50 2 0 2 1 1 3 111.1 17 8 9 3 4 14 24 79 0 0 0 8 8 4 131.2 57 33 24 40 4 12 15 44 2 1 3 97 97 5 521.3 11 4 7 3 2 7 9 30 0 0 0 1 1 2 92.1 28 15 13 15 5 9 19 55 110 2 113 23 26 0 282.2 1 1 0 3 0 0 1 6 0 0 0 4 6 0 12.3 5 5 0 3 0 0 2 5 7 2 9 9 10 0 52.4 8 7 1 3 1 2 4 13 0 0 0 19 22 0 82.5 4 2 2 0 2 0 4 5 0 0 0 9 9 0 42.6 7 4 3 1 0 3 3 8 0 0 0 4 5 0 72.7 5 0 5 0 0 0 2 5 39 1 44 18 23 0 52.8 3 0 3 1 0 1 1 2 0 0 0 7 9 0 31.1 43 31 12 26 9 7 9 37 3 2 77 1 6 14 291.2 30 15 15 5 15 1 5 9 0 0 0 1 1 6 241.3 86 15 71 10 38 6 12 48 0 0 0 0 0 48 392.1 6 0 6 0 6 2 4 6 0 0 0 3 4 1 52.2 1 1 0 2 0 1 7 23 0 0 0 0 0 0 12.3 10 0 10 3 5 1 1 3 0 0 0 1 1 2 81.1 35 18 17 9 13 9 11 57 0 0 0 2 3 3 321.2 30 20 10 8 16 21 12 46 1 1 2 0 0 5 251.3 9 4 5 5 2 1 1 2 0 0 0 1 1 0 92.1 27 14 13 6 12 2 6 20 0 0 0 0 0 0 272.2 44 22 22 1 22 2 2 6 3 0 3 0 0 15 292.3 13 0 13 0 8 1 5 10 0 0 0 3 3 1 122.4 22 5 17 0 12 1 5 16 0 0 0 0 0 0 221.1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 01.2 5 0 5 0 1 0 0 0 0 0 0 0 0 0 51.3 102 47 55 9 23 14 12 42 3 3 6 7 9 9 932.1 2 0 2 0 3 2 3 6 0 0 0 0 0 0 22.2 20 10 10 3 7 10 13 43 1 0 1 2 2 2 182.3 79 28 51 19 24 4 12 45 0 0 0 4 4 10 691.1 43 9 34 6 24 4 4 10 1 0 1 16 19 10 331.2 39 16 23 7 30 6 2 10 16 0 16 0 0 7 321.3 36 16 20 2 9 3 5 16 0 0 0 2 2 1 352.1 39 19 20 0 13 0 4 4 0 0 0 0 0 7 322.2 70 26 44 9 33 12 8 32 0 0 0 16 16 24 462.3 14 2 12 0 12 0 1 1 0 0 0 0 0 0 141.1 10 7 3 0 1 10 8 29 1 4 5 0 0 2 81.2 11 5 6 1 1 3 6 22 6 0 6 2 2 3 81.3 1 0 1 0 0 3 4 19 0 0 0 0 0 0 12.1 2 2 0 2 0 2 4 18 0 1 1 2 2 1 12.2 3 3 0 0 1 2 4 10 0 0 0 3 4 0 32.3 5 5 0 6 0 16 15 113 2 1 4 3 6 0 52.4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Kappa

Lambda

Omega

Pi

Theta

Individual Scores, 1st Period

Alpha

Beta

Delta

Epsilon

Gamma

Iota

A.1. Individual Team Member Scores 183

1.11.21.32.12.22.31.11.21.32.12.22.31.11.21.32.12.22.32.41.11.21.31.42.12.22.31.11.21.32.12.22.32.41.11.21.32.12.22.32.42.52.62.72.81.11.21.32.12.22.31.11.21.32.12.22.32.41.11.21.32.12.22.31.11.21.32.12.22.31.11.21.32.12.22.32.4

Kappa

Lambda

Omega

Pi

Theta

Alpha

Beta

Delta

Epsilon

Gamma

Iota

I01-d I02-d I03-d I04-d I05-d I06-b I07-b I08-b I09-b I10-b I11-b I12-b I13-b I14-d I15-d99 50 49 11 48 13 8 36 156 101 380 316 441 26 7392 52 40 5 22 12 6 36 85 5 92 62 82 21 7172 34 38 3 27 14 6 35 85 12 109 182 290 11 6132 5 27 3 16 2 5 12 29 20 95 113 190 2 3023 8 15 7 15 2 4 7 16 16 32 135 165 0 2320 8 12 2 4 0 4 6 7 6 14 91 248 0 20

128 63 65 5 59 2 1 10 34 2 36 164 173 27 10395 48 47 16 25 1 0 4 84 1 85 11 11 17 7867 27 40 20 29 0 0 5 3 0 3 350 358 7 6082 46 36 26 69 1 0 2 1 0 1 102 113 16 6844 27 17 43 11 0 0 0 0 0 0 24 24 6 4142 8 34 12 8 0 1 0 5 1 6 11 11 2 4150 23 27 5 20 36 23 117 227 2 229 233 465 17 3326 5 21 10 7 1 7 10 45 8 54 139 182 10 1615 4 11 4 0 3 1 8 30 20 53 162 342 3 1214 2 12 2 4 4 9 24 45 0 45 291 373 3 1153 27 26 17 9 6 15 42 0 0 0 124 171 10 4335 15 20 1 6 7 13 43 22 15 41 188 314 10 2522 3 19 6 1 1 5 7 168 32 200 80 87 8 149 2 7 1 0 0 2 4 1 1 2 25 29 0 9

19 5 14 21 8 0 1 4 12 0 12 24 27 2 1734 27 7 8 8 6 9 30 23 6 29 34 41 3 315 0 5 0 0 0 2 2 7 0 7 15 15 1 4

24 18 6 5 8 3 6 36 171 33 210 116 277 0 2427 20 7 13 8 5 8 57 19 3 23 45 65 0 2736 32 4 12 10 10 11 68 14 2 17 24 38 2 341 0 1 0 0 0 0 0 0 0 0 0 0 0 1

50 16 34 3 14 2 2 6 2 1 3 26 28 11 3955 29 26 30 7 0 3 7 0 0 0 35 36 12 4323 13 10 11 2 0 2 4 2 0 2 78 78 1 2215 11 4 5 4 1 1 7 33 0 33 17 20 0 1513 2 11 6 4 0 4 11 3 0 3 180 204 2 1135 17 18 7 8 4 6 25 43 0 43 70 99 3 3245 27 18 6 12 8 5 37 3 1 4 205 245 13 3280 48 32 9 15 6 5 22 1773 1199 3324 2843 4628 25 564 2 2 2 1 0 3 4 1 0 1 0 0 3 1

18 14 4 4 5 4 3 26 79 3 82 8 8 1 171 0 1 0 2 0 1 1 0 0 0 41 41 0 15 5 0 3 0 0 1 2 101 0 101 356 376 0 5

20 12 8 9 5 3 6 13 3 0 3 74 76 2 183 1 2 4 0 1 2 3 28 1 29 77 80 0 37 1 6 2 1 0 2 2 9 0 9 56 59 1 66 1 5 4 0 0 3 6 2 0 2 18 20 1 54 1 3 4 2 0 2 2 0 0 0 26 26 0 4

26 13 13 10 7 0 1 3 6 4 10 54 79 6 2016 10 6 7 1 0 3 8 26 7 36 100 113 4 1299 49 50 25 37 0 0 46 14 2 17 10 11 50 497 0 7 2 1 0 3 8 1 0 1 5 5 0 78 5 3 3 1 0 1 17 0 0 0 5 6 0 8

13 0 13 6 11 0 1 6 0 0 0 3 3 0 1357 35 22 2 22 2 13 41 129 7 144 86 91 11 4638 29 9 0 15 17 12 43 88 3 91 381 396 9 2923 8 15 2 17 5 13 28 22 1 23 53 107 9 1445 23 22 5 17 2 12 21 383 57 440 338 355 7 39

125 80 45 8 41 1 19 22 200 8 209 516 528 40 8622 4 18 4 8 26 20 81 1 3 5 25 42 1 2122 4 18 2 9 4 7 19 0 0 0 40 95 0 2214 3 11 0 1 0 0 0 0 0 0 0 0 0 1476 40 36 20 10 1 4 8 2 2 14 33 85 4 72

197 99 98 22 36 0 1 1 5 4 9 29 185 25 17214 2 12 3 0 0 1 1 0 0 0 0 0 0 1453 32 21 12 9 2 3 7 0 0 0 0 0 0 53

132 72 60 34 47 6 3 26 171 0 171 0 0 7 12543 11 32 8 21 1 2 3 0 0 0 1 1 4 3940 8 32 1 24 0 0 0 2 0 2 2 2 3 3799 26 73 14 24 15 8 34 4 0 4 2 2 1 9834 3 31 11 11 0 1 2 0 0 0 3 44 5 2979 33 46 29 38 5 5 13 8 1 9 6 6 13 6644 4 40 6 14 3 7 14 1 0 1 13 15 6 389 6 3 2 1 1 6 20 3 1 4 1 3 6 3

18 3 15 0 4 8 3 24 0 0 0 0 0 15 33 1 2 0 2 2 3 41 1 0 1 3 5 1 20 0 0 0 0 0 0 3 36 0 36 2 3 0 00 0 0 0 0 0 1 2 1 1 2 14 29 0 04 3 1 1 1 16 5 95 5 0 5 11 22 1 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Individual Scores, 2nd Period

184 Case Study Data

1.11.21.32.12.22.31.11.21.32.12.22.31.11.21.32.12.22.32.41.11.21.31.42.12.22.31.11.21.32.12.22.32.41.11.21.32.12.22.32.42.52.62.72.81.11.21.32.12.22.31.11.21.32.12.22.32.41.11.21.32.12.22.31.11.21.32.12.22.31.11.21.32.12.22.32.4

Kappa

Lambda

Omega

Pi

Theta

Alpha

Beta

Delta

Epsilon

Gamma

Iota

I01-d I02-d I03-d I04-d I05-d I06-b I07-b I08-b I09-b I10-b I11-b I12-b I13-b I14-d I15-d136 50 86 3 52 12 9 34 11 9 21 33 48 75 6182 41 41 16 23 11 6 31 2 0 2 2 2 30 5215 6 9 0 3 3 0 5 0 0 0 0 0 4 1128 1 27 2 9 2 3 15 14 13 29 36 46 2 2623 8 15 15 7 4 3 11 44 33 77 26 33 1 2225 16 9 0 3 2 2 8 1 1 2 13 24 4 21

121 55 66 8 40 2 1 29 31 2 33 77 310 14 107116 50 66 18 49 0 0 8 44 4 49 37 125 18 98130 47 83 30 57 0 0 11 54 6 60 288 468 21 10947 17 30 11 20 1 3 6 5 0 5 34 99 12 3547 19 28 8 3 0 1 11 0 0 0 90 213 8 3946 5 41 7 26 0 1 0 2 0 2 29 71 6 4064 31 33 0 27 7 7 31 17 0 17 36 62 14 5030 10 20 14 5 0 2 3 3 0 3 36 45 13 1734 15 19 8 7 1 2 5 23 8 32 5 9 12 2231 14 17 1 23 2 4 13 4 0 4 46 71 7 2431 16 15 5 8 4 3 15 0 0 0 16 32 5 2622 2 20 0 4 2 3 7 1 1 2 13 13 8 1433 6 27 0 6 1 3 10 230 0 230 21 26 9 2414 7 7 9 0 0 1 18 0 0 0 2 3 3 1110 1 9 2 2 0 4 7 0 0 0 2 2 1 918 11 7 0 1 0 2 10 6 0 6 14 18 3 1512 7 5 7 1 0 1 1 0 0 0 9 9 1 1117 14 3 3 5 1 5 16 35 9 58 168 238 1 1619 13 6 10 3 3 5 22 6 1 7 33 42 1 1841 36 5 22 10 4 5 28 14 8 24 30 41 3 380 0 0 0 0 0 0 0 0 0 0 0 0 0 0

107 28 79 12 9 1 0 3 4 0 4 1 1 48 6049 25 24 43 3 0 0 0 0 0 0 1 1 19 3038 15 23 13 3 0 0 0 0 0 0 0 0 13 2538 11 27 14 1 0 1 5 0 0 0 0 0 19 1918 4 14 5 1 0 1 1 0 0 0 1 1 5 1362 21 41 30 9 0 0 0 0 0 0 0 0 31 3030 20 10 11 8 5 7 24 23 0 23 0 1 10 2062 24 38 10 6 2 15 34 9 2 11 2 19 22 400 0 0 0 0 0 0 0 0 0 0 0 0 0 0

12 7 5 2 1 7 7 28 0 0 0 4 5 0 120 0 0 0 0 18 6 31 0 0 0 4 6 0 01 1 0 3 0 0 1 1 4 0 4 5 0 0 1

13 5 8 4 10 1 5 16 0 0 0 0 1 2 112 1 1 1 0 0 4 9 0 0 0 0 0 0 24 0 4 0 0 0 0 0 0 0 0 3 4 0 43 0 3 0 2 2 5 11 0 0 0 1 1 0 30 0 0 0 0 0 1 1 0 0 0 125 126 0 0

39 25 14 25 27 0 0 6 3 0 3 15 25 17 2278 47 31 21 36 0 0 7 4 2 6 4 6 35 43

108 31 77 19 23 0 0 12 0 0 0 11 11 53 551 0 1 1 0 0 1 11 0 0 0 0 0 0 1

21 16 5 10 10 1 2 17 0 0 0 0 0 13 87 4 3 8 1 0 2 12 7 0 7 5 5 2 5

27 10 17 2 8 1 5 13 0 0 2 1 2 3 2418 12 6 1 4 1 3 4 3 0 3 2 2 7 115 3 2 0 3 0 3 4 0 0 0 3 3 0 5

22 12 10 0 4 2 6 10 33 16 57 7 15 8 1490 39 51 1 23 0 5 10 5 0 5 1 2 51 393 1 2 0 2 5 4 18 0 0 0 2 2 1 27 5 2 0 11 2 1 3 0 0 0 1 1 2 50 0 0 0 0 0 0 0 0 0 0 0 0 0 0

88 36 52 14 15 1 4 16 0 0 0 0 0 14 7485 36 49 13 6 8 4 21 0 0 0 0 0 6 7923 8 15 3 1 1 1 3 0 0 0 0 0 3 2090 51 39 39 27 0 5 12 20 1 33 0 0 9 81

135 72 63 19 60 13 10 55 0 0 0 0 0 15 12031 9 22 3 17 0 1 1 1 0 1 1 1 3 2841 14 27 0 9 1 0 2 2 0 2 2 2 9 3296 27 69 19 28 1 0 2 8 0 8 3 3 16 8010 5 5 0 0 1 0 1 0 0 0 0 0 1 938 8 29 7 12 2 0 4 3 2 5 51 338 9 3164 4 60 9 15 0 0 1 7 0 7 5 7 18 4617 12 5 4 0 0 1 1 0 0 0 4 4 4 1312 5 7 0 0 4 2 11 0 0 0 4 4 9 317 2 15 2 2 0 2 6 1 0 1 2 2 12 53 3 0 2 1 0 0 0 0 0 0 2 2 0 32 2 0 2 0 0 0 0 0 0 0 0 0 0 26 6 0 0 0 2 1 10 7 0 7 4 19 0 61 0 1 0 0 2 2 5 0 0 0 3 3 0 1

Individual Scores, 3rd Period

A.1. Individual Team Member Scores 185

186 Case Study Data

A.2 Team Level Scores

A.2. Team Level Scores 187

Table A.2. Team-level attributes queried from the generated Team Collaboration Networks.

ID Description

T01-d Number of distinct emails sentT02-d Number of distinct initiating emailsT03-d Number of distinct email repliesT04-d Number of attachments sent with distinct emailsT05-b Number of URLs in distinct emails

T01-d T02-d T03-d T04-d T05-b T01-d T02-d T03-d T04-d T05-b T01-d T02-d T03-d T04-d T05-b

Alpha 1 12 21 1 11 23 13 39 22 60 10 17 36 14 116

Beta 1 12 21 1 27 6 18 59 16 75 0 18 60 1 79

Delta 13 0 23 9 40 23 0 73 17 61 29 27 50 20 68

Epsilon 1 0 24 4 9 0 1 29 0 8 0 1 14 0 13

Gamma 13 1 15 11 38 11 1 38 7 29 5 3 71 5 135

Iota 3 0 16 3 11 1 0 44 9 46 2 2 24 8 34

Kappa 13 22 54 15 71 3 15 51 13 60 8 3 67 7 120

Lambda 8 5 18 4 24 54 1 81 24 77 19 13 72 15 72

Omega 5 0 18 7 24 6 0 24 8 36 18 3 21 21 47

Pi 33 3 37 29 49 33 1 38 20 32 36 0 39 22 56

Theta 4 1 16 2 6 17 3 17 17 23 10 7 50 9 25

Team Scores, 1st Period Team Scores, 2nd Period Team Scores, 3rd Period

B

Regression Analysis Results

Regression: Outbound Email Communication vs. Team Satisfaction

MethodVariables RemovedVariables Entered

1 Enter.Ratio_Ext_Int_TEAMa

ModelModel

Variables Entered/Removedb

a. All requested variables entered.

b. Dependent Variable: AVG_Hackmann_group_mean_neu

SUBGROUP_IDENTIFIER =

Stanford (11 cases) (Selected)

Std. Error of the EstimateAdjusted R SquareR Square

R

1 ,38568,206,285,534a

ModelModel

Model Summary

a. Predictors: (Constant), Ratio_Ext_Int_TEAM

Sig.FMean SquaredfSum of

Squares

Regression

Residual

Total

1

1 01,873

,14991,339

,091a

3,591,5341,534

ModelModel

ANOVAb

a. Predictors: (Constant), Ratio_Ext_Int_TEAM


Std. ErrorB Beta Sig.t VIFTolerance

Collinearity Statistics

Standardized CoefficientsUnstandardized Coefficients

(Constant)

Ratio_Ext_Int_TEAM

1

1,0001,000,0911,895,534,5281,000

,00016,572,2173,601

ModelModel

Coefficientsa

a. Dependent Variable: AVG_Hackmann_group_mean_neu

Condition IndexEigenvalue

Ratio_Ext_Int_TEAM(Constant)

Variance Proportions

1

2

1

,92,923,447,155

,08,081,0001,845

Model DimensionModel Dimension

Collinearity Diagnosticsa


Page 1

189

Regression: Outbound Email Communication and Teaching Team Involvement vs. Team Satisfaction

MethodVariables RemovedVariables Entered

1 Enter.No_of_distinct_emails_from_tteam_total, Ratio_Ext_Int_TEAM

a

ModelModel

Variables Entered/Removedb

a. All requested variables entered.


SUBGROUP_IDENTIFIER =

Stanford (11 cases) (Selected)

Std. Error of the EstimateAdjusted R SquareR Square

R

1 ,34923,349,479,692a

ModelModel

Model Summary

a. Predictors: (Constant), No_of_distinct_emails_from_tteam_total, Ratio_Ext_Int_TEAM

Sig.FMean SquaredfSum of Squares

Regression

Residual

Total

1

1 01,873

,1228,976

,074a

3,678,4492,897

ModelModel

ANOVAb

a. Predictors: (Constant), No_of_distinct_emails_from_tteam_total, Ratio_Ext_Int_TEAM


Std. ErrorB Beta Sig.t VIFTolerance

Collinearity Statistics

Standardized CoefficientsUnstandardized Coefficients

(Constant)

Ratio_Ext_Int_TEAM

No_of_distinct_emails_from_tteam_total

1

1,194,837,123-1 ,725- ,481,003- ,005

1,194,837,0312,611,728,5221,363

,00012,105,3364,072

ModelModel

Coefficientsa


Condition IndexEigenvalue

No_of_distinct_emails_from_tteam_

totalRatio_Ext_Int_TEAM(Constant)

Variance Proportions

1

2

3

1

,94,05,867,503,049

,05,92,133,991,174

,01,03,011,0002,776

Model DimensionModel Dimension

Collinearity Diagnosticsa


Page 1

190 Regression Analysis Results

C

d.store - API Reference

This section of the appendix documents the HTTP/1.1-based service in-terface of the d.store platform.

A.1

. Pla

tfo

rm I

nd

ex

UR

L P

att

ern

: http://<root>/[index]

The

pla

tfor

m in

dex

repr

esen

ts t

he r

oot

reso

urce

of t

he d

.stor

e ap

plic

atio

n. It

ser

ves

as a

n en

try

poin

t (i.

e. a

hom

e pa

ge fo

r H

TM

L cl

ient

s) b

y pr

ovid

ing

a br

ief o

verv

iew

of t

he

curr

ent

plat

form

sta

te a

nd/o

r us

er-r

elat

ed in

form

atio

n.

Re

pre

sen

tati

on

Typ

es:

te

xt/h

tml

appl

icat

ion/

json

G

ET

G

et t

he p

latf

orm

inde

x. T

he H

TM

L re

pres

enta

tion

of t

his

reso

urce

re

pres

ents

the

d.st

ore

hom

e pa

ge.

Que

ry P

aram

eter

s:

n/a

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

pla

tfor

m in

dex

with

bas

ic in

form

atio

n is

re

turn

ed.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

N

ot s

uppo

rted

A.2

. Ne

two

rk C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs

Rep

rese

nts

the

colle

ctio

n of

info

rmat

ion

netw

orks

man

aged

by

the

d.st

ore

serv

er in

stan

ce.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Not

impl

emen

ted

PU

T

Not

sup

port

ed

PO

ST

C

reat

e a

new

tea

m c

omm

unic

atio

n ne

twor

k re

sour

ce.

Que

ry P

aram

eter

s:

n/a

Supp

orte

d R

eque

st E

ntiti

es:

Co

nte

nt

Typ

e: ap

plic

atio

n/x-

ww

w-f

orm

-url

enco

ded

Fiel

d N

ame

Des

crip

tion

id*

a un

ique

net

wor

k id

entif

ier

la

bel

a re

adab

le la

bel f

or t

he n

etw

ork

desc

ript

ion

optio

nal n

otes

or

desc

ript

ion

Co

nte

nt

Typ

e: ap

plic

atio

n/js

on

{ id*

: st

ring,

l

abel

: st

ring,

d

escr

iptio

n :

strin

g }

a un

ique

net

wor

k id

entif

ier

a re

adab

le la

bel f

or t

he n

etw

ork

optio

nal n

otes

or

desc

ript

ion

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

201

– C

reat

ed

A r

esou

rce

for

a ne

w n

etw

ork

inst

ance

has

bee

n cr

eate

d w

ith t

he g

iven

ID.

400

– Ba

d R

eque

st

bad_

requ

est

Inco

mpl

ete

or m

alfo

rmed

req

uest

ent

ity.

DE

LE

TE

N

ot s

uppo

rted

192 d.store - API Reference

A.3

. Ne

two

rk I

nst

ance

UR

L P

att

ern

: http://<root>/graphs/<graph-id>

A n

etw

ork

inst

ance

rep

rese

nts

a te

am c

omm

unic

atio

n ne

twor

k co

nsis

ting

of r

esou

rces

(n

odes

) an

d th

eir

dire

cted

rel

atio

nshi

ps t

o ea

ch o

ther

(ed

ges)

.

Re

pre

sen

tati

on

Typ

es:

te

xt/h

tml

appl

icat

ion/

json

G

ET

R

etri

eve

stat

istic

al in

form

atio

n ab

out

a ne

twor

k in

stan

ce.

Que

ry P

aram

eter

s:

n/a

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k Ba

sic

info

rmat

ion

abou

t th

e ne

twor

k st

ate

is

retu

rned

.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

R

emov

e th

e ne

twor

k re

sour

ce a

nd a

ll ot

her

cont

aine

d re

sour

ces

from

the

sy

stem

.

Que

ry P

aram

eter

s:

n/a

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k T

he n

etw

ork

reso

urce

has

bee

n de

lete

d.

403

– Fo

rbid

den

Aut

hori

zatio

n fa

iled.

Insu

ffici

ent

user

rig

hts.

A.4

. No

de

In

stan

ce C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/resources[/<type-list>]

The

se r

esou

rces

rep

rese

nt a

col

lect

ion

of n

etw

ork

node

s. E

ach

node

inst

ance

rep

rese

nts

met

a-in

form

atio

n ab

out

a W

eb r

esou

rce

iden

tifie

d by

its

UR

L. T

he li

st o

f nod

es a

re

sour

ce r

epre

sent

s is

det

erm

ined

by

an o

ptio

nal l

ist

of c

onca

tena

ted

node

typ

es,

sepa

rate

d by

a ‘+

’ cha

ract

er (

enco

ded:

%2B

). T

his

defin

es a

n A

ND

filte

r on

ava

ilabl

e ne

twor

k no

de t

ypes

, mea

ning

tha

t on

ly t

hose

nod

e in

stan

ces

are

retu

rned

tha

t ar

e of

all

type

s m

entio

ned

in t

he li

st.

Re

pre

sen

tati

on

Typ

es:

te

xt/h

tml

appl

icat

ion/

json

ap

plic

atio

n/gr

aphm

l G

ET

G

et a

(fil

tere

d) li

st o

f nod

e in

stan

ces

for

this

net

wor

k. E

ach

inst

ance

re

pres

ents

con

text

ual m

eta-

info

rmat

ion

for

an a

rbitr

ary

reso

urce

on

the

Web

.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

star

t In

dex

of t

he fi

rst

node

inst

ance

in t

he t

otal

res

ult

set

that

is r

etur

ned

to t

he c

lient

.

limit

Max

imum

num

ber

of n

odes

to

retu

rn.

sort

Sp

ecifi

es t

he a

ttri

bute

to

whi

ch t

he n

ode

list

will

be

asso

rted

. Acc

epte

d va

lues

: ‘id

’ (de

faul

t), ‘

labe

l’,

‘pos

tdat

e’

dir

If om

itted

or

valu

e is

‘asc

’: so

rt r

esul

t lis

t in

as

cend

ing

orde

r. In

all

othe

r ca

ses:

sor

t th

e re

sult

list

in d

esce

ndin

g or

der.

rela

tions

D

efin

es t

he t

ype

of r

elat

ions

tha

t th

e pl

atfo

rm

shou

ld r

etur

n fo

r ea

ch r

esou

rce

in t

he r

esul

t se

t. If

unsp

ecifi

ed, n

o re

latio

ns w

ill b

e re

turn

ed.

Acc

epte

d va

lues

: ‘on

to’,’

grap

h’,’u

ser’,

’all’

.

attr

ibut

es

Def

ines

the

typ

e of

att

ribu

tes

that

the

pla

tfor

m

shou

ld r

etur

n fo

r ea

ch r

esou

rce

in t

he r

esul

t se

t. If

unsp

ecifi

ed, n

o at

trib

utes

will

be

retu

rned

. A

ccep

ted

valu

es: ‘

onto

’,’gr

aph’

,’use

r’,’a

ll’.

Serv

er R

espo

nse:

Res

pons

e C

ode

/ d.

stor

e St

atus

D

escr

iptio

n

200

– O

k A

(po

tent

ially

em

pty)

list

of n

etw

ork

node

s is

re

turn

ed.

193

retu

rned

.

404

– N

ot F

ound

un

know

n_re

sour

cecl

ass

The

list

of n

odes

is u

ndef

ined

bec

ause

at

leas

t on

e of

the

typ

es in

the

req

uest

ed t

ype

filte

r do

es n

ot

exis

t.

PU

T

Not

sup

port

ed

PO

ST

A

dd a

nod

e to

the

net

wor

k. T

his

crea

tes

a ne

w n

ode

reso

urce

to

repr

esen

t m

eta-

info

rmat

ion

abou

t an

othe

r re

sour

ce id

entif

ied

by t

he p

oste

d U

RL.

The

no

de is

mer

ged

into

the

net

wor

k of

exi

stin

g no

des

and

rela

tions

hips

bas

ed

on t

he a

ttri

bute

s an

d re

latio

ns t

hat

are

post

ed.

Que

ry P

aram

eter

s:

n/a

Req

uest

Rep

rese

ntat

ions

:

Co

nte

nt

Typ

e: ap

plic

atio

n/x-

ww

w-f

orm

-url

enco

ded

Fiel

d N

ame

Des

crip

tion

url*

th

e U

RL

of t

he a

nnot

ated

res

ourc

e

labe

l a

read

able

labe

l for

the

res

ourc

e no

_red

irec

t_ch

eck

prev

ent

the

d.st

ore

serv

er fr

om c

heck

ing

whe

ther

th

e gi

ven

UR

L is

red

irec

ting

to a

diff

eren

t lo

catio

n.

Co

nte

nt

Typ

e: ap

plic

atio

n/js

on

{ url

* : s

trin

g,

lab

el :

strin

g,

pos

tdat

e : s

trin

g,

not

es :

strin

g,

tag

s : s

trin

g,

att

ribu

tes

: arr

ay [

{

nam

e* :

strin

g,

v

alue

* : s

trin

g,

p

ostd

ate

: str

ing,

del

eted

ate

: str

ing

}, …

],

rel

atio

ns :

arra

y [

{

n

ame*

: st

ring,

tar

get*

: st

ring,

pos

tdat

e : s

trin

g,

d

elet

edat

e : s

trin

g }

, … ]

}

the

UR

L of

the

ann

otat

ed r

esou

rce

a re

adab

le la

bel f

or t

he r

esou

rce

ex

plic

itly

sets

the

nod

es’s

cre

atio

n tim

esta

mp

note

s or

des

crip

tion

spac

e-se

para

ted

list

of t

ag la

bels

to

be a

ssig

ned

a lis

t of

att

ribu

te in

stan

ces

the

attr

ibut

e’s

type

nam

e th

e at

trib

ute’

s va

lue

yyyy

-mm

-dd

hh:m

m:s

s yy

yy-m

m-d

d hh

:mm

:ss

a lis

t of

rel

atio

n in

stan

ces

the

rela

tion’

s ty

pe n

ame

the

rela

tion’

s ta

rget

UR

L or

nod

e in

dex

yyyy

-mm

-dd

hh:m

m:s

s yy

yy-m

m-d

d hh

:mm

:ss

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

201

– C

reat

ed

A n

ode

inst

ance

for

the

spec

ified

UR

L ha

s be

en

crea

ted

and

is a

cces

sibl

e us

ing

the

retu

rned

inde

x va

lue.

valu

e.

400

– Ba

d R

eque

st

bad_

requ

est

Inco

mpl

ete

or m

alfo

rmed

req

uest

ent

ity.

400

– Ba

d R

eque

st

Req

uest

Val

idat

ion

Det

ails

are

enc

lose

d in

the

res

pons

e en

tity.

403

– Fo

rbid

den

Aut

hori

zatio

n fa

iled.

Insu

ffici

ent

user

rig

hts.

DE

LE

TE

N

ot s

uppo

rted


A.5

. No

de

Typ

e C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/tags

Rep

rese

nts

the

colle

ctio

n of

ava

ilabl

e no

de t

ypes

in a

net

wor

k.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

a li

st o

f ava

ilabl

e no

de t

ypes

.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

type

Fi

lter

the

resu

lt se

t by

typ

e cl

ass.

Acc

epte

d pa

ram

eter

val

ues

are:

‘ont

o’ fo

r on

tolo

gy-d

efin

ed

type

s, ‘g

raph

’ for

gra

ph-le

vel t

ypes

, ‘us

er’ f

or u

ser-

defin

ed t

ypes

. By

defa

ult,

all n

ode

type

s w

ill b

e re

turn

ed.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

list

of a

vaila

ble

node

typ

es is

ret

urne

d.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

N

ot s

uppo

rted

A.6

. Att

rib

ute

Typ

e C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/attributes

Rep

rese

nts

the

colle

ctio

n of

att

ribu

te t

ypes

ava

ilabl

e in

a n

etw

ork.

An

attr

ibut

e is

a t

yped

, lit

eral

val

ue t

hat

can

be a

ttac

hed

to a

ny r

esou

rce

node

in a

tea

m c

omm

unic

atio

n ne

twor

k.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

a li

st o

f ava

ilabl

e at

trib

ute

type

s in

the

net

wor

k.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

type

Fi

lter

the

resu

lt se

t by

typ

e cl

ass.

Acc

epte

d pa

ram

eter

val

ues

are

‘ont

o’ fo

r on

tolo

gy-d

efin

ed

attr

ibut

es, ‘

grap

h’ fo

r gr

aph

attr

ibut

es, a

nd ‘u

ser’

for

user

-def

ined

att

ribu

tes.

By

defa

ult,

all a

ttri

bute

ty

pes

will

be

retu

rned

.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

list

of a

vaila

ble

attr

ibut

e ty

pes

is r

etur

ned.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

N

ot s

uppo

rted

195

A.7

. Re

lati

on

Typ

e C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/relations

Rep

rese

nts

the

colle

ctio

n of

rel

atio

n ty

pes

avai

labl

e in

a n

etw

ork.

A r

elat

ion

is a

typ

ed,

dire

cted

ass

ocia

tion

betw

een

two

reso

urce

nod

es o

f a t

eam

com

mun

icat

ion

netw

ork.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

a li

st o

f ava

ilabl

e re

latio

n ty

pes

in t

he n

etw

ork.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

type

Fi

lter

the

resu

lt se

t by

cla

ss t

ype.

Acc

epte

d pa

ram

eter

val

ues

are

‘ont

o’ fo

r on

tolo

gy r

elat

ions

, ‘g

raph

’ for

gra

ph r

elat

ions

, and

‘use

r’ fo

r us

er-

defin

ed r

elat

ions

. By

defa

ult,

all r

elat

ion

type

s w

ill

be r

etur

ned.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

list

of a

vaila

ble

rela

tion

type

s is

ret

urne

d.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

N

ot s

uppo

rted

A.8

. No

de

In

stan

ce

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/resources/<node-index>

Rep

rese

nts

a re

sour

ce n

ode

in t

he n

etw

ork.

Re

pre

sen

tati

on

Ty

pe

s:

text

/htm

l

appl

icat

ion/

json

ap

plic

atio

n/gr

aphm

l G

ET

G

et in

form

atio

n ab

out

an a

nnot

ated

res

ourc

e, s

uch

as t

ypes

, att

ribu

tes,

and

re

latio

nshi

ps t

o ot

her

reso

urce

s.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

rela

tions

Sp

ecify

the

typ

e of

nod

e re

latio

ns t

hat

the

plat

form

sh

ould

ret

urn

for

this

req

uest

. By

defa

ult,

no

rela

tions

are

ret

urne

d. A

ccep

ted

valu

es a

re:

‘ont

o’,’g

raph

’,’us

er’,’

all’.

attr

ibut

es

Spec

ify t

he t

ype

of n

ode

attr

ibut

es t

hat

the

plat

form

sho

uld

retu

rn fo

r th

is r

eque

st. B

y de

faul

t, no

att

ribu

tes

are

retu

rned

. Acc

epte

d va

lues

are

: ‘o

nto’

,’gra

ph’,’

user

’,’al

l’.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k M

eta-

info

rmat

ion

abou

t th

e re

sour

ce r

epre

sent

ed b

y th

is n

ode

is r

etur

ned.

Res

ourc

e R

epre

sent

atio

ns:

Co

nte

nt

Typ

e: ap

plic

atio

n/js

on

{ ind

ex :

num

ber,

url

: st

ring,

l

abel

: st

ring,

n

otes

: st

ring,

p

ostd

ate

: str

ing,

d

elet

edat

e : s

trin

g,

ont

otyp

es :

arra

y,

gra

phty

pes

: arr

ay,

use

rtyp

es :

arra

y,

att

ribu

tes

: arr

ay [

{

nam

e : s

trin

g,

t

ype

: str

ing,

val

ue :

strin

g }

, … ]

, r

elat

ions

: ar

ray

[ {

nam

e : s

trin

g,

t

ype

: str

ing,

val

ue :

strin

g }

, … ]

}

the

uniq

ue n

ode

inde

x th

e an

nota

ted

reso

urce

a

read

able

res

ourc

e la

bel

note

s/de

scri

ptio

n no

de c

reat

ion

date

no

de d

elet

ion

data

on

tolo

gy t

ype

inst

ance

s gr

aph

type

inst

ance

s us

er t

ype

inst

ance

s ar

ray

of a

ttri

bute

inst

ance

s th

e at

trib

ute’

s ty

pe n

ame

‘ont

o’, ’

grap

h’, o

r ’u

ser’

arra

y of

rel

atio

n in

stan

ces


rel

atio

ns :

arra

y [

{

n

ame

: str

ing,

typ

e : s

trin

g,

v

alue

: st

ring

}, …

]

}

arra

y of

rel

atio

n in

stan

ces

PU

T

Upd

ate

the

prop

ertie

s of

a n

ode

inst

ance

. Any

fiel

d co

ntai

ned

in t

he r

eque

st

entit

y w

ill b

e up

date

d w

ith t

he a

ccor

ding

val

ues.

The

sta

te o

f any

fiel

d th

at is

om

itted

in t

he r

eque

st w

ill r

emai

n un

chan

ged.

Que

ry P

aram

eter

s:

n/a

Req

uest

Rep

rese

ntat

ions

:

Co

nte

nt

Typ

e: ap

plic

atio

n/x-

ww

w-f

orm

-url

enco

ded

Fiel

d N

ame

Des

crip

tion

labe

l a

read

able

res

ourc

e la

bel

note

s no

tes

or d

escr

iptio

n C

on

ten

t T

yp

e: ap

plic

atio

n/js

on

{ lab

el :

strin

g,

pos

tdat

e : s

trin

g,

not

es :

strin

g,

typ

es :

strin

g,

att

ribu

tes

: arr

ay [

{

nam

e : s

trin

g,

v

alue

: st

ring,

pos

tdat

e : s

trin

g,

d

elet

edat

e : s

trin

g }

, … ]

, r

elat

ions

: ar

ray

[ {

nam

e : s

trin

g,

t

arge

t : s

trin

g,

p

ostd

ate

: str

ing,

del

eted

ate

: str

ing

}, …

]

}

a re

adab

le r

esou

rce

labe

l ex

plic

itly

sets

the

nod

es’s

cre

atio

n tim

esta

mp

note

s or

des

crip

tion

spac

e-se

para

ted

list

of t

ype

labe

ls t

o be

ass

igne

d a

list

of a

ttri

bute

inst

ance

s an

att

ribu

te’s

typ

e na

me

an a

ttri

bute

’s v

alue

yy

yy-m

m-d

d hh

:mm

:ss

yyyy

-mm

-dd

hh:m

m:s

s a

list

of r

elat

ion

inst

ance

s a

rela

tion’

s ty

pe n

ame

a

rela

tion’

s ta

rget

UR

L or

nod

e in

dex

yyyy

-mm

-dd

hh:m

m:s

s yy

yy-m

m-d

d hh

:mm

:ss

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k T

he n

ode

has

been

upd

ated

with

the

pro

pert

y va

lues

incl

uded

in t

he r

eque

st e

ntity

.

400

– Ba

d R

eque

st

bad_

requ

est

Inco

mpl

ete

or m

alfo

rmed

req

uest

ent

ity.

400

– Ba

d R

eque

st

Req

uest

Val

idat

ion

Det

ails

are

enc

lose

d in

the

rep

rese

ntat

ion.

403

– Fo

rbid

den

Aut

hori

zatio

n fa

iled.

Insu

ffici

ent

user

rig

hts.

PO

ST

N

ot s

uppo

rted

DE

LE

TE

R

emov

e th

e no

de a

long

with

any

ass

ocia

ted

attr

ibut

es a

nd in

com

ing

or

outg

oing

rel

atio

ns fr

om t

he n

etw

ork.

Que

ry P

aram

eter

s:

n/a

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k T

he n

ode

has

been

del

eted

.

403

– Fo

rbid

den

Aut

hori

zatio

n fa

iled.

Insu

ffici

ent

user

rig

hts.

197

A.9

. No

de

Att

rib

ute

Co

lle

ctio

n

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/resources/<instance-id>/attributes

Rep

rese

nts

the

colle

ctio

n of

att

ribu

tes

assi

gned

to

a ne

twor

k no

de in

stan

ce.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

a li

st o

f att

ribu

tes

assi

gned

to

a no

de.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

type

Fi

lter

the

resu

lt se

t by

typ

e cl

ass.

Acc

epte

d pa

ram

eter

val

ues

are

‘ont

o’ fo

r on

tolo

gy a

ttri

bute

s,

‘gra

ph’ f

or g

raph

att

ribu

tes,

and

‘use

r’ fo

r us

er-

defin

ed a

ttri

bute

s. B

y de

faul

t, al

l att

ribu

te t

ypes

will

be

ret

urne

d.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

list

of a

ttri

bute

inst

ance

s is

ret

urne

d.

PU

T

Not

sup

port

ed

PO

ST

N

ot im

plem

ente

d

DE

LE

TE

N

ot s

uppo

rted

A.1

0. N

od

e R

ela

tio

n C

oll

ect

ion

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/resources/<instance-id>/relations

Rep

rese

nts

the

colle

ctio

n of

out

goin

g re

latio

ns d

efin

ed fo

r a

reso

urce

(no

de).

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

a li

st o

f rel

atio

ns fo

r th

is r

esou

rce

node

.

Que

ry P

aram

eter

s:

Para

met

er

Des

crip

tion

type

Fi

lter

the

resu

lt se

t by

typ

e cl

ass.

Acc

epte

d pa

ram

eter

val

ues

are

‘ont

o’ fo

r on

tolo

gy r

elat

ions

, ‘g

raph

’ for

gra

ph r

elat

ions

, and

‘use

r’ fo

r us

er-

defin

ed r

elat

ions

. If u

nspe

cifie

d, a

ll re

latio

ns w

ill b

e re

turn

ed.

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k A

list

of r

elat

ions

to

othe

r re

sour

ces

is r

etur

ned.

PU

T

Not

sup

port

ed

PO

ST

N

ot im

plem

ente

d

DE

LE

TE

N

ot s

uppo

rted


A.1

1. N

od

e T

yp

e

UR

L P

att

ern

: http://<root>/graphs/<graph-id>/tags/<type-id>

Rep

rese

nts

a no

de t

ype.

Dep

endi

ng o

n th

e ne

twor

k co

nfig

urat

ion,

eve

ry t

ype

is o

f one

of

the

clas

s on

tolo

gy, g

raph

, or

user

. Ont

olog

y ty

pes

are

defin

ed in

one

of t

he p

re-d

efin

ed

team

com

mun

icat

ion

onto

logi

es. G

raph

typ

es a

re im

port

ed fr

om o

ther

ont

olog

ies

on

netw

ork-

spec

ific

leve

l. U

ser

type

s ar

e cu

stom

typ

es t

hat

are

crea

ted

by c

lient

s at

run

-tim

e.

Re

pre

sen

tati

on

Typ

es:

ap

plic

atio

n/js

on

GE

T

Get

info

rmat

ion

abou

t a

node

typ

e

Que

ry P

aram

eter

s:

n/a

Serv

er R

espo

nse:

Res

pons

e C

ode

Des

crip

tion

200

– O

k In

form

atio

n ab

out

the

type

is r

etur

ned.

PU

T

Not

sup

port

ed

PO

ST

N

ot s

uppo

rted

DE

LE

TE

N

ot im

plem

ente

d

199

Acronyms

ABox Assertional BoxALM Application Lifecycle ManagementAPI Application Programming Interface

CAD Computer-aided DesignCSCW Computer-supported Cooperative Work

FEI Front End of InnovationFFE Fuzzy Front End

HTML Hypertext Markup LanguageHTTP Hypertext Transfer Protocol

ICT Information and Communication TechnologyISO International Organization for Standardization

JSON JavaScript Object Notation

KB Knowledge Base

NPPD New Product & Process Development

OWL OWL Web Ontology Language

RDBMS Relational Database Management SystemRDF Resource Description FrameworkRDFS Resource Description Framework SchemaREST Representational State TransferRPC Remote Procedure Call

Acronyms 201

SOA Service-oriented ArchitectureSPARQL SPARQL Protocol and RDF Query LanguageSQL Structured Query LanguageSWRL Semantic Web Rule Language

TBox Terminological BoxTCN Team Collaboration NetworkTCN-S Team Collaboration Network System

UCD User-centered DesignURI Uniform Resource IdentifierURL Uniform Resource Locator

VoIP Voice over Internet Protocol

W3C World Wide Web ConsortiumWebDAV Web-based Distributed Authoring and VersioningWWW World Wide Web

XML Extensible Markup Language

Glossary

Architectural StyleA coordinated set of architectural constraints that restricts the roles/fea-tures of architectural elements and the allowed relationships amongthose elements within any architecture that conforms to that style.

Computer-supported Cooperative Work (CSCW)Computer-assisted coordinated activity carried out by groups of collab-orating individuals.

Engineering Design(also: conceptual design, design) Comprises the team-based and inter-disciplinary activities during the early stages of an engineering project,in which opportunities and innovative concepts for a new product, soft-ware, or service are ideated, (re-)designed, and conceptualized.

Front End of Innovation (FEI)(also: Fuzzy Front End, FFE) Design activities that take place prior tothe formal, well-structured new product and process development.

GroupwareComputer-based systems that support groups of people engaged in acommon task or goal and that provide an interface to a shared envi-ronment.

ResourceAnything that is important enough to be referenced as a thing itself.Resources have a globally shared request message classification systemcalled uniform interface and are addressable via uniform resource iden-tifiers.

ServiceA distinct part of the functionality that is provided by an entity throughinterfaces, whereby an interface is a named set of operations that char-acterize the behavior of an entity.

Glossary 203

Team Collaboration NetworkTeam Collaboration Networks (TCNs) are the formalization of (virtual)collaboration activities in engineering design teams. A TCN definesthe semantics and the occurrences of relationships between individualsand/or collaboration resources.

Virtual CollaborationTwo or more people working together to accomplish a task without theuse of face to face interaction. Tasks and activities carried out with thehelp of information and communication technology.

Virtual TeamA group of collaborating individuals whose members are mediated bytime, distance, or technology.

Index

ABox, 76ALM, 41architecture, 52, 89

client-server, 89resource-oriented, 53service-oriented, 52style, 52

class extension, 61collaboration

metric, 1process, 1tools, 5virtual, 2

component, 51CSCW, 1, 3, 34

d.store, 89design rationale, 35Design Thinking, 3

formal system, 58

graph, 60groupware, 3, 35

HTTP, 92

inference rule, 59innovation, 2instance, 61instrumentation, 1, 4

Jena, 90JSON, 92

namespace, 60no-overwrite, 98notation, 62

ontology, 59organizational memory, 35OWL, 58, 61–62, 72

notation, 62

prefix, 60

provenance, 94

RDF, 58–61graph, 60notation, 62Schema, 58statement, 60triple, 60

RDFS, 58reification, 94representation, 54resource, 54

descriptive, 56REST, 53–56, 89

Semantic Web, 58semantics, 58service, 52

interface, 89orientation, 7platform, 53

SOA, 52statement, 60subsystem, 51system, 51

formal, 58

TBox, 73Team Collaboration Network, 67, 79

definition, 68system (TCN-S), 79validity, 68

time travel, 98time-point query, 100triple, 60triple store, 94

URI, 58, 60User-centered Design, 3

validity, 68, 91virtual team, 31

XML, 58

monitoring virtual team collaboration: methods...

Documents