API for Gretl

Site Feedback
1

Hi everyone,
Has anybody tried to access db.nomics data from gretl or knows how to do?
Cheers,
Martin

1 Like
2

Hi, as it happens, I’ve heard it’s in the making… (on the gretl side).
Have you tried using the csv format in the meantime? (Honest question, haven’t done it myself.)

3

Yep, we’re working on it!

4

Hi!
Just to keep you informed that we push a new version of the python client for DBnomics, with more features : https://git.nomics.world/dbnomics/dbnomics-python-client/tree/master. I hope it can help. We are currently adapting the R client.

5

Hello again,

We (gretl team) now have a quite functional prototype dbnomics interface in testing (using the new API). But I have a question. I notice that the API has changed quite substantially within the last 24 hours, including renaming of certain key JSON fields (“value” -> “values”, “period” -> “periods”, “categories_tree” -> “category_tree”, etc.) and revised URLs (“datasets” -> “search”). Is there an automated way of getting notification when such changes are made? Or if not, is there a recommended way of ensuring that we keep up to date? Thanks.

6

Hello Gretl,

Thanks for your interest in DBnomics.

Is there an automated way of getting notification when such changes are made? Or if not, is there a recommended way of ensuring that we keep up to date? Thanks.

First, the API follows sermantic versioning policy (https://semver.org/). Before version 1.0, all 0.X versions
introduce breaking changes. So 0.20.0 to 0.20.1 doesn’t implies any changes on your side, but 0.20 to 0.21 does.
Until the API reaches version 1.0, it is considered a beta version. It is quite stable now, and that the kind of changes you’re talking about are not willing to occur anymore in the near future.

We plan to add version numbers directly to the URL, allowing supporting many versions of the API in parallel. Clients like Gretl will be able to continue using an older version while transitioning to the new one. Cf this issue.

We will introduce a changelog in the dbnomics-api repository when the next version introducing breaking changes will be released (this is not planned for now).

There is currently no automated way to get notifications of dbnomics-api updates. We use Git tags (see this page) to track the releases of dbnomics-api. Apparently GitLab doesn’t allow to subscribe to tags yet, sadly. We could post a topic on DBnomics forum for each release of the API. Would that be useful for you?

Please note that we intend to ship the 1.0 version in the near future, after this milestone is completed.

Thanks again for your interest in DBnomics!

7

Thanks, that’s all very clear. I think it would be helpful if you could post a topic on the forum for each API release.

8

Hi @acottrell

I had an afterthought about your message and felt it would be useful to comment some changes:

  • “categories_tree” -> “category_tree”: this is a pure English language fix which was reported by an American native user
  • “value” -> “values” and “period” -> “periods”: this was a mistake, and I switched back to singular spellings. All JSON fields are singular in series returned by /series API endpoint.

Sorry for inconvenience, again.

9

Thanks again. It’s true, “category_tree” reads better to a native English speaker.

On reverting to the singular for “value” and “period”: fine; we’re currently equipped to search for both singular and plural but it will be helpful to scrub that complication.

10

I just want to say: we really appreciate your work at DB.NOMICS, this is a fantastic resource in the making!

Anyway, I’m exploring the full tree of providers’ datasets as accessed via our new gretl code and I’ve come across a couple of anomalies (or so it seems to me), namely the providers DREES and ONS. Our working assumption is that if we look for datasets under a provider’s category_tree we should find an equal number of “code” and “name” elements, either under “children” (if the provider groups its datasets into named categories) or just under the “category_tree” itself. This works for all the currently listed providers except for DREES and ONS.

DREES: has 10 “code” entries but only 8 of them have a corresponding “name”.

ONS: the JSON tree looks weird, with multiple levels of “children” – is this supposed to be OK?

11

On closer examination, while the results for DREES and ONS are both somewhat strange, they don’t seem to be formally erroneous. Our gretl client is now able to handle them.

You might want to take a look at these cases, but this does not have the status of a bug report.

12

The new version of gretl (2018b, released on 10/8) contains a native interface to dbnomics.

I recorded an instructional video to show its most salient features: https://youtu.be/B2KmX9A6ICg

Comments welcome!

2 Likes
13

Hi @acottrell

thanks for your feedback. You’re right, it’s not bugs, but for the record I wanted to answer more precisely:

This is OK, our data model requires only code to be defined for datasets (see here for technical source). Sometimes the fetchers can’t extract the name of the dataset programmatically, or sometimes the developer of the fetcher did not managed to do it. If it is possible, we could enhance the fetcher, or accept a pull-request in that sense.

Yes, because the category tree can be defined with arbitrary levels of depth. DBnomics aims to reproduce the category tree of the provider, as presented on the original website/database.

Thanks for making the video, we’re glad to see DBnomics in action :slight_smile:

14

Jack Lucchetti is the one to thank for the video. It’s a nice showcase for both DBnomics and gretl, I think.

15

Hi @jacklucchetti and @acottrell,

I just wanted to inform you that we updated the DBnomics web-site to add a link to Gretl in the footer.