Spectra to/from MSnExp

[lgatto]

I am wondering if we wouldn't need methods to coerce MSnExp objects to/from Spectra objects. One example I am going to implement soon, after combining spectra (see #366), is that these new data will need to be quantified and serialised to mzML.

@jotsetung @sgibb - what do you think?

[jorainer]

I'd like to keep the Spectra agnostic of where it comes from (e.g. mzML or a database). Wouldn't be a combineSpectra,MSnExp what you're looking for? You combine the spectra (get an MSnExp back), call quantify on that and you then save the MSnExp with the writeMSData back to mzML.

Getting a Spectra from an MSnExp is rather simple: Spectra(spectra(<MSnExp>)).

[sgibb]

Sorry, but Spectra(spectra(<MSnExp>)) is awkward. I would prefer that there are some as(<MSnExp>, "Spectra")/as(<Spectra>, "MSnExp") and Spectra(<MSnExp>)/MSnExp(<Spectra>) functions. May we should discuss whether spectra(<MSnExp>) should return a Spectra object. Converting it to a simple list via as.list(spectra(<MSnExp>)) is easy even for inexperienced users.

[jorainer]

I know that Spectra(spectra is awkward. For me spectra returning a Spectra is the cleanest solution (possibly in addition with an as(<MSnExp>, "Spectra").

[jorainer]

hm, my previous comment disappeared...

@sgibb, I know, Spectra(spectra is awkward, but that's presently the way how you can convert an MSnExp to a Spectra. I would opt for spectra returing a Spectra. The question is what to do with the fData, pass that as mcols to the Spectra? For OnDiskMSnExp that can result in quite a heavy Spectra object. Also, should spectra be identical to as(<MSnExp>, "Spectra")? My feeling is that it might be better to return with spectra a Spectra without all feature data to keep that more lightweight, and to use as(<MSnExp>, "Spectra") to pass along also all feature data as mcols. On the other hand it might be more intuitive to have also spectra return a Spectra with feature data as metadata columns.

[lgatto]

The as(from, to) syntax is general across many object types, and hence I think it would be nice to have as(<MSnExp>, "Spectra") and as(<Spectra>, "MSnExp"), as it does exactly what's on the tin. And similarly, having as(<Spectra>, "list") would to get a plain list. I am ok with redundancy and also having constructors Spectra(<MSnExp>) and MSnExp(<Spectra>).

As for mcols, yes, it always gets passed along to/from fData.

[jorainer]

I've added the related conversion methods in #378