[FIX] Specify marker filenames for KIT data (MEG) #62

monkeyman192 · 2018-10-22T23:29:51Z

closes #45

jasmainak · 2018-10-23T10:41:31Z

Looks reasonable to me

chrisgorgo · 2018-10-25T16:51:31Z

Thank you for opening the PR.

I got one concern: you are using the acq filename keyword which is free form everywhere else but in this particular case you two values are allowed. This makes the spec inconsistent. I would suggest proposing another keyword.

monkeyman192 · 2018-10-25T22:33:54Z

I just did this because it's what @robertoostenveld and @teonbrooks recommended.
I agree however that there is the potential of conflict by using acq, hence why I initially suggested to just suffix marker with pre or post.
Essentially making the line

sub-control01_ses-001_task-rest_run-01_markers[-pre,-post].<mrk,sqd>

I don't think this has to be an entirely new key-value pair that can be used elsewhere in the specification. This seems to be a unique scenario so I don't see why we can't just have something unique for it.

monkeyman192 · 2018-10-30T03:27:53Z

Any thoughts @chrisfilo @teonbrooks ? Would be nice to get this sorted.

chrisgorgo · 2018-10-30T03:35:13Z

I would prefer new tag (like marker) instead of reusing acq for reasons stated above, but we need more MEG people to join the conversation.

teonbrooks · 2018-10-30T19:11:16Z

since _markers is only specified for KIT in the spec, i think we could generalize it to a keyword as @chrisfilo suggested. I think having -pre and -post as its possible values is fine.

jasmainak · 2018-10-30T19:45:34Z

What would be the suffix if the key-value pair is marker-pre and marker-post ? Shouldn't all filenames in BIDS follow the format:

<key1>-<value1>_<key2>-<value2>_..._<suffix>.<extension>

?

chrisgorgo · 2018-11-08T20:51:38Z

This is a good question. There should be a prefix.

monkeyman192 · 2018-11-08T22:56:48Z

Could just reuse meg?
although it would then not make sense for when you don't specify pre or post...

jasmainak · 2018-11-09T06:04:01Z

I think the most backwards compatible solution would be to leave the suffix as it is (_markers.mrk) and instead come up with a new key-value pair to indicate weather it's recorded before or after a trial.

robertoostenveld · 2018-11-09T08:22:44Z

I would like a solution that scales to other types of data and not only KIT. Repeated measurements of 3-D coordinates of specific points (landmarks, fiducials=markers=headcoils, electrodes) with a digitizer (like a Polhemus) also can happens for CTF MEG recordings, but also EEG recordings, and might also happen in iEEG datasets.

The issue reminds me of a discussion that we had with "events" where it is considered desirable to have post-hoc "annotations" (i.e. events that are based on visual inspection of the data, i.e. offline) separate from the deterministic/objective events represented in the events.tsv file. Here you could think of spike or seizure detection, possibly done with different methods. The format would always be the same as for the events.tsv file, but multiple files are desired. That is also what we have for the marker files: there can be one or multiple (calling them pre/post would limit it to 2 files).

Just from a more principled viewpoint: A good (generic/scalable) solution would use a key-value pair. As an analogy: I suppose that run-1, run-2, ... would be used for repeated anatomical MRIs with the exactly the same scan parameters. The last part of the file should describe the type of data contained in the file (headshape, meg, eeg) and the extension the file format (ds, sqd, fif).

monkeyman192 · 2018-12-13T03:57:34Z

so I was looking through the specification for something else and noticed that the recording kvp is completely unused for MEG as far as I can tell, so maybe we could use this?
More specifically the name of the file would become:
sub-<label>[_ses-<label>][_task-<label>][_run-<label>][_recording-<pre,post>]_markers.<mrk,sqd>
Also, I think limiting this to two files is fine because you can't have more than two anyway I think.

chrisgorgo · 2018-12-13T16:55:39Z

I think recording is already used in physiological data: https://github.com/bids-standard/bids-specification/blob/master/src/04-modality-specific-files/04-physiological-and-other-continous-recordings.md#physiological-and-other-continuous-recordings

