-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properly serialize an xcms result object to disk/files #693
Comments
How much of that could be handled by mzTab-M ? The SMF Feature table nicely corresponds to the (grouped) xcms list. Ungrouped data is technically also kinda possible and requires lots of repetition. Metadata works as well. Bonus: we'd be able to read results from e.g. MS-Dial for further analysis. Alternatively there are some functions by @PayamEmami in the MetaboIgniter workflow An earlier version was even implemented in Galaxy to integrate OpenMS and R based tools. Main question would be if true round-tripping (export xcms object1 and re-import to object2 guaranteeing object1==object2) is a requirement. Yours, Steffen |
Agree that it would be great to use standard file formats as much as possible! maybe we could export the feature data as a mzTab-M and the rest as other files (all in one folder). I would like to be able to export a full xcms result object to completely restore it again later (including process history, adjusted retention times, etc). |
@sneumann , do you have some definition somewhere how the mzTab-M format should actually look like? |
Hi, the official docs are in |
Had a quick look at the |
+1 for not having all that as dependency. |
+1 for not adding these dependencies. |
Hi - I agree that it would not need to be in the XCMS package to not further increase dependencies - also I think the XCMS object is quite stable, so not a lot of API breaking changes expected I think. I agree that exporting to mzTab-m and importing would also be an option - then the question is, how well does mzTab-M work for peaks? I thought always it was more designed to capture the final output with compound concentrations etc.? |
I would then suggest to maybe define a method
implementations of these methods could then be defined for different param objects:
The first two could be implemented in While it's not exactly what we have with the backend concept in |
mzTab-M, in contrast to mzTab 1.0, has the feature table, which allows you to report start and end time of aligned "m/z features", area etc. The output of final compound concentrations (or whatever quantity you define to report) is reported in the summary table. The evidence table further allows you to report identification evidence for your features. |
Additionally, there are low level IO functions available in the package already for reading: The writing part is currently tied to R6, as Steffen said, due to the fact that I autogenerated the models and REST API implementation for the online validator webservice based on the OpenApi specification. https://github.com/lifs-tools/rmzTab-m/blob/master/R/write_mz_tab.R However under the hood, most objects are converted to and from tables in some sort of way, also using jsonlite a lot. So mapping this or reimplementing it with another object model, @jorainer which one would you prefer? |
Each object already has toDataFrame and fromDataFrame methods available, see the Instrument class as an example: https://github.com/lifs-tools/rmzTab-m/blob/master/R/instrument.R#L173 |
So converting this to S4 reference classes, or what alternative class type would you recommend, should be doable? |
S4 would be ideal - we could however also use the R6 implementation and hide all the R6 stuff from the user through the functions (e.g. the |
Maybe @philouail can have a look into this. I'm assigning the issue to her. |
That sounds great, thanks for getting started on this! Feel free to reach out if you have any more questions or you need some example data for the plain text export! |
@jorainer do you think it would also be possible to create an import from mzTab? |
also xref lifs-tools/rmzTab-m#3 |
yes, sure @hechth , we will also work on an mzTab-M importer - but let's first get started with the "simpler" text export/imports. |
Cool - let me know if I can help on this. The mzTab-M importer would be great to import results from OpenMS peak picking which exports as mzTab - so then we could build an XCMS object and then for example run it through RAMClustR etc. |
Instead of exporting/saving an
xcms
object in RData format it would be good to also support import/export from/to files in textual format.Idea:
Why? mostly for Galaxy-based workflows, to enable usage of the result objects across tools.
The text was updated successfully, but these errors were encountered: