<fidData> Specification

[Steffen Neumann]

Hi,

for the specification document, we need to create the encodign/decoding
of the binary <fidData>. We have started this process in this issue:
https://github.com/nmrML/nmrML/issues/57

IMHO we need to finalise two aspects

1) which are our supported byteFormat's ?
We currently have example files with:

byteFormat="class java.lang.Integer"
byteFormat="Complex128"
byteFormat="Float64"
byteFormat="byteFormat1"
byteFormat="byteFormat11"
byteFormat="byteFormat13"
byteFormat="byteFormat15"
byteFormat="byteFormat17"
byteFormat="byteFormat19"
byteFormat="byteFormat3"
byteFormat="byteFormat5"
byteFormat="byteFormat7"
byteFormat="byteFormat9"

The issue https://github.com/nmrML/nmrML/issues/74
shows that nmRIO currently can handle "Complex128",
but confusingly Complex128 currently only has 64 bits,
because it is represented with two 4byte float values.

=> I suggest to use Complex64 for what is currently known
as "Complex128", and specify Complex128 to actually use
two 8byte doubles if there is a need for Complex128 precision.

Question: does it make sense to use Integer anywhere ?

=> If we're dead-certain that no other datatypes will come up
in the future, we can make byteFormat="" an XML enum.
Otherwise I suggest moving the byteFormat into a cvParam,
and use something like this:

http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS:1000518&termName=binary%20data%20type

2) We need to specify what compression is actually allowed.
Currently we have examples with:

compressed="false"
compressed="true"

=> I would suggest to rename this attribute into compression="",
and make the value an enum with the values "no compression" and "zlib"
to better show what compression is meant here.

Alternative I would also support moving to a cvParam as in mzML:

http://www.ebi.ac.uk/ontology-lookup/browse.do?ontName=MS&termId=MS%3A1000572&termName=binary%20data%20compression%20type

Opinions ? Support ? Veto's ?

Yours,
Steffen


--
IPB Halle AG Massenspektrometrie & Bioinformatik
Dr. Steffen Neumann http://www.IPB-Halle.DE
Weinberg 3 http://msbi.bic-gh.de
06120 Halle Tel. +49 (0) 345 5582 - 1470
+49 (0) 345 5582 - 0
sneumann(at)IPB-Halle.DE Fax. +49 (0) 345 5582 - 1409

[Philippe]

Hi Steffen,

I'd personally prefer cv terms to nmrML-CV for consistency and possibly
ease of maintenance for the schema (both cases described)
Should you decide this route however would require clear documentation,
embeded in the schema and pointing for each CVParam to a couple of
examples with nmrML CV identifiers.

it seems the PSI example sent foots the bill.

the use/query case should also be included in the document
e.g."to be able to get all gzip compressed spectra"

HTH

P

[DJ]

Hi,

1) Supported byteFormat's 

Concerning Bruker data (both FID and Spectra), intensity are coded as integer (32bits => 4 bytes) or as Long (64 bits => 8 bytes).

So, it seems logical to put Interger32 or Integer64 for byteFormat.

2) Compression 

I agree, it is not enough to just put a boolean!

does "zlib" always stand for "zip" ? what about "gzip" ?

cheers,

DJ

[Steffen Neumann]

Hi,

On Thu, 2014-03-06 at 07:25 -0800, DJ wrote:


> 1) Supported byteFormat's
I have created a corresponding issue for this:
https://github.com/nmrML/nmrML/issues/113