CARP Core Library
This package is one of the software components in the the overall Copenhagen Research Platform (CARP).
This package contains the CARP Core domain model as implemented in Dart. It contains the domain model used in the carp_mobile_sensing framework and all of its supporting libraries, packages, etc.
This package does nothing on its own.
Documentation
-
For an overview of CARP Mobile Sensing (CAMS), see the CARP Mobile Sensing homepage. Also see the carp_mobile_sensing framework on pub.dev, as well as the API documentation.
-
For an overview of all CAMS packages, see CARP Mobile Sensing in Flutter.
-
For documentation on how to use CAMS, see the documentation.
-
For a thorough description of the CARP Core domain model, see the carp.core-kotlin repository. The
example.dartof this package illustrates how the Kotlin examples are implemented using Dart.
License
This software is copyright (c) the Technical University of Denmark (DTU) and is part of the Copenhagen Research Platform. This software is available 'as-is' under a MIT license.
Libraries
- carp_core
- This library contains the core domain model for the Copenhagen Research Platform (CARP). This is a Dart implementation of the Kotlin CARP Core Domain Model. This is used in the CARP Mobile Sensing (CAMS) framework implemented in Flutter, and all of its sub-packages.
- client
- The runtime which performs the actual data collection on a device (e.g., desktop computer or smartphone). The client subsystem contains reusable components which understand the runtime configuration derived from a study protocol by the ‘deployment’ subsystem. Integrations with sensors are loaded through a 'device data collector' plug-in system to decouple sensing — not part of core — from sensing logic.
- common
- Contains common CARP domain classes which are used across the libraries.
- data
- Contains all pseudonymized data. When combined with the original study protocol, the full provenance of the data (when/why it was collected) is known.
- deployment
- Maps the information specified in a study protocol to runtime configurations used by the 'clients' subsystem to run the protocol on concrete devices (e.g., a smartphone) and allow researchers to monitor their state. To start collecting data, participants need to be invited, devices need to be registered, and consent needs to be given to collect the requested data.
- protocol
- Implements open standards which can describe a study protocol, i.e., defining how a study should be run. Essentially, this subsystem has no technical dependencies on any particular sensor technology or application as it merely describes why, when, and what data should be collected.