Interview: VIP + Open Civic Identifiers

Introductory comments

What is the data federation effort all about? What am I looking to get out of it? This is a collaborative research project with GSA's Office of Products & Platforms and 18F. The goal is to build a toolkit / playbook for undertaking intra-governmental data collection / aggregation projects, such as data.gov, code.gov, and NIEM. Or goal is to find out what works, what doesn't, and what tools are appropriate for what circumstances, in order to accelerate similar efforts in the future.
Notes & Report will be public
Any questions before we get started?

What is VIP / Open Civic Identifiers, in your own words?

VIP = it's a standard that allows states to report ballot / voting information, ties it to a street / address point, also information about election officials that can help them with civic questions. OCId's - schemas and tools for gathering information on government officials / political geographies. Different ways of expressing the same thing- how to link ontologies to geographies. Those identifiers used to build out the civic information API. Most commonly in use for geographies- districts, commission districts, anything where you might want to link voters to an office and a person who represents them.

What was impetus or driving force for this effort: policy, user needs, etc (perhaps after the first question)

VIP => 2008, effort between Pew and Google. Google said people are going online to find this and can't. 8 states + LA joined, now 48 states + DC. Last election 48 states publish . OCIds- google / sunlight labs / some others, realized that they all had data around identifiers but couldn't be joined. Little bit of a lull, now getting a new governance model.

Note- not just a linker, also ontological / standard names for things.

In building X, what were the biggest challenges, and what went smoothly?

VIP => biggest issue is that election offices say they already have it online, why implement VIP? Why do I need to work with you? Convey scale & partnerships. Ability to adjust specification to adopt to unique voting structure. As project evolved, able to more quickly give feedback to states. Some things run in to- "already busy as it is", spec is technical in nature, a bit of a workup to getting specification described and translated into terms they understand.

What tools and technologies do you use for these effort?

VIP -> csv / xml single file, single election, includes all relevant polling and ballot data. VIP hosts server, states submit it there, gets validated and packaged and sent to google and they include voting API. xsd accompanies spec, also web based tools summarizes data and fixes broken data links. custom for the project.

note: setup time for demo. OCIds - CSVs in a github repo. 3 different parts: details of spec itself, folks who work on it to validate, and data set itself.

Why did you choose this architecture or process. Were others tried, etc (after the "data aggregation/distribution" question)

it's evolved over time, dashboard wasn't around at the beginning of the project. Other ideas: allowing states to create flat file / csv which we would process into xml. Most work in getting it out of systems and into xml. Unique for each state- sometimes disparate systems, other cases it's in a central system.

What are the political and organizational dynamics of collecting this data?

some pushback: concerned about having data in 3rd party tools that they can't correct. Should be mechanism to approve / correct data, but not always clear to counties.

Who were the relevant stakeholders for this project, how were they identified and convened?

sunlight diaspora, put together a convening every year of ballot community, also working groups that meet quarterly. For VIPs- people providing data (states), people integrating / using API (campaigns, large tech companies).

Is there anyone else I should speak with to better understand X?

some folks, hopefully will get an introduction

18F / data-federation-project