My site BioNames links to lots of EOL images, e.g. http://bionames.org/taxa/gbif/4656474 With EOL 3 these links have all broken, fo example http://media.eol.org/content/2012/04/05/00/45076_88_88.jpg no longer exists. Is there a mapping between the old EOL image URLs and the new ones that I can use to restore images to BioNames?
For deep linking to image files we don’t recommend EOL media URLs. They’re still not promised to be stable.
You might try your luck with the media URLs of the providers; most media are still present there. That’ll take work, but the last re-mapper I spoke with managed using the v2 archive. That may not work in this case. I think you don’t have any other data fields you might have used to map from?
Were the image selections curated, or is it an option to re-load images from the EOL Pages API? If so, you might be better served once we have published a mapping of EOL taxon IDs to major classification providers. We preserved as many taxon IDs as we could, but we were collapsing 6M unresolved names from v2. API users so far have found ~20% misses if they try the Pages API from v2 taxon IDs. There may not be that much harm in trying it in your case, though. Misses will remain unresolved; they won’t map to other taxa.
@hammockj why can’t the URLs be stable? Seems like the media URLs should be tied to the EOL IDs anyhow, no?
The short answer is that it was a policy decision. We don’t have the institutional commitment needed to promise that kind of stability. Also, the media are the property of our content partners and we wanted them to be able to change what they choose to share with us. That’s not a legal requirement once material is published for redistribution under creative commons license, but it’s part of content partner autonomy, and can be important for image aggregators in case they discover a case of mistaken ownership of something they shared with us, and need to take it down. That’s a rare case, of course.
Mechanically, the media in the old EOL platform were harvested in over ten years and several different versions of the codebase, and a learning curve. There is no particular reason to expect individual URLs to change routinely going forward.
With all due respect, this was very very poor policy decision. It’s literally Rule #1 of the Web that “Cool URIs don’t change” (Tim Berners-Lee, 1988). There is never any excuse for a serious service to do this; in doing it, you are telling the world that EOL cannot be relied upon.
It gives me no pleasure at all to say this. Please find a way to reinstate the old URLs.