...
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, would be okay). As said by 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 instance) is 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.
Assessments also have 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).
Validation
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.
...
Things that can change by profile:
is it required?
validatedwhat validation should occur? (if not required and not present, not validated). This validation at
first would just be that the file contained bytes.none, or something else)?
Export
In addition to these concerns, we can ask how data has to be grouped…
Data from a single assessment is ideally in a single upload. Assuming we want this, study designers can create new assessments out of old assessments, and we’ll need to know what the structure of a zip file should look like when this happens. (And the structure of a related reportreport… or though maybe the server doesn’t need to know any of this if it’s just storying the file.)
Data from a session instance should be identified by a common session instance identifier (currently called a “run” id).
There are other ways that researchers may want to group and access data: by participant; by study arms; by demographic characteristics; by protocol; by a type of assessment. In essence we want to post-process the data so it is “indexed” by the metadata characteristics of the data files. This would give access to the The session instance relationship , among other thingswould be covered by this, but it would also be flexible.
Data needs to go into projects in Synapse. We also have a question as to how the data should be divided between projects. Three possibilities that we’ve discussed:
...
On the downside, if one organization wants another organization’s data, even the data of the main study, they’d have to ask for it. Alternatively, we We could possibly create a system to where an organization could grant access from one project to another organization, and allow the export system to copy the uploaded data to multiple projects based on this configuration. A study administrator could be allowed to grant access like this(or pointers to that data) into the projects for both those organizations. But that’s only a partial solution since many of those arrangements could be made after the data was exported to Synapse.
Data from a protocol to one project. This would be the most fine-grained separation of data from an app. Even if a single organization updated a protocol (a the study was renewed with slight changes, or some changes are made mid-study as part of an app release), the data would go to separate projects. I usually stop there haven’t thought much further about this option because it doesn’t seem useful.
...