...
performance of a scheduled assessment → upload → export → indexing for analysis → post-processing (including things like validation or indexing by Bridge)
We have discussed a few aspects about how this might work:
How data is grouped during upload is not important to scientists, as long as it be grouped in a useful manner when it is made available to scientists (this does not necessarily mean grouped together physically… and index between grouping concepts in files, like an index of files from a single assessment, is would be okay). As said by some scientist Dan during one of our meetings: "colocation is the biggest win for researchers." Having said that, the only way we may be able to provide colocation is by ensuring that data from a particular bounded unit (the assessment, a session instancesinstance) is store stored together.
The semantics of data generated from an assessment should be documented as part of the assessment’s development. Documentation support is being built into the design of assessments, which can then be made public or shared for other studies to use.
Syntactic validation will probably center on some simple checks of the ZIP files, ZIP file entries, and file types in an upload (for example, does a file exist, does it have some bytes in it). This processing would happen on the Bridge worker platform as part of post-processing, sending an error back to the app development team.
Reports Assessments also need documentationhave reports that need to be documented, including some validation support like providing schemas for client developers to use to validate their report data;. Bridge would not know about this, it’s for the use of client developers. The assessment API is being rewritten in part so that assessments can have server-managed state similar to what the reports API is being used for now.
A lifecycle for assessments might help, for example, when determining whether or not to validate (however I doubt this since we also have examples of needing to troubleshoot in production, eg. running code in a simulator. In this environment, some files might be missing, and that shouldn’t generate spurious validation errors).
If you think about the various environments in which the client app can be run as profiles, there are really only a couple of values that might change: whether or not a file is required, and whether or not it should be validated in some manner.
Simple profiles:
development
published
simulator
Things that can change by profile:
required?
validated? (if not required and not present, not validated). This validation at
first would just be that the file contained bytes.
In addition to these concerns, we can ask how data has to be grouped…
...