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

    Yan Wong commented on "EOL API Discussion Group":

    More random questions, sorry - I feel I should start a FAQ! The Creative Commons seem to have retired the public domain licence that is returned in the "license" field of PD dataObjects (http://creativecommons.org/licenses/publicdomain/). Are there plans to start classifying public domain items listed in EoL under the replacement CC-Zero or CC-PD-mark licences?

    over 1 year ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Yan Wong: Not all providers use the "source" agent. They probably will have a "supplier" though.

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Jeff Holmes:

    My fault slightly, I don't think I'm getting "Unreviewed" as a return value for vettedStatus at all, just "Trusted" and "Unknown". Can I assume that there might be some objects labelled "Untrusted" in there as well?

    Another minor point: should all images have a "Source" field? DataObjectID 19887625 doesn't seem to.

    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":

    Actually, I'm not sure why the API is returning all content by default with the pages API. Content that has been specifically "untrusted" by curators should not be returned by default in my opinion.

    over 1 year ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: Hi Yan, I agree that it is a bit confusing since the vetted parameter documentation doesn't say that the parameter will be referred to as "vettedStatus" in the returned data. I think it's working though since setting the vetted parameter to "2" in an API call does return all content except those that have been marked "untrusted" specifically by a curator. Not sure where the "unknown" is coming from but I imagine that is equal to "unreviewed". In other words, content that has come in from a source that is not "trusted" by default. This would include Flickr, Wikipedia, etc. Some of the other values you mention (e.g. roles) are hard to predict because they depend on what content partners have provided in their data transfer. Cheers, Jeff

    over 1 year ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    Thanks Cyndy. Yes - I've been working from the API doc page. The only ref I can see to the vetting is describing the "vetted" parameter (0, 1 or 2) when calling the API. The actual field returned is a text field called "vettedStatus" which (as far as I have found) can be either "Trusted" "Unreviewed" or "Unknown". But I can't see that documented anywhere. I've been bitten when assuming certain text values in the API (e.g. sometimes instead of returning role="photographer", you get role="fotograaf" or various other translations). So it might be helpful to list the possible return values for these fields (as well as specifying the sort order).

    I see what you mean about discouraging excess html. But when I started posting it wasn't even clear to me that I could use html to break up paragraphs, etc.

    over 1 year ago • edited: over 1 year ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL API Discussion Group":

    @Yan Wong: Hi Yan, did you look at http://eol.org/api/docs/pages/1.0? I agree that the default sort order isn't explained in the documentation. I think that they are sorted in the order of dataRating although we also have a concept of "exemplar image" which is set by curators and can override (on EOL pages) the ratings (which could be vulnerable to user whimsy). I believe the exemplar image is supposed to be returned first by the API. But let's see what the developers say, and ask them to add it to the API documentation.


    I'm pretty sure we haven't documented what HTML is allowed because we don't want to necessarily encourage highly HTML-formatted text in general (can break pages in various ways). But I agree it would be helpful to have a whitelist somewhere.

    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":

    Hi - new here. I've a few of specific questions about the page API - perhaps there is some detailed documentation somewhere?

    1) what are the possible values for the "vettedStatus" parameter on dataObjects? I'm guessing Trusted, Unreviewed, then Unknown?

    2) what order are the dataObjects returned in? I'm trying to grab a single public domain or CC-BY image for each species, and I'd like the one with the most trustworthy vettedStatus, and if several with the same value, the one with the highest dataRating. I imagine this is the most likely order to want. At the moment I'm just grabbing the first 10, and sorting them myself, but it would be less strain on EoL bandwidth to simply ask for a single image, with the appropriate sort order.

    p.s. - it's not clear to me what HTML formatting is allowed in posts on this group. Might it be an idea to put a link in to a page detailing how to use the discussion groups appropriately? I see I'm allowed <small> :)

    Cheers

    over 1 year ago • edited: over 1 year ago

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

    over 1 year ago

  • Profile picture of Anne Thessen who took this action.

    Anne Thessen commented on "EOL API Discussion Group":

    @Patrick Leary: I don't particularly need xml. I have been playing around with the json most of today, but I'm not having much luck there either. I can load the json okay (I think) but it doesn't want to recognize any of the nested dictionaries and dictionaries.

    over 1 year ago

  • Profile picture of Anne Thessen who took this action.

    Anne Thessen commented on "EOL API Discussion Group":

    @Roderic Page: Interesting that the tags in the xml you link to is different from what the API returned to me for another species....

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

    Patrick Leary commented on "EOL API Discussion Group":

    @Anne Thessen: Hi Anne. If you continue to have troubles with XML and you do not need URIs and namespaces, then you could try the JSON response format http://eol.org/api/pages/1.json?details=1 . I am not a Python developer, but a quick search brought up http://docs.python.org/2/library/json.html which gives examples of how to decode JSON. If you can fetch the JSON result then pass it to json.loads, that might be easier to work with.

    over 1 year ago

  • Profile picture of Anne Thessen who took this action.

    Anne Thessen commented on "EOL API Discussion Group":

    @Roderic Page: Thanks for the suggestion. When I use the purl URI I lose the complaints about the dc:prefix, but now it doesn't pick up anything. I'll keep pounding away at it, but if you've got a bit of code working I'd really appreciate it if you would send it along. Thanks!

    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 Anne Thessen who took this action.

    Anne Thessen commented on "EOL API Discussion Group":

    Hi I'm new to this community. I have a question about parsing the xml output from the API. I'm using python to pick out the bits I need, but it doesn't seem to like the dc: prefix. I've tried to define it using namespaces, but it is still not happy. Has anyone else run into this problem? Below is what I'm doing. Any advice is appreciated. import xml.etree.ElementTree as ET nsmap = {'dc':'http://dublincore.org/documents/dces'} tree = ET.parse('test.xml') identifier = tree.findtext('response/taxon/dataObject/dc:identifier', namespace=nsmap) description = tree.findtext('response/taxon/dataObject/dc:description', namespace=nsmap) print (identifier, description)

    over 1 year ago

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

    over 1 year ago

  • Profile picture of Barb Banbury who took this action.

    Barb Banbury commented on "EOL API Discussion Group":

    @Patrick Leary: Great news, thanks so much! I look forward to the fix!

    over 1 year ago

  • Profile picture of Patrick Leary who took this action.

    Patrick Leary commented on "EOL API Discussion Group":

    @Barb Banbury: Hi Barb - thanks for bringing this to our attention. We found the problem (likely introduced about two weeks ago) and submitted a fix for it. We will be releasing some new code on Thursday morning, and by about noon Eastern time the fix will be live and API calls which include the IUCN status will be working. Thanks again

    over 1 year ago