Barb Banbury

Still developing

The EOL Profile Newsfeed contains comments left for its owner by other members, EOL Community invitations, and gathers updates associated with the items in the owner's EOL watch list.

Add a new comment

  • Profile picture of Nathan Wilson who took this action.

    Nathan Wilson commented on "EOL API Discussion Group":

    The only approach I've found for doing this with the current API is to use the collection API to get a list of the photos provided by a content partner. It's a bit ugly, but there's enough information there to figure out the needed calls to the data_object API call.
    I'm interested in your use case. The most important case we've come up with is providing content partners a way to get deep links into EOL. This suggest a large batch lookup for all the content for a partner would be more efficient than a picture by picture lookup using, for example, the unique id provided by a given content partner.
    In our existing ticket tracking system, I've already requested:
    - A single (possibly paginated) API call that returns all the information a content partner needs to connect their pages to the appropriate EOL pages. In this case having the returned by the data_object API call added to the collection API call would be sufficient, but having the unique id provided by the content partner would be better (parsing URLs is ugly).
    - Include in the collection API the data_object URL rather than just the EOL data_object id (gives EOL the ability to change the URL).
    - An API call for discovering a content partner's collection (currently you have to look it up by hand and hard code it).

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Jonathan Ray who took this action.

    Jonathan Ray commented on "EOL API Discussion Group":

    Well I was thinking of matching the picture and then parsing the data, maybe not actually retrieving the photo itself but the data of the matched picture, but down the line actually rwtieving like a thumbnail of the matched picture may prove beneficial. Thanks.

    over 1 year ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Jonathan Ray: I think it is somewhat difficult to do this, as to use the data_objects method you need to know either the EOL DataObject version ID or a 16 character GUID, neither of which you can get without inspecting the XML for a page on which that photo appears. I could be wrong about this, but if I'm right this is a good suggestion for API improvement. How would you want to retrieve the photo?

    over 1 year ago

  • Profile picture of Jonathan Ray who took this action.

    Jonathan Ray commented on "EOL API Discussion Group":

    Is it possible to use the EOL API to match a particular photo sent in, in order to the parse xml data about said picture?

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Bob Corrigan: Thanks Bob. If you are referring to the thumbnail sizes, I worked out that two of the "proportional" sizes are labelled _98_68 and _580_360. I'd still be interested to know what the 3rd available size is.

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Cyndy Parr: Thanks Cyndy. I'm absolutely sure it used to return both 12132222 and 1057290 before, but as you say, it only returns 1057290 now, so the problem has magically resolved itself! Thanks.

    over 1 year ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Yan Wong: Searching for Acanthodactylus bedriagae on the site finds this page: http://eol.org/pages/1057290/ . I tried the API call http://eol.org/api/search/1.0.json?q=Acanthodactylus+bedriagai and it seems to return the same thing. If there was a hiccup in the index it seems to have resolved itself.

    over 1 year ago

  • Profile picture of Bob Corrigan who took this action.

    Bob Corrigan commented on "EOL API Discussion Group":

    @Yan Wong: @Yan, did you get the answer you needed from anyone?

    over 1 year ago

  • Profile picture of clkirby1 who took this action.
    clkirby1 joined the community "EOL API Discussion Group".

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    An API search for "Acanthodactylus bedriagae" gives 12132222 as the first page ID, but searching for that ID using the pages API returns "error": "Page \"12132222\" is no longer available". If a page has been deleted, shouldn't it be removed from the search database?

    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 Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Patrick Leary: So _88_88 and _130_130 are the suffixes for square thumbnail images. I see that _98_68 is the suffix for one of the 3 sizes of proportional thumbnails? I'd be grateful to know the suffixes for the other sizes of proportional thumbnails.

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Nathan Wilson: Thanks. I've just seen that there is a little documentation on this, actually: http://eol.org/info/54#crop

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Nathan Wilson who took this action.

    Nathan Wilson commented on "EOL API Discussion Group":

    Just fixed the example image. I believe the intent is to make the cropping available to all curators including assistant curators.

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Jeff Holmes:

    Sure - it's from http://eol.org/data_objects/5902712

    For the majority, I think a single version is good enough. Maybe the tool should be available to curators?

    Out of interest, are you likely to rename the thumbnails to "small_square", "small_proportional", or the like? I don't have strong views on the matter, though, and I guess you could just provide both options via redirects

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: We do have a tool that is available to admin users that does let us adjust thumbnails but only one version can be saved. I'll have a go at fixing the one you mentioned... Can you provide a link to that page?

    over 1 year ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: I encourage the building of tools on EOL to let users add value to content that is aggregated. For images, I'd like to see an editor that enables a user to crop a thumbnail as desired and save their version back to EOL for others to use as well. Currently, we have 2 sizes of thumbnails with the ability to have only one version of each - it would be nice to have more options available.

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Roderic Page:

    With reference to thumbnails, there are (of course) some unfortunate effects of creating non-proportional thumbnails. Here's an amusing one: http://media.eol.org/content/2012/06/15/04/39036_130_130.jpg.

    In this case the effect is avoidable, I think. Is there any way for curators to change the centering of individual thumbnails for specific pictures on EoL, so as to override the default options? For people using thumbnails, that might save some duplication of effort in looking through thumbnails to see which are sensible and which are not.

    Of course, a nicer way to do this would be to pick the centre of the image programmatically, but I guess that's staggeringly hard, even if the task is just confined to vertebrates.

    over 1 year ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Patrick Leary: I think what we need is an email option in the account settings that says "I want to receive technical notifications from EOL". That way developers could be notified beforehand as well so they would have a chance to monitor the changes more closely.

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Roderic Page: The API changed in that an new optional parameter cache_ttl was added, but that should not have any impact on existing use of the API. The cache_ttl parameter is optional, and the responses from all requests that choose not to use it should not have changed.

    I just tried a few uses of cURL with no problem. On the command line:
    curl http://eol.org/api/search_by_provider/1.0/180542?hierarchy_id=903

    And in PHP (using PHP 5.3.15):
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, 'http://eol.org/api/search_by_provider/1.0/180542.json?hierarchy_id=903');
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $result = json_decode(curl_exec($ch));
    echo $result[0]->eol_page_id."\n";

    Can you provide an example where you are seeing a problem? As for announcing API changes I agree we need better communication. This was part of the reason we developed a forum, and that forum does include a post about the new cache_ttl parameter. I realize I did not make a similar post to this group, so I will make sure to share information about API releases more widely next time.

    over 1 year ago • edited: over 1 year ago