Roderic Page

My activity

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "Tindariopsis":

    @Bob Corrigan: Agreed. There are a few things which came together to create this perfect storm (mapping names without authors may have been part of the problem).

    I only spotted this because I was browsing molluscs in BioNames and was suddenly confronted by a moth. Great argument for the desirability of interfaces that make it easy to check data.

    about 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "Tindariopsis":

    The fail is strong with this one.

    Why is a butterfly picture shown for a mollusc genus?

    As far as I can work out, what has happened here is the following:

    1. EOL has followed ITIS in regarding Tindariopsis as a synonym of Saturnia

    2.However, Saturnia Seguenza 1877 (the mollusc genus) is a homonym of the butterfly genus Saturnia Schrank 1802

    3. The EOL mapping hasn't realised that there are two genera with the name "Saturnia" and has picked the butterfly

    4. Hence this mollusc has ended up embedded in the butterflies

    Other classifications, such as WORMS accept Tindariopsis as valid. Taxonomy, eh, gotta love it.

    about 1 year ago • edited: about 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    If EOL already has the image then it should be straightforward to create a service to locate it (just match a hash of the image file). Google Images supports searching for images (go to http://www.google.co.uk/imghp and click on the camera icon in the search box). I've searched for EOL images and Google finds them (for example, chose an image from EOL, download it to your computer, then upload it to Google images and search for it). This answers the question "is this particular image in EOL?"). This question is obviously limited as it requires EOL to already have the image, but you could imagine that as more and more images end up in EOL (e.g., via Flicker and iNaturalist, and other contributors) the chances that an image you find on the web already exists in EOL will start to rise.

    The problem of finding an image "like" one you have is harder. Google supports this query as well, but seems to rely on matching images with similar distribution of colours, and so doesn't work terribly well. There are some useful posts on Stackoverflow about the general problem, e.g. http://stackoverflow.com/questions/843972/image-comparison-fast-algorithm and http://stackoverflow.com/questions/75891/algorithm-for-finding-similar-images.

    It strikes me that another way to tackle this question is to ask it in an other way, namely "what images would an organism generate if photographed?" For example, take a 3D model of an animal (the BBC has some which could be used as starting points), generate 2D photos of different aspects, then use something like template matching to try and classify images. Even a coarse classification (this matches a shrimp) might be a start.

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on Roderic Page's newsfeed:

    One of the API features I'm using is the mapping from an external identifier (such as GBIF or NCBI) to EOL. Doing this over the entire GBIF or NCBI tree will take a lot of API calls. Is there a way to get a data dump of those mappings (i.e., just a listing of pairs of integers, one for EOL and one for the external provider)?

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Patrick Leary: Thanks Patrick. Of course, now I can't reproduce the bug. But yesterday, I swear, for me it was not working with cURL unless the cache_ttl parameter was included. I know it can be difficult to communicate API changes, but email and/or Twitter would also help. I get fairly regular emails from NCBi, for example, where they warn if anything is going to change.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    Argh, the API has changed, causing me to waste time trying to debug code that worked previously.
    Turns out I now need to add now need to add &cache_ttl= to http://eol.org/api/docs/search_by_provider API to get anything back if I'm calling the API from a script (e.g. cURL in PHP).
    Guys, can please we have some way of being notified of these changes?

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Patrick Leary: HI Patrick, you're right I can do everything here, but if square images are available from EOL it would save a little effort at my end. If you have 88x88 and 130x130 available then listing those URLs would be helpful. Maybe they could be more cleanly rewritten as "small" and "medium" so if you decide that some other size works better, users won't have to rewrite their API client code (maybe the URLs could also specify whether the image was square or proportional).

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    The ability to grab a square thumbnail image for a taxon would be handy. As far as I can tell EOL doesn't provide this via the API, so I end up grabbing the full image, then centring (using ImageMagick's notion of "gravity") and resizing it. Square images have all sorts of uses, including mobile apps (I use them my iPad interface to EOL).

    EOL's web pages display square thumbnails that seem to all end in "_88_88.jpg" (e.g., http://media.eol.org/content/2013/02/03/12/43681_88_88.jpg ). Obviously this is an awful hack, but is there any reason not to construct equivalent URLs for other images and grab those? It would be much easier there was an API call to retrieve a square thumbnail, either of predefined size or user specified.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Yan Wong: Welcome to the joy that is the EOL API. Programming against it can be an exercise in frustration. It's a pity EOL doesn't "dog food", that is, program against their own API to generate the HTML pages. If they did, the limitations of the API would be exposed a lot faster (and probably fixed a lot faster).

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL Discussion Group":

    @Yan Wong: The vast majority of species on the planet are not covered by the IUCN (nor are they likely to be). The IUCN site suggests some 65,000 species have been assessed http://www.iucnredlist.org/about/summary-statistics (see Fig. 2). EOL has two IUCN lists (why?), the largest http://eol.org/collections/309 has 63097 taxa.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Patrick Leary: JSON FTW ;)

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Anne Thessen: I'm tempted to ask why you want to consume XML, which is a truly hideous format. EOL also outputs JSON, which is much nicer to work with.

    But since that's probably not the answer you're looking I've posted some code here: https://gist.github.com/rdmpage/5143326 It's in PHP (I kick it old skool) but it may help. I think there are two issues that you might be facing. The first is that I don't think 'response/taxon/dataObject/dc:description' is a field that exists, at least not in the example I quickly looked at (e.g., http://bit.ly/ZFfx8r ). The second is that you'll need to declare the default namespace ("http://www.eol.org/transfer/content/1.0") and add this to your XPath queries. For example, if you add 'eol':'http://www.eol.org/transfer/content/1.0' to the namespace map, and insert the "eol" prefix in your XPath query (e.g., "/eol:response/eol:dataObject/eol:dataObjectID"), things should work.

    If a service provides a choice between JSON and XML, JSON is almost always going to be the easier choice to use. XML is overkill in most cases, and a pain to work with. Hope this helps.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Anne Thessen: Anne, any reason you are using "http://dublincore.org/documents/dces" as the namespace for Dublin Core? The EOL API uses "http://purl.org/dc/elements/1.1/" for the Dublin Core namespace, which AFAIK is the current namespace URI. If you use a different namespace URI the XML parser is likely to fail to recognise terms from that namespace.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL Browsing Classifications":

    @Cyndy Parr: You can get the latest GBIF classification from http://ecat-dev.gbif.org/checklist/1 Click on the registry link http://gbrds.gbif.org/browse/agent?uuid=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c to get to the ZIP file.

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL Browsing Classifications":

    Any idea when GBIF will feature here...?

    over 1 year ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "Loxodonta cyclotis (Matschie, 1900)":

    The name Elephas cyclotis was published by P. Matschie in "Über geographische Abarten des afrikanischen Elefanten" http://biostor.org/reference/107170 (this reference doesn't appear in the list from BHL http://eol.org/pages/289547/literature/bhl )

    almost 2 years ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    @Anthony Goddard: Great, it's working for me now. PS, love the RAAF avatar!

    almost 2 years ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "EOL API Discussion Group":

    The API is down (returning "Error 503 Service Unavailable"). Any idea when it will be up again...?

    almost 2 years ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "Megascolecidae":

    @Bob Corrigan: The problem is that Catalogue of Life did have a nice classification for these worms that listed a number of genera. In the version EOL has recently ingested, CoL have simply adopted the WORMS classification, which doesn't cover terrestrial taxa. As a result, the terrestrial earthworms in this family have simply disappeared! CoL doesn't seem to have a means to check whether each updated classification makes sense and it's approach of delegating parts of the tree of life to particular projects (e.g,. ITIS, WORMS, etc.) can cause problems if those projects have a specific bias (e.g., WORMS handles marine taxa).

    In other words, the prior version made sense, the latest one is an obvious botch, and I'm frustrated because cached classification data I have is now broken. It is time the field stopped messing about and adopted a single, global classification coupled with decent version control so that errors like this get scrutinised and fixed.

    almost 2 years ago

  • Profile picture of Roderic Page who took this action.

    Roderic Page commented on "Megascolecidae":

    The Catalogue of Life classification http://eol.org/content_partners/14 for this family is broken. For reasons which surpass understanding the classification for this terrestrial family of earthworms has been taken from the World Register of Marine Species, which recognises a single genus (Pontodrilus).

    almost 2 years ago