diff --git a/.github/workflows/docs.yaml b/.github/workflows/docs.yaml
index 80d7fb43..a50cf292 100644
--- a/.github/workflows/docs.yaml
+++ b/.github/workflows/docs.yaml
@@ -2,7 +2,7 @@ name: docs
on:
push:
branches:
- - day_segments
+ - time_segments
jobs:
deploy:
runs-on: ubuntu-latest
diff --git a/.gitignore b/.gitignore
index d0920998..60899167 100644
--- a/.gitignore
+++ b/.gitignore
@@ -95,7 +95,7 @@ packrat/*
data/external/*
!/data/external/.gitkeep
!/data/external/stachl_application_genre_catalogue.csv
-!/data/external/daysegments*.csv
+!/data/external/timesegments*.csv
data/raw/*
!/data/raw/.gitkeep
data/interim/*
diff --git a/.travis.yml b/.travis.yml
index 98421603..98993d3e 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -52,7 +52,7 @@ jobs:
branches:
only:
- master
- - day_segment
+ - time_segment
stages:
- name: deploy
diff --git a/config.yaml b/config.yaml
index 8af1d996..1aef391f 100644
--- a/config.yaml
+++ b/config.yaml
@@ -25,10 +25,10 @@ CREATE_PARTICIPANT_FILES:
DEVICE_ID_COLUMN: device_id # column name
IGNORED_DEVICE_IDS: []
-# See https://www.rapids.science/latest/setup/configuration/#day-segments
-DAY_SEGMENTS: &day_segments
+# See https://www.rapids.science/latest/setup/configuration/#time-segments
+TIME_SEGMENTS: &time_segments
TYPE: PERIODIC # FREQUENCY, PERIODIC, EVENT
- FILE: "data/external/daysegments_periodic.csv"
+ FILE: "data/external/timesegments_periodic.csv"
INCLUDE_PAST_PERIODIC_SEGMENTS: FALSE # Only relevant if TYPE=PERIODIC, see docs
diff --git a/data/external/daysegments_default.csv b/data/external/timesegments_default.csv
similarity index 100%
rename from data/external/daysegments_default.csv
rename to data/external/timesegments_default.csv
diff --git a/data/external/daysegments_event.csv b/data/external/timesegments_event.csv
similarity index 100%
rename from data/external/daysegments_event.csv
rename to data/external/timesegments_event.csv
diff --git a/data/external/daysegments_frequency.csv b/data/external/timesegments_frequency.csv
similarity index 100%
rename from data/external/daysegments_frequency.csv
rename to data/external/timesegments_frequency.csv
diff --git a/data/external/daysegments_periodic.csv b/data/external/timesegments_periodic.csv
similarity index 100%
rename from data/external/daysegments_periodic.csv
rename to data/external/timesegments_periodic.csv
diff --git a/docs/features/add-new-features.md b/docs/features/add-new-features.md
index 1b8a6071..3f1dba8d 100644
--- a/docs/features/add-new-features.md
+++ b/docs/features/add-new-features.md
@@ -83,12 +83,12 @@ In this step you need to add a folder, script and function for your provider.
!!! info "Python function"
```python
- def [providername]_features(sensor_data_files, day_segment, provider, filter_data_by_segment, *args, **kwargs):
+ def [providername]_features(sensor_data_files, time_segment, provider, filter_data_by_segment, *args, **kwargs):
```
!!! info "R function"
```r
- [providername]_features <- function(sensor_data, day_segment, provider)
+ [providername]_features <- function(sensor_data, time_segment, provider)
```
### Implement your feature extraction code
@@ -98,7 +98,7 @@ The provider function that you created in the step above will receive the follow
| Parameter | Description
|---|---|
|`sensor_data_files`| Path to the CSV file containing the data of a single participant. This data has been cleaned and preprocessed. Your function will be automatically called for each participant in your study (in the `[PIDS]` array in `config.yaml`)
-|`day_segment`| The label of the day segment that should be processed.
+|`time_segment`| The label of the time segment that should be processed.
|`provider`| The parameters you configured for your provider in `config.yaml` will be available in this variable as a dictionary in Python or a list in R. In our example this dictionary contains `{MY_PARAMETER:"a_string"}`
|`filter_data_by_segment`| Python only. A function that you will use to filter your data. In R this function is already available in the environment.
|`*args`| Python only. Not used for now
@@ -115,24 +115,24 @@ The code to extract your behavioral features should be implemented in your provi
Note that phone's battery, screen, and activity recognition data is given as episodes instead of event rows (for example, start and end timestamps of the periods the phone screen was on)
-??? info "2. Filter your data to process only those rows that belong to `day_segment`"
+??? info "2. Filter your data to process only those rows that belong to `time_segment`"
This step is only one line of code, but to undersand why we need it, keep reading.
```python
- acc_data = filter_data_by_segment(acc_data, day_segment)
+ acc_data = filter_data_by_segment(acc_data, time_segment)
```
- You should use the `filter_data_by_segment()` function to process and group those rows that belong to each of the [day segments RAPIDS could be configured with](../../setup/configuration/#day-segments).
+ You should use the `filter_data_by_segment()` function to process and group those rows that belong to each of the [time segments RAPIDS could be configured with](../../setup/configuration/#time-segments).
- Let's understand the `filter_data_by_segment()` function with an example. A RAPIDS user can extract features on any arbitrary [day segment](../../setup/configuration/#day-segments). A day segment is a period of time that has a label and one or more instances. For example, the user (or you) could have requested features on a daily, weekly, and week-end basis for `p01`. The labels are arbritrary and the instances depend on the days a participant was monitored for:
+ Let's understand the `filter_data_by_segment()` function with an example. A RAPIDS user can extract features on any arbitrary [time segment](../../setup/configuration/#time-segments). A time segment is a period of time that has a label and one or more instances. For example, the user (or you) could have requested features on a daily, weekly, and week-end basis for `p01`. The labels are arbritrary and the instances depend on the days a participant was monitored for:
- the daily segment could be named `my_days` and if `p01` was monitored for 14 days, it would have 14 instances
- the weekly segment could be named `my_weeks` and if `p01` was monitored for 14 days, it would have 2 instances.
- the weekend segment could be named `my_weekends` and if `p01` was monitored for 14 days, it would have 2 instances.
- For this example, RAPIDS will call your provider function three times for `p01`, once where `day_segment` is `my_days`, once where `day_segment` is `my_weeks` and once where `day_segment` is `my_weekends`. In this example not every row in `p01`'s data needs to take part in the feature computation for either segment **and** the rows need to be grouped differently.
+ For this example, RAPIDS will call your provider function three times for `p01`, once where `time_segment` is `my_days`, once where `time_segment` is `my_weeks` and once where `time_segment` is `my_weekends`. In this example not every row in `p01`'s data needs to take part in the feature computation for either segment **and** the rows need to be grouped differently.
- Thus `filter_data_by_segment()` comes in handy, it will return a data frame that contains the rows that were logged during a day segment plus an extra column called `local_segment`. This new column will have as many unique values as day segment instances exist (14, 2, and 2 for our `p01`'s `my_days`, `my_weeks`, and `my_weekends` examples). After filtering, **you should group the data frame by this column and compute any desired features**, for example:
+ Thus `filter_data_by_segment()` comes in handy, it will return a data frame that contains the rows that were logged during a time segment plus an extra column called `local_segment`. This new column will have as many unique values as time segment instances exist (14, 2, and 2 for our `p01`'s `my_days`, `my_weeks`, and `my_weekends` examples). After filtering, **you should group the data frame by this column and compute any desired features**, for example:
```python
acc_features["maxmagnitude"] = acc_data.groupby(["local_segment"])["magnitude"].max()
@@ -143,7 +143,7 @@ The code to extract your behavioral features should be implemented in your provi
??? info "3. Return a data frame with your features"
After filtering, grouping your data, and computing your features, your provider function should return a data frame that has:
- - One row per day segment instance (e.g. 14 our `p01`'s `my_days` example)
+ - One row per time segment instance (e.g. 14 our `p01`'s `my_days` example)
- The `local_segment` column added by `filter_data_by_segment()`
- One column per feature. By convention the name of your features should only contain letters or numbers (`feature1`). RAPIDS will automatically add the right sensor and provider prefix (`phone_accelerometr_vega_`)
@@ -151,7 +151,7 @@ The code to extract your behavioral features should be implemented in your provi
For your reference, this a short example of our own provider (`RAPIDS`) for `PHONE_ACCELEROMETER` that computes five acceleration features
```python
- def rapids_features(sensor_data_files, day_segment, provider, filter_data_by_segment, *args, **kwargs):
+ def rapids_features(sensor_data_files, time_segment, provider, filter_data_by_segment, *args, **kwargs):
acc_data = pd.read_csv(sensor_data_files["sensor_data"])
requested_features = provider["FEATURES"]
@@ -162,7 +162,7 @@ The code to extract your behavioral features should be implemented in your provi
acc_features = pd.DataFrame(columns=["local_segment"] + features_to_compute)
if not acc_data.empty:
- acc_data = filter_data_by_segment(acc_data, day_segment)
+ acc_data = filter_data_by_segment(acc_data, time_segment)
if not acc_data.empty:
acc_features = pd.DataFrame()
diff --git a/docs/features/fitbit-heartrate-intraday.md b/docs/features/fitbit-heartrate-intraday.md
index bafb8944..3dcedc14 100644
--- a/docs/features/fitbit-heartrate-intraday.md
+++ b/docs/features/fitbit-heartrate-intraday.md
@@ -31,8 +31,8 @@ We provide examples of the input format that RAPIDS expects, note that both exam
## RAPIDS provider
-!!! info "Available day segments"
- - Available for all day segments
+!!! info "Available time segments"
+ - Available for all time segments
!!! info "File Sequence"
```bash
@@ -56,16 +56,16 @@ Features description for `[FITBIT_HEARTRATE_INTRADAY][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |-------------- |---------------------------|
-|maxhr |beats/mins |The maximum heart rate during a day segment.
-|minhr |beats/mins |The minimum heart rate during a day segment.
-|avghr |beats/mins |The average heart rate during a day segment.
-|medianhr |beats/mins |The median of heart rate during a day segment.
-|modehr |beats/mins |The mode of heart rate during a day segment.
-|stdhr |beats/mins |The standard deviation of heart rate during a day segment.
-|diffmaxmodehr |beats/mins |The difference between the maximum and mode heart rate during a day segment.
-|diffminmodehr |beats/mins |The difference between the mode and minimum heart rate during a day segment.
-|entropyhr |nats |Shannon’s entropy measurement based on heart rate during a day segment.
-|minutesonZONE |minutes |Number of minutes the user’s heart rate fell within each `heartrate_zone` during a day segment.
+|maxhr |beats/mins |The maximum heart rate during a time segment.
+|minhr |beats/mins |The minimum heart rate during a time segment.
+|avghr |beats/mins |The average heart rate during a time segment.
+|medianhr |beats/mins |The median of heart rate during a time segment.
+|modehr |beats/mins |The mode of heart rate during a time segment.
+|stdhr |beats/mins |The standard deviation of heart rate during a time segment.
+|diffmaxmodehr |beats/mins |The difference between the maximum and mode heart rate during a time segment.
+|diffminmodehr |beats/mins |The difference between the mode and minimum heart rate during a time segment.
+|entropyhr |nats |Shannon’s entropy measurement based on heart rate during a time segment.
+|minutesonZONE |minutes |Number of minutes the user’s heart rate fell within each `heartrate_zone` during a time segment.
!!! note "Assumptions/Observations"
diff --git a/docs/features/fitbit-heartrate-summary.md b/docs/features/fitbit-heartrate-summary.md
index 553421c1..9392dea6 100644
--- a/docs/features/fitbit-heartrate-summary.md
+++ b/docs/features/fitbit-heartrate-summary.md
@@ -31,7 +31,7 @@ We provide examples of the input format that RAPIDS expects, note that both exam
## RAPIDS provider
-!!! info "Available day segments"
+!!! info "Available time segments"
- Only available for segments that span 1 or more complete days (e.g. Jan 1st 00:00 to Jan 3rd 23:59)
!!! info "File Sequence"
@@ -56,22 +56,22 @@ Features description for `[FITBIT_HEARTRATE_SUMMARY][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-|maxrestinghr |beats/mins |The maximum daily resting heart rate during a day segment.
-|minrestinghr |beats/mins |The minimum daily resting heart rate during a day segment.
-|avgrestinghr |beats/mins |The average daily resting heart rate during a day segment.
-|medianrestinghr |beats/mins |The median of daily resting heart rate during a day segment.
-|moderestinghr |beats/mins |The mode of daily resting heart rate during a day segment.
-|stdrestinghr |beats/mins |The standard deviation of daily resting heart rate during a day segment.
-|diffmaxmoderestinghr |beats/mins |The difference between the maximum and mode daily resting heart rate during a day segment.
-|diffminmoderestinghr |beats/mins |The difference between the mode and minimum daily resting heart rate during a day segment.
-|entropyrestinghr |nats |Shannon’s entropy measurement based on daily resting heart rate during a day segment.
-|sumcaloriesZONE |cals |The total daily calories burned within `heartrate_zone` during a day segment.
-|maxcaloriesZONE |cals |The maximum daily calories burned within `heartrate_zone` during a day segment.
-|mincaloriesZONE |cals |The minimum daily calories burned within `heartrate_zone` during a day segment.
-|avgcaloriesZONE |cals |The average daily calories burned within `heartrate_zone` during a day segment.
-|mediancaloriesZONE |cals |The median of daily calories burned within `heartrate_zone` during a day segment.
-|stdcaloriesZONE |cals |The standard deviation of daily calories burned within `heartrate_zone` during a day segment.
-|entropycaloriesZONE |nats |Shannon’s entropy measurement based on daily calories burned within `heartrate_zone` during a day segment.
+|maxrestinghr |beats/mins |The maximum daily resting heart rate during a time segment.
+|minrestinghr |beats/mins |The minimum daily resting heart rate during a time segment.
+|avgrestinghr |beats/mins |The average daily resting heart rate during a time segment.
+|medianrestinghr |beats/mins |The median of daily resting heart rate during a time segment.
+|moderestinghr |beats/mins |The mode of daily resting heart rate during a time segment.
+|stdrestinghr |beats/mins |The standard deviation of daily resting heart rate during a time segment.
+|diffmaxmoderestinghr |beats/mins |The difference between the maximum and mode daily resting heart rate during a time segment.
+|diffminmoderestinghr |beats/mins |The difference between the mode and minimum daily resting heart rate during a time segment.
+|entropyrestinghr |nats |Shannon’s entropy measurement based on daily resting heart rate during a time segment.
+|sumcaloriesZONE |cals |The total daily calories burned within `heartrate_zone` during a time segment.
+|maxcaloriesZONE |cals |The maximum daily calories burned within `heartrate_zone` during a time segment.
+|mincaloriesZONE |cals |The minimum daily calories burned within `heartrate_zone` during a time segment.
+|avgcaloriesZONE |cals |The average daily calories burned within `heartrate_zone` during a time segment.
+|mediancaloriesZONE |cals |The median of daily calories burned within `heartrate_zone` during a time segment.
+|stdcaloriesZONE |cals |The standard deviation of daily calories burned within `heartrate_zone` during a time segment.
+|entropycaloriesZONE |nats |Shannon’s entropy measurement based on daily calories burned within `heartrate_zone` during a time segment.
!!! note "Assumptions/Observations"
diff --git a/docs/features/fitbit-sleep-summary.md b/docs/features/fitbit-sleep-summary.md
index c9bc8064..9ac79357 100644
--- a/docs/features/fitbit-sleep-summary.md
+++ b/docs/features/fitbit-sleep-summary.md
@@ -51,7 +51,7 @@ We provide examples of the input format that RAPIDS expects, note that both exam
## RAPIDS provider
-!!! info "Available day segments"
+!!! info "Available time segments"
- Only available for segments that span 1 or more complete days (e.g. Jan 1st 00:00 to Jan 3rd 23:59)
!!! info "File Sequence"
@@ -77,18 +77,18 @@ Features description for `[FITBIT_SLEEP_SUMMARY][PROVIDERS][RAPIDS]`:
|Feature |Units |Description |
|------------------------------ |---------- |-------------------------------------------- |
-|countepisodeTYPE |episodes |Number of sleep episodes for a certain sleep type during a day segment.
-|avgefficiencyTYPE |scores |Average sleep efficiency for a certain sleep type during a day segment.
-|sumdurationafterwakeupTYPE |minutes |Total duration the user stayed in bed after waking up for a certain sleep type during a day segment.
-|sumdurationasleepTYPE |minutes |Total sleep duration for a certain sleep type during a day segment.
-|sumdurationawakeTYPE |minutes |Total duration the user stayed awake but still in bed for a certain sleep type during a day segment.
-|sumdurationtofallasleepTYPE |minutes |Total duration the user spent to fall asleep for a certain sleep type during a day segment.
-|sumdurationinbedTYPE |minutes |Total duration the user stayed in bed (sumdurationtofallasleep + sumdurationawake + sumdurationasleep + sumdurationafterwakeup) for a certain sleep type during a day segment.
-|avgdurationafterwakeupTYPE |minutes |Average duration the user stayed in bed after waking up for a certain sleep type during a day segment.
-|avgdurationasleepTYPE |minutes |Average sleep duration for a certain sleep type during a day segment.
-|avgdurationawakeTYPE |minutes |Average duration the user stayed awake but still in bed for a certain sleep type during a day segment.
-|avgdurationtofallasleepTYPE |minutes |Average duration the user spent to fall asleep for a certain sleep type during a day segment.
-|avgdurationinbedTYPE |minutes |Average duration the user stayed in bed (sumdurationtofallasleep + sumdurationawake + sumdurationasleep + sumdurationafterwakeup) for a certain sleep type during a day segment.
+|countepisodeTYPE |episodes |Number of sleep episodes for a certain sleep type during a time segment.
+|avgefficiencyTYPE |scores |Average sleep efficiency for a certain sleep type during a time segment.
+|sumdurationafterwakeupTYPE |minutes |Total duration the user stayed in bed after waking up for a certain sleep type during a time segment.
+|sumdurationasleepTYPE |minutes |Total sleep duration for a certain sleep type during a time segment.
+|sumdurationawakeTYPE |minutes |Total duration the user stayed awake but still in bed for a certain sleep type during a time segment.
+|sumdurationtofallasleepTYPE |minutes |Total duration the user spent to fall asleep for a certain sleep type during a time segment.
+|sumdurationinbedTYPE |minutes |Total duration the user stayed in bed (sumdurationtofallasleep + sumdurationawake + sumdurationasleep + sumdurationafterwakeup) for a certain sleep type during a time segment.
+|avgdurationafterwakeupTYPE |minutes |Average duration the user stayed in bed after waking up for a certain sleep type during a time segment.
+|avgdurationasleepTYPE |minutes |Average sleep duration for a certain sleep type during a time segment.
+|avgdurationawakeTYPE |minutes |Average duration the user stayed awake but still in bed for a certain sleep type during a time segment.
+|avgdurationtofallasleepTYPE |minutes |Average duration the user spent to fall asleep for a certain sleep type during a time segment.
+|avgdurationinbedTYPE |minutes |Average duration the user stayed in bed (sumdurationtofallasleep + sumdurationawake + sumdurationasleep + sumdurationafterwakeup) for a certain sleep type during a time segment.
diff --git a/docs/features/fitbit-steps-intraday.md b/docs/features/fitbit-steps-intraday.md
index aba4da84..0dbffe53 100644
--- a/docs/features/fitbit-steps-intraday.md
+++ b/docs/features/fitbit-steps-intraday.md
@@ -31,8 +31,8 @@ We provide examples of the input format that RAPIDS expects, note that both exam
## RAPIDS provider
-!!! info "Available day segments"
- - Available for all day segments
+!!! info "Available time segments"
+ - Available for all time segments
!!! info "File Sequence"
```bash
@@ -51,30 +51,30 @@ Parameters description for `[FITBIT_STEPS_INTRADAY][PROVIDERS][RAPIDS]`:
|`[COMPUTE]` | Set to `True` to extract `FITBIT_STEPS_INTRADAY` features from the `RAPIDS` provider|
|`[FEATURES]` | Features to be computed from steps intraday data, see table below |
|`[THRESHOLD_ACTIVE_BOUT]` | Every minute with Fitbit steps data wil be labelled as `sedentary` if its step count is below this threshold, otherwise, `active`. |
-|`[INCLUDE_ZERO_STEP_ROWS]` | Whether or not to include day segments with a 0 step count during the whole day. |
+|`[INCLUDE_ZERO_STEP_ROWS]` | Whether or not to include time segments with a 0 step count during the whole day. |
Features description for `[FITBIT_STEPS_INTRADAY][PROVIDERS][RAPIDS]`:
|Feature |Units |Description |
|-------------------------- |-------------- |-------------------------------------------------------------|
-|sumsteps |steps |The total step count during a day segment.
-|maxsteps |steps |The maximum step count during a day segment.
-|minsteps |steps |The minimum step count during a day segment.
-|avgsteps |steps |The average step count during a day segment.
-|stdsteps |steps |The standard deviation of step count during a day segment.
-|countepisodesedentarybout |bouts |Number of sedentary bouts during a day segment.
-|sumdurationsedentarybout |minutes |Total duration of all sedentary bouts during a day segment.
-|maxdurationsedentarybout |minutes |The maximum duration of any sedentary bout during a day segment.
-|mindurationsedentarybout |minutes |The minimum duration of any sedentary bout during a day segment.
-|avgdurationsedentarybout |minutes |The average duration of sedentary bouts during a day segment.
-|stddurationsedentarybout |minutes |The standard deviation of the duration of sedentary bouts during a day segment.
-|countepisodeactivebout |bouts |Number of active bouts during a day segment.
-|sumdurationactivebout |minutes |Total duration of all active bouts during a day segment.
-|maxdurationactivebout |minutes |The maximum duration of any active bout during a day segment.
-|mindurationactivebout |minutes |The minimum duration of any active bout during a day segment.
-|avgdurationactivebout |minutes |The average duration of active bouts during a day segment.
-|stddurationactivebout |minutes |The standard deviation of the duration of active bouts during a day segment.
+|sumsteps |steps |The total step count during a time segment.
+|maxsteps |steps |The maximum step count during a time segment.
+|minsteps |steps |The minimum step count during a time segment.
+|avgsteps |steps |The average step count during a time segment.
+|stdsteps |steps |The standard deviation of step count during a time segment.
+|countepisodesedentarybout |bouts |Number of sedentary bouts during a time segment.
+|sumdurationsedentarybout |minutes |Total duration of all sedentary bouts during a time segment.
+|maxdurationsedentarybout |minutes |The maximum duration of any sedentary bout during a time segment.
+|mindurationsedentarybout |minutes |The minimum duration of any sedentary bout during a time segment.
+|avgdurationsedentarybout |minutes |The average duration of sedentary bouts during a time segment.
+|stddurationsedentarybout |minutes |The standard deviation of the duration of sedentary bouts during a time segment.
+|countepisodeactivebout |bouts |Number of active bouts during a time segment.
+|sumdurationactivebout |minutes |Total duration of all active bouts during a time segment.
+|maxdurationactivebout |minutes |The maximum duration of any active bout during a time segment.
+|mindurationactivebout |minutes |The minimum duration of any active bout during a time segment.
+|avgdurationactivebout |minutes |The average duration of active bouts during a time segment.
+|stddurationactivebout |minutes |The standard deviation of the duration of active bouts during a time segment.
!!! note "Assumptions/Observations"
diff --git a/docs/features/fitbit-steps-summary.md b/docs/features/fitbit-steps-summary.md
index a9b5298a..af8bb134 100644
--- a/docs/features/fitbit-steps-summary.md
+++ b/docs/features/fitbit-steps-summary.md
@@ -31,7 +31,7 @@ We provide examples of the input format that RAPIDS expects, note that both exam
## RAPIDS provider
-!!! info "Available day segments"
+!!! info "Available time segments"
- Only available for segments that span 1 or more complete days (e.g. Jan 1st 00:00 to Jan 3rd 23:59)
!!! info "File Sequence"
@@ -56,11 +56,11 @@ Features description for `[FITBIT_STEPS_SUMMARY][PROVIDERS][RAPIDS]`:
|Feature |Units |Description |
|-------------------------- |---------- |-------------------------------------------- |
-|maxsumsteps |steps |The maximum daily step count during a day segment.
-|minsumsteps |steps |The minimum daily step count during a day segment.
-|avgsumsteps |steps |The average daily step count during a day segment.
-|mediansumsteps |steps |The median of daily step count during a day segment.
-|stdsumsteps |steps |The standard deviation of daily step count during a day segment.
+|maxsumsteps |steps |The maximum daily step count during a time segment.
+|minsumsteps |steps |The minimum daily step count during a time segment.
+|avgsumsteps |steps |The average daily step count during a time segment.
+|mediansumsteps |steps |The median of daily step count during a time segment.
+|stdsumsteps |steps |The standard deviation of daily step count during a time segment.
!!! note "Assumptions/Observations"
diff --git a/docs/features/phone-accelerometer.md b/docs/features/phone-accelerometer.md
index 3009a8b5..64a43380 100644
--- a/docs/features/phone-accelerometer.md
+++ b/docs/features/phone-accelerometer.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_ACCELEROMETER]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
@@ -46,8 +46,8 @@ Features description for `[PHONE_ACCELEROMETER][PROVIDERS][RAPIDS]`:
These features are based on the work by [Panda et al](../../citation#panda-accelerometer).
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
diff --git a/docs/features/phone-activity-recognition.md b/docs/features/phone-activity-recognition.md
index 9c8a78e8..e2b791b7 100644
--- a/docs/features/phone-activity-recognition.md
+++ b/docs/features/phone-activity-recognition.md
@@ -10,8 +10,8 @@ Sensor parameters description for `[PHONE_ACTIVITY_RECOGNITION]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
diff --git a/docs/features/phone-applications-foreground.md b/docs/features/phone-applications-foreground.md
index dec35e92..53f1aed0 100644
--- a/docs/features/phone-applications-foreground.md
+++ b/docs/features/phone-applications-foreground.md
@@ -14,8 +14,8 @@ Sensor parameters description for `[PHONE_APPLICATIONS_FOREGROUND]` (these param
The app category (genre) catalogue used in these features was originally created by [Stachl et al](../../citation#stachl-applications-foreground).
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
@@ -45,9 +45,9 @@ Features description for `[PHONE_APPLICATIONS_FOREGROUND][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
|count |apps | Number of times a single app or apps within a category were used (i.e. they were brought to the foreground either by tapping their icon or switching to it from another app)
-|timeoffirstuse |minutes | The time in minutes between 12:00am (midnight) and the first use of a single app or apps within a category during a `day_segment`
-|timeoflastuse |minutes | The time in minutes between 12:00am (midnight) and the last use of a single app or apps within a category during a `day_segment`
-|frequencyentropy |nats | The entropy of the used apps within a category during a `day_segment` (each app is seen as a unique event, the more apps were used, the higher the entropy). This is especially relevant when computed over all apps. Entropy cannot be obtained for a single app
+|timeoffirstuse |minutes | The time in minutes between 12:00am (midnight) and the first use of a single app or apps within a category during a `time_segment`
+|timeoflastuse |minutes | The time in minutes between 12:00am (midnight) and the last use of a single app or apps within a category during a `time_segment`
+|frequencyentropy |nats | The entropy of the used apps within a category during a `time_segment` (each app is seen as a unique event, the more apps were used, the higher the entropy). This is especially relevant when computed over all apps. Entropy cannot be obtained for a single app
!!! note "Assumptions/Observations"
Features can be computed by app, by apps grouped under a single category (genre) and by multiple categories grouped together (meta-categories). For example, we can get features for `Facebook` (single app), for `Social Network` apps (a category including Facebook and other social media apps) or for `Social` (a meta-category formed by `Social Network` and `Social Media Tools` categories).
diff --git a/docs/features/phone-battery.md b/docs/features/phone-battery.md
index b19b3fbb..8b791537 100644
--- a/docs/features/phone-battery.md
+++ b/docs/features/phone-battery.md
@@ -9,8 +9,8 @@ Sensor parameters description for `[PHONE_BATTERY]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
diff --git a/docs/features/phone-bluetooth.md b/docs/features/phone-bluetooth.md
index c16958ed..e37b2628 100644
--- a/docs/features/phone-bluetooth.md
+++ b/docs/features/phone-bluetooth.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_BLUETOOTH]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
@@ -33,9 +33,9 @@ Features description for `[PHONE_BLUETOOTH][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-| countscans | devices | Number of scanned devices during a `day_segment`, a device can be detected multiple times over time and these appearances are counted separately |
-| uniquedevices | devices | Number of unique devices during a `day_segment` as identified by their hardware (`bt_address`) address |
-| countscansmostuniquedevice | scans | Number of scans of the most scanned device during a `day_segment` across the whole monitoring period |
+| countscans | devices | Number of scanned devices during a `time_segment`, a device can be detected multiple times over time and these appearances are counted separately |
+| uniquedevices | devices | Number of unique devices during a `time_segment` as identified by their hardware (`bt_address`) address |
+| countscansmostuniquedevice | scans | Number of scans of the most scanned device during a `time_segment` across the whole monitoring period |
!!! note "Assumptions/Observations"
NA
diff --git a/docs/features/phone-calls.md b/docs/features/phone-calls.md
index 51cd53ce..f96ef060 100644
--- a/docs/features/phone-calls.md
+++ b/docs/features/phone-calls.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_CALLS]`:
## RAPIDS Provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
@@ -35,28 +35,28 @@ Features description for `[PHONE_CALLS][PROVIDERS][RAPIDS]` incoming and outgoin
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-|count |calls |Number of calls of a particular `call_type` occurred during a particular `day_segment`.
-|distinctcontacts |contacts |Number of distinct contacts that are associated with a particular `call_type` for a particular `day_segment`
-|meanduration |seconds |The mean duration of all calls of a particular `call_type` during a particular `day_segment`.
-|sumduration |seconds |The sum of the duration of all calls of a particular `call_type` during a particular `day_segment`.
-|minduration |seconds |The duration of the shortest call of a particular `call_type` during a particular `day_segment`.
-|maxduration |seconds |The duration of the longest call of a particular `call_type` during a particular `day_segment`.
-|stdduration |seconds |The standard deviation of the duration of all the calls of a particular `call_type` during a particular `day_segment`.
-|modeduration |seconds |The mode of the duration of all the calls of a particular `call_type` during a particular `day_segment`.
-|entropyduration |nats |The estimate of the Shannon entropy for the the duration of all the calls of a particular `call_type` during a particular `day_segment`.
+|count |calls |Number of calls of a particular `call_type` occurred during a particular `time_segment`.
+|distinctcontacts |contacts |Number of distinct contacts that are associated with a particular `call_type` for a particular `time_segment`
+|meanduration |seconds |The mean duration of all calls of a particular `call_type` during a particular `time_segment`.
+|sumduration |seconds |The sum of the duration of all calls of a particular `call_type` during a particular `time_segment`.
+|minduration |seconds |The duration of the shortest call of a particular `call_type` during a particular `time_segment`.
+|maxduration |seconds |The duration of the longest call of a particular `call_type` during a particular `time_segment`.
+|stdduration |seconds |The standard deviation of the duration of all the calls of a particular `call_type` during a particular `time_segment`.
+|modeduration |seconds |The mode of the duration of all the calls of a particular `call_type` during a particular `time_segment`.
+|entropyduration |nats |The estimate of the Shannon entropy for the the duration of all the calls of a particular `call_type` during a particular `time_segment`.
|timefirstcall |minutes |The time in minutes between 12:00am (midnight) and the first call of `call_type`.
|timelastcall |minutes |The time in minutes between 12:00am (midnight) and the last call of `call_type`.
-|countmostfrequentcontact |calls |The number of calls of a particular `call_type` during a particular `day_segment` of the most frequent contact throughout the monitored period.
+|countmostfrequentcontact |calls |The number of calls of a particular `call_type` during a particular `time_segment` of the most frequent contact throughout the monitored period.
Features description for `[PHONE_CALLS][PROVIDERS][RAPIDS]` missed calls:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-|count |calls |Number of `missed` calls that occurred during a particular `day_segment`.
-|distinctcontacts |contacts |Number of distinct contacts that are associated with `missed` calls for a particular `day_segment`
+|count |calls |Number of `missed` calls that occurred during a particular `time_segment`.
+|distinctcontacts |contacts |Number of distinct contacts that are associated with `missed` calls for a particular `time_segment`
|timefirstcall |minutes |The time in hours from 12:00am (Midnight) that the first `missed` call occurred.
|timelastcall |minutes |The time in hours from 12:00am (Midnight) that the last `missed` call occurred.
-|countmostfrequentcontact |calls |The number of `missed` calls during a particular `day_segment` of the most frequent contact throughout the monitored period.
+|countmostfrequentcontact |calls |The number of `missed` calls during a particular `time_segment` of the most frequent contact throughout the monitored period.
!!! note "Assumptions/Observations"
1. Traces for iOS calls are unique even for the same contact calling a participant more than once which renders `countmostfrequentcontact` meaningless and `distinctcontacts` equal to the total number of traces.
diff --git a/docs/features/phone-conversation.md b/docs/features/phone-conversation.md
index 4e96e369..d67747aa 100644
--- a/docs/features/phone-conversation.md
+++ b/docs/features/phone-conversation.md
@@ -9,8 +9,8 @@ Sensor parameters description for `[PHONE_CONVERSATION]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
@@ -46,8 +46,8 @@ Features description for `[PHONE_CONVERSATION][PROVIDERS][RAPIDS]`:
| minconversationduration | minutes | Shortest duration of all conversations |
| avgconversationduration | minutes | Average duration of all conversations |
| sdconversationduration | minutes | Standard Deviation of the duration of all conversations |
-| timefirstconversation | minutes | Minutes since midnight when the first conversation for a day segment was detected |
-| timelastconversation | minutes | Minutes since midnight when the last conversation for a day segment was detected |
+| timefirstconversation | minutes | Minutes since midnight when the first conversation for a time segment was detected |
+| timelastconversation | minutes | Minutes since midnight when the last conversation for a time segment was detected |
| noisesumenergy | L2-norm | Sum of all energy values when inference is noise |
| noiseavgenergy | L2-norm | Average of all energy values when inference is noise |
| noisesdenergy | L2-norm | Standard Deviation of all energy values when inference is noise |
diff --git a/docs/features/phone-data-yield.md b/docs/features/phone-data-yield.md
index a51775da..5327a131 100644
--- a/docs/features/phone-data-yield.md
+++ b/docs/features/phone-data-yield.md
@@ -1,6 +1,6 @@
# Phone Data Yield
-This is a combinatorial sensor which means that we use the data from multiple sensors to extract data yield features. Data yield features can be used to remove rows ([day segments](../../setup/configuration/#day-segments)) that do not contain enough data. You should decide what is your "enough" threshold depending on the type of sensors you collected (frequency vs event based, e.g. acceleroemter vs calls), the length of your study, and the rates of missing data that your analysis could handle.
+This is a combinatorial sensor which means that we use the data from multiple sensors to extract data yield features. Data yield features can be used to remove rows ([time segments](../../setup/configuration/#time-segments)) that do not contain enough data. You should decide what is your "enough" threshold depending on the type of sensors you collected (frequency vs event based, e.g. acceleroemter vs calls), the length of your study, and the rates of missing data that your analysis could handle.
!!! hint "Why is data yield important?"
Imagine that you want to extract `PHONE_CALL` features on daily segments (`00:00` to `23:59`). Let's say that on day 1 the phone logged 10 calls and 23 hours of data from other sensors and on day 2 the phone logged 10 calls and only 2 hours of data from other sensors. It's more likely that other calls were placed on the 22 hours of data that you didn't log on day 2 than on the 1 hour of data you didn't log on day 1, and so including day 2 in your analysis could bias your results.
@@ -35,10 +35,10 @@ Before explaining the data yield features, let's define the following relevant c
- A valid minute is any 60 second window when any phone sensor logged at least 1 row of data
- A valid hour is any 60 minute window with at least X valid minutes. The X or threshold is given by `[MINUTE_RATIO_THRESHOLD_FOR_VALID_YIELDED_HOURS]`
-The timestamps of all sensors are concatenated and then grouped per day segment. Minute and hour windows are created from the beginning of each day segment instance and these windows are marked as valid based on the definitions above. The duration of each day segment is taken into account to compute the features described below.
+The timestamps of all sensors are concatenated and then grouped per time segment. Minute and hour windows are created from the beginning of each time segment instance and these windows are marked as valid based on the definitions above. The duration of each time segment is taken into account to compute the features described below.
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
@@ -64,14 +64,14 @@ Features description for `[PHONE_DATA_YIELD][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-|ratiovalidyieldedminutes |rows | The ratio between the number of valid minutes and the duration in minutes of a day segment.
-|ratiovalidyieldedhours |lux | The ratio between the number of valid hours and the duration in hours of a day segment. If the day segment is shorter than 1 hour this feature will always be 1.
+|ratiovalidyieldedminutes |rows | The ratio between the number of valid minutes and the duration in minutes of a time segment.
+|ratiovalidyieldedhours |lux | The ratio between the number of valid hours and the duration in hours of a time segment. If the time segment is shorter than 1 hour this feature will always be 1.
!!! note "Assumptions/Observations"
- 1. We recommend using `ratiovalidyieldedminutes` on day segments that are shorter than two or three hours and `ratiovalidyieldedhours` for longer segments. This is because relying on yielded minutes only can be misleading when a big chunk of those missing minutes are clustered together.
+ 1. We recommend using `ratiovalidyieldedminutes` on time segments that are shorter than two or three hours and `ratiovalidyieldedhours` for longer segments. This is because relying on yielded minutes only can be misleading when a big chunk of those missing minutes are clustered together.
- For example, let's assume we are working with a 24-hour day segment that is missing 12 hours of data. Two extreme cases can occur:
+ For example, let's assume we are working with a 24-hour time segment that is missing 12 hours of data. Two extreme cases can occur:
the 12 missing hours are from the beginning of the segment or
diff --git a/docs/features/phone-light.md b/docs/features/phone-light.md
index 26b66ab0..e44b81e8 100644
--- a/docs/features/phone-light.md
+++ b/docs/features/phone-light.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_LIGHT]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
diff --git a/docs/features/phone-locations.md b/docs/features/phone-locations.md
index 8c45ac66..646dc9b0 100644
--- a/docs/features/phone-locations.md
+++ b/docs/features/phone-locations.md
@@ -11,7 +11,7 @@ Sensor parameters description for `[PHONE_LOCATIONS]`:
!!! note "Assumptions/Observations"
**Types of location data to use**
- AWARE Android and iOS clients can collect location coordinates through the phone\'s GPS, the network cellular towers around the phone or Google\'s fused location API. If you want to use only the GPS provider set `[LOCATIONS_TO_USE]` to `GPS`, if you want to use all providers (not recommended due to the difference in accuracy) set `[LOCATIONS_TO_USE]` to `ALL`, if your AWARE client was configured to use fused location only or want to focus only on this provider, set `[LOCATIONS_TO_USE]` to `RESAMPLE_FUSED`. `RESAMPLE_FUSED` takes the original fused location coordinates and replicates each pair forward in time as long as the phone was sensing data as indicated by [`PHONE_VALID_SENSED_BINS`](../phone-data-quality/#phone-valid-sensed-bins), this is done because Google\'s API only logs a new location coordinate pair when it is sufficiently different in time or space from the previous one.
+ AWARE Android and iOS clients can collect location coordinates through the phone\'s GPS, the network cellular towers around the phone or Google\'s fused location API. If you want to use only the GPS provider set `[LOCATIONS_TO_USE]` to `GPS`, if you want to use all providers (not recommended due to the difference in accuracy) set `[LOCATIONS_TO_USE]` to `ALL`, if your AWARE client was configured to use fused location only or want to focus only on this provider, set `[LOCATIONS_TO_USE]` to `RESAMPLE_FUSED`. `RESAMPLE_FUSED` takes the original fused location coordinates and replicates each pair forward in time as long as the phone was sensing data as indicated by the joined timestamps of [`[PHONE_DATA_YIELD][SENSORS]`](../phone-data-yield/), this is done because Google\'s API only logs a new location coordinate pair when it is sufficiently different in time or space from the previous one.
There are two parameters associated with resampling fused location. `FUSED_RESAMPLED_CONSECUTIVE_THRESHOLD` (in minutes, default 30) controls the maximum gap between any two coordinate pairs to replicate the last known pair (for example, participant A\'s phone did not collect data between 10.30am and 10:50am and between 11:05am and 11:40am, the last known coordinate pair will be replicated during the first period but not the second, in other words, we assume that we cannot longer guarantee the participant stayed at the last known location if the phone did not sense data for more than 30 minutes). `FUSED_RESAMPLED_TIME_SINCE_VALID_LOCATION` (in minutes, default 720 or 12 hours) stops the last known fused location from being replicated longer that this threshold even if the phone was sensing data continuously (for example, participant A went home at 9pm and their phone was sensing data without gaps until 11am the next morning, the last known location will only be replicated until 9am). If you have suggestions to modify or improve this resampling, let us know.
@@ -20,7 +20,7 @@ Sensor parameters description for `[PHONE_LOCATIONS]`:
These features are based on the original open-source implementation by [Barnett et al](../../citation#barnett-locations) and some features created by [Canzian et al](../../citation#barnett-locations).
-!!! info "Available day segments and platforms"
+!!! info "Available time segments and platforms"
- Available only for segments that start at 00:00:00 and end at 23:59:59 of the same day (daily segments)
- Available for Android and iOS
@@ -42,7 +42,7 @@ Parameters description for `[PHONE_LOCATIONS][PROVIDERS][BARNETT]`:
|`[FEATURES]` | Features to be computed, see table below
|`[ACCURACY_LIMIT]` | An integer in meters, any location rows with an accuracy higher than this will be dropped. This number means there's a 68% probability the true location is within this radius
|`[TIMEZONE]` | Timezone where the location data was collected. By default points to the one defined in the [Configuration](../../setup/configuration#timezone-of-your-study)
-|`[MINUTES_DATA_USED]` | Set to `True` to include an extra column in the final location feature file containing the number of minutes used to compute the features on each day segment. Use this for quality control purposes, the more data minutes exist for a period, the more reliable its features should be. For fused location, a single minute can contain more than one coordinate pair if the participant is moving fast enough.
+|`[MINUTES_DATA_USED]` | Set to `True` to include an extra column in the final location feature file containing the number of minutes used to compute the features on each time segment. Use this for quality control purposes, the more data minutes exist for a period, the more reliable its features should be. For fused location, a single minute can contain more than one coordinate pair if the participant is moving fast enough.
@@ -80,8 +80,8 @@ Features description for `[PHONE_LOCATIONS][PROVIDERS][BARNETT]` adapted from [B
These features are based on the original implementation by [Doryab et al.](../../citation#doryab-locations).
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
@@ -104,7 +104,7 @@ Parameters description for `[PHONE_LOCATIONS][PROVIDERS][BARNETT]`:
| `[DBSCAN_MINSAMPLES]` | The number of samples (or total weight) in a neighborhood for a point to be considered as a core point of a cluster. This includes the point itself.
| `[THRESHOLD_STATIC]` | It is the threshold value in km/hr which labels a row as Static or Moving.
| `[MAXIMUM_GAP_ALLOWED]` | The maximum gap (in seconds) allowed between any two consecutive rows for them to be considered part of the same displacement. If this threshold is too high, it can throw speed and distance calculations off for periods when the the phone was not sensing.
-| `[MINUTES_DATA_USED]` | Set to `True` to include an extra column in the final location feature file containing the number of minutes used to compute the features on each day segment. Use this for quality control purposes, the more data minutes exist for a period, the more reliable its features should be. For fused location, a single minute can contain more than one coordinate pair if the participant is moving fast enough.
+| `[MINUTES_DATA_USED]` | Set to `True` to include an extra column in the final location feature file containing the number of minutes used to compute the features on each time segment. Use this for quality control purposes, the more data minutes exist for a period, the more reliable its features should be. For fused location, a single minute can contain more than one coordinate pair if the participant is moving fast enough.
| `[SAMPLING_FREQUENCY]` | Expected time difference between any two location rows in minutes. If set to `0`, the sampling frequency will be inferred automatically as the median of all the differences between any two consecutive row timestamps (recommended if you are using `FUSED_RESAMPLED` data). This parameter impacts all the time calculations.
@@ -114,18 +114,18 @@ Features description for `[PHONE_LOCATIONS][PROVIDERS][BARNETT]`:
|-------------------------- |---------- |---------------------------|
|locationvariance |$meters^2$ |The sum of the variances of the latitude and longitude columns.
|loglocationvariance | - | Log of the sum of the variances of the latitude and longitude columns.
-|totaldistance |meters |Total distance travelled in a day segment using the haversine formula.
-|averagespeed |km/hr |Average speed in a day segment considering only the instances labeled as Moving.
-|varspeed |km/hr |Speed variance in a day segment considering only the instances labeled as Moving.
+|totaldistance |meters |Total distance travelled in a time segment using the haversine formula.
+|averagespeed |km/hr |Average speed in a time segment considering only the instances labeled as Moving.
+|varspeed |km/hr |Speed variance in a time segment considering only the instances labeled as Moving.
|circadianmovement |- | \"It encodes the extent to which a person's location patterns follow a 24-hour circadian cycle.\" [Doryab et al.](../../citation#doryab-locations).
|numberofsignificantplaces |places |Number of significant locations visited. It is calculated using the DBSCAN clustering algorithm which takes in EPS and MIN_SAMPLES as parameters to identify clusters. Each cluster is a significant place.
-|numberlocationtransitions |transitions |Number of movements between any two clusters in a day segment.
+|numberlocationtransitions |transitions |Number of movements between any two clusters in a time segment.
|radiusgyration |meters |Quantifies the area covered by a participant
|timeattop1location |minutes |Time spent at the most significant location.
|timeattop2location |minutes |Time spent at the 2nd most significant location.
|timeattop3location |minutes |Time spent at the 3rd most significant location.
|movingtostaticratio | - | Ratio between the number of rows labeled Moving versus Static
-|outlierstimepercent | - | Ratio between the number of rows that belong to non-significant clusters divided by the total number of rows in a day segment.
+|outlierstimepercent | - | Ratio between the number of rows that belong to non-significant clusters divided by the total number of rows in a time segment.
|maxlengthstayatclusters |minutes |Maximum time spent in a cluster (significant location).
|minlengthstayatclusters |minutes |Minimum time spent in a cluster (significant location).
|meanlengthstayatclusters |minutes |Average time spent in a cluster (significant location).
diff --git a/docs/features/phone-messages.md b/docs/features/phone-messages.md
index fec2957a..2c3d3108 100644
--- a/docs/features/phone-messages.md
+++ b/docs/features/phone-messages.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_MESSAGES]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
@@ -34,11 +34,11 @@ Features description for `[PHONE_MESSAGES][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-|count |messages |Number of messages of type `messages_type` that occurred during a particular `day_segment`.
-|distinctcontacts |contacts |Number of distinct contacts that are associated with a particular `messages_type` during a particular `day_segment`.
-|timefirstmessages |minutes |Number of minutes between 12:00am (midnight) and the first `message` of a particular `messages_type` during a particular `day_segment`.
-|timelastmessages |minutes |Number of minutes between 12:00am (midnight) and the last `message` of a particular `messages_type` during a particular `day_segment`.
-|countmostfrequentcontact |messages |Number of messages from the contact with the most messages of `messages_type` during a `day_segment` throughout the whole dataset of each participant.
+|count |messages |Number of messages of type `messages_type` that occurred during a particular `time_segment`.
+|distinctcontacts |contacts |Number of distinct contacts that are associated with a particular `messages_type` during a particular `time_segment`.
+|timefirstmessages |minutes |Number of minutes between 12:00am (midnight) and the first `message` of a particular `messages_type` during a particular `time_segment`.
+|timelastmessages |minutes |Number of minutes between 12:00am (midnight) and the last `message` of a particular `messages_type` during a particular `time_segment`.
+|countmostfrequentcontact |messages |Number of messages from the contact with the most messages of `messages_type` during a `time_segment` throughout the whole dataset of each participant.
!!! note "Assumptions/Observations"
1. `[MESSAGES_TYPES]` and `[FEATURES]` keys in `config.yaml` need to match. For example, `[MESSAGES_TYPES]` `sent` matches the `[FEATURES]` key `sent`
diff --git a/docs/features/phone-screen.md b/docs/features/phone-screen.md
index c1203f7b..e438e328 100644
--- a/docs/features/phone-screen.md
+++ b/docs/features/phone-screen.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_SCREEN]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
diff --git a/docs/features/phone-wifi-connected.md b/docs/features/phone-wifi-connected.md
index 216a22ee..537bfd44 100644
--- a/docs/features/phone-wifi-connected.md
+++ b/docs/features/phone-wifi-connected.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_WIFI_CONNECTED]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android and iOS
!!! info "File Sequence"
@@ -33,9 +33,9 @@ Features description for `[PHONE_WIFI_CONNECTED][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-| countscans | devices | Number of scanned WiFi access points connected during a day_segment, an access point can be detected multiple times over time and these appearances are counted separately |
-| uniquedevices | devices | Number of unique access point during a day_segment as identified by their hardware address |
-| countscansmostuniquedevice | scans | Number of scans of the most scanned access point during a day_segment across the whole monitoring period |
+| countscans | devices | Number of scanned WiFi access points connected during a time_segment, an access point can be detected multiple times over time and these appearances are counted separately |
+| uniquedevices | devices | Number of unique access point during a time_segment as identified by their hardware address |
+| countscansmostuniquedevice | scans | Number of scans of the most scanned access point during a time_segment across the whole monitoring period |
!!! note "Assumptions/Observations"
1. A connected WiFI access point is one that a phone was connected to.
diff --git a/docs/features/phone-wifi-visible.md b/docs/features/phone-wifi-visible.md
index 2a098e81..60786e07 100644
--- a/docs/features/phone-wifi-visible.md
+++ b/docs/features/phone-wifi-visible.md
@@ -8,8 +8,8 @@ Sensor parameters description for `[PHONE_WIFI_VISIBLE]`:
## RAPIDS provider
-!!! info "Available day segments and platforms"
- - Available for all day segments
+!!! info "Available time segments and platforms"
+ - Available for all time segments
- Available for Android only
!!! info "File Sequence"
@@ -33,9 +33,9 @@ Features description for `[PHONE_WIFI_VISIBLE][PROVIDERS][RAPIDS]`:
|Feature |Units |Description|
|-------------------------- |---------- |---------------------------|
-| countscans | devices | Number of scanned WiFi access points visible during a day_segment, an access point can be detected multiple times over time and these appearances are counted separately |
-| uniquedevices | devices | Number of unique access point during a day_segment as identified by their hardware address |
-| countscansmostuniquedevice | scans | Number of scans of the most scanned access point during a day_segment across the whole monitoring period |
+| countscans | devices | Number of scanned WiFi access points visible during a time_segment, an access point can be detected multiple times over time and these appearances are counted separately |
+| uniquedevices | devices | Number of unique access point during a time_segment as identified by their hardware address |
+| countscansmostuniquedevice | scans | Number of scans of the most scanned access point during a time_segment across the whole monitoring period |
!!! note "Assumptions/Observations"
1. A visible WiFI access point is one that a phone sensed around itself but that it was not connected to. Due to API restrictions, this sensor is not available on iOS.
diff --git a/docs/file-structure.md b/docs/file-structure.md
index b3744db5..d4c3f6ad 100644
--- a/docs/file-structure.md
+++ b/docs/file-structure.md
@@ -5,14 +5,14 @@
All paths mentioned in this page are relative to RAPIDS' root folder.
-If you want to extract the behavioral features that RAPIDS offers, you will only have to create or modify the [`.env` file](../setup/configuration/#database-credentials), [participants files](../setup/configuration/#participant-files), [day segment files](../setup/configuration/#day-segments), and the `config.yaml` file. The `config.yaml` file is the heart of RAPIDS and includes parameters to manage participants, data sources, sensor data, visualizations and more.
+If you want to extract the behavioral features that RAPIDS offers, you will only have to create or modify the [`.env` file](../setup/configuration/#database-credentials), [participants files](../setup/configuration/#participant-files), [time segment files](../setup/configuration/#time-segments), and the `config.yaml` file. The `config.yaml` file is the heart of RAPIDS and includes parameters to manage participants, data sources, sensor data, visualizations and more.
All data is saved in `data/`. The `data/external/` folder stores any data imported or created by the user, `data/raw/` stores sensor data as imported from your database, `data/interim/` has intermediate files necessary to compute behavioral features from raw data, and `data/processed/` has all the final files with the behavioral features in folders per participant and sensor.
All the source code is saved in `src/`. The `src/data/` folder stores scripts to download, clean and pre-process sensor data, `src/features` has scripts to extract behavioral features organized in their respective subfolders , `src/models/` can host any script to create models or statistical analyses with the behavioral features you extract, and `src/visualization/` has scripts to create plots of the raw and processed data.
-There are other important files and folders but only relevant if you are interested in extending RAPIDS (e.g. virtual env files, docs, tests, Dockerfile, the Snakefile, etc.). In the figure below, we represent the interactions between users and files. After a user modifies `config.yaml` and `.env` the `Snakefile` file will decide what Snakemake rules have to be executed to produce the required output files (behavioral features) and what scripts are in charge of producing such files. In addition, users can add or modifiy files in the `data` folder (for example to configure the [participants files](../setup/configuration/#participant-files) or the [day segment files](../setup/configuration/#day-segments)).
+There are other important files and folders but only relevant if you are interested in extending RAPIDS (e.g. virtual env files, docs, tests, Dockerfile, the Snakefile, etc.). In the figure below, we represent the interactions between users and files. After a user modifies `config.yaml` and `.env` the `Snakefile` file will decide what Snakemake rules have to be executed to produce the required output files (behavioral features) and what scripts are in charge of producing such files. In addition, users can add or modifiy files in the `data` folder (for example to configure the [participants files](../setup/configuration/#participant-files) or the [time segment files](../setup/configuration/#time-segments)).