source type field: switch to radio button and text field

[dwsideriusNIST]

This is a change I had planned for the PHP digitizer and hadn't pushed upstream yet. The idea is that the user selects either figure or table via radio button, then fills in a field with the figure or table number. Then if the source type is table, set another key in the output JSON:

"tabular": 1

A user (CS) asked if I could label isotherms that are based on tabular data (as opposed to digitized from figures) so that he/she could generate a high-confidence subset of isotherms.

[dwsideriusNIST]

Tangential issue addressed in PR #30

• "Tabular checkbox" allows specification of a Figure source type, but also tabular-source. (Covers instances where data is from a figure, but authors provided tabular data.

Original issue is still relevant, as it restricts the vocabulary of figures and tables.

[dwsideriusNIST]

Example available in: https://github.com/dwsideriusNIST/isotherm-digitizer-panel/tree/feature-radiobuttons

Two issues remaining:

1. Vertical alignment of the pn.pane.HTML row with the source type and ID needs improvement
2. The red asterix to indicate a required input is not visible.

[ltalirz]

So, do we still want to change this?
Currently the free-form text input allows users to provide also information like "Figure 2a" - but of course this is mainly useful for manual inspection.

The question is: for automated queries, do we need to know more than whether an entry is tabular or not?

P.S. A typical user interface / schema definition tip is to use boolean flags only when you can mathematically prove that there are only ever going to be two options. I.e. even if we currently just have a switch tabular/digitized, on the JSON one might want to leave the possibility open (e.g. by calling the field source_type_class with options tabular and non-tabular).
Anyhow, I guess the tabular key has already gone in the spec, and so it's fine to keep it - just wanted to mention this as a useful rule of thumb for the future.

[dwsideriusNIST]

After working on this (I have a feature branch with a working version, but have never made a PR), I questioned its necessity. Originally, my intention was to hook the tabular: True/False to key to a "Table" selection in the form, but I realized this was incorrect. (For example, the isotherms for the new CH4/RM-8850 reference isotherm have tabular: True, but with Figure-type articleSource: Figure X. The paper/SI has the isotherms only in figure form, but the authors gave me the tabular isotherm data so there was no digitization step.) There are also situations where the isotherm data is presented in both Figure(s) and Table(s) in a paper, which is stored as articleSource: Figure X/Table Y.

Thus, I'm inclined to drop this feature request. Maybe we eventually add a feature in the plot tab where warnings or other messages are included. One message could be if 'table' in articleSource and not tabular: print(warning: tabular not selected, but articleSource includes 'table' (just as an example)

Regarding a more verbose API, these are all features that I will add to a to-do list. Maybe API v3.0 will be a re-think of the metadata structure.