This project's goal is to author, through community consensus, international open government data specifications relating to the legislative branch of government, so that civil society can spend less time transforming data and more time applying it to the problems they face. A related goal is to make it easier for civic developers to create government transparency, monitoring and engagement websites, by developing reusable open source components that implement the specifications. Although the data specification is designed primarily for open government use cases, many other use cases are supported.

Principles

  1. This project rigorously researches and studies existing specifications and reuses suitable existing work wherever possible. It looks for existing specifications that balance breadth of adoption with quality of modeling. It prioritizes reuse over novelty.

  2. This specification satisfies a broad range of use cases, without requiring an exhaustive vocabulary of terms. It focuses on flexibility to do more with fewer terms.

  3. A fact that many specifications overlook is that our knowledge of the world is imprecise and uncertain. This specification attempts, as much as possible, to make it easy to represent real world data while preserving clarity and meaning.

A civil society organization doesn't know the precise date on which a legislator assumed office. Its legislative information service should nonetheless be able to publish an approximate date in that legislator's profile.
When extracting the sponsors of a bill from a legislature's website, it isn't immediately possible to disambiguate a sponsor's name and link to the appropriate legislator or committee profile. A legislative information service should be able to publish the incomplete sponsor information, without having to first determine whether that information belongs to a legislator or a committee.
A civil society organization has the phone number of a legislator; however, it doesn't know whether it is the capitol office number, the constituency office number or a mobile number. A data specification should be able to handle data at varying levels of detail.

Process

The high-level specification development process is as follows:

  1. Identify use cases and requirements for a specific activity system.
  2. Research existing specifications that fulfill the use cases and requirements.
  3. Author a specification and related documentation that respect the principles.
  4. Iteratively improve the specification.

Specification development works by an open process and by rough consensus. Participation is open and free to all.

Specification

Jump to a section below or start at the beginning.

  1. Scope
  2. Conformance
  3. Use cases & requirements
  4. Standard reuse
  5. Classes and properties

    1. Person: Name Component
    2. Organization
    3. Membership
    4. Post
    5. Contact Detail
  6. Serialization

    1. JSON schema and examples
    2. Metadata serialization
    3. Embedded JSON documents
    4. JSON subschema
  7. Change history

Appendices

  1. Example Popolo JSON documents
  2. Multilingualization
  3. Handling duplicates
  4. Survey of existing specifications
  5. Inventory of terms from the survey
  6. Data model patterns (semantics, succintness, edge cases)
  7. JSON serialization patterns (embedding, simplicity)
  8. Best practices for software components (document identifiers, database isolation)

Participation

Participation is free and open to anyone. These documents are Working Drafts. Their governance roughly follows the W3C process.

Questions? Contact james@opennorth.ca.

Implementation