Kristen Lans

Life is Good!

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 Katja Schulz who took this action.
    Katja Schulz added "Mangrove leaves" to the collection "EOL pages that don't represent real taxa".

    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 Katja Schulz who took this action.
    Katja Schulz added an unknown item to the collection "EOL pages that don't represent real taxa".

    over 1 year ago

  • Profile picture of Katja Schulz who took this action.
    Katja Schulz added "* *" to the collection "EOL pages that don't represent real taxa".

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

    Cyndy Parr commented on "EOL Discussion Group":

    @Bart C.: We're working on a better way to upload a batch of taxa into a collection. But there is a way you can do this right now -- use the spreadsheet upload method as if you are adding content to EOL. Then you can copy to a "fresh" collection so you can easily add and subtract new pages from there. Feel free to contact Jen Hammock who can help you.

    over 1 year ago

  • Profile picture of Bart C. who took this action.

    Bart C. commented on "EOL Discussion Group":

    Would it be possible to construct and submit a list of species you want to add to a collection via a spreadsheet? I am a member of group of naturalists that want to establish fauna lists for our working area. We want to publish this on our website. A link to an EOL collection would be perfect to update annotations instantly, without bothering our webmaster too much and have additional information about those species one click away for our visitors. Adding hundreds of species one by one to a collection and adding annotations and references via the EOL one by one is a bit too much.

    over 1 year ago • edited: 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 trobertson who took this action.

    trobertson commented on "EOL Curators":

    Hi all, @Constantine Wing Heng Lau @Cyndy Parr I will contact Discover Life but please see the DL page for that record [1] which states "decimal latitude_longitude from gazetteer ••• 41.1_-85.1". DL are automatically (and too optimistically) using a reverse geocoding to provide coordinates based on textual information on the record. The record published through GBIF [2] does not contain coordinates and the GBIF network content does not appear at first glance to be particularly problematic for that species [3]. I hope this helps explain the content you are seeing. Best wishes, Tim - Systems architect, GBIF [1] http://www.discoverlife.org/mp/20l?id=GBIF50315052&btxt=Encyclopedia+of+Life&burl=www.eol.org/pages/311781 [2] http://data.gbif.org/occurrences/50312715 [3] http://data.gbif.org/species/2435451/

    over 1 year ago

  • Profile picture of Cyndy Parr who took this action.

    Cyndy Parr commented on "EOL Curators":

    @Constantine Wing Heng Lau: Please click through to the map object page (http://eol.org/data_objects/21430628) and leave your comment so that the source and other visitors will know there is a problem. You can untrust and hide the map but again, give an explanation so that the source can fix the problem. This can also be a problem with our GBIF maps which currently are not curatable. We are aware and hope to improve this in the future.

    over 1 year ago

  • Profile picture of Claudia Sotgia who took this action.

    Claudia Sotgia commented on "EOL Curators":

    @Constantine Wing Heng Lau: After a quick look, if I understand correctly, you're right. The maps should represent the natural range of a species; the presence in a zoo cannot be considered as a population. I am a new curator and I still haven't seen as make changes, but I suggest leavingg only the distribution map. I hope I have been helpful. Also I would like to tell you that I'd like to contact you because my working group is writing a manual of good practices on bees. I am writing on pollination service and on the problems of habitat loss, fragmentation etc. Can you give me some advice? Ciao, Claudia

    over 1 year ago

  • Profile picture of Constantine Wing Heng Lau who took this action.

    Constantine Wing Heng Lau commented on "EOL Curators":

    I just took a random look on the page for Tasmanian Devil (Sarcophilus harrisii), and found an issue. As I understood this species should live on one or more islands next to Australia. However, the one of the 2 maps on its page showed that it appeared in the USA. Turns out, I checked the original source of the data point at USA, and found that it was a collection of the Ft. Wayne Children's Zoo in Indiana, US. (http://www.discoverlife.org/mp/20m?act=make_map&kind=Sarcophilus+harrisii) In this case, the map seems misleading to the public because it was neither showing the natural occurance or all of the zoo records. Any suggestion?

    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