[SCHEMA] Add metadata term files #762
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,6 +14,23 @@ Templates: | |
| The file `dataset_description.json` is a JSON file describing the dataset. | ||
| Every dataset MUST include this file with the following fields: | ||
|
|
||
| {{ MACROS___make_metadata_table( | ||
| { | ||
| "Name": "REQUIRED", | ||
|
There was a problem hiding this comment. I don't see name in rendered version: https://bids-specification--762.org.readthedocs.build/en/762/03-modality-agnostic-files.html#dataset_descriptionjson |
||
| "BIDSVersion": "REQUIRED", | ||
| "HEDVersion": "RECOMMENDED", | ||
| "DatasetType": "RECOMMENDED", | ||
| "License": "RECOMMENDED", | ||
| "Authors": "OPTIONAL", | ||
| "Acknowledgements": "OPTIONAL", | ||
| "HowToAcknowledge": "OPTIONAL", | ||
| "Funding": "OPTIONAL", | ||
| "EthicsApprovals": "OPTIONAL", | ||
| "ReferencesAndLinks": "OPTIONAL", | ||
| "DatasetDOI": "OPTIONAL", | ||
| } | ||
|
There was a problem hiding this comment. having such specifications in the document text would be a big step back from toward the target of having a "machine readable" schema. Why not to add There was a problem hiding this comment.
I see it as an incremental move forward. It definitely doesn't solve a lot of the problems (e.g., requirement levels, conditional relationships between metadata fields), but to be fair those are the hard problems so I don't feel too bad about it.
I'll have to try it out, but that sounds like a good plan for the PR after this one. I figure that, since we want to separate the core definitions from the rules of the schema, we can tackle those two pieces in separate stages. There was a problem hiding this comment. I think the best next step for the schema (after this) is to try to identify the types of rules we can expect from the schema, along with any really weird edge cases. That's what I've tried to do in #620, although I worry that my current list isn't exhaustive. Without a list of necessary rules, I'm not sure if we can define them in YAML files in a way that will satisfy everyone. There was a problem hiding this comment. Sure could and should be a multistage process. I am ok with your proposal. I just thought that it might be nice to just put rules identification for later pr, thus keep description free form, while already allowing for machine readable specification of possible requirement levels and keeping everything under src/schema. But such a move could indeed be just yet another follow up PR to not block this one |
||
| ) }} | ||
|
|
||
| | **Key name** | **Requirement level** | **Data type** | **Description** | | ||
| |--------------------|-----------------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | Name | REQUIRED | [string][] | Name of the dataset. | | ||
|
|
@@ -69,6 +86,13 @@ In addition to the keys for raw BIDS datasets, | |
| derived BIDS datasets include the following REQUIRED and RECOMMENDED | ||
| `dataset_description.json` keys: | ||
|
|
||
| {{ MACROS___make_metadata_table( | ||
| { | ||
| "GeneratedBy": "REQUIRED", | ||
| "SourceDatasets": "RECOMMENDED", | ||
|
There was a problem hiding this comment. SourceDatasets is missing: https://bids-specification--762.org.readthedocs.build/en/762/03-modality-agnostic-files.html#derived-dataset-and-pipeline-description I guess script should be adjusted to error out if some field is not "handled"? There was a problem hiding this comment. Ultimately yes, but since I'm still in the process of converting all of the metadata terms, I don't want everything to error out just yet. Right now it just filters out any missing terms and renders the available ones. |
||
| } | ||
| ) }} | ||
|
|
||
| | **Key name** | **Requirement level** | **Data type** | **Description** | | ||
| |----------------|-----------------------|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | GeneratedBy | REQUIRED | [array][] of [objects][] | Used to specify provenance of the derived dataset. See table below for contents of each object. | | ||
|
|
@@ -339,15 +363,15 @@ The purpose of this file is to describe timing and other properties of each | |
| imaging acquisition sequence (each *run* file) within one session. | ||
|
|
||
| Each neural recording *file* SHOULD be described by exactly one row. | ||
| Some recordings consist of multiple parts, that span several files, | ||
| for example through `echo-`, `part-`, or `split-` entities. | ||
| Such recordings MUST be documented with one row per file. | ||
|
|
||
| Relative paths to files should be used under a compulsory `filename` header. | ||
|
|
||
| If acquisition time is included it should be listed under the `acq_time` header. | ||
| Acquisition time refers to when the first data point in each run was acquired. | ||
| Furthermore, if this header is provided, the acquisition times of all files that | ||
| belong to a recording MUST be identical. | ||
|
|
||
| Datetime should be expressed as described in [Units](./02-common-principles.md#units). | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
table seems to be (rendered) empty, shortcut link https://bids-specification--762.org.readthedocs.build/en/762/02-common-principles.html#tabular-files