CRAN Task View Proposal: HumanActivityRecognition

[walkabilly]

trafficstars

Scope

The scope of this task view is to provide descriptions of packages that can be used for HumanActivityRecognition. Packages for both research grade devices (e.g., accelerometers or GPS devices) and commercial wearable devices (e.g., Fitbit) are included. Packages can range from those for data acquisition (e.g., connecting to APIs or reading in weird data formats), to data processing (e.g., missing data imputation specific to these data), to activity recognition (e.g., detecting steps or swimming). This Task View is necessary because of the area of HumanActivityRecognition is expanding rapidly, however, there is no hub to connect the various work that people are doing.

Inclusion criteria for packages

• Analysis involving humans (there are some packages for accelerometer data for cows and pigs)
• Analysis related to activity recognition and data processing for activity recognition

Exclusion criteria for packages

• Archived packages

Related packages

• The TimeSeries view is related to HumanActivityRecognition because much of the analysis work uses high-frequency time series data from accelerometers.

Maintainers

• Daniel Fuller, [email protected]
• Kevin Mongeon, [email protected]

Packages

We developed a package finder script to search relevant packages. We then manually reviewed the package names and descriptions to decide what to include in the task view. We then review the download statistics and discussed each package with colleagues to determine if it should be considered a core package. The package finder can easily be updated and packages can be included manually as well.

There is a repo with code examples for many published methods in Human Activity Recognition. This was developed by Dr. Kimberly Clevenger.

Core Packages

• GGIR
• fitbitr
• HMMpa
• MIMSunit
• mMARCH.AC
• walkboutr

Packages

Data acquisition

• fitbitr
• fitbitScraper
• GENEAread
• GGIRread
• lifelogr
• PASenseWear
• read.gt3x
• SwimmeR
• trackeRapp

Data processing

• acc
• accelerometry
• accelmissing
• ActFrag
• actilifecounts
• activAnalyzer
• activPAL
• impactr
• MIMSunit
• mMARCH.AC
• pawacc

Activity recognition

• cycleRtools
• GENEAsphere
• GENEAclassify
• HMMpa
• PhysActBedRest
• PhysicalActivity
• Sojourn.Data
• walkboutr

Miscellaneous

• fitbitViz

Archived Packages

• Sojour
• PAutilities
• activityCounts

[wibeasley]

This is cool. When it's approved, will you please notify/remind @pachadotdev and I in the Web Technologies TV. We'll add a quick reference to this, like we did for the spatial analysis web services:

[zeileis]

Thanks, Daniel @walkabilly & Kevin @kmongeon, for the proposal!

I think that the topic is interesting but somewhat narrow. Also, there is substantial overview with the following existing task views:

• Tracking
  Maintained by Rocío Joo @rociojoo and Mathieu Basille @basille. Already covers various of the more technical packages related to data reading/processing like GGIR, acc, accelerometry, pawacc, and PhysicalActivity.
• SportsAnalytics
  Maintained by Benjamin S. Baumer @beanumber, Quang Nguyen @qntkhvn, and Gregory J. Matthews @gjm112. Already covers some packages related to analytics of physical activity data like SwimmeR and trackeRapp.

Hence, my feeling is that there is no need for creating a new task view. Instead, I suggest that many of the packages which are currently not yet listed in any task view could be listed in the Tracking view, maybe even in a dedicated subsection. What do you think @rociojoo & @basille? Also, it would probably be good to add a link to the SportsAnalytics task view.

Additionally, some of the packages probably fit better into the SportsAnalytics task view because they are more geared to analytics of sports and physical activity. This task view already has a short section on "GPS Tracking" which already links to the Tracking task view. Maybe this section could be extended and generalized a bit, @beanumber & @qntkhvn & @gjm112?

[coatless]

@walkabilly regardless of whatever comes of the task view proposal, this is an outstanding list of packages and I greatly appreciate you putting together the list. If only you did it slightly earlier. 😉

@zeileis the suggested "Tracking" taskview feels more directed toward understanding animal movement than sensor-level data. Maybe a lot of this could be pivoted toward a "Sensors" task view with human activity being listed as a subsection?