monkeyman192 · 2018-12-13T23:04:52Z

would it matter if were used for a different context for a pretty niche case?
I don't think it would cause any conflict as recording isn't used in any other context for MEG data

chrisgorgo · 2018-12-13T23:21:33Z

I would prefer to avoid such internal inconsistency by picking a different keyword.

jasmainak · 2018-12-15T23:40:10Z

@chrisfilo what would you suggest that maintains internal consistency? I suppose trying to use any of the existing keys would lead to consistency issues, so adding a new key-value pair seems to be the only solution.

chrisgorgo · 2018-12-15T23:44:43Z

Yes. I think adding a new keyword instead of redefining an old one would improve the consistency and make the standard more intuitive for people working with multiple modalities.

monkeyman192 · 2018-12-17T23:36:45Z

I completely see the justification for wanting to introduce another kvp to avoid inconsistencies, however it just seems silly to add another for just one single case.
I am not against adding another kvp, I just think we keep adding synonyms for recording (run, acquisition), sometimes it may be more confusing having more terms. When someone looks at the specification they may wonder why there are so many terms that all mean essentially the same thing.

Finally do you have a suggestion for an appropriate key? I can't really think of one that would be good. If we don't care about having the kvp used elsewhere then we could just use mark-<pre,post>_marker even if it sort of doubles up the marker tag.

robertoostenveld · 2018-12-18T07:58:23Z

I propose to consider this also in relation to EEG and especially iEEG specifications. For the iEEG it is not uncommon to have pre and post-operative data. For EEG it would be possible (but not common) to have pre- and post-measurement electrode digitizations.

robertoostenveld · 2018-12-18T08:03:06Z

besides the two pre and post, I think that more than two files with auxiliary data (i.e. data that enriches the core _meg/_eeg/_ieeg dataset) would also be possible. The labels pre and post are just two possible values. E.g. consider the case that multiple photos are taken of EEG electrodes or MEG markers, like with photogrammetry. The series of photos would be from different angles, but not from different moments per see.

monkeyman192 · 2018-12-18T23:01:53Z

maybe having meas (for measurement) as the key could work?
For the marker measurements we could say that the values have to be one of pre or post.
For other cases such as the photogrammetry the values could be un-restricted.

monkeyman192 · 2019-02-25T05:21:53Z

Any further thoughts on this? It would be quite nice to get this sorted as it blocks a few things that I am working on and the sooner it is sorted the less impact it has on all the data converted to BIDS format by where I work.

robertoostenveld · 2019-02-25T08:02:53Z

What would be the suffix if the key-value pair is marker-pre and marker-post ? Shouldn't all filenames in BIDS follow the format:

The suffix is already specified as headshape, i.e. as
sub-<label>[_ses-<label>][_acq-<label>]_headshape.<manufacturer_specific_extension>

In the thread above marker is suggested as suffix. I don't see the need for that, and I don't see it anywhere in the current specification.

Re: restricted versus free form values: I think that just pre and post applies often, but will not enough in practice. Therefore I think that the value should free form and hence acq as the key would work. I have a general preference of not introducing too many keys, especially not if they conceptually have the same meaning.

sappelhoff · 2019-02-25T08:11:47Z

I share both @monkeyman192 and @robertoostenveld's opinion about not having too many key-value pairs with overlapping (or even identical / synonymous) meaning. This adds to the confusion of the user rather than ease it.

Supporting what @robertoostenveld said furthermore about unrestricted values for the new key value pair (kvp), I would suggest that for MEG pre and post could be RECOMMENDED in the spec, ... while still all possible other values would be permitted.

I am in favor of re-using the acq keyword. It's meaning would be fitting.

Excerpt from the spec

The OPTIONAL acq- key/value pair corresponds to a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality.

Example

sub-control01_ses-001_task-rest_run-01[_acq-<aqc-label>]_markers.<mrk,sqd>

Where aqc-label can be any value
Note, that pre / post are RECOMMENDED to label coil data acquisition before or after an MEG recording

jasmainak · 2019-02-25T21:23:53Z

