AnalyzeD - A Virtual Design Observatory
is a virtual collaboration analysis tool, that allows researchers and practitioners to easily capture, aggregate, and analyze artifacts of collaboration tool usage. It consists of two components: a local analysis platform that can be deployed at the respective universities and companies, and a shared repository that connects the local platforms and allows the users to share indicators for detrimental or beneficial collaboration behavior.
Local Analysis Platform
The local analysis component of AnalyzeD
is presented in detail below. It consists of three components. Firstly, specialized sensor clients capture collaboration events from the groupware landscape. For each used groupware tool, a specialized sensor client needs to be available. Regardless of the parsed systems, each client needs to implement an interface that allows the "Configuration and Control Service" to get basic information about required input parameters, to invoke the client, and to retrieve the results, i.e., the parsed collaboration events, in a common format. Thus, the system remains adaptable to newly created groupware tools.
The data returned by the sensor clients is being aggregated into so-called Team Collaboration Networks (TCN). These networks are built upon ontologies that represent concepts of different collaboration tools, such as wikis, email lists, or version control systems. Thereby, the system can easily be extended just by creating a new ontology if new tools for collaboration are created that differ conceptually from the tools we know today. All nodes of the TCN can be linked by relations. Hence, these networks provide a holistic view that, for example, can model links from revisions to bug tracking items or from emails to wiki pages and allows to analyze whether the occurrence of such links might affect team collaboration. The TCN are stored within an off-the-shelf graph database.
The ontology-based system allows to add additional information to the TCN without having to change underlying data structures. If needed, new concepts or additions to existing ones can be modeled by means of an ontology, which then needs to be uploaded to the local analysis component. After that, sensor clients can be used to upload the corresponding data, e.g. calendar events, questionnaires filled out by project participants, or assessments of group or individual performance, and integrate it into the TCN. While currently not implemented, upcoming versions of the shared repository will allow users to upload these extension ontologies, too.
Analysis of the TCN can be performed by utilizing a SPARQL endpoint, which is offered by the underlying graph database, or by using RDF/OWL compatible visualization and analysis tools.
Analysis of said networks usually reveals reoccurring subgraphs that either have a direct impact on team performance or at least provide indicators for ongoing beneficial or detrimental collaboration behavior within the observed project teams. We formally described how to model such abstract subgraphs. In addition to the formal definition, we provided a graphical notation that allows to specify said behavioral snippets in a more accessible fashion.
The picture above presents an example of this graphical notation containing all possible building blocks. Nodes are represented as circles that are labeled with possible classes of the node. The label can be extended by a set of valid tags for a node, which is depicted in squared brackets. Relations between nodes are represented by solid, directed edges.
The label of an edge denotes the name of the relation and optionally defines cardinality constraints. Sequences can be expressed by dashed edges that connect two relations. Finally, attribute constraints are expressed within a separate rectangle that is attached to the respective node. Attribute constraints can be defined using SPARQL syntax.
As depicted in the architecture overview (see below), we created a graphical editor ("Visual Creator") for this notation. Thereby, users of the systems are able to model behavioral snippets that represent, for example, learning goals within their classes. The graphical notations are translated into SPARQL queries for the purpose of detecting occurrences of the described behavior within the TCN under investigation. The "Matcher" component thereby takes into account characteristics of the respective networks and adopts cardinalities or terminology of tags. Finally, the "Observer" component allows to constantly monitor TCN for such occurrences and notify the user about newly detected instances. In combination, these components can serve as a freely configurable project management dashboard that simplifies the detection of indicators for desired or unwanted behavior within the monitored projects.
The currently is being prepared for open source publication. Please contact us via email if you are interested in using the system within your projects.
For further questions please contact Thomas Kowark
| Thomas Kowark, M. Sc.
| Phone: +49 (331) 5509-1317
| E-mail: thomas.kowark (at) hpi.uni-potsdam.de
| Room: V-0.19