Should/could fa- (flip angle) contain a <value> not an <index>? #71
Comments
|
I think the rationale was that for most metadata the values are too far ranging to be included in the file name, so it makes sense to only have it in the json file. BUT - I have a light memory that you can choose whatever index you want in the filename.... So you could - if you wanted to have I agree that the current specification isn't clear on this src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md#indexable_metadata-index-key-value-pair and its also wildly possible that I'm misremembering a conversation. Tagging @agahkarakuzu who might have more thoughts than me..... |
|
So what you need to do is
|
|
I agree with @tiborauer that the filename should only contain index(es) of some metadata like FA. @yarikoptic if you have multiple sessions, couldn't you label the sessions/runs ( |
|
I see no reason why you could not. You need a list only, if you use a single JSON for multiple images. I would prefer using the corresponding keys rather than just having runs. Although, |
|
As for @KirstieJane this is from one of my previous commits, I though that it would be redundant and omitted this from the specification. I think we should put it back, what do you think?
@ChristophePhillips @tiborauer I have added bunch of details regarding JSON files on this branch. These are not final of course, needs discussion before merging, but should be helpful. For the JSON files of the Note that
|
|
I'm confused about the list thing after our conversation on the call yesterday - seems like we need to clarify that.... I had taken away from the conversation yesterday that we can't have lists. Are there any metadata fields in the main specification that are lists? Are we inventing something new here? Seems big.... If we didn't allow lists, would we then allow any value? I feel like this conversation has been had elsewhere in the specification. @yarikoptic - are you aware of other metadata fields that are stored in the filename? I agree that |
|
|
|
The confusion comes for the fieldmaps. I proposed, back then, using list to store TE for dual-echo fieldmaps; however, the proposal using |
These wouldn't use the index from the filename though, right? I think this is a first use of using the index to grab information from a list.....and I guess having us just insert the |
I think that there is 1 <--> 1 mapping between a JSON file and an image, this is why we had inheritance principle discussion. Given that there'll be a JSON for each image with a different |
|
@KirstieJane, For MEG, they already have a very similar concept: "Some software reader may skip important metadata that is specific to MEG system manufacturers. It is therefore RECOMMENDED that users provide additional meta information extracted from the manufacturer raw data files in a sidecar JSON file. This allows for easy searching and indexing of key metadata elements without the need to parse files in proprietary data format. Other relevant files MAY be included alongside the MEG data; examples are provided below." I agree it may be vague; however, I am not sure why it may not work. However, there is a clear statement in the current spec against using actual values (for ME data): "Please note that the |
|
Coolio! Thanks @tiborauer - that makes sense to me to conform with the suggestion already in the spec to have the index be the index not the real value. (I've remembered by the way the conversation that I couldn't properly bring to mind earlier. Your indices don't have to correspond to any order of the metadata. So index 1 can be flip angle 45, index 2 can be 65 and index 3 can be 25. No problem. 😸) @yarikoptic - does all this make sense? Probably different json files for the two different scans with different flip angles and use the indexes rather than the values. Is there a different angle (lolz) that we haven't considered? |
|
Thank you everyone for this lively discussion. Sorry for me being a slow one ;) TL;DR: Overall, I think that And now the longer version: ;-) I think I will need to spend some more time to grasp Meanwhile, let me dump here some notes/arguments which could, once again, be irrelevant in the realm of Inheritance principle
IMHO (see bids-standard/bids-specification#102) inheritance principle ATM is quite a weak point within BIDS. Although pybids and probably other tools have their own way to treat it, I am afraid it is not yet formalized well enough and thus I would not rely on it heavily just yet. If I am wrong, please follow up on that issue and clarify.
|
|
@yarikoptic going back to the very first comment you made
As you also noted in your latest comment, it makes sense within the context of This is why we suggest the use of For example: The use of When people go ahead and read the table for grouping suffixes, it is clear why Therefore, it does not make much sense to use The problem here is that you can draw the line anywhere you like for the amount of flip angle difference that separates This gives a better feeling that someone was just experimenting with different flip angles. Whereas the use of Lastly, the benefit brought by The inheritance principle in its current form is a concern for BEP001, because we were planning to keep all the constant parameters in one (top) JSON file and put only varying parameters in lower JSON files such as: According to the inheritance principle this is not valid, because the structure above makes one JSON file apply to more than one images. This is why we diverged from this approach, which was the only case we interfaced with the inheritance principle. |
Was this suggestion discussed within the "BIDS core"? |
Hm... I do not think anything in BIDS is intended to answer why (why do we collect any anat/ -- for registration? for diagnosis? for deriving surfaces? for both?), but rather what. That is why I actually quite dislike having once again -- sounds like a good discussion to bring up with other BIDS |
|
I think what we're trying to do in BEP001 is have a smaller group work through the (many) complexities of extending the specification before opening up the discussion. Although - to be clear - everyone is welcome to join in! Conversations like this make it much easier to see where the challenges are and how we should be capturing the many discussions we've had about this over the years. We'll absolutely take your considerations into our extension of the specification - particuarly capturing more of the motivation for why we've chosen to go down this path which is - at the moment - not clearly enough explained. One last point - I'm not a fella. Please don't generalise the BIDS community as all male. |
No (over)generalization was intended, sorry. I used And even though dictionary meaning of "fellow" have many gender neutral meanings for the one I intended to convey$> dict fellow
5 definitions found
From The Collaborative International Dictionary of English v.0.48 [gcide]:
Fellow \Fel"low\, n. [OE. felawe, felaghe, Icel. f[=e]lagi, fr.
f[=e]lag companionship, prop., a laying together of property;
f[=e] property + lag a laying, pl. l["o]g law, akin to liggja
to lie. See {Fee}, and {Law}, {Lie} to be low.]
1. A companion; a comrade; an associate; a partner; a sharer.
[1913 Webster]
The fellows of his crime. --Milton.
[1913 Webster]
We are fellows still,
Serving alike in sorrow. --Shak.
[1913 Webster]
That enormous engine was flanked by two fellows
almost of equal magnitude. --Gibbon.
[1913 Webster]
Note: Commonly used of men, but sometimes of women. --Judges
xi. 37.
[1913 Webster]
2. A man without good breeding or worth; an ignoble or mean
man.
[1913 Webster]
Worth makes the man, and want of it, the fellow.
--Pope.
[1913 Webster]
3. An equal in power, rank, character, etc.
[1913 Webster]
It is impossible that ever Rome
Should breed thy fellow. --Shak.
[1913 Webster]
4. One of a pair, or of two things used together or suited to
each other; a mate; the male.
[1913 Webster]
When they be but heifers of one year, . . . they are
let go to the fellow and breed. --Holland.
[1913 Webster]
This was my glove; here is the fellow of it. --Shak.
[1913 Webster]
5. A person; an individual.
[1913 Webster]
She seemed to be a good sort of fellow. --Dickens.
[1913 Webster]
6. In the English universities, a scholar who is appointed to
a foundation called a fellowship, which gives a title to
certain perquisites and privileges.
[1913 Webster]
7. In an American college or university, a member of the
corporation which manages its business interests; also, a
graduate appointed to a fellowship, who receives the
income of the foundation.
[1913 Webster]
8. A member of a literary or scientific society; as, a Fellow
of the Royal Society.
[1913 Webster]
Note: Fellow is often used in compound words, or adjectively,
signifying associate, companion, or sometimes equal.
Usually, such compounds or phrases are
self-explanatory; as, fellow-citizen, or fellow
citizen; fellow-student, or fellow student;
fellow-workman, or fellow workman; fellow-mortal, or
fellow mortal; fellow-sufferer; bedfellow; playfellow;
workfellow.
[1913 Webster]
Were the great duke himself here, and would lift
up
My head to fellow pomp amongst his nobles.
--Ford.
[1913 Webster] |
|
I would argue against BIDS ignoring why. Modality-specific suffixes answer why rather than what, and we already have some discussions on the inaccuracies of the what. There are two main motivations behind using grouping suffixes.
|
|
Although related to the original issue, I think it is worth a separate discussion, thus moving into a new #72 |
Our use case: We are doing period QA (data is available from http://datasets.datalad.org/?dir=/dbic/QA), and in the past had some scans with standard flip angles with no indication of flip angle in the file name. Now we (in particular @kodiweera) experimenting with different flip angles. If we resort to
_fa-<index>, we could potentially have confusingly identical filenames across sessions when actual flip angle would be different. Moreover it is not immediately clear from the filename how any two files (e.g._fa-1and_fa-2) are different, and would require lookups into .json files, decreasing the usefulness from BIDS convention.I wondered what was the rationale (besides may be inability/difficulty of reflecting floating point values? did you see any of those in over 10% (100-90% of the use cases? ;)) for storing indexes and not the actual values?
The text was updated successfully, but these errors were encountered: