I don't like the idea of a "Key & Value" table. The problem with tables like that is that different properties have different storage types. With the "exp.ObjectProperty" table in LabKey, the table has columns "floatValue", "dateTimeValue" and "stringValue", and in any particular table row, only one of those columns has a non-null value.
In theory, with SQLite, we would not need to do that, since SQLite columns can hold any data type. I am not sure whether we should actually take advantage of this feature.
I think we should just add columns to the RefSpectra table for all the values we want to store. We should only add columns for things that we have data for, and readers of the database should have to look at the database schema in order to see which values are available.
I might be wrong. It might be that we should come up with logical groups of properties (probably groups of values which are likely to be shared by many rows in the RefSpectra table, such as Isolation Target, Isolation Window Lower, Isolation Window Upper) and there would be a foreign keys in the RefSpectra table which point to values in other tables.