What should we return to a user for pheno-only subjects

[surchs]

We have decided that we will support datasets where some or even all subjects have only phenotypic data, and no (BIDS) imaging data. In our current data model this means that these subjects won't have acquisition nodes, and that they also won't have file paths to their session nodes. For the API this means that there will be a mismatch between the reported number of matching subjects*sessions, and the number of returned file paths - in an extreme case where none of the matching subjects have imaging data, the list of file paths might be empty even though we are finding subjects that match the criteria.

We should discuss what information we want to return to a user in such a case.

User-facing documentation is also needed to alert the user that (currently) the list of file paths returned for a query only covers subjects with BIDS imaging data (done).

[github-actions]

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 30 days.
We have applied the stale-issue label to indicate that this issue should be reviewed again and then either prioritized or closed.

[alyssadai]

From the issue description, I think maybe the best way to prevent any confusion for now would be to update the docs issue, rather than modifying the response structure (which would be a more involved change). How about turning this into a docs issue for now, to clarify that file paths only correspond to subjects w/ BIDS data? (Also relevant now that we're adding IDPs).

[alyssadai]

Bumping this: as mentioned above, I think this was mainly a docs issue. Given that we have now reformatted the query tool result TSVs and corresponding documentation to clarify specific column names (including SessionFilePath -> ImagingSessionPath), I think the availability of pheno-only subject data will be less confusing.

@neurobagel/dev, can we close this issue or is there something else to discuss?

One thing to note is that since the column names are determined by the query tool, the session-level variables in the raw responses from the API currently still contain (the less clear) old names, e.g. session_file_path (see example here). If we think this is a problem for direct API users, we could rework this issue to entail renaming those variables in the API response.

[rmanaem]

One thing to note is that since the column names are determined by the query tool, the session-level variables in the raw responses from the API currently still contain (the less clear) old names, e.g. session_file_path (see example here). If we think this is a problem for direct API users, we could rework this issue to entail renaming those variables in the API response.

I think it's a good idea to have the same names across the tools.

[surchs]

Yeah, agree with @rmanaem, let's rename the session_paths in the API response to match what the query tool is displaying. I think this would be close enough to the original issue that we can keep the issue open and just rename / change the description. But I'm also OK with new issue and close the current issue because the original problem is in fact addressed.