I agree with the views shared above by @robertoostenveld and @sappelhoff . We should reuse the acq key

sappelhoff

Reminder to please incorporate #19 (comment) in this PR

monkeyman192 · 2019-04-05T04:03:05Z

@sappelhoff ok, rebased and hopefully addressed your comment as well as addressing @yarikoptic 's comment and @robertoostenveld 's comment (I did reword it a bit however as I think the wording wasn't quite right. Hopefully you agree!!)

sappelhoff

Thanks @monkeyman192!

I just tested adding an acq parameter to a markers file by temporarily modifying the type.spec.js file in my local validator version and it works. :-)

src/99-appendices/06-meg-file-formats.md

sappelhoff

Thanks @monkeyman192. I also opened an issue on the validator that the order of parameters is not checked (at least for run and acq).

@jasmainak can you review and help Matt to get this merged? :-)

jasmainak

LGTM. The table is a bit hard to read. It would be nice if the CIs also build the doc and show it in the artifacts tab

effigies · 2019-04-15T18:04:06Z

@jasmainak

It would be nice if the CIs also build the doc and show it in the artifacts tab

https://496-150465237-gh.circle-artifacts.com/0/home/circleci/project/site/99-appendices/04-entity-table.html

jasmainak · 2019-04-15T18:11:58Z

Oh nice, sorry missed it. Thanks! And PR looks good to me.

sappelhoff · 2019-04-23T16:50:29Z

thanks @monkeyman192

