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.

[vkuznet]

I am tagging @ksg52 @adas42 @suchismitasarker @kenygren for any input they can provide on this topic. Please look-up the following proposed common schema files and let us know your opinion:

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

@wernersun I suggest to put this ticket on display for discussion on next CHESS comp scientist meeting.

[ksg52]

in beamline.json:

• for the key "beamline", we should already add "5A" into the value list
• for key "staff_scientist", if this stays in the beamline.json the value list should be expanded to, at least: "ShanksKS, DasA, GustafsonSE, KoJYP, NygrenKE, SarkerS, PollockCJ, DebefveL, SmieskaL, WollAR, YeeE" at present - and we should probably confirm with individual scientists how they want to appear (e.g. WollA vs WollAR). Contrary to @jpk96 I would prefer that staff_scientist values not be determined by the selected beamline because we have had edge cases at 3A where another CHESS staff member (for example, Jacob) subs in for alignment and support for a week.
• similarly, I would prefer the values for "beamline_funding_partner" not be determined by the selected beamline, again because of weird edge cases. All values should just be accessible.
• Agree with @jpk96 on removing the "alignment" key.
• I would prefer removing "affiliation" from beamline.json, we do not use it at 3A.

[vkuznet]

@ksg52 , @jpk96 , I adjusted beamline.json according to your feedback. Please review it again.

[suchismitasarker]

@vkuznet Updated beamline.json looks good to me. Thank you!

[ksg52]

@vkuznet updated beamline.json looks good to me. I agree with Arthur's comment in last week's meeting that we should present this at a Thursday scientist meeting to confirm buy-in from folks not actively interacting here. If you like, I can take the lead on presenting and collecting feedback (which I can put into this issue).

[vkuznet]

@ksg52 , I think it would be more appropriate if you'll present this on scientist meeting. I'm providing technical part but I cannot make decision about actual content as it is driven by scientist requirements.

[jpk96]

@vkuznet I reviewed beamline,.json and have a couple of suggested edits to consider:

• for beamline key: I recommend replacing "5A" with "5". Looking ahead, there will likely be an additional value ("6") to add in the future, though that doesn’t need to be added right now.
• For the values in the staff_scientist key: I like @wernersun's suggestion from last week's meeting of using CLASSE ID. Another reason to consider this is that for beamlines which record participants during beam time, this information could potentially be captured from BeamPASS automatically with each participant's CLASSE ID -- the information BeamPASS already has for each scheduled beam time. Using CLASSE IDs for staff_scientists would also provide consistency in how we capture personnel information.