[ENH] Clarify that recording entity may be used to distinguish recording instruments

[drammock]

In #1998 we're working on a BEP for EMG data. We're hoping to use the acq entity for cases where multiple EMG devices were used simultaneously, but they were recording through different amplifiers, into different data files, possibly with different sampling frequencies, etc. This PR proposes some slight wording changes to the acq entity definition to make it clearer that such uses of acq are acceptable. EDIT: following #2090 (comment) we're going to use recording instead, and this PR modifies the definition of recording accordingly.

(if they're deemed not acceptable, better that we know that now so we can adapt #1998 accordingly).

One possible alternative would be a new sys entity, analogous to the tracksys entity introduced for BIDS-Motion, with the (likely) end result that in future releases tracksys would be replaced by sys in motion datasets.

cc @JuliusWelzel @neuromechanist

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.71%. Comparing base (9854498) to head (a6f8669).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2090   +/-   ##
=======================================
  Coverage   82.71%   82.71%           
=======================================
  Files          20       20           
  Lines        1608     1608           
=======================================
  Hits         1330     1330           
  Misses        278      278           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[effigies]

This sounds like the exact use case for the recording-<label> entity. Was that considered?

At least in the MRI world, two files that differed by acq-<label> would not be expected to have been collected simultaneously.

[neuromechanist]

We can expand the definition both as a separate PR or directly on #1998.
@bids-maintenance, please let us know which one you prefer.

[neuromechanist]

Yes, it was discussed here: #1998 (comment).

To set the scene, in some EMG experiments, separate EMG systems are being used at the same time, recording with different settings, parameters, starting times, and sensor locations. We intend to use acq-<label> to allow the raw files from all sources to be included in the dataset.

Here are the current definitions:

recording-<label> description:

Definition: The recording- entity can be used to distinguish continuous recording files.

recording-<label> is being currently used to attach physio and stim data to the main recordings (link), which is not the use case for EMG-BIDS. Actually, we should accommodate using recording-<label> for the same purpose in EMG-BIDS as well.

acq-<label> description:

The acq- entity corresponds to a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality.

A couple of points in favor of using acq could be that it better conveys using separate acquisition devices/instruments with different sets of parameters, recording the same modality. Also, the acq entity is much shorter than the recording entity.

I am in favor of slightly expanding definitions rather than introducing another entity, although that could also work.

[drammock]

This sounds like the exact use case for the recording-<label> entity. Was that considered?

I thought there had been some discussion of using recording instead of acq during one of our meetings (and the idea had been rejected), but when I went back to the (admittedly incomplete) notes, this section is all I found and it doesn't mention rec at all (the notes only mention tracksys and acq).

recording-<label> is being currently used to attach physio and stim data to the main recordings (link),

Does that prevent using it in other ways though? Would it be wrong for a dataset to contain, for example

sub-<label>/[ses-<label>/]
    emg/
        <matches>_recording-breathing_physio.tsv.gz
        <matches>_recording-breathing_physio.json
        <matches>_recording-eyetracking_physio.tsv.gz
        <matches>_recording-eyetracking_physio.json
        <matches>_recording-bipolar_emg.edf
        <matches>_recording-bipolar_emg.json
        <matches>_recording-grid_emg.edf
        <matches>_recording-grid_emg.json

I personally don't care much whether we use acq or recording as long as the filenames are unambiguous.

[effigies]

recording-<label> is being currently used to attach physio and stim data to the main recordings (link),

Does that prevent using it in other ways though?

I don't think so. If we're considering expanding acq- to permit simultaneous recordings, it seems at least as valid to expand recording- to apply to data files and not just auxiliary recordings. One person's auxiliary recording is another person's primary data, so this distinction seems like it's only existed in the absence of an alternate use case.

I think we could update the recording definition as follows (additions in bold):

The recording- entity can be used to distinguish simultaneously acquired, continuous recording files.

This entity may be applied when continuous recordings have different sampling frequencies or start times,
or are acquired with different instruments.
For example, physiological recordings with different sampling frequencies may be distinguished using labels like recording-100Hz and recording-500Hz.

Would that cover your use case? Then it's just a matter of EMG files declaring recording to be a valid entity for that suffix.

---

It also looks like BEP 020 (#1128) is using recording-<label> to indicate eyetracking, so this wouldn't be in conflict. cc @mszinte for your thoughts. (Feel free to loop in other BEP020 participants.)

I'm not dead set against expanding acq, but the argument against recording doesn't seem compelling, and it is more closely aligned.

[drammock]

recording-<label> is being currently used to attach physio and stim data to the main recordings (link),

Does that prevent using it in other ways though?

I don't think so.

agreed

If we're considering expanding acq- to permit simultaneous recordings, it seems at least as valid to expand recording- to apply to data files and not just auxiliary recordings.

agreed.

I think we could update the recording definition as follows (additions in bold):

The recording- entity can be used to distinguish simultaneously acquired, continuous recording files.
This entity may be applied when continuous recordings have different sampling frequencies or start times,
or are acquired with different instruments.
For example, physiological recordings with different sampling frequencies may be distinguished using labels like recording-100Hz and recording-500Hz.

Would that cover your use case?

Yep I think so. @neuromechanist do you agree that this would suffice?

[neuromechanist]

TL, DR: BIDS had provided the data type facility to accommodate each functional group of data live under their own directory.
Along the way, however, the "auxiliary" modalities (such as _physio and _stim) were allowed to be at the host data type directory, using the additional _recording-<label> entity.
While we very well could extend the definition of the recording to also include concurrent data of the intended data type, I believe we would benefit from making a distinction between data files intended in the data type directory and the so-called auxiliary files.

---

Interestingly, the issue's scope is becoming much larger than anticipated, so I appreciate making it a separate pull request.

I see that either entities would require expansion, and with @drammock's example, using recording could work quite perfectly. But:

If we're considering expanding acq- to permit simultaneous recordings, it seems at least as valid to expand recording- to apply to data files and not just auxiliary recordings. One person's auxiliary recording is another person's primary data.

I have reservations about this statement. Auxiliary recordings are auxiliary not in the sense that it might be important for someone or not, but in the sense that which data type is hosting the data.

IMO, we would benefit from using two separate entities to distinguish if the data file is auxiliary (as they live under a different datatype than their intended modality) or if they are native under their data type. It does not need to be acq or recording, it could be a new entity, like sys as suggested by @JuliusWelzel at #1998.

The use-case could become even more potent when considering the new BEP045 (physio-BIDS, #1675, cc @smoia), where the physio data would claim its own data type. I don't think under BIDS 1.x we can deprecate the use of auxiliary _physio files, in other directories, but we might be able to make a clear distniction using two separate entities based on what is being recorded and saved under the intended data type and what is being hosted out of its place.

Currently, Motion-BIDS (cc @JuliusWelzel, @sjeung) use tracksys to (among other uses) differentiate concurrent recordings under the same data type (hence, the new sys entity to keep the resemblance).

I also understand that this change has BIDS2.0 implications, both about scans/recordings.tsv and modality independence bids-standard/bids-2-devel#29 and bids-standard/bids-2-devel#45 (cc @tsalo, @yarikoptic) and also potentially harmonizing the data type and modality bids-standard/bids-2-devel#54 (as well as probably a couple more issues).

To sum up, I think any or all will work ok, so I won't have any objections against them. Using different entities may make the file structures more clear down the road, and I hope that I could lay out the case and involve all potential stakeholders.

[drammock]

TL, DR: BIDS had provided the data type facility to accommodate each functional group of data live under their own directory.
Along the way, however, the "auxiliary" modalities (such as _physio and _stim) were allowed to be at the host data type directory, using the additional _recording-<label> entity.

Yes, but the use of *_recording-<label> is optional in those cases, so IIUC it's really the _physio and _stim parts of the filenames that marks them as "this is a different datatype then the parent folder would indicate". Thus it's not clear (to me at least) that there's anything about the definition of recording that makes it unsuitable for our needs in #1998.

[oesteban]

@drammock would it be possible to add some examples of this definition extension of acq- in the appropriate part of the spec? Without examples, it's hard to see why (or why not) recording would be adequate.

[drammock]

@oesteban example added in 034f62a. Does that help?

[smoia]

@neuromechanist @drammock in #1675 and BEP045 we're proposing to add an optional metadata field to indicate what data are collected together and hence are "auxiliary" (without necessarily forcing a hierarchy). IDK if that could be a valid option for you as well?

Also cc'ing other BEP045 leads startign with @m-miedema

[yarikoptic]

re sys entity -- sounds analogous to

• device/dev- entity + devices.{tsv,json} #2027

Left a comment with my preference on #1998 (comment).

As for "auxiliary" data types -- I think we should at large strive for making all data types "1st class citizens" since discrimination between them is mostly "an intent" of an experimenter and thus IMHO should be just noted at the level of the dataset, and otherwise result in identical layouts regardless of the intent: users looking for datatype X should find it in a consistent location regardless of the intent of the experimenter, and then some metadata structure (e.g. within filenames and _scans.tsv) should establish the relationship across subfolders if we are to have them at all (where BIDS 2.0 could potentially dissolve them). I know we have some fundamental divergences from such a potential principle (e.g. going back to _events.tsv nearby functional data vs beh/ folder ), but IMHO it is something to keep in mind for while working out new data types.

[drammock]

@smoia says:

in #1675 and BEP045 we're proposing to add an optional metadata field to indicate what data are collected together and hence are "auxiliary" (without necessarily forcing a hierarchy). IDK if that could be a valid option for you as well?

That looks useful, but I don't think it captures/addresses the use case we're facing. We're dealing with EMG as the primary modality, but with multiple separate devices making recordings simultaneously (from different muscles/locations on the body). So we need multiple *_emg.bdf files in the same sub-*/ses-*/emg/ folder, and need to differentiate them.

@yarikoptic says that we should consider the dev / device entity instead (cf. #2027). I strongly agree, device is semantically a better entity name than acq (or sys or recording) for what we're trying to capture. Shall I close this PR and open a new one to implement that? My only hesitation is that we need to pick something to make the EMG spec workable, and since acq already exists it seems like an easier lift to slightly expand its definition, rather than getting a whole new entity added.

[oesteban]

@oesteban example added in 034f62a. Does that help?

It does help, however the suffix is _emg which doesn't exist in BIDS to date. I believe the example given would perfectly be described as:

sub-01_recording-bipolar_physio.tsv.gz
sub-01_recording-grid_physio.tsv.gz

assuming that the two recordings have different sampling frequencies. Otherwise, they can be sibling columns in a single _physio.tsv.gz file.

With the acceptance of #1128 (fingers crossed), we could quickly define a new PhysioType electromyogram which would allow for specific metadata and rules for recordings names, as we are proposing for the new PhysioType eyetrack.

[drammock]

@oesteban example added in 034f62a. Does that help?

It does help, however the suffix is _emg which doesn't exist in BIDS to date.

@oesteban Please see the original description of this PR, where in the first sentence I explain that:

In #1998 we're working on a BEP for EMG data.

I intentionally didn't include an example here at first, since I know that it wouldn't make sense to merge an example that illustrates the EMG modality before that BEP is merged; I added such an example later at your request. So if you assume for a moment that an EMG modality does exist (or will soon) and interpret the example in that context, what do you think? Is expanding the definition of acq good (as in this PR), or do you prefer one of the other suggestions that have emerged:

• use recording
• use a new entity device
• use a new entity sys (based on tracksys)

[oesteban]

I did read the initial message. But rather than a solution to a problem within that BEP, it is presented as a current problem of BIDS. Unless an example fully compliant with current BIDS is given, I can only see this as a solution to an issue we don't have, and we may not have it in the future either. The eye tracking BEP020 avoided creating new suffixes and would be solid alternative to represent physio data with minimal changes to BIDS (no new entities).

…

On Tue, Apr 1, 2025, 16:45 Daniel McCloy ***@***.***> wrote: @oesteban <https://github.com/oesteban> example added in 034f62a <034f62a>. Does that help? It does help, however the suffix is _emg which doesn't exist in BIDS to date. @oesteban <https://github.com/oesteban> Please see the original description of this PR, where in the first sentence I explain that: In #1998 <#1998> we're working on a BEP for EMG data. I intentionally didn't include an example here at first, since I know that it wouldn't make sense to merge an example that illustrates the EMG modality *before* that BEP is merged; I added such an example later at your request. So if you assume for a moment that an EMG modality does exist (or will soon) and interpret the example in that context, what do you think? Is expanding the definition of acq good (as in this PR), or do you prefer one of the other suggestions that have emerged: - use recording - use a new entity device - use a new entity sys (based on tracksys) — Reply to this email directly, view it on GitHub <#2090 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESDRTZNRODHGEWOWH4OOD2XKYATAVCNFSM6AAAAABZVLGZBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRZHAYTOOBQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: drammock]*drammock* left a comment (bids-standard/bids-specification#2090) <#2090 (comment)> @oesteban <https://github.com/oesteban> example added in 034f62a <034f62a>. Does that help? It does help, however the suffix is _emg which doesn't exist in BIDS to date. @oesteban <https://github.com/oesteban> Please see the original description of this PR, where in the first sentence I explain that: In #1998 <#1998> we're working on a BEP for EMG data. I intentionally didn't include an example here at first, since I know that it wouldn't make sense to merge an example that illustrates the EMG modality *before* that BEP is merged; I added such an example later at your request. So if you assume for a moment that an EMG modality does exist (or will soon) and interpret the example in that context, what do you think? Is expanding the definition of acq good (as in this PR), or do you prefer one of the other suggestions that have emerged: - use recording - use a new entity device - use a new entity sys (based on tracksys) — Reply to this email directly, view it on GitHub <#2090 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESDRTZNRODHGEWOWH4OOD2XKYATAVCNFSM6AAAAABZVLGZBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRZHAYTOOBQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[drammock]

I did read the initial message. But rather than a solution to a problem within that BEP, it is presented as a current problem of BIDS.

OK, that was not my intent, so apologies that the original message wasn't clear. Hopefully this clarifies:

We have enountered a problem in preparing a BEP for electromyography (cf #1998) that we want to get wider input on. It is common to record EMG at different sites from multiple devices simultaneously. Sometimes the devices feed into the same amplifier and the data end up in the same file, sometimes that is not the case. When it's not, we need an entity to distinguish data files from devices recording simultaneously. We're considering using acq but its current definition doesn't clearly reflect our use case. Here's a proposed definition update that would meet our needs. Open to other suggestions.

The eye tracking BEP020 avoided creating new suffixes and would be solid alternative to represent physio data with minimal changes to BIDS (no new entities).

Perhaps. But this PR as written isn't proposing any new entities, it's proposing to (slightly) expand the definition of an existing entity. @effigies then suggested using recording (also not new). @JuliusWelzel had previously suggested sys (as analogous to tracksys) which is technically new, but with the understanding that tracksys would be replaced with the more general sys afterwards. The only truly new proposed entity was @yarikoptic's idea to use device (which was already proposed elsewhere in #2027).

If your feedback is "there is no need for an EMG modality, just use _physio analogous to what we're proposing in BEP020" then I think that feedback belongs over at #1998, not here. Reading between the lines, however, your example filenames are using recording so I guess for the question at hand, you're voting for recording over the other proposed entities?

[oesteban]

If this PR is merged but BEP042 finally doesn't use it or uses it differently, then we would be adding something already abandoned with this PR. I believe this should be discussed there already.

Happy to join the discussion of BEP042 and make a case for the BEP020 rationale. That said, I'll try to push BEP020 over the finish line before I can dedicate any time to another physiology BEP.

[neuromechanist]

FWIW, I also support the dev/device entity. It is general enough to cover many cases (unless there is a multimodal recording device, such as a wearable, in which I think different channels will have their channel type anyways). This entity also provides the opportunity to introduce devices.tsv/json down the road to describe the list of recording instruments used across modalities.

@oesteban, You are more than welcome to join the BEP042 #1998 or #1371 discussion. I look forward to discussing the possibility of including electromyography on different limbs as a part of Eye-tracking specifications. An argument might be whether there is a need for separate Eye-tracking or EMG BEPs, and shouldn't all be consolidated into BEP045 (Physio-BIDS, #1675). Although this discussion has been done here and there, it might be worth consolidation in a separate Issue.

IMO, the rationale for this PR is quite clear and beyond #1998 as comments provided by the stakeholders from other BEPs also point out: Some modalities might have concurrent data recordings that, for some technical reasons, can't be part fo the same file. This can be different tracking systems in Motion-BIDS, concurrent video recordings in #1771, multiple Physio recordings in BEP045 and also recording EMG using more than one device.

Since these efforts are going quite in parallel, it made sense to create this PR to coordinate with all stakeholders to harmonize the use of an entity that refers to such concurrent recording across all data types/modalities.

Is there a risk that this PR goes through and #1998 does not?

Yes, but that is quite minimal. Even in that case, there are still several other potential BEPs that could use this PR for their specifications.

[oesteban]

FWIW, I also support the dev/device entity. It is general enough to cover many cases (unless there is a multimodal recording device, such as a wearable, in which I think different channels will have their channel type anyways). This entity also provides the opportunity to introduce devices.tsv/json down the road to describe the list of recording instruments used across modalities.

Sure, that's not what's being proposed here, and considering the volume of such a change, a device entity would likely require its own BEP because it conflicts with current BIDS foundations (which may be wrong, I'm not entering that debate). Let's focus on this particular PR.

@oesteban, You are more than welcome to join the BEP042 #1998 or #1371 discussion. I look forward to discussing the possibility of including electromyography on different limbs as a part of Eye-tracking specifications. An argument might be whether there is a need for separate Eye-tracking or EMG BEPs, and shouldn't all be consolidated into BEP045 (Physio-BIDS, #1675). Although this discussion has been done here and there, it might be worth consolidation in a separate Issue.

Thank you for the invitation—I certainly appreciate the openness to broader discussions. My main point here was procedural clarity: the BEP mechanism is designed precisely to handle these broader, cross-cutting discussions.

BIDS established the BEP mechanism for large changes so those iterations over the spec are made consistently. Splitting this from those BEPs is inconsistent and risks introducing a problem. If there's a dependency relationship between BEPs (and that sounds reasonable and likely), then the solution is to make BEP045 contingent on the outcome of BEP042, so if this change to acq- is accepted there, then BEP045 would just piggyback on that change.

As you indicate at the end, I would not call for caution if this were just a separate issue—however, it's a PR that may introduce a change to the spec.

IMO, the rationale for this PR is quite clear and beyond #1998 as comments provided by the stakeholders from other BEPs also point out: Some modalities might have concurrent data recordings that, for some technical reasons, can't be part fo the same file. This can be different tracking systems in Motion-BIDS, concurrent video recordings in #1771, multiple Physio recordings in BEP045 and also recording EMG using more than one device.

I understand and appreciate that rationale. The issue I'm raising here is one of scope and procedure. The PR mechanism in BIDS is typically reserved for incremental, less controversial changes or bug fixes. Given the cross-cutting nature of the proposed change (affecting multiple BEPs), addressing this change first as an issue calling for opinions or as part of BEP042 seems more appropriate. This would ensure that all stakeholders have a clear understanding and agreement before making permanent updates to the specification.

In general, BIDS evolves the spec BEP-by-BEP. The PR mechanism is reserved to fix uncontroversial, safe changes.

Since these efforts are going quite in parallel, it made sense to create this PR to coordinate with all stakeholders to harmonize the use of an entity that refers to such concurrent recording across all data types/modalities.

I completely agree and support the idea of coordination and harmonization across BEPs—it is indeed essential. My intention isn't to discourage coordination but rather to ensure it happens in a structured way that respects established BIDS procedures. Perhaps an issue explicitly aimed at harmonizing these parallel discussions, gathering input from all stakeholders upfront, might serve better than immediately proceeding with a specification-changing PR.

Is there a risk that this PR goes through and #1998 does not?

Yes, but that is quite minimal. Even in that case, there are still several other potential BEPs that could use this PR for their specifications.

I appreciate your assessment here. My perspective is simply that any risk—minimal as it may seem—of prematurely committing to a specification change that could affect ongoing BEPs warrants caution. It's precisely to manage this kind of risk that BIDS established the BEP mechanism.

Overall, my recommendation is procedural rather than conceptual: let's ensure we're clear on dependencies, implications, and cross-BEP coordination before committing to this PR. I believe that will strengthen our collective efforts, reduce potential friction, and better serve the community in the long run.

[drammock]

I appreciate you taking the time to clearly explain your rationale @oesteban.

Overall, my recommendation is procedural rather than conceptual: let's ensure we're clear on dependencies, implications, and cross-BEP coordination before committing to this PR. I believe that will strengthen our collective efforts, reduce potential friction, and better serve the community in the long run.

That makes sense to me, and I think the root of this dialog is that I am used to a different set of norms around the distinction between "issue" and "pull request". In the dev communities where I spend most of my time, it's OK to open pull requests as a conversation-starter/request-for-input if it makes it easier to see exactly what is being suggested (via the diff view on GitHub). I probably should have made it clearer that such was my intent (at a minimum marking the PR as draft, which I'll do now).

The PR mechanism in BIDS is typically reserved for incremental, less controversial changes or bug fixes. Given the cross-cutting nature of the proposed change (affecting multiple BEPs), addressing this change first as an issue calling for opinions or as part of BEP042 seems more appropriate.

I'm happy to work within the norms of this community, now that I know what some of them are.
That said, I do feel you're being a bit harsh here, given that the discussion about this was started within the BEP, and it was suggested that we get wider input via a PR. I'm not trying to shift blame here, rather just pointing out that I'm apparently not the only one who thought a proposal-as-PR would be OK (and AFAICT nobody else who commented before you was bothered by its status as PR vs issue).

[oesteban]

That makes sense to me, and I think the root of this dialog is that I am used to a different set of norms around the distinction between "issue" and "pull request". In the dev communities where I spend most of my time, it's OK to open pull requests as a conversation-starter/request-for-input if it makes it easier to see exactly what is being suggested (via the diff view on GitHub). I probably should have made it clearer that such was my intent (at a minimum marking the PR as draft, which I'll do now).

Thanks for clarifying! I completely understand where you're coming from. BIDS BEPs function similarly to Python's PEPs (and other large-scale projects), guiding broader discussions through established processes to ensure changes have solid consensus. Given how critical backward compatibility is for BIDS, each PR tends to be carefully evaluated. Even changes that appear straightforward at first glance can have unforeseen implications later on, which is why careful review is so important.

That said, I do feel you're being a bit harsh here, given that the discussion about this was started within the BEP, and it was #1998 (comment).

I’m sorry if my feedback came across as harsh—this was definitely not my intent. I understand your approach better now after seeing how this discussion started within the BEP. For those like me who had not engaged in the BEP but received notifications of this PR, it seemed to represent an effort to push a change rather than a request for discussion. And as I mention above, changes to BIDS require rigorous assessment even if they seem innocuous. Marking it as a draft now does help clarify your intent, and I appreciate you doing that.

I will try to look at BEP042 asap and provide feedback. That said, we are in the final stages of BEP020 and I think that could definitely change the way BEP042 and BEP045 are being approached. I would invite you, @neuromechanist, @JuliusWelzel and others to join our meeting on Thursday (info to join is given on the PR's message #1128).

[neuromechanist]

I brought this PR to today's @bids-standard/maintainers. It seems that recording-<label> would require the least changes to the specifications to accommodate concurrent recordings.
This is of course in the context of EMG being a modality and data type, which is being discusses in #2108.

Maybe harmonizing the entity to indicate recordings from different instruments (tracksys, recording, and the proposed dev #2027) would be a topic for BIDS2.0

[neuromechanist]

I think the overall consensus is to use the recording entity for this use case.
I will update to follow this: bids-standard/bids-examples#480

The definition can be very minimally updated:

bids-specification/src/schema/objects/entities.yaml

Lines 253 to 255 in 034f62a

	This entity is commonly applied when continuous recordings have different sampling frequencies or start times.
	For example, physiological recordings with different sampling frequencies may be distinguished using
	labels like `recording-100Hz` and `recording-500Hz`.

This can be updated to

This entity is commonly applied when continuous recordings are from different acquisition instruments, have different sampling frequencies**, or different** start times. For example, physiological recordings with different sampling frequencies may be distinguished using labels like recording-100Hz and recording-500Hz.

[effigies]

Should this still be marked draft?

[drammock]

Should this still be marked draft?

thanks for the ping. I've updated the PR description slightly to match the edited title, and pulled out of draft mode.