Text is using both 'file name' and 'filename' pretty much to the equal amount ATM (see git grep outputs below). Code uses 'filename', and wikipedia has https://en.wikipedia.org/wiki/Filename and prefers to use 'filename' in it. So I decided to harmonize into 'filename'. $> git grep 'file name' | grep '\.md' | grep -v MACRO | nl 1 src/02-common-principles.md:1. **File extension** - a portion of the file name after the left-most 2 src/02-common-principles.md:are compulsory. For example a particular file name format is required when 3 src/02-common-principles.md:saved under a particular file name specified in the standard. This standard 4 src/02-common-principles.md:A file name consists of a chain of *entities*, or key-value pairs, a *suffix* and an 5 src/02-common-principles.md:`subject`, the file name MUST begin with the string `sub-<label>_ses-<label>`. 6 src/02-common-principles.md:If the `session` level is omitted in the folder structure, the file name MUST begin 7 src/02-common-principles.md:key/value pair MUST also be included as part of the file names themselves. 8 src/02-common-principles.md:produces a human readable file name, such as `sub-01_task-rest_eeg.edf`. 9 src/02-common-principles.md:It is evident from the file name alone that the file contains resting state 10 src/02-common-principles.md:Entities within a file name MUST be unique. 11 src/02-common-principles.md:For example, the following file name is not valid because it uses the `acq` 12 src/02-common-principles.md:label, but must be included in file names (similarly to other key names). 13 src/02-common-principles.md:meaning of file names and setting requirements on their contents or metadata. 14 src/02-common-principles.md:to suppress warnings or provide interpretations of your file names. 15 src/03-modality-agnostic-files.md:This file is REQUIRED if `sample-<label>` is present in any file name within the dataset. 16 src/04-modality-specific-files/05-task-events.md:Where `<matches>` corresponds to task file name. For example: 17 src/04-modality-specific-files/06-physiological-and-other-continuous-recordings.md:In the template file names, the `<matches>` part corresponds to task file name 18 src/05-derivatives/02-common-data-types.md:is used to prevent clashing with the original file name. 19 src/06-longitudinal-and-multi-site-studies.md:and [file names](02-common-principles.md#file-name-structure) 20 src/99-appendices/03-hed.md:screen or the file name of the stimulus image. 21 src/99-appendices/03-hed.md: "LongName": "Stimulus file name", 22 src/99-appendices/04-entity-table.md:[file name structure](../02-common-principles.md#file-name-structure), 23 src/99-appendices/06-meg-file-formats.md:that not only the file names, but also the internal file pointers will be 24 src/99-appendices/09-entities.md:[file name structure](../02-common-principles.md#file-name-structure). 25 src/CHANGES.md:- \[FIX] Clarify use of session entity in file names [bids-standard#532](bids-standard#532) ([Moo-Marc](https://github.com/Moo-Marc)) 26 src/CHANGES.md:- \[FIX] Specify marker file names for KIT data (MEG) [bids-standard#62](bids-standard#62) ([monkeyman192](https://github.com/monkeyman192)) 27 src/CHANGES.md:- Added missing `sub-<participant_label>` in behavioral data file names. 28 src/pregh-changes.md:- Added missing `sub-<participant_label>` in behavioral data file names. $> git grep 'filename' | grep '\.md' | grep -v MACRO | nl 1 CONTRIBUTING.md:Make sure that all filename format templates, entity tables, and entity definitions are correct 2 src/02-common-principles.md:(with the same filename as the `.nii[.gz]` file, but with a `.json` extension). 3 src/03-modality-agnostic-files.md: "filename": ("REQUIRED", "There MUST be exactly one row for each file."), 4 src/03-modality-agnostic-files.md:filename acq_time 5 src/04-modality-specific-files/02-magnetoencephalography.md:which saves the MEG sensor coil positions in a separate file with two possible filename extensions (`.sqd`, `.mrk`). 6 src/05-derivatives/01-introduction.md: status. Any modification of raw files must use a modified filename that does 7 src/05-derivatives/01-introduction.md: not conflict with the raw filename. Further, any files created as part of a 8 src/05-derivatives/01-introduction.md: derivative dataset must not match a permissible filename of a valid raw 9 src/05-derivatives/01-introduction.md: dataset. Stated equivalently, if any filename in a derivative dataset has a 10 src/05-derivatives/01-introduction.md:- Each Derivatives filename MUST be of the form: 11 src/05-derivatives/01-introduction.md: `source_entities` MUST be the entire source filename, with the omission of 12 src/05-derivatives/01-introduction.md: the source suffix and extension. One exception to this rule is filename 13 src/05-derivatives/01-introduction.md:- There is no prohibition against identical filenames in different derived 14 src/05-derivatives/03-imaging.md:filename. 15 src/99-appendices/04-entity-table.md:specification, and establishes a common order within a filename. 16 src/99-appendices/08-coordinate-systems.md:The `scanner` coordinate system is implicit and assumed by default if the derivative filename does not define **any** `space-<label>`. 17 src/99-appendices/11-qmri.md:filenames will remain the same; however, the optional metadata (third column) may 18 src/CHANGES.md:- \[SCHEMA] Use macro for filename templates in file collections appendix [bids-standard#787](bids-standard#787) ([tsalo](https://github.com/tsalo)) 19 src/CHANGES.md:- \[FIX] Accidentally swapped Neuromag/Elekta/MEGIN cross-talk & fine-calibration filename extensions [bids-standard#621](bids-standard#621) ([hoechenberger](https://github.com/hoechenberger)) 20 src/CHANGES.md:- \[INFRA] SCHEMA: Declare entities by concept names, add entity field for filename components [bids-standard#616](bids-standard#616) ([effigies](https://github.com/effigies)) 21 src/CHANGES.md:- \[FIX] Common principles: Fix filename in inheritance principle [bids-standard#261](bids-standard#261) ([Lestropie](https://github.com/Lestropie)) 22 src/CHANGES.md:- \[FIX] Example for IntendedFor was missing session indicator in the filename [bids-standard#129](bids-standard#129) ([yarikoptic](https://github.com/yarikoptic)) 23 src/schema/README.md:the entity tables, entity definitions, filename templates, and metadata tables. 24 src/schema/README.md:- `entities.yaml`: Entities (key/value pairs in folder and filenames). 25 src/schema/README.md:This file contains a dictionary in which each entity (key/value pair in filenames) is defined. 26 src/schema/README.md:they appear in filenames _and_ their full names. 27 src/schema/README.md:For example, the key for the "Contrast Enhancing Agent" entity, which appears in filenames as `ce-<label>`, 28 src/schema/README.md:since many entities (such as `ce`) have very short filename elements. 29 src/schema/README.md:The `entity` field is the entity as it appears in filenames. For example, the `entity` for `ceagent` is `ce`. 30 src/schema/README.md:Given that all entities appear in filenames, they should all be strings and the `type` field should always be `string`. 31 src/schema/README.md:For example, `run` should have an index, so a valid key-value pair in a filename would be `run-01`. 32 src/schema/README.md:Keys are the filenames (without file extensions), 33 src/schema/README.md:- `datatypes/*.yaml`: Files in the `datatypes` folder contain information about valid filenames within a given datatype. 34 src/schema/README.md: Each dictionary contains a list of suffixes, entities, and file extensions which may constitute a valid BIDS filename. 35 src/schema/README.md:- `entities.yaml`: This file simply defines the order in which entities, when present, MUST appear in filenames. 36 src/schema/README.md:Each dictionary corresponds to a group of suffixes that have the same rules regarding filenames. 37 src/schema/README.md:**NOTE**: The order in which entities appear in these dictionaries does not reflect how they should appear in filenames. 38 src/schema/README.md:This file contains a list of entities in the order in which they must appear in filenames. === Do not change lines below === { "chain": [], "cmd": "bash -c 'git grep -l '\"'\"'file name'\"'\"' | grep '\"'\"'\\.md'\"'\"' | grep -v MACRO | xargs sed -i -e '\"'\"'s,file name,filename,g'\"'\"''", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^

