Possible inconsistencies

[robinschmid]

1. MS1MZ and MS2PROD do the same filtering on different MS levels.

Maybe we can use a similar names then to describe signals?
Options would include:

MS1MZ=200 / MS2MZ / MS3MZ
MZ=200:MS2
MZ=200:MSLEVEL:2

Maybe with convention over configuration we could even have something like:
QUERY scaninfo(MS2DATA) WHERE mz=200
without specifying the MS level it is inferred from the query statement

2. Use of scaninfo() with MS1DATA and MS2DATA

The transformation with scaninfo() does not feel like the rest of the language.

Maybe we can just add scandata to the modification functions (replacing MS1DATA and MS2DATA) and add the MSLEVEL=2 as a condition

QUERY **scandata** | scaninfo | scansum | scannum WHERE **MSLEVEL=2** AND ....

Feels a bit more natural. The MSLEVEL is a scan property like the retention time etc

[mwang87]

You won't be able to put the MSLEVEL in the conditions, you might be able to put it in the filter section. Since you want to match MS1 and MS2 in the conditions, but only get the results from the MS2.

You could do this:

QUERY scandata WHERE MS2PROD=100 AND MS1MZ=500 AND MS2PREC=500 FILTER MSLEVEL=2

[robinschmid]

I like the
QUERY scandata WHERE .... format.

The end result of scaninfo(MS2DATA) acts like a condition - in the end you will remove all MS1 scans from the results (similar to conditions). The only thing that you need for the MS1MZ to work is the relationship between MS2 scans and their preceding MS1 scans.

Something like ms2scan.get_preceding_ms1()