-
Notifications
You must be signed in to change notification settings - Fork 33
A Set of APIs for Personal Data
OpenPDS provides a means of storing raw sensor data, processing that raw data into answers, and retrieving these answers. This article describes how to push raw data to openPDS. Every publicly available endpoint within openPDS uses bearer_token and datastore_owner__uuid querystring parameters as a means of authorizing access to the endpoint.
OpenPDS provides built-in support for storing raw Funf data via the /funf_connector/data endpoint. The application generating this data posts an encrypted SQLite db file containing raw Funf data to this endpoint, passing in an OAuth 2.0 bearer token (provided by a registry server) and the datastore owner's uuid as the bearer_token and datastore_owner__uuid querystring parameters, respectively. The bearer_token provided must be approved for the funf_write scope.
Please see the InternalDataStore API for details on how to access data within the PDS.
See answering questions for details on constructing answer modules to run within the PDS.
After processing raw data into answers, an application can retrieve these answers via the answer or answerlist REST endpoints on the PDS. These are located at /api/personal_data/answer and /api/personal_data/answerlist, respectively. Each of these endpoints take bearer_token and datastore_owner__uuid as querystring parameters, as well as the key for the answer to retrieve. The bearer_token provided must have a scope associated with the answer key it is requesting - if the bearer_token does not have a scope associated with the key being requested, the endpoint will return a 401 (unauthorized) response.
Example answerlist data can be found here:
Example answer data can be found here:
Upon signing into the Social Health Tracker application (or, in the case of the MIT Mobile app, upon opting in to Living Labs data collection), a Registry Server is contacted to authorize access to the user's PDS for the application via an OAuth 2.0 token. This includes authorization to write Funf data, as well as to read social health answers that the application's server-side data processing generates. After receiving this token, the location of the user's PDS, and the user's unique id within openPDS (the datastore_owner__uuid), the application begins data collection and processing on the server.
The Social Health Tracker application uses the data collected from the MIT Mobile Application to determine scores for social, activity, and focus metrics. It collects the raw data via the Funf connector described above, and implements a single task (and helper methods) within openPDS to process this data into 4 answers: socialhealth (used to populate the radial graph), RecentActivtityByHour, RecentSocialByHour, and RecentFocusByHour (to populate the time graphs). The socialhealth answer uses the last week's worth of ActivityProbe data for the activity score, SMS, call logs, and bluetooth probes for the social score, and screen on events for focus. The code to create theses answers is located in oms_pds/tasks.py.
Graphs are constructed in HTML, javascript, and CSS using jQuery and d3.js. Upon loading each graph's page, a request is made using Backbone.js to the answerlist endpoint on the user's PDS, providing the key for the respective answer, along with the bearer_token and datastore_owner__uuid. These pages are loaded into a WebView for display within the application.
The aggregate socialhealth answer described above is provided by each PDS to contribute to the average social health scores displayed on the graphs. After contributing to this computation, a copy of the group answer is pushed back into the socialhealth answer on the user's PDS. There is currently no means of opting out of this aggregate data collection aside form uninstalling the application / lab.