opendatafit / bindfit-datapackage

Bindfit datapackage for opendata.fit
0 stars 0 forks source link

Implement algorithm view to replace params and options views #13

Closed echus closed 9 months ago

echus commented 9 months ago

Mapping between params and options resources should happen inside algorithm specification.

JamesWilmot commented 9 months ago

So my thoughts on this are that we should probably tie together parameters and options at the algorithm level a la something like the below:

{
  "name": "bindfit",
  "title": "Bindfit",
  "code": "",
  "inputs": [
    {
      "name": "data",
      "type": "resource",
      "resource": "inputData",
    },
    {
      "name": "params",
      "type": "resource",
      "resource": "inputParamsNMR12",
      "view": "some-view"
    },
      {
      "name": "options",
      "type": "resource",
      "resource": "bindfit-options-1",
      "view": "some-view-for-bindfit-options-1"
    }
  ],
  "outputs": [
    {
      "name": "params",
      "type": "resource",
      "resource": "outputParams"
    },
    {
      "name": "fit",
      "type": "resource",
      "resource": "outputFit"
    },
    {
      "name": "residuals",
      "type": "resource",
      "resource": "outputResiduals"
    }
  ],
  "resources": [
    {
      "title": "NMR1:1",
      "name": "nmr11",
      "inputs": [{
        "params": {
          "resource": "inputParamsNMR1:1",
          "view": "some-view-here"
        } , 
        "options": {
          "resource": "some-bindfit-options",
          "view": "some-view-here"
        }
      }]
    },
  ]
}

With the algorithm view, the widget would actually be doing a number of things:

<Opendatafit::AlgorithmViewWidget @datapackage @algorithm />

would render just the drop down for the model selection.

<Opendatafit::AlgorithmViewWidget @datapackage @algorithm @inputName="params" />

Would render the view currently in the params input.

<Opendatafit::AlgorithmViewWidget @datapackage @algorithm @inputName="options" />

Would render the view specified in the options input.

echus commented 9 months ago

I'm unsure about keeping the params and options separate. In your example above, I can't see a way to map a certain params resource e.g. inputParamsNMR11 to its associated options resource e.g. inputOptionsNMR. If we combine params and options together, then we can specify two resources for the one input and that gets rid of the need to do any sort of mapping between params & options inputs. Does that make sense? Thoughts?

For context, this is the sort of mapping we would need to encode somewhere:

inputParamsNMR11 -> inputOptionsNMR
inputParamsNMR12 -> inputOptionsNMR
inputParamsUV11 -> inputOptionsUV
inputParamsUV12 -> inputOptionsUV