The spec says "List of temporal software filters applied.", and this is an object that does not have an inherent ordering. If ordering is important, than this should probably be lists of single-element objects. If the ordering is not important, then it can be kept as is, but I would suggest updating the language of the spec to change from "list", which has a meaning in JSON.

As an example of a list of single-element objects:

  "SoftwareFilters": [
    {
      "Anti-aliasing filter": {
        "half-amplitude cutoff (Hz)": 500,
        "Roll-off": "6dB/Octave"
      }
    },
    {
      "Other filter": {
        "param1": "val1",
        "param2": "val2"
      }
    }
  ],

So far, we have always dealt with objects, see also the schema implemented in the validator

and the examples in the starter-kit

A change of language in the spec is thus warranted IMO.

And order does not matter? Because software that parses JSON is not obligated to provide key-value pairs in any particular order, or preserve it when copying metadata forward to derivatives.

This was never discussed in detail. I think in most use cases the order of filters (order in which they are applied after one another) is irrelevant - but in cases where it IS relevant, perhaps a keyword "order": "first" ... could be used? --> This would however be more easily solved with a list that has a naturally defined order, as you mentioned above Chris.

cc @robertoostenveld for some third opinion

tagging more EEG folks: Please read this thread and leave your opinion on how we want to format filters in BIDS. Estimated time: <5minutes @bids-standard/raw-electrophys

1. As far as I understand it, JavaScript Arrays are a bit like Python lists.
2. yes, the idea is that:
   1. either we allow an object ("SoftwareFilters") which contains one object per filter used .... and these filter objects then have key value pairs for their parameters
   2. OR we allow a list ("SoftwareFilters"), which is empty if None were applied ... or it contains objects, each of which is corresponding to a filter. Then the order of objects in the list corresponds to the order in which the respective filters were applied to the data

The second of the ideas above allows for an easy way to specify the order in which filters were used. ... the first of the ideas is how it's currently implemented in the validator

I think a practical solution would be to allow both variants. and IF the order of filters is relevant, then we RECOMMEND that users take the list of objects (solution 2) rather than the object of objects (solution 1) way.

Opinions?

@jasmainak

1. https://json.org/

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

Their grammar does refer to the structure as an array, so I suppose there's some ambiguity as to whether "list" is a reserved word in that sense. But it does have a common computer-science meaning, which is referenced above.

2. Sure.

To the point, though: does ordering ever matter? If it does, then I would suggest that an actual list (or array) be used. If it does not, then we can refer to it as an object.

To the point, though: does ordering ever matter? If it does, then I would suggest that an actual list (or array) be used. If it does not, then we can refer to it as an object.

this is a signal processing question, as long as the filters are linear, then the order of application of the filters should not matter.

I am not sure about non-linear filters though.

The example of an anti-aliasing filter without subsequent resampling does not make much sense for most acquisition systems. An anti aliasing filter would typically be implemented in hardware. I would prefer a better (i.e. a more common and more easily recognized) example.

Example:

The Brain Products BrainAmp always samples the data at 5kHz, applying a 1kHz anti-aliasing filter. However, in the recording software settings, you can also select lower sampling rates (e.g., 1kHz).

--> If that is done, the software applies a "software filter" and downsamples the data (online) ... before saving it to disk.

This is reflected in the present example, which I find good :-)

If you prefer a better example, could you perhaps suggest one?