Hi @Lin_Zhaowei,
this is a fundamental point and caused headaches for last year’s index (see this thread for further info).
All of your mentioned points are correct. The “API issue” is a matter of balancing the functionalities of real-time access and user-friendliness with 1) open data’s technical requirement of access to ‘complete’ data (bulk data) and 2) open data’s normative requirement of allowing users to choose whether they want to register or not.
Let me answer to your point that GODI penalizes API access as “not available free online”. This is only partly true. If you go to the submission page and click on the question mark-symbol next to question B2 you can see following text field popping up:
Answer “Yes”, if the data are made available by the government on a public website. Answer “No” if the data are NOT available online or are available online only after registering, requesting the data from a civil servant via email, completing a contact form or another similar administrative process.
APIs normally do not qualify for the question because they make registration mandatory. If a country only provides data through an API it loses 10 points for question B2. Yet, we do not say that this data is not available for free which would mean that you have to pay for access (asked in B4) and which would block the open license question (B7). Instead, the GODI 2016 edition allows to continue the survey - an improvement that brings more clarity compared to former editions.
We assume that API access is definitely a great feature (see my comments below), and we regard it as a valuable additional form of accessing data. But there are other reasons why we didn’t include API access into the scoring:
The Global Open Data Index is a cross-country assessment. We want to make the results of the assessment comparable across countries. Therefore we base our requirements of necessary weather and air quality data on governmental documentation standards as well as use cases that are not time-critical so that they would require a real-time data provision. For instance some pollutants are provided by governments only in 8-hour rhythms. We kept our definition of timely data provision broad so it can apply to all pollutants across the board. We definitely lose some detail here, but circumvent to become overly confusing by providing different timeliness criteria for different data elements.
However, we allow submitters to document API access in question B2 because this is valuable contextual information. For the future we will consider possibilities to score different forms of data access adjusted to whether the data are time-critical or not. However, this would come at the expense of making our assessment more complex too.
We would love to hear your or other people’s feedback on this! Please share your ideas and comments in this thread.
Best
Danny