[zeileis]

Thanks for the suggestion @coatless. Indeed, taking some of the packages out of the Tracking task view and putting them into a new broader view, such as Sensors or something similar, could also be a way forward.

[walkabilly]

I would be open to revising and having a Sensors view that would incorporate a broader set of packages. The other thing I had in mind was a BiosignalData view that would encompass data from accelerometers, ECG, EMG, etc, and potentially exclude GPS data. I find it hard to identify what would go in a Sensors view but BiosignalData might define what is in and what is out more clearly.

@coatless I've been sitting on this since 2020... life just got in the way. Arg.

[zeileis]

Thanks for the discussion! I think that BiosignalData might be a good way forward. Am I correct that this would not include GPS tracker data (which would remain in Tracking)?

I'm also curious whether the maintainers of the other task views and the other editors have some thoughts and feedback.

[walkabilly]

Thanks. Yes, in my mind the Biosignal data would not include GPS data and we could point people to the Tracking view for GPS data.

[zeileis]

Got it, makes sense to me 👍

Let's see what the others say...

[basille]

From our perspective, we're aiming at keeping the scope of the Tracking CTV very clear, i.e. focusing on tracking data (x,y,t). See the figure at the top of our CTV. So anything that can process raw data (i.e. sensor data, of whatever type) into tracking data would fit in the Tracking CTV. This said, we are primarily focused on animal movement, since this is what originated this CTV — and we do have a section that deals with movement but not tracking data (including the analysis of human accelerometry data). If the packages of this section (and specifically the subsection "Analysis of biologging data") would be covered in more details in the BiosignalData CTV, I think it would make sense to simply refer to it and remove this section in our CTV (as it's not about tracking data). What do you think @rociojoo?

[pachadotdev]

@walkabilly @zeileis as a person in academia, I find the narrow goal of the view to be a very strong feature. I am on medical leave now, so happy to contribute somehow in two weeks.

[zeileis]

Thanks Matthieu @basille, that sounds like a good plan to me!

[jpiaskowski]

Reading through this chain, I'm still a bit unclear what separates this proposed (Biosignal?) CTV from the Tracking CTV. Can you clarify?

I think your methodology for package inclusion is clear. For determining Core packages, I would urge you to consider more than popularity (as indicated by downloads). That is obviously one important factor, but I would also consider what packages provide critical functions, and ensure that each core package provides distinct and unique functions from the other 'core' packages.

[zeileis]

In my understanding, the Tracking task view originated as a collection for analyzing animal movement although tracking human movement from GPS devices (e.g., Strava etc.) also falls within this scope. They have this nice visualization of the tracking workflow:

They also have a short section on Dealing with movement but not tracking data that mainly gives a short overview of analyzing data from biologging devices (e.g., wearables like Fitbit, Actiheart, etc.). But this section is very short and does not really fit into the Tracking task view.

So the idea would be to remove this short section from the Tracking task view and expand it into a proper BiosignalData task view. The latter would not include the GPS tracking stuff for which it would refer to the Tracking task view.

Daniel @walkabilly , please correct/explain further and maybe comment on Julia's other points.

Given the discussion so far I'm in favor of endorsing further development of this task view into a full first draft. What are your thoughts Dirk @eddelbuettel, Julia @jpiaskowski, Nathalie @tuxette, Roger @rsbivand ? (If you agree, giving a 👍 is sufficient.)

[walkabilly]

Thanks.

In general, I think @zeileis sums my proposal up nicely. Create a new view for BioSignalData that would include some aspects from the Tracking view but also different data sources that extend beyond what is currently included in the "Dealing with movement but not tracking data." The movement but not tracking section is very cursory at the moment and would be included in the biosignal package.

Related to @jpiaskowski questions. Yes, I can adapt my current method for selecting packages and do a manual review for critical functions that would be considered when identifying packages are core or not.

[jpiaskowski]

Thank you @zeileis for clarifying.

[basille]

