Hi Jen,
Yes, the previously included query does show the issue.
Cheers,
Greg
fixed- all licenses now means all licenses. Thanks for reporting!
1 Like
hoping the CORS issue is resolved. Could you try again?
1 Like
We allow users to choose default images to represent taxa and to choose those images from iNat observations, Flickr, EOL, and Wikimedia Commons. We donât necessarily encourage one source over another, but iNat obs are the first choice presented if only because it prevents problems with third parties (like the one weâre discussing right now). Even so, iNat users have chosen EOL photos for many of our taxa because there are no available iNat observation photos to use, so it doesnât really matter what we encourage or how people behave on iNat now, we still have a ton of taxa with broken images. If you folks could resurrect those data object IDs and get the data_objects endpoint to work with them again we could at least refresh the URLs for all those photos.
Is EOL in the loop for the selected iNat images also?
Not sure what this means.
So, what I would like to know is
- Are these old identifiers ever going to work with the data_objects API endpoint again? Sounds like the answer is âmaybeâ?
- Can EOL commit to stable identifiers for photos from now on? B/c if you cannot we need to stop allowing our users to choose EOL photos for iNat taxa b/c this problem will probably just keep happening.
I see; that makes it clearer, thanks. If youâd like to put a bandaid on this and can send a list of the image file URLs, we can send you a mapping; it may take awhile and I expect it will cover most but not all of the images. Sources have been reharvested, and we have seen some media disappear at the source.
We could also try mapping back to the file URL from which we harvested them- many may have come originally from your other two sources.
Going forward, the need for another reharvest event like this one is unlikely with our new codebase. That being said, EOL is (still) not a media repository. I cannot offer the commitment you describe.
@hammockj Thank you but the problem still remains.
Error message is still present but this morning there is additional message about CORB which wasnât there before.
Access to XMLHttpRequest at âhttps://eol.org/api/pages/1.0.json?id=1745&details=true&images_per_page=30&common_names=falseâ from origin âhttp://wiki.mydns.jpâ has been blocked by CORS policy: No âAccess-Control-Allow-Originâ header is present on the requested resource.
jquery-3.3.1.min.js:2 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://eol.org/api/pages/1.0.json?id=1745&details=true&images_per_page=30&common_names=false with MIME type application/json. See Cross-Origin Read Blocking (CORB) - Chrome Platform Status for more details.
Iâm getting an unexpected result format from batch pages api calls. I believe the old format, at the top level, was an object mapping
{ <identifier>: <result>, ⌠}
but I am now getting an array
[ <result>, ⌠]
Is this change intentional?
For single-identifier pages api calls (non-batch), there is now a top level taxonConcept attribute which didnât previously exist â itâs a bit confusing, since its value also contains a taxonConcepts array. Is the format expected to stay this way?
To be clear, Iâm referring to the JSON api in these comments.
@gregm, apologies, we have a slightly different data model now, requiring a slightly different construction for text objects, eg:
https://eol.org/api/data_objects_articles/1.0/12749603.json?taxonomy=false&cache_ttl=&language=en
can you manage?
@OLDY weâre finding CORS issues difficult to test, but have tried a couple of fixes per enable-cors.org. Could you report what youâre seeing now, please?
Thank Jen,
Yes, this API change is easy for me adapt to, no problem on that front.
In my efforts to test this change though, I noticed that a number of other things changed yesterday afternoon (around the time you posted on this topic) that break other parts of the API. The most significant issue is affecting my use of the âpagesâ API. No mater what identifier I use (which I get from the search API) it always returns the same (wrong) results. For example if I search for a âYellow Tangâ and pick the search result with the identifier: 46577088 I get the same (or at least very similar) results as if I search for a âBoxfishâ and pick the result with the identifier: 46570907.
In both cases I get a result with a scientific name of: âMetazoaâ and (the same) images related to spiders and reptiles. Here is the pages command for the âReticulated Boxfishâ example:
my previous postâs pages command was for the Yellow Tang example and it use to give correct results (I didnât reproduce it here).
The second issue is yet another change to the JSON results structure that is returned. Before v3 the pages API returned a dictionary object at the top level that contained the âtaxonconceptsâ dictionary. Then when v3 was first releases the top level was a dictionary that had a dictionary âtaxonconceptâ (no s) that contained the v2 version of the dictionary. Now it appears that the âtaxonconceptâ dictionary contains a two element array with the second element being the original dictionary that contains the âtaxonconceptsâ dictionary.
This later change is fine, but it would be good to know if this will stay this way or if it will continue to evolve or if this is an error and it will revert to its previous structure.
The third issue is that the âtextâ data objects returned from the pages lookups that Iâve cited do not result in text results (they appears to be large arrays of dictionaries containing identical information related to classifications). If I use the object identifiers that I had from before this change (as with your example) then I get appropriate results. Of course, this issue may be related to the fact that the result of the pages API call itself is wrong.
Thanks for all your help getting this to work for everyone again.
Cheers,
Greg
Hi @gregm,
I am still learning how to use APIs and everything for EOL, but for the first part of your problem I noticed that you are using ââŚ/1.0.json?..â and that is why you always get âMetazoaâ which has taxon id of 1. If you change it to ââŚ/46577088.json?..â or ââŚ/46570907.json?..â you will get the result for those taxon ids. I am not sure how accurate I am but I hope it helps and If I am wrong please let me know.
Thanks,
Navid
1 Like
Hi Navid,
Thanks ⌠that is a very helpful. The API use to work (prior to yesterday) the way I had it (with 1.0.json and the id=XXXX), which may have been a coincidence, but you are right that as of now, removing the id=XXXX and putting the ID before the â.jsonâ is working. This form of the API is certainly more consistent with some of the other API. I just reviewed the current EOL.org Classic API documentation and it also confirms your interpretation.
Thanks again, great catch.
Cheers,
Greg
Thank goodness! @gregm are your 2nd and/or 3rd issues still issues or did they descend from the 1.0 as taxon ID business?
Also wondering about the JSON result format change that @gregm and @mmvitale have mentioned. Will this new format be a permanent change or is this an incorrect result? Changing to this new format seems to make everything work again but I donât want to push a fix for it if itâs changing again soon.
Hi! It is fixed! No CORS error any more.
Thank you very much for working on this issue.
1 Like
Itâs probably worth documenting the change @gregm and @navidz discussed as a difference from the v2 API on the âclassic APIsâ page. I just bumped into that issue too.
edit: if thatâs the new format, whatâs the correct way to call pages with a batch of ids?
Hi Jen,
The second issue (the change to the structure of the returned JSON) is still an âissueâ. As I and other have mentioned, the change is okay, but it would be good to know if this is stable change as it is hard to code for all possible return structures. Iâve modified my app so it will work with all three of the structures that weâve seen to date so if the results stay within those bounds Iâm happy.
The third issue is not really a problem for me, it just represents a change from the v2 results of the original data_objects API. This call for example:
https://eol.org/api/data_objects_articles/1.0/12657377.json?taxonomy=false&cache_ttl=&language=en
results in an additional taxonConcepts dictionary that (I think) the âtaxonomy=falseâ should eliminate. It is not an issue other than the extra web traffic that it creates so I mostly mention it so you are aware of it.
Probably the bigger issue for me is that many of the âdescriptionsâ that were available in v2 no longer seem to be returned by the current âpagesâ API (and so I canât find them to use the data_objects_articles API). It seems that many of the original English descriptions are no longer returned and mostly we are seeing Italian (language=it) and Spanish (language=es) results. There are still a few cases where the language is returned as NULL and these tend to be English usually. In v2 it seemed that an English description was returned for almost all items (in fact, I use to use text_per_page=1 with the pages API and always got an English text object, now I use text_per_page=10 and usually get multiple Spanish and Italian results and the occasional NULL result).
Sorry about the original error in my pages API call vs the new API structure.
Cheers,
Greg
Understood, thanks. The inconsistencies in Pages are next on the list after hierarchy_entries is returned to service; weâll make those explicit one way or another.
Youâre not the only one waiting on missing content. Alas, some of our oldest and most idiosyncratic resources are text object datasets; weâve had trouble reharvesting some of them and are addressing the errors case by case. It may be a long winter, but everything should be back in eventually.