BF: percent -> percents for value of a unit

[yarikoptic]

The other units have plural version for the value, so I thought it would
make sense here as well

[rly]

I agree that "percent" is an outlier compared with the other units. My understanding is that "percent" is a collective noun and can be both singular or plural. "Percents" is also a valid plural form, but in my experience is typically used in place of "percentages". Using "percents" to describe the units sounds awkward to me.

My original rationale for not updating "percent" in NWB 2.1 was thinking, if the value is non-singular, what unit word would follow it? 10 volts, 10 meters, 10 grams, 10 percent (though 10 percent is not a quantity like the others; it is more of a unit-less measure)

I appreciate the eye to detail! What do others think about this?

[yarikoptic]

Fwiw, I was surprised that unit description values were expressed as plural to start with. As for description of a unit I would have used single form.

[yarikoptic]

Note that doc field says "Unit of measurement...", Suggesting a single form.

[rly]

We considered using the singular form for the same reason and the fact that the field is called "unit" and not "units". But the plural form felt more natural to use. I am open to changing the value to be singular.

[jonc125]

Other standards I've been involved with (in computational biology for instance, SBML & CellML) have used the singular form for units.

[yarikoptic]

so -- what should be the verdict? I see 3 possibilities

• do nothing and stay inconsistent within and with others
• convert everything to singular (consistent within and with others)
• convert everything to plural (consistent within, but requires documentation adjustment, and likely not with others)

[rly]

I am in favor of option 2, and maybe option 1.

Note that with option 2, a v2.2 file with unit: seconds would not be compliant with a v2.3 schema with unit: second, but I think that would be OK. (We did make similar changes between v2.0 and v2.1.)

[satra]

@rly - here is the link to the ascii units specification: https://people.csail.mit.edu/jaffer/MIXF/MIXF-10

some folks have written python parsers for this as well. i know most of these discussions are around simple units, but as the complexity of the nwb file grows with behavioral recordings then things like acceleration and other metadata may come in. so unit combos are likely to be a thing. i think this spec helps a lot with that. i'm simply putting it here for discussion.

[rly]

@satra Out of curiosity, why use the MIXF-10 units specification as opposed to the UCUM or other specifications? I see that BIDS has adopted it. UCUM is used by DICOM and a variety of other groups.

And is there a preference toward using the full name of the unit, e.g., "meter" as opposed to the symbol "m"? I slightly prefer the full name because it is more readable and reduces ambiguity, but I realize that most (if not all) other systems use at least the symbol.

Also linking to the discussion here: incf-nidash/nidm-specs#482

https://ucum.nlm.nih.gov/
http://dicom.nema.org/medical/dicom/2014c/output/chtml/part16/sect_7.2.2.html

[satra]

@rly - a few notes first:

• bids is about to adopt cmixf-12 ([FIX] Recommend SI units formatting to adhere to CMIXF-12 bids-standard/bids-specification#411)
• i wrote a python parser last weekend (https://github.com/sensein/cmixf)
• and there is a javascript parser being developed as well

regarding choice of CMIXF-12 is the focus in BIDS on SI units with some specific exceptions that may be allowed. and CMIXF-12 covers those. and the table is much easier for a user to look at relative to UCUM. if there is a need to support broader units, especially weird biological ones (colony forming unit), then one should expand out.

[rly]

@satra Thanks! The BIDS discussion is really helpful.

[rly]

Closing this in favor of new PR #446