Text is using both 'file name' and 'filename' pretty much to the equal amount ATM (see git grep outputs below). Code uses 'filename', and wikipedia has https://en.wikipedia.org/wiki/Filename and prefers to use 'filename' in it. So I decided to harmonize into 'filename'. $> git grep 'file name' | grep '\.md' | grep -v MACRO | nl 1 src/02-common-principles.md:1. **File extension** - a portion of the file name after the left-most 2 src/02-common-principles.md:are compulsory. For example a particular file name format is required when 3 src/02-common-principles.md:saved under a particular file name specified in the standard. This standard 4 src/02-common-principles.md:A file name consists of a chain of *entities*, or key-value pairs, a *suffix* and an 5 src/02-common-principles.md:`subject`, the file name MUST begin with the string `sub-<label>_ses-<label>`. 6 src/02-common-principles.md:If the `session` level is omitted in the folder structure, the file name MUST begin 7 src/02-common-principles.md:key/value pair MUST also be included as part of the file names themselves. 8 src/02-common-principles.md:produces a human readable file name, such as `sub-01_task-rest_eeg.edf`. 9 src/02-common-principles.md:It is evident from the file name alone that the file contains resting state 10 src/02-common-principles.md:Entities within a file name MUST be unique. 11 src/02-common-principles.md:For example, the following file name is not valid because it uses the `acq` 12 src/02-common-principles.md:label, but must be included in file names (similarly to other key names). 13 src/02-common-principles.md:meaning of file names and setting requirements on their contents or metadata. 14 src/02-common-principles.md:to suppress warnings or provide interpretations of your file names. 15 src/03-modality-agnostic-files.md:This file is REQUIRED if `sample-<label>` is present in any file name within the dataset. 16 src/04-modality-specific-files/05-task-events.md:Where `<matches>` corresponds to task file name. For example: 17 src/04-modality-specific-files/06-physiological-and-other-continuous-recordings.md:In the template file names, the `<matches>` part corresponds to task file name 18 src/05-derivatives/02-common-data-types.md:is used to prevent clashing with the original file name. 19 src/06-longitudinal-and-multi-site-studies.md:and [file names](02-common-principles.md#file-name-structure) 20 src/99-appendices/03-hed.md:screen or the file name of the stimulus image. 21 src/99-appendices/03-hed.md: "LongName": "Stimulus file name", 22 src/99-appendices/04-entity-table.md:[file name structure](../02-common-principles.md#file-name-structure), 23 src/99-appendices/06-meg-file-formats.md:that not only the file names, but also the internal file pointers will be 24 src/99-appendices/09-entities.md:[file name structure](../02-common-principles.md#file-name-structure). 25 src/CHANGES.md:- \[FIX] Clarify use of session entity in file names [#532](#532) ([Moo-Marc](https://github.com/Moo-Marc)) 26 src/CHANGES.md:- \[FIX] Specify marker file names for KIT data (MEG) [#62](#62) ([monkeyman192](https://github.com/monkeyman192)) 27 src/CHANGES.md:- Added missing `sub-<participant_label>` in behavioral data file names. 28 src/pregh-changes.md:- Added missing `sub-<participant_label>` in behavioral data file names. $> git grep 'filename' | grep '\.md' | grep -v MACRO | nl 1 CONTRIBUTING.md:Make sure that all filename format templates, entity tables, and entity definitions are correct 2 src/02-common-principles.md:(with the same filename as the `.nii[.gz]` file, but with a `.json` extension). 3 src/03-modality-agnostic-files.md: "filename": ("REQUIRED", "There MUST be exactly one row for each file."), 4 src/03-modality-agnostic-files.md:filename acq_time 5 src/04-modality-specific-files/02-magnetoencephalography.md:which saves the MEG sensor coil positions in a separate file with two possible filename extensions (`.sqd`, `.mrk`). 6 src/05-derivatives/01-introduction.md: status. Any modification of raw files must use a modified filename that does 7 src/05-derivatives/01-introduction.md: not conflict with the raw filename. Further, any files created as part of a 8 src/05-derivatives/01-introduction.md: derivative dataset must not match a permissible filename of a valid raw 9 src/05-derivatives/01-introduction.md: dataset. Stated equivalently, if any filename in a derivative dataset has a 10 src/05-derivatives/01-introduction.md:- Each Derivatives filename MUST be of the form: 11 src/05-derivatives/01-introduction.md: `source_entities` MUST be the entire source filename, with the omission of 12 src/05-derivatives/01-introduction.md: the source suffix and extension. One exception to this rule is filename 13 src/05-derivatives/01-introduction.md:- There is no prohibition against identical filenames in different derived 14 src/05-derivatives/03-imaging.md:filename. 15 src/99-appendices/04-entity-table.md:specification, and establishes a common order within a filename. 16 src/99-appendices/08-coordinate-systems.md:The `scanner` coordinate system is implicit and assumed by default if the derivative filename does not define **any** `space-<label>`. 17 src/99-appendices/11-qmri.md:filenames will remain the same; however, the optional metadata (third column) may 18 src/CHANGES.md:- \[SCHEMA] Use macro for filename templates in file collections appendix [#787](#787) ([tsalo](https://github.com/tsalo)) 19 src/CHANGES.md:- \[FIX] Accidentally swapped Neuromag/Elekta/MEGIN cross-talk & fine-calibration filename extensions [#621](#621) ([hoechenberger](https://github.com/hoechenberger)) 20 src/CHANGES.md:- \[INFRA] SCHEMA: Declare entities by concept names, add entity field for filename components [#616](#616) ([effigies](https://github.com/effigies)) 21 src/CHANGES.md:- \[FIX] Common principles: Fix filename in inheritance principle [#261](#261) ([Lestropie](https://github.com/Lestropie)) 22 src/CHANGES.md:- \[FIX] Example for IntendedFor was missing session indicator in the filename [#129](#129) ([yarikoptic](https://github.com/yarikoptic)) 23 src/schema/README.md:the entity tables, entity definitions, filename templates, and metadata tables. 24 src/schema/README.md:- `entities.yaml`: Entities (key/value pairs in folder and filenames). 25 src/schema/README.md:This file contains a dictionary in which each entity (key/value pair in filenames) is defined. 26 src/schema/README.md:they appear in filenames _and_ their full names. 27 src/schema/README.md:For example, the key for the "Contrast Enhancing Agent" entity, which appears in filenames as `ce-<label>`, 28 src/schema/README.md:since many entities (such as `ce`) have very short filename elements. 29 src/schema/README.md:The `entity` field is the entity as it appears in filenames. For example, the `entity` for `ceagent` is `ce`. 30 src/schema/README.md:Given that all entities appear in filenames, they should all be strings and the `type` field should always be `string`. 31 src/schema/README.md:For example, `run` should have an index, so a valid key-value pair in a filename would be `run-01`. 32 src/schema/README.md:Keys are the filenames (without file extensions), 33 src/schema/README.md:- `datatypes/*.yaml`: Files in the `datatypes` folder contain information about valid filenames within a given datatype. 34 src/schema/README.md: Each dictionary contains a list of suffixes, entities, and file extensions which may constitute a valid BIDS filename. 35 src/schema/README.md:- `entities.yaml`: This file simply defines the order in which entities, when present, MUST appear in filenames. 36 src/schema/README.md:Each dictionary corresponds to a group of suffixes that have the same rules regarding filenames. 37 src/schema/README.md:**NOTE**: The order in which entities appear in these dictionaries does not reflect how they should appear in filenames. 38 src/schema/README.md:This file contains a list of entities in the order in which they must appear in filenames. === Do not change lines below === { "chain": [], "cmd": "bash -c 'git grep -l '\"'\"'file name'\"'\"' | grep '\"'\"'\\.md'\"'\"' | grep -v MACRO | xargs sed -i -e '\"'\"'s,file name,filename,g'\"'\"''", "exit": 0, "extra_inputs": [], "inputs": [], "outputs": [], "pwd": "." } ^^^ Do not change lines above ^^^

