search

SD2E / experimental-intent-parser

A tool that combines a word-processing interface with structured tables and assisted linking to definitions to provide a simple interface for incremental codification of experiment designs.
BSD 3-Clause "New" or "Revised" License
4 stars 0 forks source link

Autofill optional parameter fields for opil output #328

Closed tramyn closed 3 years ago

tramyn commented 3 years ago

Below is a list of parameter fields that xplan expect Intent Parser to have provide information but are getting dropped from opil output.

This will need to be fixed when processing opil output:

 experimental_info.experiment_id
 experimental_info.experiment_reference
 experimental_info.experiment_reference_url
jgladwig commented 3 years ago

Adding a summary of what I heard at the end of the call today that seemed like a shift in how this data is represented. Please let me know if it does not match with what others were hearing or expecting.

Short form: We were talking above moving the SD2 specific values that are used by XPlan and the labs from Parameter objects to custom annotations.

Thoughts and details: I think the main benefit of the shift is that is removes the requirement of SD2 specific values from being represented as Parameter objects on the ProtocolInterface. There are some rough edges that carry over from how we have handled interaction with Strateos so far. More below...

We are dealing with these three values:

These values are used by and must be accessible by XPlan. They are also used by Strateos (to identify uploaded data). They will ultimately be used by Aquarium for the same purpose as they are currently used by Strateos. To date the values have been included in the Strateos params file as a direct part of their protocol. So the direct conversion of these values (as seen in the Strateos to OPIL converter) is to treat them as Parameter objects on the ProtocolInterface.

What I was hearing today was that we do not want to continue this behavior of treating these values as Parameter objects as we incorporate Aquarium into the system. Instead we were talking about shifting to using custom annotations within the SD2 namespace on the ExperimentalRequest object that is returned by Intent Parser. This sounds like it will work reasonably well as XPlan has access to the values by reading the three annotations off of the ExperimentalRequest.

In addition the information is still available to both Strateos and Aquarium under the same custom annotation that is present on the ExperimentalRequest sent out by XPlan. So the OPIL to Strateos converter will be able to incorporate these values into their specific protocol json by reading from the custom annotations while parsing the OPIL document. Aquarium will have this same access when parsing the OPIL for their specific internal format/processing pipeline.

I will note one issue I immediately see. I expect it is minor and just something to be aware of. The issue relates to the ProtocolInterface object that is currently returned by the Strateos to OPIL converter. This converter reads through the entire protocol object as defined by the Strateos protocol json description and creates an equivalent OPIL representation as a ProtocolInterface. In doing so this will result in the existence of Parameter fields on the ProtocolInterface for:

 experimental_info.experiment_id
 experimental_info.experiment_reference
 experimental_info.experiment_reference_url

Assuming we follow the custom annotation changes as I described above this will mean these three Parameters will never be used and should never be used because their values are instead represented as custom annotations on the ExperimentalRequest.

Please let me know if the above makes sense. It is a fairly notable change from how these three values have been represented so far but given the desire I was hearing to avoid requiring special changes to protocols to specifically support the SD2 pipeline it seems like a fair change to make.

jakebeal commented 3 years ago

@jgladwig I believe that is indeed a better path forward.

These values really aren't parameters that affect the manner in which the protocol is executed. They are metadata that is added to the ExperimentRequest to help the SD2 system catalog it. Therefore, they should really be additional SD2-specific fields on the ExperimentRequest.

The Strateos-to-OPIL converter will, indeed, need to be modified to make the equivalent change, though intermediate kludges of various sorts should be fine during the transition.