My activity
-
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
Patrick Leary commented on "EOL API Discussion Group":
@Roderic Page: The API changed in that an new optional parameter cache_ttl was added, but that should not have any impact on existing use of the API. The cache_ttl parameter is optional, and the responses from all requests that choose not to use it should not have changed.
I just tried a few uses of cURL with no problem. On the command line:
curl http://eol.org/api/search_by_provider/1.0/180542?hierarchy_id=903
And in PHP (using PHP 5.3.15):
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://eol.org/api/search_by_provider/1.0/180542.json?hierarchy_id=903');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$result = json_decode(curl_exec($ch));
echo $result[0]->eol_page_id."\n";
Can you provide an example where you are seeing a problem? As for announcing API changes I agree we need better communication. This was part of the reason we developed a forum, and that forum does include a post about the new cache_ttl parameter. I realize I did not make a similar post to this group, so I will make sure to share information about API releases more widely next time. -
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
-
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. -
Patrick Leary commented on "Cressa":
@DBvdPloeg: Thanks for the report. The two genera should now be properly separated.
-
Patrick Leary commented on "Jeremy Rice":
This comment was deleted.
-
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
Patrick Leary commented on Patrick Leary's newsfeed:
This comment was deleted.
-
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. -
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.
-
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. -
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? -
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
-
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) -
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.
-
Patrick Leary commented on "Patrick Leary":
This comment was deleted.
-
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