jasmainak previously approved these changes Oct 23, 2018

View reviewed changes

jasmainak mentioned this pull request Oct 25, 2018

[MRG] Simplify raw_to_bids mne-tools/mne-bids#106

Merged

monkeyman192 mentioned this pull request Dec 27, 2018

[MRG] Reader for raw data stored in BIDS format mne-tools/mne-bids#135

Merged

2 tasks

monkeyman192 dismissed jasmainak’s stale review via 903b90a February 25, 2019 22:19

monkeyman192 force-pushed the FIX_KIT_markers branch from 657647a to 903b90a Compare February 25, 2019 22:19

sappelhoff mentioned this pull request Mar 28, 2019

[FIX] Remove father-level for meg filetypes other than BTi/4D data #19

Merged

sappelhoff requested changes Mar 28, 2019

View reviewed changes

monkeyman192 added 6 commits April 5, 2019 14:51

apply changes over PR bids-standard#19

d139b9a

reword specification

b64c9a6

added markers to entity table

8e1da1b

fix acq label tag in spec and reworded a little

40c66d9

Changed wording as suggested by @robertoostenveld

19655b7

slight rewording and fixed acq-<label>

978960e

monkeyman192 force-pushed the FIX_KIT_markers branch from c625734 to 978960e Compare April 5, 2019 04:00

