EOL API Discussion Group

With growing interest in using the Encyclopedia of Life API (application programming interface), comes the need for an openly available place to ask and answer questions. This is the place.

The Newsfeed for this EOL Community gathers updates associated with the items belonging to its Managed Collections, including activities of its members and comments from other EOL users.

Add a new comment

Newsfeed

  • 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 Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Roderic Page: replacing the end of the file name with _88_88, or _130_130 should always work... for now. How would you prefer to get the list of images sizes? Should they always be returned with the data object, or conditionally based on a parameter, or would you want there to be a separate method just for image sizes?

    We have a set number of predefined image sizes which are generated and saved to disk - we don't offer any dynamic image resizing services. If we exposed all the image size URLs (2 square, 3 proportionally scaled, and the original) do you still think there would be a need for us to offer a service that accepts user-defined image sizes? For our purposes the pre-generated sizes are sufficient for most needs. More advanced users like yourself could generate their own custom sizes, and others could find a close-enough size and use CSS to scale the image (not ideal but since we have a few options hopefully there isn't a huge amount of wasted bandwidth when downloading something slightly larger than they need). I guess I'm wondering if you think this is a service EOL should offer (essentially a hosted imagemagick) or something the user could do themselves by chaining together services.

    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 Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Yan Wong: We might have to change more than the harvesting code for Wikimedia if these are license values that the rest of EOL isn't set up to handle. We can add it to our queue but I don't know how quickly our developers will get to it. Harvesting code for Wikimedia might be on Github, which would mean that it is open source code others could potentially update.

    almost 2 years ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Barb Banbury: I don't see a ticket in our system for this. I'll add it -- if it is considered a bug it might get fixed on Monday (our bug fix day) but I can't promise. Can you work around it?

    almost 2 years ago

  • Profile picture of Barb Banbury who took this action.

    Barb Banbury commented on "EOL API Discussion Group":

    I know this has been mentioned, but I thought I would add that I am waiting for a fix on the taxon search without quotes as well. For example, http://eol.org/api/search/1.0.xml?q=Ursus+arctos&page=1&exact=true should return he same as http://eol.org/api/search/1.0.xml?q=%22Ursus+arctos%22&page=1&exact=true, but it doesn't.

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Patrick Leary:
    "The pages API returns objects sorted first by type, next by vetted status, then by data rating"

    only it doesn't always. For example, try http://eol.org/api/pages/1.0/1179006.json?images=2&text=0&iucn=false&subjects=overview&licenses=pd%7Ccc-by&details=true&common_names=true&references=false&vetted=0 which returns 2 images, the first of which is untrusted, the second of which is trusted.

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Patrick Leary: Re: CC-Zero, CC-PD-Mark, I'm aware that many lovely images scanned from old books and now on Wikimedia Commons are tagged using CC-PD-Mark (e.g. http://eol.org/data_objects/17769448). I wondered if these could be automatically tagged by the WikiCommons scraping algorithm, so that the url in the license field is http://creativecommons.org/publicdomain/mark/1.0/.

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Patrick Leary: Personally, I don't mind if optional API fields are either not returned, or returned blank. I suppose not returning them saves some bandwidth, so is marginally preferable. What is more important to me is that the possibilities for each field are documented somewhere.

    almost 2 years ago • edited: almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Patrick Leary:
    "The pages API returns objects sorted first by type, next by vetted status, then by data rating"

    Excellent. That's exactly what I wanted to know, and what I had hoped. Thank you. Might it be a good idea to add this to the documentation?

    almost 2 years ago • edited: almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Yan Wong: When EOL imports content we rely on algorithms to determine which incoming taxa are related to which pages. Sometimes the algorithm makes a mistake. In this case we had some Platanista gangetica content inappropriately showing on the Platanista page, which also then confused the search results. I manually fixed the names problem, so that exact search is returning the correct result.

    The issue with quotes is a separate bug, and indeed something strange is happening there. We will looking into it and push out a fix when we can. Thanks for reporting it.

    almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Barb Banbury: Hi Barb - unfortunately 75 is a hard limit on each content type at the moment. Ideally this could be increased and we could allow calls which would 'page' through lists of media for taxa, but this has not yet been implemented.

    almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Yan Wong: EOL is accepting new content using the CC-Zero license, but I have not heard any talk of trying to reclassify existing CC/publicdomain content as CC-Zero. I am not an expert on rights matters, so I couldn't personally say if these licenses are identical such that we could reclassify cc/publidomain as cc/zero without approval by the contributor.

    Also, I appreciate the questions and would in interested in a more usable way of documenting such problems. We have been working on an alternative to these discussion threads which we may soon have people help us beta test. Stand by for news on that.

    almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Yan Wong: It sounds like the API is returning "Unknown" which is synonymous with "Unreviewed". I will look into updating the label to read Unreviewed. Some objects will indeed be untrusted. As Jeff mentioned, we should likely not be returning untrusted objects by default. We used to display these on the site for all users, but now they are not shown by default - so the API should probably reflect this behavior.

    As for source - as you have discovered this is not a field that all providers will supply us with. It would be a good idea for us to document all the fields that might possibly get returned, and note which ones will always or only sometimes get returned. There are other object fields like rightsHolder, bibliographicCitation, or even title which are optional and will only be returned in the API if an object has values for them. I have heard some people request that we include empty values for these fields (null values in the JSON response or empty fields like <title/> in XML). Do people feel this would be better than not returning them at all?

    almost 2 years ago • edited: almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Yan Wong: There are only a few values that we can expect to be returned with relatively consistent values. These include dataType, mimeType, license, audience and vettedStatus. There are other values that we recommend values for, but providers can give their own values if they wish. Those fields include agent roles and languages. Then there are free text field which will vary significantly including title, rights holder, bibliographicCitation, description, etc. We could provide a list of the more controlled terms in the documentation. The only fields that will effect sort order will be dataType and vettedStatus

    almost 2 years ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Yan Wong: Hi Yan. 1) as I think has been explained already, there are 3 vettedStatuses: Trusted, Unreviewed (sometimes called Unknown though we should be using Unreviewed instead) and Untrusted. When sorting objects that is also the order of priority of the vetted statuses.

    2) The pages API returns objects sorted first by type (text, images, videos, sounds, maps, IUCN statuses), next by vetted status (trusted, unreviewed then untrusted), then by data rating (highest rated first) and finally by the date the particular object revision was harvested by EOL (newest objects show first). If an EOL curator has specified an exemplar image or text article, those will show first, bypassing all other sort criteria. Of couse all of these are flavored by the request parameters, so if you request only trusted content and a page has an exemplar image which happens to be unreviewed, that image will not be returned. If no parameters are provided, then the first image returned by the API should always be the "best" image we have for the taxon (i.e. the image that will show first on the taxon page)

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Jeff Holmes:

    Is there a bugtrac-like thing where we can report this sort of thing, or do we just report stuff here? I'd be happy to add to documentation if appropriate too.

    By the way, any follow up on the what the default order of returned dataObjects is?

    almost 2 years ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Roderic Page: Agreed... although the goal is eventually to convert the site over to be entirely API driven. Of course, part of the problem is limited resources to get all this done. A fast pages API is my dream... :-)

    almost 2 years ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: I'll leave the IT group a ticket about this one. Looks like it's not behaving correctly to me as well.

    almost 2 years ago