zoo load: still queries with GI numbers, bad

[phiweger]

see discussion here, from 2016-10-24

The code supporting the new &idtype parameter has not yet been released. We are expecting it to be released soon and will blog about it when it happens. For several years EFetch has supported accession.version identifiers in the &id parameter, and so it may appear that &idtype is working, when it simply is existing functionality for EFetch. The true changes will be to ESummary, EPost, and ELink, which only accept GI numbers (for sequences) in &id. Once &idtype is released, they will accept accession.version like EFetch does now. In addition, ESearch will output accession.version identifiers with &idtype=acc.

clarification:

Thank you for the clarification. So for now it is OK to get the IDs from “esearch” and then use “efetch” to “translate” the resulting GIs to Accession numbers, right? At least until “&idtype=acc” is released. Because this approach I mentioned feels “hackish”. I’ll be watching this space closely for the follow up so I can implement “&idtype” in my tool.

comment on that:

Yes, what you propose is fine. It depends on what you’re starting with. If you have a list of GI’s already, then use EFetch by itself to translate to accessions. ESearch is really only required if you have a text query and want to use that to pull GI’s. In that case, you could add &usehistory=y to the ESearch call, and then pass the WebEnv and query_key params from the ESearch result to EFetch (with &rettype=acc). This avoids using a (possibly large) literal list of GI’s.

[phiweger]

This is what our code does, so for now ok, but'll keep this issue open as a reminder that zoo load needs some refactoring in the future.

[phiweger]

convert GI to accession

https://ncbiinsights.ncbi.nlm.nih.gov/2016/12/23/converting-lots-of-gi-numbers-to-accession-version/ https://ncbiinsights.ncbi.nlm.nih.gov/2016/12/06/converting-gi-numbers-to-accession-version/