sappelhoff previously approved these changes Apr 5, 2019

View reviewed changes

sappelhoff requested review from jasmainak, robertoostenveld and yarikoptic April 5, 2019 07:50

sappelhoff reviewed Apr 6, 2019

View reviewed changes

src/99-appendices/06-meg-file-formats.md Outdated Show resolved Hide resolved

sappelhoff changed the title ~~Add specification for KIT marker file names~~ [FIX] Specify marker file names for KIT data (MEG) Apr 12, 2019

reordered run and acq parameters

a533e83

monkeyman192 dismissed sappelhoff’s stale review via a533e83 April 15, 2019 06:16

sappelhoff mentioned this pull request Apr 15, 2019

order of parameters in filename are not always verified bids-standard/legacy-validator#767

Closed

sappelhoff approved these changes Apr 15, 2019

View reviewed changes

jasmainak approved these changes Apr 15, 2019

View reviewed changes

sappelhoff merged commit 8d5a389 into bids-standard:master Apr 23, 2019

monkeyman192 deleted the FIX_KIT_markers branch April 23, 2019 22:45

sappelhoff mentioned this pull request Jun 21, 2019

Update MEG regexps and testsuite to comply with father level specification bids-standard/legacy-validator#789

Merged

sappelhoff changed the title ~~[FIX] Specify marker file names for KIT data (MEG)~~ [FIX] Specify marker filenames for KIT data (MEG) Dec 18, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[FIX] Specify marker filenames for KIT data (MEG) #62

