It's time for me to do catch-up on show-and-tell of the various components of open source software that are available in software repositories currently located at:

(Note: we are in the process of some major reorganization of our repositories and not all of our work is currently available in github.  This is a policy of early stage design and development practices in the Core Team.  You are always welcome to contact us to get more information and in some cases access to source if you are interested in participating in development work and there is a good fit.)

While this is more beneficial to those following the Knight Foundation Funded VoteStream Project progress, it is also a nice vehicle to provide our quarterly update on software progress.

I start with an account of a handful of modules that we're developing as part of the VoteStream project, but which also serve the open data standards community. Thanks to Knight Foundation's grant for continuing VoteStream work, we've refactored and extended some of our previous work to support the new and recent U.S. national standards for election data interoperability. Our goal is to continue to be leader in offering reference implementations of all these standards, as they developed by the Voting System Standards Committee (VSSC, working under the auspices of the U.S. Election Assistance Commission), and promulgated by the U.S. standards body, NIST.

First up is the standard for election results reporting -- obviously essential to VoteStream. Our experience on the previous phase of VoteStream work enabled us to contribute to this standards effort, and we're pleased to have a reference implementation ready when NIST issues the standard (which is in the final review phase). Our reference implementation is structured in 3 parts, to meet the varying needs of different usage of the standard:

  1. A software package that consumes a data set in the standard data format, and creates an object space for the data set's data elements. Programmers can use this package to avoid re-implementing the parsing and the object model, and go straight to doing whatever usage of the data they are working on.
  2. A software package that builds on the first, by implementing a persistent storage layer of the data set's data object, in a database. Programmers can use to to avoid re-implementing data storage, and go straight to the task at hand, for example, developing a web application to explore the data in a public database of election results.
  3. A software package that builds on both, to encapsulate all of it in a RESTful web services API (application programming interface). The API enables completely separate applications to access the various elements of the data set, without being responsible for the source data, data storage, or the "business logic" of correctly creating, updating, and viewing the various data elements.

For project purposes, we call these packages VEDaSpace, VEDaStore, VEDapiService, respectively.  Although VEDa is a bit of a pun on the Hindu word for knowledge (including in scriptures), VED just stands for "VSSC Election Data."

We developed these so that VoteStream itself could advantage of the modularity of the software, but also so that others could re-use our technology for other purposes than what VoteStream does -- without having to rip apart the VoteStream source code to get at underlying modules.

Discerning readers and github explorers will also find a repo called VEDaPublisher, which is a key part of the VoteStream-2 architecture, and deserves a separate post. The same is true of modules for other data standards, which are in nascent form as VODaSpace and VITALspace to complement VEDaSpace.

But before get to these earlier stage efforts -- to say nothing of developments in VoteStream that use them -- next up for our quarterly update I'll provide a couple postings on repos of code that are already in production.