Event colligation

The next step is to identify theoretically meaningful events from the incident data. There is a particular kind of relationship between incidents and events. As noted above, incidents are descriptions of happenings, documentary records of occurrences, and are raw data. In contrast, an event is a theoretical construct (Abbott, 1984), built upon a systematic interpretation of what is relevant to the process. As such the stream of incidents, a first order construction, needs to be translated into a sequence of events, a second-order construction (Poole et al., 2000).

However, events may vary in several respects, as they may differ in temporal duration, may overlap or nest, and may also differ in spatial extension (Poole et al., 2000). That events may differ in temporal and spatial scope suggests that incidents may well indicate more than one overlapping event.

Events may be embedded within other different types of events of larger scope. Here both event levels may be important for understanding the change process, because interleaving narratives may clarify the emergence process better than either narrative could on its own. Another complication is that the event-incident relationship may change over time (Abbott, 1984). Just as the significance of events may change as a process unfolds, so can the relationship between an incident and event change. As a consequence, incident indicators can correspond to a theoretical construct in a variety of ways: some are better representatives than others, and some are easier to measure or detect (Poole et al., 2000).

To identify events from a collection of incidents requires colligation, which can be formally defined as the combination of incidents into an emergent whole (Abbott, 1984; McCullagh, 1978;

Walsh, 1958; Whewell, 1847). The task of colligation involves three essential parts (Abbott, 1984, 1990b).⁷

The first part of colligation involves identifying the levels of analysis within which a coherent story can be told. Each level of analysis is a social level-of-action on which the story events for that level occur (Abbott, 1990b). These levels of analysis are also those where one can conceive of coherent cases for the stories (Abbott, 1984). Based upon our identification above of the central subject, relevant levels of analysis include the ecosystem, the digital service, the organisation that provides that service, and the wider contextual environment, such as competitors and wider societal institutional events. The level of incident was applied univocally; for an incident to act as an indicator of an event requires the incident to be applicable at a single level (Abbott, 1984). The decision rules for the classification of an incident into a level are detailed in Table 11 on the following page.

The second part of colligation is substantive colligation, or deciding the substantive story at each of those levels (Abbott, 1984). This consists of assembling the narrative by deciding its essential events at each of those levels and ensuring the same event granularity at each level (Abbott, 1984, 1990a).

There are a number of approaches to formally map indicators to events, including giving all indicators an equal weight, considering each indicator on a case-by-case basis, or using some measure of central tendency (Abbott, 1984). Following Poole et al. (2000) the first and third strategies were adopted for initial classification, and the second strategy then used to adjust the initial classification to one that was meaningful within the context of the case. This means that conceptual and practical reasoning are used to correct the bluntness of the objective rules.

In order to construct an event from a set of incidents, clear and rigorous decision rules are required to so that high construct validity can be achieved. Table 12, also on the following page, details the decision rules that govern the indication of an event. These rules utilise a triangulation logic between differing indicators to ensure additional reliability (Jick, 1979; Yin, 1984).

7 The reliability of the colligation process should also be tested (Poole et al, 2000), something that has not been carried out in this research. This requires testing the unitising reliability, or the consistency in dividing the stream of activity into units. The main technique is to use a second researcher to ensure that decision rules are consistently interpreted.

Table 11 – Decision rules for levels of incidents

Level Organisation Service Ecosystem Context

Definition An incident that relates to the organisation that controls the digital service

An incident that relates to

the digital service An incident that relates to the participants that interact

Table 12 – Event colligation indication decision rules

• When an incident was deemed worthy of a press release, newsletter or some other public broadcast or publication by the hub firm, then there is an indicator of an event.

• When an incident is named as critical by an ecosystem participant, then there is an indicator of an event.

• When an incident is named as a ‘milestone’ by a participant, then there is an indicator of an event.

• Where there is a change in the functionality of the digital service, the capability of the hub firm or the environment in which the ecosystem resides, then there is an indicator of an event.

• When an incident is mentioned more than once from differing data sources, then there is an indicator of an event.

As the goal is to create a series of events which all have the same approximate granularity, additional decision rules are required when there are multiple indicators that occur on a given day. The following rules described in Table 13 below apply in the decision to construct an event from a single incident or multiple incidents.

Table 13 – Event colligation multiple indicator decision rules

• When multiple indicators occur on the same day, if these are the same incident then they are joined together into the same event.

• When multiple indicators occur on the same day which are not exactly the same but are closely related, where logical, these should be joined together into the same event. For instance, if three new technical features are released on the same day, then these can be colligated into the same event. However, if there is a technical feature and a new pricing policy on the same day, then these should be considered separate events.

• When there is a series of indicators over differing dates that can be better considered as a single event, then these should also be joined into a single event. Here the decision rule is “do these indicators together cover a single event in relation to ecosystem emergence?” In general these incidents should not run over a long time period, say 4 months, but should be clustered around a number of closely spaced days. The date assigned should correspond to the emphasis of the event.

For instance, a series of articles in the press over a couple of days can be reduced to a single press event. Here the date of the event would the publication of the first article. Similarly a series of meetings and activities which result in a failed or successful funding or acquisition can be considered the one event, however here the date should be that which concludes the incident as all other lead to that date.

The third part of colligation concerns the analysis of the formal qualities of each event (Abbott, 1984). The first formal quality is duration, which has been discussed earlier, and is obviously an issue when there are events occurring at differing levels. The second formal quality is dispersion, where an event propagates from one level of analysis to another, and need to be carefully noted. However this is done, Abbott (1984) points out that the final colligation should be coherent in both its limitation to the level of analysis and by extension to the participants in the event, and the pattern of links between events must be closed, although external antecedent events may be allowed. Here event duration was noted on each event.

Table 14 below details the number of events colligated for each case.

Table 14 – Event and incident counts

Amazon eBay Facebook Google Salesforce Wikipedia

Incidents 1246 796 888 918 941 1005

Events 674 483 520 568 721 710

As can be observed, the dispersion between the numbers of events for each case has decreased as compared to the dispersion for incidents. Again, it is important to emphasise that the list of events is only a sample of the events that can be identified.