[ENH] BEP036 - Phenotypic Data Guidelines

[ericearl]

The BEP leads can meet as-needed to discuss this BEP PR

Coordinate a meeting by emailing Eric Earl: eric.earl.nih@gmail.com.

Communicate on this PR to provide feedback otherwise.

HTML preview of this BEP

BEP036 brings guidelines for best tabular phenotypic data to the BIDS specification.

• Includes an appendix called phenotype.md
• Includes a new AdditionalValidation key for the dataset_description.json, for which the usage is described in the modality agnostic files sections
• Includes the new option to store session_id as the second column in the participants.tsv

Additional Links

1. Original Google Doc
2. Draft BIDS Validator errors and warnings
3. BIDS Examples PR

---

Co-authored-by: Eric Earl eric.earl@nih.gov @ericearl
Co-authored-by: Samuel Guay samuel.guay@umontreal.ca @SamGuay
Co-authored-by: Sebastian Urchs sebastian.urchs@mcgill.ca @surchs
Co-authored-by: Arshitha Basavaraj arshitha.basavaraj@iiitb.ac.in @Arshitha

[surchs]

Copying from https://github.com/surchs/bids-specification/pull/1/files#r2103117486

For this section, would it make sense to suggest that demo-like information be prioritized in this file rather than participants.tsv, making the latter primarily a list of subject IDs? I haven't seen this explicitly addressed anywhere, though I'm unsure if it's something we want to formalize 😬
Something like this could follow the paragraph?:

When all demographic data is stored in phenotype/demographics.tsv, participants.tsv may serve primarily as a minimal listing of subject identifiers with only the participant_id column.

[Arshitha]

I agree. It'd be good to mention this.

[timdressler]

Hi, I am new to commenting a PR and also relatively new to BIDS - so my comment might be stupid.

