Filename convention
Store numerical or categorical feature data derived from sensor
or event
files.
Filename convention
Feature files could be in arbitrary length. But for on-the-fly computation, it is recommended to store features in hourly length to keep the file size reasonably small for fast I/O.
This often ships with source code that indicates the computation of the feature, the source code should be clear about FEATUREID and VERSIONCODE.
FeatureType
Used to represent the name of the feature. If multiple features are combined into one file, becoming a feature set, then feature type should clearly state the name of the feature set.
CamelStyle, allowed characters: alphabets and digits.
Required.
Examples
For single feature file: Correlation
, DominantFrequency
, PhoneVariance
, DominantWristActivityCount
.
For feature set file: TimeDomainFeatures
, DominantWristFeatures
.
FEATUREID
Locally unique identifible for current feature set, flexible to include location, id, and any information.
UPPERCASE style, allowed characters: alphabets, digits and dash.
Required.
Examples
For feature set: DOMINANTWRIST
, DOMINANTWRIST-PARTICIPANT1TO3
For single feature: DOMIANTWRIST-CORRELATION
, [IMEI]-CORRELATION
VERSIONCODE
It's possible feature gets updated, then use
VERSIONCODE
to indicate the difference.Optional, if omit, use
NA
instead.Allowed characters: alphabets and digits.
Timestamp
Timestamp has the same convention as that of sensor data. The time represents the first row of annotation.
Last updated