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

    over 1 year 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)

    over 1 year 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?

    over 1 year 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... :-)

    over 1 year 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.

    over 1 year 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).

    over 1 year 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.

    over 1 year 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.

    over 1 year 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?

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

    over 1 year 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?

    over 1 year ago

  • 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 Eduard Solà who took this action.

    Eduard Solà added the Catalan common name "Sípia" to "Sepia officinalis Linnaeus, 1758".

    over 1 year ago