establish CI to produce / update shipped nidm.jsonld in nidm branch

[yarikoptic]

first #6 should be done

then this CI run would run either triggered by an update to dataset (e.g. when #7 pushes an update) or on cron.

it should push updated (if anything changed) file back to the fork .

[yarikoptic]

ATM master is "openbagel-improved". I think we might want to establish a "pipeline of enhancements" and have master to be the merge branch accumulating them all while openbagel having only openbagel tune ups and nidm only bids2nidm? WDYT @surchs?

[surchs]

I think the goal would be to have any augmentations / semantic-annotations to the OpenNeuro datasets done in a format that is generic and usable by everyone. That was my takeaway from our little hackathon thing in Montreal last November. For example, the augmented participants.json files we have in the master branch here is not supposed to be a neurobagel type of annotation but something that is BIDS compatible and contains enough information to also make a nidm or dandi representation.

There's probably some more discussion to be done on the exact format of this file. We discussed starting a BEP with the OpenNeuro folks to make the format play nice with BIDS tooling (OpenNeuroOrg/openneuro#2807 (comment)) and we'll also talk this evening with the Repronim folks. But I vote for keeping the annotation as a shared thing, and then have bot-tools knit the different harmonized representations from them.

[surchs]

@yarikoptic: let's say we

• keep the "generic" type annotation / aka "augmented participants.json that everyone can use in the master branch
• make sub-branches for the different flavours of "I make a graph jsonld file from the dataset and the augmented participants.json file"

then how should we do

then this CI run would run either triggered by an update to dataset (e.g. when #7 pushes an update)

Is there some "any repo was updated" hook you were thinking of? Or do we need to specify such a job in each forked dataset repo separately?