exploring.rmd

---
title: Exploring event data
output: 
  html_document:
    toc: true
    toc_depth: 3
    toc_float: 
      collapsed: false
      print: false
---
```{r echo = F}
htmltools::includeHTML("tracking_google_analytics.html")
```

```{r include = F}
library(bupaR)
```


The metrics for exploring and describing event data which are available are based on literature in the field of operational excellence and are organized in the following (sub)categories

*	Time perspective
*	Organizational perspective
*	Structuredness perspective
	*	Variance
	*	Rework
	
## Time perspective

Three different time metrics can be computed:

*	throughput time: the time between the very first event of the case and the very last
*	processing time: the sum of the duration of all activity instances
*	idle time: the time when no activity instance is active

The duration of an activity instance is the time between the first and the last event related to that activity instance. In case several activity instances within a case overlap, processing time for that overlap will be counted twice. The figure below shows a schematic overview of different time metrics. 

```{r echo = F}
knitr::include_graphics("images/processingtime.PNG")
```





#### Idle Time

The idle time is the time that there is no activity in a case or for a resource. It can only be calculated when there are both start and end timestamps available for activity instances. It can be computed at the levels trace, resource, case and log, and using different time units.

```{r}
patients %>%
	idle_time("resource", units = "days")
```

The output of __all__ metrics in edeaR can be visualized by supplying it to the plot function.

```{r}
patients %>%
	idle_time("resource", units = "days") %>%
	plot()
```

#### Processing Time

The processing time can be computed at the levels log, trace, case, activity and resource-activity. It can only be calculated when there are both start and end timestamps available for activity instances.

```{r}
patients %>% 
	processing_time("activity") %>%
	plot
```

#### Throughput Time

The throughput time is the time form the very first event to the last event of a case. The levels at which it can be computed are log, trace, or case.

```{r}
patients %>%
	throughput_time("log") %>%
	plot()
```


## Organizational Perspective

#### Resource Frequency

The resource frequency metric allows the computation of the number/frequency of resources at the levels of log, case, activity, resource, and resource-activity.

```{r}
patients %>%
	resource_frequency("resource")
```

#### Resource Involvement

Resource involvement refers to the notion of the number of cases in which a resource is involved. It can be computed at levels case, resource, and resource-activity. 

```{r}
patients %>%
	resource_involvement("resource") %>% plot
```
It this example it shows that only r1 and r2 are involved in all cases, r6 and r7 are involved in most of the cases, while the others are only involved in half of the cases, more or less.


#### Resource Specialization

The resource specalization metric shows whether resources are specialized in certain activities or not. It can be calculated at the levels log, case, resource and activity.

```{r}
patients %>%
	resource_specialisation("resource")
```
In the simple patients event log, each resource is performing exactly one activity, and is therefore 100% specialized.

## Structuredness

### Variance

#### Activity Presence

Activity presence shows in what percentage of cases an activity is present. It has no level-argument.

```{r}
patients %>% activity_presence() %>%
	plot
```


#### Activity Frequency

The frequency of activities can be calculated using the activity_frequency function, at the levels log, trace and activity.

```{r}
patients %>%
	activity_frequency("activity")
```

#### Start Activities

The start of cases can be described using the start_activities function. Available levels are activity, case, log, resource and resource activity.

```{r}
patients %>%
	start_activities("resource-activity")
```

This shows that in this event log, all cases are started with the Registration by resource r1.

#### End Activities

Conversely, the end_activities functions describes the end of cases, using the same levels: log, case, activity, resource and resource-activity.

```{r}
patients %>%
	end_activities("resource-activity")
```
In contract to the start of cases, the end of cases seems to differ more frequently, although it is mostly the Check-Out activity.

#### Trace Coverage

The trace coverage metric shows the relationship between the number of different activity sequences (i.e. traces) and the number of cases they cover.

```{r}
patients %>%
	trace_coverage("trace") %>%
	plot()
```

In the patients log, there are only 7 different traces, and 2 of them cover nearly 100% of the event log.

#### Trace Length

The trace length metric describes the length of traces, i.e. the number of activity instances for each case. It can be computed at the levels case, trace and log.

```{r}
patients %>%
	trace_length("log") %>%
	plot
```

It can be seen that in this simple event log, most cases have a trace length of 5 or 6, while a minority has a trace length lower than 5.

### Rework

Documentation coming soon


```{r echo = F, eval = F}

### Rework

#### Number of selfloops

A selfloop occurs when an activity is immediatey

#### Size of selfloops
#### Referral matrix selfloops
#### Number of repetitions
#### Size of repetitions
#### Referral matrix repetitions
```