API for the Russian public initiative. Step 2.1: UK experience with electronic petition data

    Earlier in a post on Habré I wrote about the very first step for creating an API for an ROI - uploading existing data using a parser.
    API for the Russian public initiative. Step 1: data collection and analysis


    But this step, of course, although important, but not the last in understanding what we want to do. Another step is to see what others have done. There are many projects in the world of electronic petitions; we will consider several of them in terms of API and open data.



    UK Electronic Petitions (epetitions.direct.gov.uk)



    Great Britain was one of the first countries to introduce the practice of collecting petitions from citizens and the mandatory review of them. Several tens of thousands of petitions passed
    through the British project epetitions.direct.gov.uk
    • 5,741 petitions opened
    • closed 18 323 petitions
    • 21,030 petitions rejected

    all figures as of November 5, 2013.
    Details on the website http://epetitions.direct.gov.uk/petitions?state=open.

    Russian petitions are partly similar to the British, it is also necessary to collect 100 thousand signatures and not more than 1 year.

    However, UK petitions have several important features:

    1. The petition is sent to the executive branch. Filling it, you yourself choose which department it belongs to and the petition is checked by the employees of this particular department. Thus, they confirm that what is written in the petition is, in principle, possible and all actions take place within the authority of the government, and not in the powers of the courts or parliament.
    2. Creation of petitions is not anonymous and their authors are known - this is published on the petition page
    3. There is no rigid binding to the person as we have with the portal of public services. To vote or to register a petition, simply fill out a short form by entering your address, email and postal code.
    4. The project is created in open development mode and its source code is available on github https://github.com/alphagov/e-petitions
    5. The project has an open API, more about which is written here - http://epetitions.direct.gov.uk/faq#question11


    Petition data is divided into two parts.

    The 1st is a list of all petitions with details and the 2nd is the ability to update data on voting on petitions in real time.

    A list of all petitions is available at: http://epetitions.direct.gov.uk/api/petitions.json (approximately 36 megabytes)
    A description of a separate petition looks like this:
    {
       "petition":{
          "id":10,
          "created_datetime":"2011-07-28T23:35:39Z",
          "response":null,
          "department_name":"Cabinet Office",
          "title":"resign",
          "creator_name":"Nigel Woodcock",
          "description":"We, the people of the United Kingdom of Great Britain and Northern Ireland, call upon Prime Minister David Cameron to resign with immediate effect and to call a general election. This is required due to his lack of mandate, the Conservative Party having gained only 36% of the vote in the 2010 general election. It is doubtful that anyone who voted Liberal Democrat would endorse the neoliberal policies currently being pursued by the coalition government. Therefore a general election is required in order to validate or repudiate current governmental policies. ",
          "last_update_datetime":"2012-08-04T18:00:09Z",
          "closing_datetime":"2012-02-04T15:07:57Z",
          "state":"open",
          "signature_count":1849
       }
    }
    


    In this petition urging David Cameron to resign, there is all the information we need that is on the petition page.

    But for real-time data, the data does not contain details for each petition, but contains details on the geography of the vote.
    The data is available via links in the format epetitions.direct.gov.uk/api [petition number] .json
    for example, like this - http://epetitions.direct.gov.uk/api/petitions/44403.json The

    geography is described as postal indices, that is, the detail is even higher than if we are detailed to municipalities.

    They do not publish historical data, suggesting that those interested can independently monitor the API and upload data on a regular basis.

    Pros and cons of approach



    Obvious advantages:
    • + REST + JSON API
    • + the possibility of mass unloading of the petition base
    • + data is updated in real time
    • + there is a binding of petitions to authorities
    • + there is information on responses from authorities
    • + high granularity of voting geolocalization


    And the obvious cons:
    • - API documentation is weak, the data is simple, but they could lead a couple of lines
    • - there is no way to track the voting in the context of time - by months and days
    • - there is no way to make complex queries, you need to regularly download the entire database of petitions


    It is too early to compare ROI and UK electronic petitions in content. Substantially, we are just at the start, but in terms of technological quality it is quite possible.

    In the next step 2.2, I will write about the US electronic petition system and how the data for each petition is disclosed there.

    Also popular now: