Formalize concept of '{entity}-<label>_description.json'

[yarikoptic]

To overall provide a mechanism for per an {entity}_id metadata, alternative to {entity_plural}.tsv which we used so far and for which I filed a separate

• Formalize the concept of [{leading entities}_]{entity_plural}.{tsv,json} file(s) #2283

It was born to provide a similar (if not inspired) to dataset_description.json nested (includes lists of Authors etc) metadata record per each value of the atlas-<label> in

• BEP-038: Atlases #1714 by @bep038 group

I argued that we already have a conceptual solution for such aggregated metadata in the form of {entity_plural}.tsv (such as participants.tsv, sessions.tsv) and that introduction of such files really introduces a new conceptual new location for metadata specification as for no other entity we have such a file ATM, thus this relates heavily to

• Formalize "life-cycle"/movement and placement of metadata bids-2-devel#85

In principle we can have both this and {entity_plural}.tsv "interchangeable" besides forbidding aspects:

• names are PascalCased in json and snake_cased in tsv, and we do not have "crosswalks"
• optional columns in .tsv could still get their schema described whenever we do not have anything similar for .json so if anything custom (e.g. Version as was already provided in feedback via email) added to such a file -- would not be validatable.

thus making us to choose one or another for any particular entity, with atlas being the only one for _description.json ATM and mixing it with non-entity dataset_description.json. Also it might potentially "interfer" with Inheritance principle as suggesting that it applies to all _description.json files undeneath not really for all instances of that atlas label being used.

Without formalization, we would just make it more complicated for people to

• create datasets (do I use .tsv or .json for this entity?)
• operate on datasets programatically (need to code for both principles in general but only for specific entities)