minor edits, rephrase a few sentences

wadpac · Sep 3, 2024 · df79c41 · df79c41
1 parent f172297
commit df79c41
Show file tree

Hide file tree

Showing 6 changed files with 26 additions and 31 deletions.
diff --git a/docs/articles/chapter2_Pipeline.html b/docs/articles/chapter2_Pipeline.html
diff --git a/docs/articles/chapter3_QualityAssessment.html b/docs/articles/chapter3_QualityAssessment.html
diff --git a/docs/pkgdown.yml b/docs/pkgdown.yml
@@ -29,7 +29,7 @@ articles:
   HouseHoldCoanalysis: HouseHoldCoanalysis.html
   readmyacccsv: readmyacccsv.html
   TutorialDaySegmentAnalyses: TutorialDaySegmentAnalyses.html
-last_built: 2024-09-03T06:54Z
+last_built: 2024-09-03T07:43Z
 urls:
   reference: https://wadpac.github.io/GGIR/reference
   article: https://wadpac.github.io/GGIR/articles
diff --git a/docs/search.json b/docs/search.json
diff --git a/vignettes/chapter2_Pipeline.Rmd b/vignettes/chapter2_Pipeline.Rmd
@@ -46,14 +46,14 @@ Each part, when run, stores its output in an R-data file that has `.RData` as it
 
 The milestone files are read by the next GGIR part. The advantage of this design is that it offers internal modularity. For example, we can run part 1 now and continue with part 2 another time without having to repeat part 1 again. So, this design eases re-processing and is also helpful for us when developing and testing the GGIR code.
 
-The milestone files are stored in sub-folders of the output folder as show below. Note that the output folder is named `output_mystudy` as example but exact name may differ for you.
-
--   Part 1 milestone data are stored in `output_mystudy/meta/basic`.
--   Part 2 milestone data are stored in `output_mystudy/meta/ms2.out`.
--   Part 3 milestone data are stored in `output_mystudy/meta/ms3.out`.
--   Part 4 milestone data are stored in `output_mystudy/meta/ms4.out`.
--   Part 5 milestone data are stored in `output_mystudy/meta/ms5.out`.
--   Part 6 milestone data are stored in `output_mystudy/meta/ms6.out`.
+The milestone data files are stored in sub-folders of the output folder as show below. Note that the output folder is named `output_mystudy` as example but exact name may differ for you.
+
+-   For part 1: `output_mystudy/meta/basic`.
+-   For part 2: `output_mystudy/meta/ms2.out`.
+-   For part 3: `output_mystudy/meta/ms3.out`.
+-   For part 4: `output_mystudy/meta/ms4.out`.
+-   For part 5: `output_mystudy/meta/ms5.out`.
+-   For part 6: `output_mystudy/meta/ms6.out`.
 
 The milestone files are potentially useful for you for the following reasons:
 

diff --git a/vignettes/chapter3_QualityAssessment.Rmd b/vignettes/chapter3_QualityAssessment.Rmd
@@ -18,7 +18,7 @@ Data quality assurance is an important part of GGIR. GGIR undertakes several key
 
 ## Time gaps identification and imputation
 
-Accelerometer data stored in binary format (e.g. .bin or .cwa) where it is typically structured in data blocks. Each data block has a header at the top and a constant number of data points often represent a few seconds of data. For the Axivity accelerometer with data stored in '.cwa' file format those blocks can, on rare occasions, be corrupted and unreadable, therefore creating a gap in the information recorded.
+Accelerometer data stored in binary format (e.g. .bin or .cwa) is typically structured in data blocks. Each data block has a header at the top and a constant number of data points per block, usually the equivalent of a few seconds of data. For the Axivity accelerometer with data stored in '.cwa' file format those blocks can, on rare occasions, be corrupted and unreadable, therefore creating a gap in the information recorded.
 
 For the ActiGraph accelerometer, but also some other sensor brands that export data in ‘csv’ file format, it is possible that the recording stops at certain time and starts recording after some time, therefore creating a time gap.