Thanks Jen. The hierarchy_entries API is my highest priority too, I appreciate your efforts on this and all the other fronts.
Cheers,
Greg
Thanks Jen. The hierarchy_entries API is my highest priority too, I appreciate your efforts on this and all the other fronts.
Cheers,
Greg
@hammockj curious if you have a timeline for hierarchy_entries
returning? deciding whether to pull that functionality out of taxize temporarily or just wait on this
looks like today or tomorrow for hierarchy_entries
{ <identifier>: <result>, ⌠}
but I am now getting an array
[ <result>, ⌠]
Is this change intentional?
No. Iâve just fixed this, sorry! âŚShould be pushing the new code today.
Yes, that one is âcorrectâ in the sense of how the controller renders objects, and âfixingâ it to mimic the old API would be more work than is (IMO) warranted. Sorry about that. If itâs a show-stopper, we can, of course, put in said work!
@mmvitale @Natasha @gregm @navidz @sckott please note for Pages, (batch and non batch) @jriceâs responses just above. Batch results should have reverted to an object mapping now, non-batch format will stay the way it is. Docs will be updated. Thanks for your patience!
@gregm @sckott @divinglog @OLDY hierarchy_entries should be working now, if you care to try it. Please let us know if you see anything unexpected in the form.
Please note that for this service in particular a lot of data are still missing, if youâre interested in specific classification providers. Weâre hoping to have NCBI and CoL in within the next week or two. WoRMS and paleoDB are present now.
Hi Jen,
The hierarchy_entries API seems to be working as expected for me. Thank you for getting this done.
I have checked a number of marine critters and many of the services available for each critter. Iâll keep testing, but so far so good.
Cheers,
Greg
There is a subtle distinction between two recent changes to the results from the pages API. There is the change that has the higher level taxonConcept attribute that youâve explicitly addressed (and which will not change). The second change that @sckott and @Natasha and I mentioned was the extra level of array that was added to the taxonConcept attribute. When v3 was first released the structure was: {âtaxonConceptâ : {}} and as of a a day or so ago it switched to {âtaxonConceptâ : [, {}]}. Can you confirm that this extra level of array is what we should expect going forward?
Either way is fine, I just want to make sure.
Thanks,
Greg
Sorry! That was a regression (bug). âŚFixing that right nowâŚ
UPDATE: Iâve fixed it, but cannot push the new code right now due to some technical problems. Iâll reply here when itâs available.
Hey guys,
So when I use API to call for the name of species with taxon id 50962909, I will get the results and when I use the browser I also get the same results, but when I use Cypher, I get nothing. My Cypher code is something else but even the simplest Cypher code as bellow will give me no data:
MATCH (p:Page { page_id: 50962909})
RETURN p.page_id, p.canonical
LIMIT 1
Does anyone knows why?
Thanks
That particular page has no data, and thus isnât included in the TraitBank (neo4j) database. :\
correction, @jrice @navidz: that page is not in our default classification, the Dynamic Hierarchy, and so isnât found in the graph. Youâll see âUnresolved nameâ in the title of such pages in the interface. Taxa with no data are included in the graph, so you can do taxonomic queries this way, but youâll only see taxa in the Dynamic Hierarchy. This represents a basic level of taxonomic curation.
I want to see how the new Cypher API works.
By the looks of GitHub doc, it can only be called from server-side scripts?
Can it be called via client-side JavaScript?
Where do I start?
I canât get the images_page
parameter to do what I want.
If I call:
https://eol.org/api/pages/1.0.json?id=46577088&images_per_page=1&images_page=1
and
https://eol.org/api/pages/1.0.json?id=46577088&images_per_page=1&images_page=2
for both requests the data object returned is the same, am I doing it wrong, or is something broken?
Thanks for reporting, @justinpinkney. I think youâll find an additional problem with that query, if you want Zebrasoma flavescens. That form was incidentally supported in v2, but now it will bring you content for taxon page 1 (Metazoa). Try https://eol.org/api/pages/1.0/46577088.json?id=&images_per_page=1&images_page=1
That being said, the pagination doesnât seem to be working. Stand byâŚ
This is a good question, thanks for asking it. Ordinarily you would access web pages from Javascript using XHR, yes? If this fails, I think it will be because your browser is over-protecting EOL via SOP and what we need is a CORS exception to override SOP. (Enough acronyms yet?) I will check to see if the service is returning sensible CORS headers, or you can. Will get back to you.
@OLDY, Iâve checked and the service does not at present provide a CORS header for the response, so any XHR response will be blocked by the browser.
I will look into having this added. But, in the meantime, we have another problem if you are talking about accessing the cypher service from a public web page: unless you take unusual steps to protect the token, the token will effectively become public. Iâd like a little more information about the application before encouraging this.
(I donât think weâre committed to using secret tokens in the long run; they are there now just from an abundance of caution.)
Apologies for the LOOOOONG delay (we had a technical problem that needed fixing), but the pages API should have been updated today, and the odd array response should no longer be returned.
@jrice Thanks for getting that fix out. Just noticed a new issue though. It seems as though the images_page parameter is causing a 500 error?