However, I want to draw attention to a potential issue with the handling repeated usage of a phenotype/ measurement. Currently, if a measurement is conducted more than once, a run_id column MUST be added that "corresponds to an existing run- entity used in a filename(s)" (https://bids-specification--2123.org.readthedocs.build/en/2123/modality-agnostic-files/phenotypic-and-assessment-data.html).

However, in my case (and I guess many others), a phenotype measurement tool might be conducted independently of a run in an experimental task. For example, I conduct a mood questionnaire 7 times over the course of one session in which multiple tasks (with multiple runs) are conducted. Thus, I think it is not reasonable that the run_id column in the phenotype file corresponds to an existing run_ in a (task) filename. Instead, something like a measurement_timepoint_id (or similar) that is not related to the run_ in other files might be a good idea. Again, I am sorry if my comment is stupid or I misunderstood something.

[VisLab]

Along this line: The current proposal states:

A participant identifier of the form sub-, matching a participant entity found in the dataset. Note that data for one participant MAY be represented across multiple rows in case of multiple sessions or runs, and therefore the entry in the participant_id column will be repeated. The combination of participant_id, session_id and run_id MUST be unique.

The problem with this is that it doesn't cover the following cases which are in many datasets that I am familiar with:

Example 1: A dataset in which there are multiple training sessions on some equipment or on some test procedure on multiple different days before any imaging or any data that would have a run occurs.

Example 2: Sleep questionnaires and other questionnaires that administered multiple times un-associated with any imaging sessions.

Both of these require another column identifier (not associated with the run).

[ericearl]

@VisLab Great to hear from you! Thanks for reading the BEP. Now to your comments...

Example 1: A dataset in which there are multiple training sessions on some equipment or on some test procedure on multiple different days before any imaging or any data that would have a run occurs.

We may not have made it explicit, but here is this example in the HTML preview of the appendix. It covers what to do when there's "1 participant with 2 sessions, where 1 session is only tabular phenotype and the other is only imaging". The same idea extends to more than 2 sessions of some combination of acquired data and tabular phenotypic data. For instance, in your Example 1, we could say:

Define many phenotypic session names

• ses-day1equipmenttraining1
• ses-day1equipmenttraining2
• ses-day1equipmenttraining3
• ses-day2equipmenttraining1
• ses-day2equipmenttraining2
• ses-preproceduretraining
• ses-procedure
• ses-postprocedure
• ...

Store most, if not all, in one aggregated file

• phenotype/equipment_training.tsv
  • Where participant_id, session_id, run_id, and day are joint indexes.
  • Yes, day is not a a validate-able column, but you could alternatively create a phenotype/day#_equipment_training.tsv if you want stricter validation support.
  • Remember that run_id is not about tying the data to a particular task's run, but instead to differentiate multiple runs of the same tabular phenotypic test, survey, assessment, questionnaire, or lab result within the same participant_id's session_id.

Example 2: Sleep questionnaires and other questionnaires that administered multiple times un-associated with any imaging sessions.

The answer to example 2 is the appendix example I linked above, and now here.

I hope this helps and let me know if you don't think this resolves your comment. Or if perhaps there's something else we should consider which you can propose?

[ericearl]

@timdressler

I want to draw attention to a potential issue with the handling repeated usage of a phenotype/ measurement. Currently, if a measurement is conducted more than once, a run_id column MUST be added that "corresponds to an existing run- entity used in a filename(s)" (https://bids-specification--2123.org.readthedocs.build/en/2123/modality-agnostic-files/phenotypic-and-assessment-data.html).

Wowza, good catch! I didn't notice that incorrect set of words there. It currently says:

(run_id is) A run identifier that corresponds to an existing run- entity used in a filename(s). A chronological run number is used when a measurement tool or assessment described by a tabular file was repeated within a session.

What it should say:

(run_id is) A run identifier to differentiate multiple runs of the same measurement tool. A chronological run number is used when a measurement tool or assessment described by a tabular file is repeated within a session.

Thanks! I'll edit that.

For example, I conduct a mood questionnaire 7 times over the course of one session in which multiple tasks (with multiple runs) are conducted.

Does the text edit above of "what it should say" make better sense and resolve the run_id labeling issue?

[yarikoptic]

Are we in public review already? here is one:

if you are talking about having top level sessions.tsv to now have both participant_id and session_id index keys, I will keep coming to beg on my knees "PLEASE DO NOT" (edited) until we define it as a generic principle one way or another (e.g. #2273) -- there should be a discussion on that particular aspect alone not subjects.tsv ad-hoc, and not in BEP mixing in various changes. ATM sessions.tsv must have only session_id index, as any other {entity_plural}.tsv. Please do not break the few consistencies we have.

[ericearl]

We are not in public review yet, but I am happy to receive feedback at all stages.

I see a need in BIDS for allowing flexibility in tabular data aggregating/moving "back" in the directory hierarchy (from subdirectory "leaves" to the top-level dataset "root"). When people interact with this kind of tabular data, they don't want 10's, 100's, or 1,000's of small sub-<label>/sub-<label>_sessions.tsv segregated files. They want one big aggregated file.

As a consequence of that: the closer to the dataset root you go, the more columns you will need to describe the aggregated data. For instance, if you have 1,000's of small sub-<label>/sub-<label>_sessions.tsv segregated files and you want one big aggregated file called sessions.tsv instead, aggregating up requires taking out the sub-<label>. So you end up with the need for that participant_id column in the sessions.tsv file.

I used to think this was relevant for ALL tabular files to be able to move back in the directory hierarchy, but I later realized that things like physio or other large files would be a real mess in a much larger aggregated file. I could maybe still make the case for scans.tsv or samples.tsv though, but that's a very different story...

I would almost like to say, "'Large' tabular files should stay as-is and 'small' tabular files should allow aggregation."

[yarikoptic]

sorry -- I am not following the argument here as nothing in what you said requires breaking an established .tsv file(s) convention as it can be easily adopted in a new .tsv file as e.g. I suggest in #2273.

[yarikoptic]

yikes -- that will be the literal filename like measurement_tool.tsv in there??? like the suffix _tool and some measurement thing?

[ericearl]

Yes, this is what the phenotype/ directory already permits and the validator validates pre-BEP036. It is also how the 40 (out of 1,548) datasets with a phenotype/ directory on OpenNeuro, as of 3/30/2026, curated their tabular phenotypic data. The filenames in the phenotype/ directory can be named alphanumerically (including hyphens and plus signs, I believe), but I think the practical way to make sure people continue sharing their tabular phenotypic data is to leave the file-naming of phenotype files as-is.

Names so far are usually acronyms or short descriptions or both. Some examples:

• phenotype/demographics.tsv
• phenotype/whodas.tsv
• phenotype/nih_toolbox.tsv
• phenotype/ARI_parent.tsv
• phenotype/wisc-iii.tsv

[yarikoptic]

but I think the practical way to make sure people continue sharing their tabular phenotypic data is to leave the file-naming of phenotype files as-is.

by no means I want to restrict people from sharing their data any way they want in whatever file-names they have. It is only when we talk about standardizing file names like BIDS does, that's where I have an "opinion" or otherwise we just would have ended-up with something like data/my_favorite1.nii.gz and data/notsogoodone2.nii.gz

[dorahermes]

Agree with @yarikoptic that this breaks BIDS search principles for use of underscores.

[yarikoptic]

please please please no!!! what common principle such file construction follows? it introduces inconsistencies! If you want to introduce some new principle, let's formalize it. PLEASE PLEASE PLEASE lets discuss and do that, e.g. in #2273 or as I invited you there -- please formulate an alternative but generic approach!

You can keep resolving my comments but I am sorry -- I will be coming back, so we better do talk and resolve this "conflict"!

[ericearl]

Please do keep coming back. We want the voices of those that agree AND those that have differing opinions to see whether we're satisfying 80% of the most commonly used data cases or not (see BIDS mission statement foundational principle 2). I will try to make an "alternative, but generic approach" and tag you on it referencing #2273, etc. Hopefully we can come to some agreement soon.

[yarikoptic]

There are a number of major aspects in construction of file names and their content which come up without introducing generic principles and ruining that some consistency among them what we have so far in BIDS:

• singular index in {entityplural}.tsv (see #2273 for proposal how to generalize to multiple)
• filename construction to generally follow {entityname}-{labelorindex}_{suffix}.{ext} + aforementioned {entityplural}.tsv to describe those entity values (see #2283 for proposal on how to generalize having such files for all across levels).

I have voiced my concerns over proposed here IMHO breaking changes numerous times, but as far as I see it, they were just brushed off without due search for compromise.

[dorahermes]

I agree with @yarikoptic on the file naming, which is an easy fix.

A more difficult problem is the summarization across sessions and understanding the order in which data were acquired. This needs a general solution because I imagine similar problems for annotating medication that was used during different sessions/runs/. For example, in our case we have patients who are using one type of medication during a MRI, and this changes across iEEG sessions and runs during or even within a run. It would be good to be able to filter which runs were collected on certain medication.

Also, in my initial impression, a phenotype is a static feature that does not change across sessions, can phenotype change across sessions?

[surchs]

AFAICT there are 3 questions left to answer:

1 - For a longitudinal dataset, where should I store my demographic/phenotypic (e.g. "age", language maybe not clearly delineated) info?

BEP036 proposes participants.tsv (in line with recommendations in the spec), and changes the schema to allow a double-index of participant_id and session_id. If we don't want to make this schema change / don't want to allow the double-index that's OK, then our alternative is to put it in /phenotype/demographics.tsv.

I like the /phenotype/demographics.tsv option. I also think we should then recommend this demographics.tsv (or best name) as the default target for such information about the participant.

2 - For a longitudinal dataset with phenotypic data (e.g. assessments, again language not super clear), where should I describe the properties (i.e. acq_time) of the phenotypic sessions.

BEP036 proposes a root level sessions.tsv, and changes the schema to allow a double-index of participant_id and session_id. If we don't want to allow this then that's also OK. However we should then find an alternative. AFAICT our options are:

a) put it in @yarikoptic proposed participant+session.tsv file as additional columns

e.g. participant+session.tsv could look like this:

participant_id	session_id	acq_time
sub-1	ses-1	2009-06-15T13:45:30
sub-1	ses-2	2009-06-16T14:45:30
sub-2	ses-1

Good:

• solves the problem

Not so good:

• imho not an intuitive place to go look for acq_time of a session
• requires that we address Formalize joint index support in .tsv via {"+".join(entities)}s.tsv files #2273 before BEP036
• I assume this is not what @yarikoptic has in mind for this file

b) put it in /sub-<label>/sub-<label>_sessions.tsv

Good:

• status quo ante

Not so good:

• for a subject with only /phenotype data, I now must make an empty sub-<label> dir in which I put a single sub-<label>_sessions.tsv file, just to list the phenotypic sessions and their acq_times etc

As I mentioned above I think we should not do this.

c) put it inside the individual .tsv files in /phenotype dir

For example, I might have a assessment1.tsv like so:

participant_id	session_id	acq_time	subscale_A_total
sub-1	ses-1	2009-06-15T13:45:30	10
sub-1	ses-2	2009-06-15T14:45:30	15
sub-2	ses-1

and also a other_assessment.tsv like so:

participant_id	session_id	acq_time	other_subscale
sub-1	ses-1	2009-06-15T13:45:30	37
sub-1	ses-2	2009-06-16T14:45:30	25
sub-2	ses-1

Good:

• already consensus for the BEP (i.e. repeated session_id or run_id are OK)

Not so good:

• will be very repetitive, i.e. does not respect "Duplication is evil!" mantra
• likely very hard to validate for humans and validator
• easy to get inconsistent info / data entry errors

I don't like any of these options, but of this list I like a) the best. I believe the most useful thing for us to do would be to either choose one of the 3 options I listed above, or to together come up with a better one.

3 - What rules should apply to file names in /phenotype dir

BEP036 proposes nothing, which afaik is the status quo (i.e. anything is allowed). If we want to change that and treat the files in /phenotype directory as regular BIDS file names, I think we need to be clear what this means. afaict there are no pheno-relevant suffixes in BIDS, i.e. there is no "good suffix" I can pick. So iiuc all underscores in the file name are effectively out. I believe it's the same for entities - but I am not sure if this means that dashes are also out. Unless I'm missing something, we already know that anything looking like a "suffix" we encounter in /phenotype will be either invalid or wrong.

I disagree with this, but I don't have a strong opinion. We should though consider the additional friction we impose on groups who want to store their phenotypic/assessments data in a BIDS conform way - because in practice it most likely means a lot of renaming of files.

My main point here is: I think we're a bit stuck/going in circles with the discussion of one specific implementation vs another / the HOW of the BEP. But in the end the implementation is only useful in service of the WHY, which to me are the questions above. And I think it should be easier for us to agree on what an acceptable solution to these questions looks like.

[karl-koschutnig]

Thanks for the work on BEP036 — this hits close to home.

The structural mismatch between phenotypic/survey data and the rest of BIDS is exactly the problem that motivated us to build PRISM (https://github.com/MRI-Lab-Graz/prism-studio). When we tried to store multi-session questionnaire data in standard BIDS, the phenotype/ flat-file pattern was the only option — and it broke every assumption the rest of the spec is built on.

Specifically what breaks:

• phenotype/tool.tsv lives outside sub-/ses-/, so JSON sidecar inheritance doesn't apply. Shared instrument metadata has no canonical location.
• session_id and run_id as TSV columns re-implement in data space what BIDS filename entities already express for every other modality.
• BIDS Apps traversing sub-/ses-/ are structurally blind to phenotypic data.

What we ended up doing in PRISM:

We store survey/questionnaire data inside the standard hierarchy under a survey/ modality folder:

sub-001/ses-01/survey/sub-001_ses-01_task-phq9_survey.tsv
sub-001/ses-01/survey/sub-001_ses-01_task-phq9_survey.json

Session and run fall out of filename entities. Sidecar inheritance works normally. BIDS Apps see the data without modification. The workaround is adding survey/ to .bidsignore — which is precisely the gap a proper BIDS extension should close.

BEP036 codifies and improves the existing phenotype/ pattern, which is valuable. But the underlying structural issue remains. We'd encourage the working group to discuss whether the normative pattern for per-session instrument data should follow the sub-/ses-/ hierarchy, with phenotype/ serving as an optional aggregate/derived representation.

Happy to share schema definitions or converter code.

[ericearl]

The scope of BEP036 is primarily to be a set of guidelines. BEP036 provides validatable best practices for BIDS tabular phenotypic data using an opt-in for additional validation. BEP036 also introduces a new use case for a “joint index” (definition below) in the phenotype/ directory to support aggregated tabular phenotypic data.

With this comment, I would like to try to address what I think are Yarik’s main concerns. Those concerns, as I understand them, are about two currently undefined generic BIDS principles he feels should apply to BIDS files, including tabular phenotypic data:

1. Using only a singular index in {entityplural}.tsv. For example: participants.tsv or sessions.tsv.
2. Constructing filenames to generally follow {entityname}-{labelorindex}_{suffix}.{ext}. For example: phenotype/table-demographics_pheno.tsv or phenotype/survey-ARIParent_pheno.tsv.

1. Using only a singular index in participants.tsv and sessions.tsv

I have long felt that aggregated participant’s session data would be best held and found inside one of three files: (a) participants.tsv, (b) sessions.tsv, or (c) phenotype/demographics.tsv.

A quick definition before I start, for clarity to readers who may be unfamiliar with the term “joint index”. Having a joint index in a tabular file means it has more than one index column. For example “participant_id & session_id” or “participant_id & session_id & run_id” or even “participant_id & run_id”. The point of the indices is to uniquely identify rows which allows for more aggregated data. For instance, if the joint index of a tabular phenotypic file is “participant_id & session_id & run_id” then there will not be more than one unique combination of a participant, their session, and their run across all rows in the aggregated file.

So, if (a) and (b) here are not allowed to use a “joint index” then the ideal location for the aggregated data should be (c) (whether it goes by that filename or some other filename) aggregated in the phenotype/ directory.

I think BEP036 can skip using a root-level aggregated participants.tsv or sessions.tsv as the central inventory of multi-session changes in participant measurements. As long as BEP036 can instead use the phenotype/ directory for aggregated files, like phenotype/demographics.tsv.

2. Constructing filenames to generally follow {entityname}-{labelorindex}_{suffix}.{ext}

I understand that BIDS does this in every other place in the first 2 or 3 levels of the directory hierarchy EXCEPT the phenotype/ directory. The phenotype/ directory has, by convention, allowed tabular phenotypic data under a “name it anything” convention since way back in BIDS version 1.0.1.

I feel {entityname} and {suffix} in the BIDS context are for representing files that differ between the otherwise same filename in segregated data. For instance, by convention the “task” entity, “run” entity, or even the “ce” entity are included in the specification to know what differs between similar filenames at a glance, and to keep them separate.

Some files defy this, like Arterial Spin Labeling (ASL) where the files can be either separate files with different suffixes or they can be concatenated with an aslcontext.tsv file provided, so the end-user knows which 3D volume in the 4D volume is which ASL file.

Files in the phenotype/ directory are always “prefixed” by existing in that directory. Their extension is also always .tsv for the tabular data or .json for the corresponding data dictionary.

I don’t think it adds any value to an aggregated tabular phenotypic data filename to introduce an {entityname} (like table or survey) or a {suffix} (like pheno) in BIDS version 1. I think it would be fine to reconsider this for BIDS 2.0. Perhaps supporting both segregated files like PRISM Studio does it (thanks @karl-koschutnig) and aggregated files like BEP036 and Psych-DS do it. I do think if we are going to define entity names and suffixes, then we would need to define useful filename-separating entity names for tabular phenotypic data.

On aggregation versus segregation of tabular phenotypic data

This is an aside that I feel is important and topical in a few of the most recent comments here.

For a long time to me, the motivating factor for aggregating sub-<label>/sub-<label>_sessions.tsv files up to an aggregated root-level sessions.tsv file was the idea of having an easier time loading in a lot of sessions data (one load command instead of 10s or 100s of load commands and one concatenating command). Also to have a better place to put all the session_id name definitions (into the sessions.json data dictionary). And going up the hierarchy to the root, you could remove the sub-<label>_ off every filename and instead add a participant_id column inside, which I think is very clean.

While the current BIDS tabular phenotypic data standard for sessions files technically works well, in practice it puts a large technical file-concatenating load on people who want to analyze the multi-session changes in tabular phenotypic data. That is why we BEP036 leads have been advocating for aggregating such data to the root-level since about half-way through this BEP’s development.

Summary

1. If we can agree on the need for a phenotype/demographics.tsv (by this or any other name) for at least an inventory of participants & sessions, then I agree we don’t need to allow a joint index in participants.tsv or sessions.tsv at the BIDS dataset root-level, and I can make those edits to the schema and specification.
2. If we can agree that {entityname} and {suffix} don’t add any value to aggregated tabular phenotypic data filenames in the phenotype/ directory, then I suggest we leave the open filenaming scheme as-is for the phenotype/ directory, and I can add language to the specification to make clearer why files in the phenotype/ directory are freely named.
3. If we cannot agree that {entityname} and {suffix} don’t add any value to aggregated tabular phenotypic data filenames in the phenotype/ directory, then please provide concrete suggestions for aggregated tabular phenotypic data {entityname} and {suffix}.

Lastly, I will try to respond to other newer comments here besides Yarik’s now. Thank you all for the comments!

Tags: @yarikoptic @dorahermes @surchs @SamGuay @Arshitha

[ericearl]

@karl-koschutnig

I love that it looks like you solved the segregated tabular phenotypic data issue with PRISM Studio! What it looks like you all did was an earlier-on goal for BEP036, but we wanted to try getting out the aggregated tabular phenotypic data BEP first before pursuing the “you need a tool to support curating and using your tabular phenotypic data” route. I would love to talk some time about how much adoption PRISM Studio has had and how well it’s being received by users.

As for:

We'd encourage the working group to discuss whether the normative pattern for per-session instrument data should follow the sub-/ses-/ hierarchy, with phenotype/ serving as an optional aggregate/derived representation.

We BEP leads have talked at length and repeatedly about that solution and we felt the aggregated use case was more important, which is why you see what we have here today.

However, I would recommend you create a PR to try to formally get PRISM Studio’s filenames and folder structure supported in the BIDS schema. Maybe re-use the “phenotype/” subdirectory as your modality directory instead of “survey” and consider other possible suffixes (I like pheno as a suffix idea) or entity names (here’s a list of entity names I’ve considered: table, survey, assess, quiz, form, meas, inst, or lab), but otherwise your project looks amazing. Nice work and thanks for continuing the conversation.

[karl-koschutnig]

@ericearl

Thanks, this is very helpful, and I appreciate the context from the BEP leads.

I’m happy to open a PR proposing formal schema support for the PRISM Studio structure. One point I’d want to make gently in that PR is that I’m not fully convinced by using phenotype/ as the primary representation, because it breaks from the way other BIDS modalities are organized. From my perspective, a survey-style BIDS structure fits the broader BIDS logic better, while aggregated tables can still be generated later from that canonical structure when needed.

That said, I’m very open to discussing naming, suffixes, and entities in a pragmatic way so the proposal is useful for the working group. I’d also be very happy to talk about adoption and user feedback sometime.

[karl-koschutnig]

as @ericearl suggested, I just opened a PR for the prism-idea of survey data structure.

#2404

I would be happy to discuss our approach in detail

[ericearl]

Just an FYI to the community after a discussion held between myself, @yarikoptic, and @dmoracze: BEP036 (this PR) will be trying to adopt the more explicit "IndexColumns" solution (issue #2402), instead of just expecting or allowing implicitly for BIDS data curators to put more than one index column into "participants" or "sessions" or "phenotypic and assessment data" files. In fact, BEP036 will be dropping the plan to allow multiple index columns inside the participants and sessions files at all. Support for multiple index columns will at first be restricted to only being in the phenotype/ directory. We also discussed how this idea could be re-used across the BIDS standard in other places later. The full discussion's meeting notes are publicly available here.

P.S. This also resolves @VisLab's Example 1 concern, where participant_id, session_id, run_id, and day all need to be joint indexes for an aggregated tabular file. I think this solution is more optimal all-around for joint indexing in tabular files.

[SamGuay]

There you go @ericearl !
(Do we need to wait for #2273 to have this one merge-able?)

[SamGuay]

Would it be useful to mention that these recommendations are ignored by default only to maintain backward compatibility for previous datasets?

[SamGuay]

Suggested change

	each `phenotype/<measurement_tool_name>.json` data dictionary.
	each `phenotype/tool-<ToolName>_phenotype.json` data dictionary.

According to the file-naming template just above (L26), this should now use tool-..._phenotype instead of only <measurement_tool_name>

[SamGuay]

Suggested change

	To read more about the guidelines for tabular phenotypic data and examples,
	see the [tabular phenotypic data guidelines appendix](../appendices/phenotype.md).

I don't think we need to repeat it one more time considering the last 3 paragraphs mention the same URL.

[SamGuay]

I might've missed this or simply forgot about the final decision, but are we moving forward with having a /sessions.tsv at the root level? (the rest of the changes don't appear to reflect that)

[SamGuay]

Suggested change

	AgeUnits:
	issue:
	code: AGE_UNITS
	message: |
	The "Units" value for age in 'participants.json' is not a valid
	ISO 8601-based duration unit.
	Allowed values are "year", "month", "week", "day", "hour", "minute",
	or "second".
	level: warning
	selectors:
	- path == '/participants.tsv'
	- '"Units" in sidecar.age'
	checks:
	- intersects([sidecar.age.Units], ["year", "month", "week", "day", "hour", "minute", "second"])

duplicate