Unification of FOXDEN schemas

[vkuznet]

We are moving towards consolidation of CHESS beamline schemas. So far we have the following new embeddable schemas:

• did.json
• beamline.json
• doi.json

We need feedback from CHESS scientist to decide if they can be applied.

@wernersun , @keara-soloway , @rolfverberg, @suchismitasarker, @jpk96 please review proposed schemas and provide feedback in this ticket.

[jpk96]

@vkuznet I’ve reviewed the three .json files. doi.json appears to be applicable for 3B. For did.json and especially beamline.json, I have specific comments on several keys. Some relate to how certain information might be automatically retrieved, while others concern placeholders and whether certain keys are relevant for 3B. Would this issue thread be the best place to share those comments, or is there an alternative (or preferred) venue for that feedback?

[vkuznet]

@jpk96 , Peter please provide feedback here as it will be documented and can be used for references to communicate with other scientists/beamline groups.

[jpk96]

did.json

• For did, I recommend using "/" as the placeholder, since each beamline may have its own method for generating a unique value.

beamline.json

• For beamline, I recommend using "" as the placeholder, not "3A".
• For staff_scientist, the list of values and placeholder should be determined by the selected beamline.
• For beamline_funding_partner, the placeholder should be determined by the selected beamline. Additionally, we could explore a way to retrieve the value from BeamPASS (There are several other keys whose values could be retrieved from BeamPASS. If desired, we could create a separate issue to address this).
• I recommend removing alignment, as it is not common across all beamlines.
• For data_location_*, I recommend retaining only data_location_raw as the other keys may not be used consistently across all beamlines.

doi.json

• I do not have any comments

[vkuznet]

@jpk96 , Peter thank you for feedback. If we should treat staff_scientist and beamline_funding_partner dynamically (e.g. based on beamline) then they should not be present in common static schema file used by all beamlines. But if we only collect all scientists names and partners in these attributes then we can leave empty string for them. Regarding did placeholder I doubt we should make it ambiguous, I rather prefer to give concrete example how it should be constructud otherwise we will only confused users. Keep in mind that placeholder is only used in web UI to give users a clue how value should looks like. But it is not default value of specific attribute.