However, I actually think, this is not necessary question. Why? Because using object-oriented programming, one can simply design a data object (for example an object for single subjects) that simply knows where the data is located.
In OOP, we start by defining some properties that our object will need to have. Therefore, this view already enforces us to plan beforehand what we would like to achieve with a given object we are programming. For example, if our aim is to define an object for representing individual subjects recorded in an experiment (a Subject object 😀), this object might have the following properties defined:
classdef Subject < Project
id %subject ID
path %path to the participant
And, my Subject object for the recorded participant number 5 could be constructed as follows:
>> s = Subject(5)
Subject 05 (/Users/onat/Documents/project_FPSA_FearGen/data//sub005/)
Subject with properties:
path : '/data//sub005/'
path_fmri : '/data/sub005/run000/fmri'
path_eye : '/data//sub005/run000/eye'
path_scr : '/data//sub005/run000/scr'
This data has been filled in by the methods that are included in the definition of the Subject object. For example, a single-liner method called get.path_fmri fills in the path to the fmri data for this subject. This could be easily changed or adapted to fit another data set (given that is consistent across participants).
Therefore according to my view, the key is not to settle on a convention that everybody will agree for folder structures, but rather to use intelligent objects to represent scientific data, that already know where things are stored. This is one of the enormous benefits OOP introduces for the organization and analysis of scientific data.