Anthony Goddard

Jerome.

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

  • 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).

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    And here's another weird thing (could just be a tagging problem): taxon 2844801 is all placental mammals, yet http://eol.org/api/search/1.0.json?page=1&q=Spalax%20uralensis&exact=true&filter_by_taxon_concept_id=2844801 returns nothing, whereas http://eol.org/api/search/1.0.json?page=1&q=Spalax%20uralensis&exact=true returns the correct placental mammal (a rat). I could probably find a few more similar cases.

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Jeff Holmes: I am using "exact". Try http://eol.org/api/search/1.0.json?q=Platanista+gangetica&page=1&exact=true and you'll see.

    almost 2 years ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: You can use the "exact" parameter with the Search API. That should work by only returning pages that exactly match the search string.

    almost 2 years ago

  • Profile picture of Yan Wong who took this action.

    Yan Wong commented on "EOL API Discussion Group":

    @Jeff Holmes:

    Great thanks Jeff.

    Another thing, I'm trying to find an exact match for species names, e.g. "Platanista gangetica". If I call the search API with q=Platanista%20gangetica, I get the genus page before the more precise species one. If I call it with quotes, q=%22Platanista%20gangetica%22, I get the most precise one first, but I also get 45 other matches.

    Is there a call I can make to get the most precise match first without all the other stuff? Or does the order of exact search results need tweaking by EoL?

    almost 2 years ago

  • Profile picture of Jeff Holmes who took this action.

    Jeff Holmes commented on "EOL API Discussion Group":

    @Yan Wong: Hi Yan, I think "unreviewed" objects are being returned as "unknown". I have seen untrusted objects returned as "untrusted" though. Take a look at the results of this call: http://eol.org/api/pages/1.0/914512.json?images=75&videos=0&sounds=0&maps=0&text=2&iucn=false

    almost 2 years ago

  • Profile picture of Barb Banbury who took this action.

    Barb Banbury commented on "EOL API Discussion Group":

    Is there any way to increase the limits on the page parameters (ie, images, videos, etc)? Is 75 the upper limit here? What if we are interested in the 76th image? Or all all media of Animalia?

    almost 2 years ago