Search Mailing List Archives
[bioontology-support] Final Notice on NCBO BioPortal Old REST API Phaseout
dan.bolser at gmail.com
Thu Feb 27 14:18:31 PST 2014
On 27 February 2014 20:31, Ray Fergerson <ray.fergerson at stanford.edu> wrote:
> <changing the cc list>
> 1) Just a gripe, but... for exploratory purposes, could you give free
> access to some small number of queries from a given IP per day, requiring
> the apikey only for 'high volume' use? It's a pain to share links in
> emails and to explore from the examples when you constantly have to paste
> your key into the URL.
> RWF: Once the API key is set in your browser it will get remembered for 2
> weeks. This is documented at the very top of:
> 2) More importantly, this URL breaks:
> It works fine if you remove 'include=all'. I'm just looking for a list of
> fields I can grab per term. Specifically I'm looking for the old
> 'definition' field... Ah... include=definition :-)
> RWF: include=all on search is broken and a known bug. It will be fixed in
> the release next week. You don't need an include to get definitions
> though. They are returned by default. The example query on the
> documentation (melanoma) returns definitions for terms. If you scroll down
> just a bit on the first returned page you can see terms that include
Sorry, I think I was looking for 'description' at first, and missed
'definition' in the output initially.
> This query reports nothing (apparently):
> while I'd expect it to turn up this information:
> RWF: another known bug. "exact_match" currently does not work with
> synonyms. Will try to get this fixed for next week too.
Yeah, it would be good to get this fixed before I have to switch over!
> There is no
> with_synonyms switch. You always get them now.
Sorry, I was thinking of include_synonyms.
> Most of the fields (like with/include_synonyms) aren't explicitly
> documented here:
> RWF: the fields that are there are documented. There is currently no
> include_synonyms switch. You always get synonyms back (except for the
> exact_match bug, described above).
Where is include_synonyms documented? What does it do? Setting
'include_synonyms=false' doesn't seem to affect the fields returned...
Is it changing what fields gets searched? You could document that...
Actually, it doesn't even affect the number of results returned, so I
can't even guess what it's doing.
> Am I doing something wrong, or are there still issues with the service? If
> I migrate all my code, how long until I'm asked to move everything again?
> RWF: Well the project has been going for 8 years and this is the first API
> revision. As they say, past history is no guarantee of future performance,
> but it would not be unreasonable to plan on reworking your code in another
> 8 years.
> Seriously though, we realize that it is a lot of work for our user
> community to adapt to a changing API. We have not made this change lightly
> and a lot of effort has gone into it. Initial feedback has been pretty
> positive wrt the old system. We are continuing to work on it and improve
> it and we are committed to getting all of the bugs out.
> It's a bit annoying to be told to move imminently to a service that seems
> to have bugs and/or missing documentation (sorry if this is just me being
> RWF: We believe that most of the documentation is there. The new system
> does have bugs but the old system had bugs too. You may have either just
> not encountered them or have worked around them. We notified people in
> October that the API would be changed. Thus we have provided almost 6
> months for a switchover. This seems pretty reasonable as these things go.
What? I'm supposed to read announcements?! ;-)
Sorry, I'm just joking. The thing is that this is a spare time project
so I only started looking at this when you said 'we really mean it
this time guys!'. However, I can't migrate my code when the
functionality I rely on is broken!
Thanks for clear replies, and sorry for being a pain.
More information about the bioontology-support