Thanks @zeileis and @walkabilly, this corresponds to my view of the Tracking CTV, and I can only encourage such a new CTV on sensors. We could refer to it in the Tracking CTV once it's published.

Just a word of caution on the inclusion of GPS: If it deals with tracking data (x,y,t), one way or the other, then it should find a place in the Tracking CTV — but we would only cover what relates to the processing, management and analysis of said tracking data. I understand that GPS can also be used for other purposes such as activity without involving tracking data. This would be out of scope. And vice versa for other sensors that can be used to compute tracking data, such as GLS, accelerometers, etc.

[zeileis]

OK, great! Thanks everybody for the productive discussion and to my fellow editors for the endorsement to continue.

Daniel @walkabilly and Kevin @kmongeon, I've set up a new repository and made you the maintainers: https://github.com/cran-task-views/BiosignalData. Daniel, you additionally have admin rights and can also add further contributors/maintainers. I would encourage you to expand the team of maintainers, adding one or two further people, maybe. Ideally, these should add to the diversity of the team, e.g., in terms of gender, geographical region, field of expertise, etc. This helps to spread the workload and to have different approaches represented in the task view.

The repository already contains a BiosignalData.md task view file but this actually just contains the header information at the moment - which you are free to revise, update, and extend, of course. See the Maintenance guidelines (and the technical documentation linked therein) to work out the first full draft of your task view. The report back here. If you have any questions, feel free to reach out at any time.

[zeileis]

Daniel @walkabilly and Kevin @kmongeon, so far there was no activity in the repository I have set up. Are you still interested in pursuing this task view?

[walkabilly]

Yes! I have the content in a different repo. Just need to move it over. Will do by next week.

[zeileis]

OK, I understand. I assume it is this repository, right? https://github.com/walkabilly/pa_task_view/blob/master/README.md

If so, then it's good to see that you have worked on the inclusion/exclusion criteria, this is very much appreciated. In addition to that, the task view should be worked out with more details and descriptions etc. Also, the .md file is currently a static Markdown file with hard-coded CRAN links etc. This should be replaced by a dynamic document using the r pkg(...) and r view(...) tags etc. See the maintenance guidelines for more details and links to the technical documentation.

[walkabilly]

Hi @zeileis. I've updated the repo here: https://github.com/walkabilly/BioSignalData_TaskView. Should I just paste what I have into this repo https://github.com/cran-task-views/BiosignalData? Thanks.

[zeileis]

Yes, please. Incorporate your md into the existing https://github.com/cran-task-views/BiosignalData/blob/main/BiosignalData.md file. Some further comments for improvement are included below.

• Note that we used "BiosignalData" with lower-case "s" as the compression for "Biosignal Data".
• If you intend to keep on using the R code for discovering new packages in the future, then I would adapt the R code correspondingly and also include it in the repository for the task view. If this was intended just for the initial setup (which is my impression) I would not discuss this so prominently and so early in the task view.
• More generally, I'm not sure how useful the Packages section really is. Download statistics should not be relevant for determining whether a package should be listed in the task view or not. Linking to Kimberly Clevenger's repository is certainly a good idea, though. Maybe also ask her to become a co-maintainer of the task view?
• The Maintainers section should be omitted. This information is contained in the header.
• The Related packages listing of the three related task views should be turned into a short paragraph with some brief explanations.
• Content on GitHub can be linked with r github(...) code chunks.
• The section Archived or Not on CRAN Packages section should be omitted. For the general strategy for handling archived packages see: https://github.com/cran-task-views/ctv/blob/main/Maintenance.md#cran-package-archivals
• Due to this, I would also recommend to drop the exclusion criterion Archived or deprecated packages. Many archived packages will eventually be excluded from the task view but some may come back to CRAN (possibly with some help/nudging) and for important packages one might continue to link the GitHub etc. But given that this is standard for the task views, I don't think it needs to be stated explicitly here.
• For DOIs you can use r doi(...) code chunks. I would recommend the following format for citations with DOIs:

  Brønd et al. (2017, `r doi("10.1249/MSS.0000000000001344")`)