[FIX] Specify marker filenames for KIT data (MEG) #62

monkeyman192 commented Oct 22, 2018

jasmainak commented Oct 23, 2018

chrisgorgo commented Oct 25, 2018 •

edited

Loading

monkeyman192 commented Oct 25, 2018 •

edited

Loading

monkeyman192 commented Oct 30, 2018

chrisgorgo commented Oct 30, 2018

teonbrooks commented Oct 30, 2018

jasmainak commented Oct 30, 2018 •

edited

Loading

chrisgorgo commented Nov 8, 2018

monkeyman192 commented Nov 8, 2018

jasmainak commented Nov 9, 2018

robertoostenveld commented Nov 9, 2018

monkeyman192 commented Dec 13, 2018

chrisgorgo commented Dec 13, 2018

monkeyman192 commented Dec 13, 2018

chrisgorgo commented Dec 13, 2018

jasmainak commented Dec 15, 2018

chrisgorgo commented Dec 15, 2018

monkeyman192 commented Dec 17, 2018

robertoostenveld commented Dec 18, 2018

robertoostenveld commented Dec 18, 2018

monkeyman192 commented Dec 18, 2018

monkeyman192 commented Feb 25, 2019

robertoostenveld commented Feb 25, 2019

sappelhoff commented Feb 25, 2019

jasmainak commented Feb 25, 2019

sappelhoff left a comment

monkeyman192 commented Apr 5, 2019

sappelhoff left a comment •

edited

Loading

sappelhoff left a comment

jasmainak left a comment

effigies commented Apr 15, 2019

jasmainak commented Apr 15, 2019

sappelhoff commented Apr 23, 2019

[FIX] Specify marker filenames for KIT data (MEG) #62

[FIX] Specify marker filenames for KIT data (MEG) #62

Conversation

monkeyman192 commented Oct 22, 2018

jasmainak commented Oct 23, 2018

chrisgorgo commented Oct 25, 2018 • edited Loading

monkeyman192 commented Oct 25, 2018 • edited Loading

monkeyman192 commented Oct 30, 2018

chrisgorgo commented Oct 30, 2018

teonbrooks commented Oct 30, 2018

jasmainak commented Oct 30, 2018 • edited Loading

chrisgorgo commented Nov 8, 2018

monkeyman192 commented Nov 8, 2018

jasmainak commented Nov 9, 2018

robertoostenveld commented Nov 9, 2018

monkeyman192 commented Dec 13, 2018

chrisgorgo commented Dec 13, 2018

monkeyman192 commented Dec 13, 2018

chrisgorgo commented Dec 13, 2018

jasmainak commented Dec 15, 2018

chrisgorgo commented Dec 15, 2018

monkeyman192 commented Dec 17, 2018

robertoostenveld commented Dec 18, 2018

robertoostenveld commented Dec 18, 2018

monkeyman192 commented Dec 18, 2018

monkeyman192 commented Feb 25, 2019

robertoostenveld commented Feb 25, 2019

sappelhoff commented Feb 25, 2019

Excerpt from the spec

Example

jasmainak commented Feb 25, 2019

sappelhoff left a comment

Choose a reason for hiding this comment

monkeyman192 commented Apr 5, 2019

sappelhoff left a comment • edited Loading

Choose a reason for hiding this comment

sappelhoff left a comment

Choose a reason for hiding this comment

jasmainak left a comment

Choose a reason for hiding this comment

effigies commented Apr 15, 2019

jasmainak commented Apr 15, 2019

sappelhoff commented Apr 23, 2019

chrisgorgo commented Oct 25, 2018 •

edited

Loading

monkeyman192 commented Oct 25, 2018 •

edited

Loading

jasmainak commented Oct 30, 2018 •

edited

Loading

sappelhoff left a comment •

edited

Loading