<div dir="ltr">Hi Ameya<div><br></div><div>Thank you for the clarification.</div><div><br></div><div>If I may comment further:</div><div><br></div><div>7) I was not implying we need an extra endpoint to the find the coord_system values, my suggestion was just to add them to the doc, assuming these are choices are relatively stable across species, but I guess I might be making too much of a simplistic assumption here...</div><div><br></div><div>8) Again, here my suggestion was also not being so ambitious as proposing to standardise all endpoints, just this specific one, really. :)</div><div><br></div><div>Thank you again, and I hope I will from you soon about the putative bug in the liftover endpoint.</div><div><br></div><div>Best regards,</div><div>RM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 25 Sep 2019 at 11:53, Ameya Chaubal <<a href="mailto:ameya@ebi.ac.uk">ameya@ebi.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Ramiro,<div><br></div><div>Here is a bit more explanation on each:</div><div><br></div><div>7) As you pointed out we do not have an endpoint ‘info/:species/coordinate_system’ which would return the possible choices - this needs to be developed and hence the suggestion for alternate options.</div><div><br></div><div>8) http code: this is more to do with following certain standards around development of REST API - what you are suggesting is helpful and could be taken into consideration for standardising the endpoints sometime in future.</div><div><br></div><div><br></div><div>Liftover question:</div><div>We will need some more time before responding to this one.</div><div><br></div><div><br></div><div>Thanks,</div><div>Ameya</div><div><div><br><blockquote type="cite"><div>On 24 Sep 2019, at 17:13, Ramiro Magno <<a href="mailto:ramiro.magno@gmail.com" target="_blank">ramiro.magno@gmail.com</a>> wrote:</div><br class="gmail-m_-5600226437247375821Apple-interchange-newline"><div><div dir="ltr">Hi Ameya,<div><br></div><div>Thank you for your quick response!</div><div><br></div><div>But I still have a few questions regarding your reply.</div><div><br></div><div><b>Question 7 (Q7)</b></div><div><br></div><div>Firstly, my question is only about the REST API so I can't really make use of these other suggestions of yours regarding the Perl API or the "read only connection to the database".</div><div><br></div><div>When it comes to Ensembl's REST API endpoint "map/:species/:asm_one/:region/:asm_two" there are several parameters available, one of them is "coord_system". For someone with some prior knowledge on genome assembly concepts it is easy to deduce that this parameter must accept one value out of an enumeration of possible choices. So my question is what are these choices? I understand I can make queries as you suggested and infer from the responses' output the possible values. However, this approach is prone to be not exhaustive, and it does not tell me how it generalises to other species than human. Given that this fine detailed level of documentation of the REST API is not yet done, we, as users, have to guess what values these take. In the doc, only example values are given (<a href="https://rest.ensembl.org/documentation/info/assembly_map" target="_blank">https://rest.ensembl.org/documentation/info/assembly_map</a>) which already qualifies as a schema :)</div><div><br></div><div><b>Question 8 (Q8)</b></div><div><br></div><div>Again, here, I don't really understand your answer, I am sorry. I will try to be more explicit.</div><div><br></div><div>When the queried region is seemingly not mappable, the json object structure as given in the response is not the same as when we perform a bona fide query, i.e. a query with a region that is mappable to the genome.</div><div><br></div><div>My suggestion is to return the same type of json object in all circumstances, regardless of whether the region is mappable or not. In my previous email, I made a few extra suggestions on possible values for the keys in the json object when the queried region does not yield a new mapped region.</div><div><br></div><div>So I don't quite understand why you say this equates to a "generic and larger request". As far as I understand this has only to do with this specific endpoint. Moreover, you also mention "http code", and I don't understand how the response code is related to my suggestions. These would still be all successful responses, as far as I understand. </div><div><br></div><div><b>Liftover question</b></div><div><br></div><div>Another kind request: could you please also answer my other question, sent as a separate email whose title is "Ensembl REST API | map/:species/:asm_one/:region/:asm_two" about a possible bug in the liftover?</div><div><br></div><div>Looking forward to hearing from you!</div><div><br></div><div>RM</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 24 Sep 2019 at 15:19, Ameya Chaubal <<a href="mailto:ameya@ebi.ac.uk" target="_blank">ameya@ebi.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Ramiro,<div><br></div><div>Thanks for the follow-up. Here are couple of thoughts on your queries:</div><div><br></div><div><br></div><div>Q8) This is more of a generic and larger request which could potentially lead to re-looking at most of the end-points. e.g.: Going by REST standards, a correct http code needs to be sent with each response. So this might be looked at a later stage.</div><div>Q7) There are couple of options to get this data:</div><div><br></div><div>- Using REST endpoint: <font face="Slack-Lato, appleLogo, sans-serif"><span style="box-sizing:inherit;font-size:15px;font-variant-ligatures:common-ligatures;background-color:rgb(255,255,255)"><a href="http://rest.ensembl.org/info/assembly/homo_sapiens?content-type=application/json" target="_blank">http://rest.ensembl.org/info/assembly/homo_sapiens?content-type=application/json</a></span></font></div><div>The top_level_region key has a list of coord_system which needs to be made unique</div><div><br></div><div>- Use Perl API:</div><div>Refer to the script given under ‘Coordinate Systems & Slices’ over here : <a href="https://www.ebi.ac.uk/training/online/sites/ebi.ac.uk.training.online/files/u1218/Core3.pdf" target="_blank">https://www.ebi.ac.uk/training/online/sites/ebi.ac.uk.training.online/files/u1218/Core3.pdf</a></div><div><br></div><div>- Use the read only connection to the database and get it from '<font color="#1d1c1d" face="Slack-Lato, appleLogo, sans-serif"><span style="font-size:15px;background-color:rgb(248,248,248)">coord_system' table</span></font></div><div><br></div><div>Thanks,</div><div>Ameya</div><div><br></div><div><div><br><blockquote type="cite"><div>On 24 Sep 2019, at 10:18, Ramiro Magno <<a href="mailto:ramiro.magno@gmail.com" target="_blank">ramiro.magno@gmail.com</a>> wrote:</div><br class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598Apple-interchange-newline"><div><div dir="ltr">Hi Devs,<br><div><br></div><div>When can I expect an update on these questions (Q7 and Q8)?</div><div><br></div><div>Thanks a lot!</div><div><br></div><div>Cheers, RM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sep 2019 at 17:53, Ramiro Magno <<a href="mailto:ramiro.magno@gmail.com" target="_blank">ramiro.magno@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you Brandon for the information!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sep 2019 at 17:38, Brandon Walts <<a href="mailto:bwalts@ebi.ac.uk" target="_blank">bwalts@ebi.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><p>Hi Ramiro</p><p>Apologies for the delay. We have some answers for you now, and
more will be forthcoming:</p><p>Q1: This endpoint should work for most species. I have seen the
errors that sometimes arise, and we think suspect (but have not
confirmed) that there may be a bug in the TranscriptMapper that
supports this in the underlying Perl API. We will look into this
further.</p><p>Q2: No, but this is a good suggestion and we will look into
possibly implementing this.</p><p>Q3: Yes, only transcript IDs are valid for this endpoint.</p><p>Q4 and Q5: For the first part of your question, basically yes.
Gap represents a gap in the sequence. We will look into whether
setting the "overrun" to a gap is the desired behaviour, or
whether there may be a better way to return a result for a query
that goes beyond the end of a transcript.</p><p>Best<br>
-Brandon<br>
</p>
<div class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686moz-cite-prefix">On 10/09/2019 14:21, Ramiro Magno
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Devs,<br>
<div><br>
</div>
<div>I have a few questions about the endpoint
"map/cdna/:id/:region".</div>
<div><br>
</div>
<div>Q1: How can I find what species work with this endpoint?</div>
<div><br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div>Q2: Is there a way of specifying the "range" parameter so
that it starts at 1 and goes till the end of the cDNA
sequence? E.g., 1..end?</div>
<div><br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div>Q3: In the doc, the description of the "id" parameter reads
"An Ensembl stable ID". But only transcript ids are valid
choices, correct? For example, making the nonsensical query
with a gene id gives back a not so tidy error: <a href="https://rest.ensembl.org/map/cdna/ENSG00000115263/1..1000?content-type=application/json;include_original_region=1" target="_blank">https://rest.ensembl.org/map/cdna/ENSG00000115263/1..1000?content-type=application/json;include_original_region=1</a>.</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Q4: What is the meaning of the variable "gap" in the json
response? Is it gap=0 means exon, and gap=1 un-mappable
region? When I exceed the end position of the transcript in
the "range" parameter I always get the excess as a region
flagged as gap=1.</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Q5: When I get an excess region as a result of asking a
cDNA sequence that goes beyond the length of transcript, why
are the genomic coordinates "start" and "end" reported as if
they were in cdna coordinate system? E.g., the request: <a href="https://rest.ensembl.org/map/cdna/ENST00000375497/1..1000?content-type=application/json;include_original_region=1" target="_blank">https://rest.ensembl.org/map/cdna/ENST00000375497/1..1000?content-type=application/json;include_original_region=1</a> yields
a last block whose coordinates are start=800, end=1000 for
both coordinate systems: "cdna" and "chromosome". Would it not
make more sense to just report NA or Null instead?</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Q6: What is the meaning of the "rank" variable in the json
output?</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Many thanks in advance!</div>
<div><br>
</div>
<div>Cheers, Ramiro</div>
</div>
<br>
<fieldset class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686moz-quote-pre">_______________________________________________
Dev mailing list <a class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686moz-txt-link-abbreviated" href="mailto:Dev@ensembl.org" target="_blank">Dev@ensembl.org</a>
Posting guidelines and subscribe/unsubscribe info: <a class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686moz-txt-link-freetext" href="https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org" target="_blank">https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org</a>
Ensembl Blog: <a class="gmail-m_-5600226437247375821gmail-m_-8935823594981018598gmail-m_-6185895876161707102gmail-m_-4241928598382362686moz-txt-link-freetext" href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Dev mailing list <a href="mailto:Dev@ensembl.org" target="_blank">Dev@ensembl.org</a><br>
Posting guidelines and subscribe/unsubscribe info: <a href="https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org" rel="noreferrer" target="_blank">https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org</a><br>
Ensembl Blog: <a href="http://www.ensembl.info/" rel="noreferrer" target="_blank">http://www.ensembl.info/</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>Dev mailing list <a href="mailto:Dev@ensembl.org" target="_blank">Dev@ensembl.org</a><br>Posting guidelines and subscribe/unsubscribe info: <a href="https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org" target="_blank">https://lists.ensembl.org/mailman/listinfo/dev_ensembl.org</a><br>Ensembl Blog: <a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br></div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></div></blockquote></div>