Introduce roles for files related to calculations

[merkys]

During workshop discussions, @giovannipizzi suggested introducing a means to specify how files are related to calculations entries. This PR introduces meta.role field to specify whether an attached file is input or output relative to the calculation in question.

Furthermore, there was a suggestion to order the related output files in a way to make it easier for automated analysis software to parse the output files in order to identify the code and/or calculation type used. Since it is impossible to define the deterministic orders for all the used codes, the suggestion is to use an arbitrary order where output files most likely to contain the identifying information come first. This way analysis software would encounter the identifying output files earlier and stop before reading in all the output files.

[rartino]

My first reaction is: doesn't this belong in metadata data rather than as data metadata? In the sense calculations records the provenance of something, the "inputs", the "outputs" and the "process/workflow" seems the core data in such an entry?

Edit: I noticed that I had swapped metadata and data in my comment. Sorry for sounding confused.

[merkys]

My first reaction is: doesn't this belong in metadata rather than as data? In the sense calculations records the provenance of something, the "inputs", the "outputs" and the "process/workflow" seems the core data in such an entry?

My suggestion is to define the inputs/outputs division in metadata of relationships. Since we use them (relationships) to refer to other entries, then I think meta of relationships is the most appropriate place to store this metadata.

[rartino]

JSON:API's meta of relationships is not something that exists in OPTIMADE outside of the JSON:API response format, so we have to define this "place" where to store this machine readable role in section 3.7. And, if we do that, why not encode that in the relationship name in JSON:API, instead of down inside the meta object?

From a "least surprise" perspective, it makes more sense to me that there is an "input" and an "output" relationship that contains the relationship linkage to inputs and outputs.

[merkys]

We have discussed this proposal during the workshop and identified a drawback: there is no way to query on relationship metadata, nor now, nor after #524 gets merged in. A possible solution was put forward to use named relationships (now relationships are named after entry types), but this would possibly:

1. interfere with the common property-entrytype namespace
2. break the nice attribute which guarantees that relationships under the same name are of the same entry type