I’m finally trying to get our system working again (diverted by other projects). I am able to find ITIS taxonomic information, but it appears the hierarchy_entries api never came back up. So… the taxonomic information is associated with pages, but I cannot do things like getting the taxonomic information by taxon_id or find the parent of any given taxonomic entry.
hierarchy_entries should be working; can you paste the query you’re trying in here?
The hierarchy_entries rabbit hole is probably less deep than I thought. To work with the new APIs I am running the test suites for my code and tracking down errors. I was mistaken about the hierarchy_entries always failing. The test suite sometimes assumed that entry ids would remain fixed and it searched by id. When the id does not exist in the current system, I get a 500 (internal error) http return. I am still checking to see if there are other circumstances where I get the error 500 return.
ah, yes, we couldn’t preserve the hierarchy_entry IDs. Keep us posted if you find any other symptoms.
Thanks for your patience, @Natasha! We finally got those files to cooperate. Audio resources are nearly all back in place now.
Hey @hammockj, it definitely seems like something is coming through but I’m not seeing any data objects? Is the fix still in progress, or is there some data that might be missing still?
When looking for images using the following query I get the data objects:
https://eol.org/api/pages/1.0/491995.json?details=true&images_per_page=10
but using the next query I don’t get any:
https://eol.org/api/pages/1.0/491995.json?details=true&sounds_per_page=10
Sound files are still pretty rare in EOL, certainly for cephalopods! You’ll have the best fishing among birds or singing insects.
But your query is correct! Try 45512044.
Jen
Hmm, alright. Definitely seems like it should work. It might be something on our side at the moment, I’ll get back to you if I find any other issues. Thanks!
@hammockj Had a chance to sit and look through the results and our code.
Here’s a sample query we’re trying to do:
https://www.eol.org/api/pages/1.0/45512044.json?images_per_page=0&videos_per_page=0&sounds_per_page=50&videos_page=0&sounds_page=1&maps_page=0&texts_page=0&subjects=overview&details=true&common_names=false&licenses=all&taxonomy=true&vetted=2&cache_ttl=3600
It appears that all the data objects are coming through with image mimetypes instead of audio types? I’m not sure if its just this particular search or if there is something wrong there? I believe this is why our query is not displaying any results.
Oh, I see. Thanks, we’ll look into it. In the meantime, you can identify them by a couple of other fields:
“dataType”:“DCMI: DCMI Metadata Terms”, “dataSubtype”:“mp3”
and
“mediumType”:“sound”
those mimetypes should be reset now, if you prefer to use those; thanks for your patience!
@hammockj Awesome, thanks for that! I’ve found one more minor bug involving the ‘eolMediaURL’ property? I imagine you guys are hosting this data yourselves to prevent hotlinking/broken links which is why the property exists? Currently all the sounds are coming through with ‘#’ as their ‘eolMediaURL’ link which seems a bit odd since our images use that for their source url and are working fine. The ‘mediaURL’ property seems to get us a working source url but I’m a bit hesitant to use it?
Thanks again!
Oh, weird! In your case the mediaURL field should be safe- our sound providers tend to be large, stable projects. But we should fix this, especially for image users. Image providers vary in their sources of support and they might be snuffed out sometimes.
@hammockj Yeah, figured I’d give you guys a heads up just in case. I’ll make a note to update our stuff to use mediaURL for sound files for now. Thanks!