Skip to content
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

mzIdentML Usage Patterns #2

Open
mobiusklein opened this issue May 4, 2017 · 5 comments
Open

mzIdentML Usage Patterns #2

mobiusklein opened this issue May 4, 2017 · 5 comments

Comments

@mobiusklein
Copy link
Owner

The API for MzIdentMLWriter is much rougher than MzMLWriter, and was designed with the assumption the user would provide generators to lazily provide all of the large collections. This makes it less intuitive to build in complex logic to prepare members of those collections on the fly.

I'm opening this issue to initiate discussion of what would be ideal. @JB-MS, if you have a chance to take a look and let me know how you plan to use the API, we might come to a better design.

@JB-MS
Copy link
Contributor

JB-MS commented May 9, 2017

We were planning to integrate the mzid writer as a node in our framework Ursgal. At the moment we have .csv as the final output format, but since mzIdentML is the official standard we would like to add a converter to convert the .csv files into mzid, to be compatible with repositories like e.g. PRIDE.

@mobiusklein, if you are interested and have time, you are welcome to join and contribute to Ursgal, and implement your writer into the framework.

I am looking forward to contribute to improvements of the design. At the moment i have no specific adjustment/improvement ideas, but maybe we will see what can be optimized, when it is integrated into Ursgal?

@mobiusklein
Copy link
Owner Author

I see several nodes in ursgal dealing with csvs. Which one should I be looking at for an equivalent result data structure?

@JB-MS
Copy link
Contributor

JB-MS commented May 9, 2017

That is correct. We rely on a workflow right now, which passes the csv from one node to another, which then read and change the csv accordingly.

Simplified example workflow:

mzML --> Search engine --> result file (e.g. xml, csv or mzid) --> conversion to csv --> unify csv (add e.g. missing meta info) --> map peptides --> validate PSMs with e.g. Percolator

See also e.g. this example script

In an ideal world we would deal with mzid the whole time, but we think it is also beneficial to have the easily accessible and readable csv format in your workflow.

I imagine the mzid writer at the end of an workflow , after the PSMs were validated using Percolator and then offer a (optional) node to convert these results into a mzid.

What do you think?

@mobiusklein
Copy link
Owner Author

That's reasonable. My use-case holds intermediary results in a sqlite3 database before translating the database into either CSV or mzIdentML as needed.

I'm looking for a definition for an output data structure in the ursgal repository, but I don't see a class or consistent dict searching the codebase. Does one exist?

@JB-MS
Copy link
Contributor

JB-MS commented May 10, 2017

This is indeed missing at the moment. We rely on mzid to csv conversion using a Java library . We used this csv format as a template and modify and add some fields.

I will set up a new parameter in uparams.py (the general parameter storage and required for correct mapping), where the fieldnames for the csv are specified and described. This should be useful to set up a correct converter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants