User stories

[remiadon]

Until now we have discussed pros and cons of different concepts and features in BEP028. The few use cases implemented as sidecar .jsonld files corresponding to standard examples. To go a little bit deeper and foster a broader range of users we would like to formulate real-life examples and discuss their implementation with the current standard

First set of user stories

1. As a researcher I'd like to found out which realignment algorithm was applied in order to understand how it affects my final results
2. As an SPM developper implementing the BIDS-PROv export I'd like to get a list of all activities in order to verify that it is consistent with my matlabbatch script.
3. As an SPM user I'd like to visualize the BIDSProv graph corresponding to my matlabbtach file in order to get a visual representation of my pipeline (for example to be shared in a paper).

[remiadon]

@cmaumet what do you think of our first 3 user stories ? Do we need more ?

[cmaumet]

Hi @satra @yarikoptic @tiborauer @dbkeator @effigies @nicholst @jbpoline! With @remiadon, we would like to build a list of use-cases for BIDS-Prov.

Could you share with us (in a comment below), what would be your favorite way(s) of using the info available in BIDS-Prov (i.e. a description of the pipeline that was applied to a given dataset)? Thank you!

[tiborauer]

• connecting pipelines
• meta-analysis on methods
• Methods section writer :)

[nicholst]

• For investigation of megaverse analysies, a comprensive representation of all the options in all the different packages. This is both for the 'recording keeping' aspect, and also to have a formal structure to 'parameterise' the possible differences for prospective investigations (i.e. choosing which elements of a pipeline to manipulate).

• Echoing @tiborauer, conducting meta-analystic reviews of methods used, and then (for a set of studies all investigating the same task) proping the systematic differences in the results as explained by methodological differences extracted from BIDS-Prov.

[yarikoptic]

Some immediate ones. As a developer, after PROV data is mined into data archives/search engines I would like to

• find data produced by my tool (for reporting and other bragging rights)
• find data produced by a known to be a faulty tool (so similar to those bots who alert on github which pinned/bundled libraries need to be updated to avoid security issues etc)
• identify which versions of the tools were used when user reports a bug which I thought I had fixed already

As a user

• identify possibly why my results started to differ (change in tools versions or workflow behavior - new step added etc)
• detect when I start to use some other version of the tool from what was used before for prior/other subjects data

[satra]

@cmaumet - thanks for starting this. after we settle on a list it may be useful to cast them into a priority survey.

conceptual issue

• even the starting bids dataset is a derivative and has provenance. so this would at least tell us how a bids dataset was generated and could identify issues with scanners, dicom conversion, datalad, heudiconv/other converters.

more practical issues

• link entities to other entities they were derived from. right now this doesn't exist in BIDS.
• Find software used. Make methods searchable and visualizable
• Find transformers that generated a given file. (right now this is at the whole derivatives level, bids-prov could potentially give us more granularity)
• visualize analyses steps
• Generate COBIDAS compliant report
• Query parameters of any pipeline

more advanced use cases:

• Determine impact of different parameters and environment on results (this is related to the meta analysis issue)
• determine what pipelines can produce entity X and what inputs are required for that pipeline.
• Discover related transforms/pipelines/analyses
• Generate diffs between two pipelines
• Regenerate analyses from prov record

ps. i'm leaning towards using the term transform instead of pipeline, but in my head they are synonymous.