the dynamic community visualisation (dcv) prototype

Figure 6.3: The Programme View of the RTÉ Xplorer Prototype Application.

Furthermore, this prototype uses the same community detection method in the Whassappi!

prototype (the OSLOM method), therefore it also suffers from the same limitations. OSLOM is a non time-aware modularity scoring function with a weakness for the sparsity of Twitter data.

6.3 the dynamic community visualisation (dcv) prototype

One of the most interesting aspects of community detection for decision makers is the ability to visualise how their managed communities evolve in time. However, most community finding approaches are unable to generate such view directly and instead focus on being able to discover independent sets of communities statically at fixed periods. Fortunately, user community track-ing algorithms exist [GDC10] that can analyse the discovered communities between consecutive time steps and identify connections between past and current configurations.

Using such tracking algorithms, a visualisation tool was developed [HH18b]⁶for extracting dynamic tracking information for a set of discovered user communities to display their evolution based on different types of dynamic events that can occur: birth, grow, shrink, intermittence, split, merge, death, and attribute change, e.g. the community topic. The proposed workflow can be seen in Figure 6.4. First, the user chooses a community detection approach suitable for the dataset under study and extract sets of independent static communities Ct,ifor consecutive time

6 Available in:https://uimr.insight-centre.org/dcv/

steps t using any desired granularity, e.g. hourly or daily. With these static step communities, the user applies the Tracker dynamic community tracking approach from Greene, Doyle, and Cunningham [GDC10] to obtain dynamic timelines that relate step communities to each other in time considering the defined evolutionary events. Finally, the user applies the Tracker2Vis post-processing algorithm [HH18b] to compute additional evolutionary events, i.e. expansion, contraction and attribute change, and generate the complete visualisation information necessary for the interactive user interface.

TRACKERAlgorithm Greene et al.

Independent static “communities”

are found by a certain algorithm for different time steps t_i t₀ t₁ t₂

Dynamic communities “timelines” are computed across consecutive time steps (t_i-1,t_i)

containing implicit evolutionary events t₀

t₁

t₂

TRACKER2VISAlgorithm Hromic et al.

Arbitrary Community Detection Algorithm

Explicit evolutionary events are computed for visualisation such as merging, change of topic and birth

t₀ t₁ t₂

Figure 6.4: Usage workflow for visualising dynamic communities with the DCV Prototype Application.

The Tracker method is based on the Jaccard similarity metric to compare “communities”

across time steps, making this tracking approach highly convenient and flexible. Any group-like structure can be used in the DCV prototype and, despite the visualisation being designed towards community analytics, it is not strictly restricted only to this use case. In Figure6.5, all of the supported evolutionary events in a synthetic set of user communities can be seen.

Figure 6.5: Example Dynamic Timeline of the DCV Prototype Application.

6.3 the dynamic community visualisation (dcv) prototype 121

Four example dynamic community timelines can be seen named from M1 to M4. For each timeline Mi, static step communities Ci,texist with a particular topic label L in each time step t.

Topic labels are represented with unique colours that can change in time. The extraction of topic labels is not restricted to any particular method. For example, in the RTÉ Xplorer prototype these topic labels can be mapped to RTÉ programmes associated to Tweets of the community, and for Whassappi!, the topic labels can be extracted using the most frequent hashtags in the community.

Furthermore, the grow and shrink is visualised using green and red over-lines respectively between two consecutive static community steps Ci,t, Ci,t+1. If the users of a static step com-munity Ci,tsplit, this is represented by a dashed line from the community to the new dynamic community these users migrated into. Likewise, if the members of a static step communities C_i,tin a dynamic community Mijoin another existing dynamic community Mjin a consecutive time step Cj,t+1, this is represented by a dashed line starting from the community that is joining to the merged community in the next time step. An example of these two events can be seen in the dynamic community M3 at the second static step community C3,2, where a portion of the users created a new dynamic community M4, and later joined the dynamic community M2.

6.3.1 Limitations of the Application

The DCV visualisation tool can provide a big picture of the evolution in time of a managed set of communities, however some limitations exist. While the visualisation is independent of the underlying community detection method used, the quality of the extracted dynamic events is subject to the quality of the detection approach and its robustness to the type of data being processed. An illustration of this using a real-world use case is in Figure6.6, where the DCV prototype was applied to a Twitter dataset from the RTÉ Xplorer prototype system.

In this example, only dynamic communities with at least three static community steps are displayed. The community topic label (and colour) corresponds to the RTÉ programme that was referenced the most in each static community step. It can be observed that some dynamic communities such as M3, M27and M29are steady and stable in time, while others such as M12, M₁₄, M21 and M26 result in quite intermittent dynamic communities. After manual examina-tion of these cases, it is revealed that there are very short-lived communities, as identified by the OSLOM method, however these communities tend to re-emerge later as new dynamic communi-ties. This observation recurs in many other extracted dynamic communities in this dataset, and is not a desired behaviour as it can be misleading to the decision maker, who for example could

Figure 6.6: The DCV Prototype Application applied to RTÉ Twitter Data.

conclude that these short-lived communities are individual groups that are not performing well, while in fact they have been inaccurately detected as a single community.

Overall, further examination using the DCV visualisation tool suggests to the analyst that an alternative detection method might be necessary for the RTÉ Xplorer prototype. In particular, one that is more robust to the highly dynamic nature of the microblogging platform. While the original work from Greene, Doyle, and Cunningham reported good performance with tra-ditional community detection methods on classic social media datasets, in the case of Twitter microblogging data the approach requires a method that is more robust to the highly dynamic nature of microblogging, as demonstrated in Chapter4.