A JSON-LD version of the dataset_description.json metadata for harmonizing with other data standards?

[mekline]

Your idea

Hi there - This is my first BIDS issue, so please feel free to close/reroute me if this is the wrong forum for this question!

I work on Psych-DS, a BIDS-inspired standard for tabular behavioral datasets. One thing that has come up in my conversations with tool builders is that they are nervous about potentially needing to support multiple metadata files that 'clutter' a user's directory, or otherwise needing to handle the presence of more than one type of metadata. One use case for this scenario might be a scanning session that uses a task script originally developed for non-scanner use that generates its own response data output directory; the researcher then wants to incorporate this response data into a BIDS beh/ directory.

A possible solution to this problem would be for multiple data standards to allow for an "alias" for the top-level metadata object, e.g. by permitting a file called metadata.json that contains one or more JSON-LD objects.

For BIDS, this would mean allowing this alternative to the dataset_description.json with only a minor change to the content, namely the inclusion of a null @context field. This would allow the correct/relevant JSON to be identified, and any other JSON-LD content present in the file should be ignored by the BIDS spec.

This might look like:

{
  "@context" : null,
  "Name": "The mother of all experiments",
  "BIDSVersion": "1.6.0",
  "DatasetType": "raw",
  "License": "CC0",
  "Authors": [
    "Paul Broca",
    "Carl Wernicke"
  ],

##...etc.##

(As a side note, this might open a door to JSON-LD BIDS context or mapping to schema.org but that's a story for another day...this question is really just about the potential to 'package' the top-level metadata object into a file that might contain additional, irrelevant-to-BIDS information.)

[Remi-Gau]

@mekline

Thanks for opening this issue.

Will point you to other issues or PRs (that I can remember) where jsonld has been mentioned.

• BEP028 - Provenance #487
• add subfields to authors in dataset_description.json #602
• dataset_description.jsonld #577

pinging people involved in those

@CPernet @cmaumet @satra

[CPernet]

if I understood @satra simply adding "@context" : null, makes dataset_description.json a jsonld and we don't even have to change the extension, and that would be fine

the bigger change would be to allow metadata.json which is unlikely IMO.

[satra]

could we simply say that an @context is optionally allowed, but if provided should follow json-ld specifications? we could formalize this in bids itself saying that a bids-specific context has to be part of @context (which has to be an array of urls/objects or an object)? technically @context=null would result in a jsonld.SyntaxError: Invalid JSON-LD syntax; @context must be an object.

regarding the manifest.json, @mekline could we work through a simple example to demonstrate the issues?

[yarikoptic]

would it be too premature to suggest/discuss "An optional @context in any .json file must follow JSON-LD specification." or it would not even be needed? ;-)

[yarikoptic]

Relates to

• [ENH] Add ContextURI to allow to define the context for the entity values #1939
• About context BEP028_BIDSprov#147