deploy: 2caf15e

_sources/index.md.txt

@@ -7,7 +7,7 @@
 
 The [SWC-Blueprint specification](specification.md) provides a set of rules and guidelines for project folder organisation, ensuring consistent data management within and between labs. The focus is on ensuring minimal overhead for researchers.
 
-**SWC-Blueprint** is being developed at the [Sainsbury Wellcome Centre (SWC) for Neural Circuits and Behaviour](https://www.sainsburywellcome.org/) by members of the [Neuroinformatics Unit (NIU)](https://neuroinformatics.dev/). As such, it prioritizes interoperability with NIU-developed data analysis tools. 
+**SWC-Blueprint** is being developed at the [Sainsbury Wellcome Centre (SWC) for Neural Circuits and Behaviour](https://www.sainsburywellcome.org/) by members of the [Neuroinformatics Unit (NIU)](https://neuroinformatics.dev/). As such, it prioritizes interoperability with NIU-developed data analysis tools.
 
 That said, the specification is designed to be as general as possible, and should be useful to anyone within the neuroscience field. We (the NIU) welcome [feedback](https://github.com/neuroinformatics-unit/SWC-Blueprint/discussions) and contributions from the wider community and commit to maintaining the specification as a living and evolving document. We will also collaborate with [ongoing efforts](https://github.com/INCF/neuroscience-data-structure) by the [INCF](https://www.incf.org/) and [BIDS community](https://bids.neuroimaging.io/) to extend the BIDS specification to non-human animal research.
 
@@ -16,4 +16,4 @@ That said, the specification is designed to be as general as possible, and shoul
 :caption: Contents
 
 specification
-```
+```

_sources/specification.md.txt

@@ -7,7 +7,7 @@ In addition, it also includes some non-mandatory conventions for [naming files](
 We mark requirements with italicised *keywords* that should be interpreted as described by the [Network Working Group](https://www.ietf.org/rfc/rfc2119.txt). In decreasing order of requirement, these are: *must* {octicon}`alert;1em;sd-text-danger`, *should* {octicon}`info;1em;sd-text-warning`, and *may* {octicon}`check-circle;1em;sd-text-success`.
 :::
 
-## Project folder structure 
+## Project folder structure
 
 Standardised project folders contain data that are hierarchically structured according to the [BIDS standard](https://bids-specification.readthedocs.io/en/stable/02-common-principles.html).
 
@@ -20,9 +20,9 @@ For example:
 
 * The project folder *may* have any name descriptive of the project, but it *must* be without spaces.
 
-* Within the project folder, data *must* be separated into `rawdata` and `derivatives`. 
+* Within the project folder, data *must* be separated into `rawdata` and `derivatives`.
 
-  * `rawdata`: coming out of the data acquisition system (e.g. binary files, tiffs, videos files). 
+  * `rawdata`: coming out of the data acquisition system (e.g. binary files, tiffs, videos files).
 
   * `derivatives`: any processed data that is derived from `rawdata` (e.g. spike sorting or pose estimation).
 
@@ -32,29 +32,29 @@ For example:
 
 * Datatype folder names *must* be one of the following : `ephys`, `behav`, `funcimg`, `histology`.
 
-* If collected, `ephys`, `behav`, `funcimg` *must* be placed under the session level. If collected, `histology` *must* be placed under the subject level. 
+* If collected, `ephys`, `behav`, `funcimg` *must* be placed under the session level. If collected, `histology` *must* be placed under the subject level.
 
 Below we describe each level of the `rawdata` folder hierarchy in more detail. Though we impose no absolute requirements for the folder structure within `derivatives`, it *should* match the hierarchy in `rawdata` whenever possible.
 
 ### Subject
 
-* Each subject *must* have exactly one subject-level folder. 
-* Subject-level folders *must* be prefixed with a key-value pair that is unique for each subject. The key *must* be `sub` and the value *must* be numerical, e.g. `sub-001`. 
+* Each subject *must* have exactly one subject-level folder.
+* Subject-level folders *must* be prefixed with a key-value pair that is unique for each subject. The key *must* be `sub` and the value *must* be numerical, e.g. `sub-001`.
 * Subjects *should* be assigned ascending numerical labels as they are added to the project. The labels *should* be prefixed with an arbitrary number of 0s for consistent indentation and sorting, e.g. `sub-001`, `sub-002`, `sub-003`.
 * Additional key-value pairs with alphanumerical labels *may* be appended after the `sub` key-value pair. For example, animal IDs (e.g. from the animal facility) can be added as follows: `sub-001_id-5645332`. The keys *should* be consistent across subjects.
 
 :::{hint}
 * valid: `sub-02`, `sub-001_id-5645332_sex-F`, `sub-02_species-mouse`
-* invalid: 
+* invalid:
   * `mouse-01`: the first key should have been `sub`.
   * `sub-001_female`: `female` should have been written as a key-value pair (e.g. `sex-female`)
   * `sub-B`: the `sub` key should have a numerical value
 :::
 
 ### Session
 
-* Each session *must* have exactly one session-level folder. 
-* Session-level folders *must* be prefixed with a key-value pair that is unique for each session. The key *must* be `ses` and the value *must* be numerical, e.g. `ses-01`. 
+* Each session *must* have exactly one session-level folder.
+* Session-level folders *must* be prefixed with a key-value pair that is unique for each session. The key *must* be `ses` and the value *must* be numerical, e.g. `ses-01`.
 * Sessions *should* be assigned ascending numerical labels as they are added to the project. The labels *should* be prefixed with an arbitrary number of 0s for consistent indentation and sorting, e.g. `ses-01`, `ses-02`, `ses-03`.
 * Additional key-value pairs with alphanumerical labels *may* be appended after the `ses` key-value pair. For example, dates can be added as follows: `ses-001_date-20230310`. The keys *should* be consistent across subjects.
 * If a date field is added, it *should* be in the format `YYYYMMDD`.
@@ -93,8 +93,8 @@ A real project folder might look like:
     │       │   │   ├── sub-001_ses-01_recording-01.bin
     │       │   │   └── sub-001_ses-01_probe-3A.imec0
     │       │   └── behav/
-    │       │       ├── sub-001_ses-01_camera-01.wav 
-    │       │       └── sub-001_ses-01_data-responses.csv 
+    │       │       ├── sub-001_ses-01_camera-01.wav
+    │       │       └── sub-001_ses-01_data-responses.csv
     │       └── histology/
     │           └── sub-001_image-brain.tiff
     └── derivatives/

_static/basic.css

@@ -237,6 +237,10 @@ a.headerlink {
     visibility: hidden;
 }
 
+a:visited {
+    color: #551A8B;
+}
+
 h1:hover > a.headerlink,
 h2:hover > a.headerlink,
 h3:hover > a.headerlink,
@@ -670,6 +674,16 @@ dd {
     margin-left: 30px;
 }
 
+.sig dd {
+    margin-top: 0px;
+    margin-bottom: 0px;
+}
+
+.sig dl {
+    margin-top: 0px;
+    margin-bottom: 0px;
+}
+
 dl > dd:last-child,
 dl > dd:last-child > :last-child {
     margin-bottom: 0;
@@ -738,6 +752,14 @@ abbr, acronym {
     cursor: help;
 }
 
+.translated {
+    background-color: rgba(207, 255, 207, 0.2)
+}
+
+.untranslated {
+    background-color: rgba(255, 207, 207, 0.2)
+}
+
 /* -- code displays --------------------------------------------------------- */
 
 pre {

_static/documentation_options.js

@@ -1,5 +1,4 @@
-var DOCUMENTATION_OPTIONS = {
-    URL_ROOT: document.getElementById("documentation_options").getAttribute('data-url_root'),
+const DOCUMENTATION_OPTIONS = {
     VERSION: '0.1.0',
     LANGUAGE: 'en',
     COLLAPSE_INDEX: false,