Technology
From BudgetWiki
|
Technologies to Tame the Budget
The information that defines our society has reached an unmanageable level of complexity. Imagine searching today’s Internet with tools from the 1970’s: a professional could do it but anyone else would be lost. In the same way that Web browsers opened the Internet to everyone, the appropriate tools could give everyone the ability to understand, and contribute to, the government process.
These tools are outlined here. The first target for this toolset will be the US Federal Budget.
Data
The data we need exists in the public domain: The federal budget, lists of relevant committees and committee members and information about lobbyists and donations. To use this data we will import it out of its current, bulky, formats, break it into discrete pieces or “fragments”, and store these in our database. These information fragments provide the starting point and a framework for community-generated content, which can then be used to guide policy.
- The database’s content and schema will be managed under version control, giving us the safety to change the database and to roll-back to previous versions as needed.
- The database will be media aware, allowing users to embed audio, video, and other forms of documentation.
- The schema, and a public database API, will be documented and disseminated to encourage other organizations and developers to use our database as their platform.
- All information in the database -- the fragments, commentary, associations between entries, and user identities -- can be tagged and rated along multiple dimensions by the community.
Identity
Like other online information systems, our tools will have a login interface and provide social networking features. Unlike other systems, our identities allow hierarchical associations, such as when a corporation recognizes a subset of individuals as representatives of its official voice.
- You can aggregate your federation of identities from compatible social networks, providing a common login.
- An identity can have multiple aliases, such as when a person is speaking for an organization versus with their personal opinion, as an expert in a field, or anonymously.
- Aliases share in the reputation of your core identity, giving even anonymous commentary accountability and authority.
Reputation
Everything created with our toolset is linked to an identity. Users can tag and rate content, and this in turn reflects on the content's originating identity, creating a formal, numerical “reputation”. Your reputation is valuable; it reflects how people see you in the system, and it adds weight and context to the everything you create.
- Accountability borne from a persistent reputation gives an incentive to be thoughtful in your contributions.
- Reputation rubs off; the reputation of the members of a group define the reputation of the group. People will judge you by your reputation and the reputation of the friends you keep.
Display and Navigation
The database will initially have a simple user interface to import data fragments, display them, create links between fragments, and add commentary. This interface may be similar to a Wiki or other hyper-linked content system. Specialized graphical interfaces will then provide more intuitive access for different [link: ./usecase.html] use cases.
- Association viewer/editor will illustrate the web of associations around a fragment.
- Comment manager will filter, rank, and organize comments into meaningful views.
- Consensus interface will lock a fragment for closed-group access until voting indicates it is ready for public use.
- Tagging and rating tools mark and filter content, commentary, associations, and users along multiple dimensions.
- Searching and filtering tools highlight, hide, and group fragments along a wide range of attributes.
- Revision viewers illustrate changes in content over time.
- Search tools for internal fragments and relevant external databases will find and import information.
- Calendar event-triggers coordinate group activities.
- “Watch” tools and RSS feeds notify users when relevant content changes.
Usability and Usefulness
Considering the tools outlined in the [link: ./technology.html]“Technologies to Tame the Budget” white-paper, and being defined in more detail on the budgetwiki.com website, several questions leap to mind.
Can they be built? Will these tools be useful? Why would anyone want to use them?
First the easy answer: yes, they can be built, and without needing to find software super-geniuses. All of the technologies in these tools, all of the user interfaces and visualization capabilities they will implement, have been done before. The “new” aspect of this project is in how these features and technologies are assembled and applied, not in the features themselves.
Will these tools be useful? Absolutely. Every problem space, every type of data, has a method of interaction that is natural for it. Using the right tool for a problem makes it easy, and using the wrong tool makes it hard. We are creating the right tools for this problem space, to highlight aspects of this data that we believe are important. As part of our solution, we are creating a platform that other organizations can use to highlight the aspects that they think are important.
Will people use these tools? We think so...
Open Philosophy
Our toolset is being created with open-source principles so that not only the US Federal Budget data is being opened up to the world, but the tools themselves will be released to everyone. Any organization would be free to modify and adjust these tools for their own special needs and to apply them to their own particular interests.
Community Access
Software tools already exist to organize and manage the Federal Budget and legislation information, though they may do this less elegantly than what we propose. Some organizations pay a lot of money for access to these tools. Our tools will give these same capabilities, and more, to small organizations, to individuals, to everyone. We are giving power to the broader community.
Connections
As individuals use our tools to research and comment on the Budget, they will find other people with similar interests, and they will start working together. As existing organizations use these tools, they will find they have common ground with other organizations. The very act of using these tools will highlight the connections and common interests between people and organizations; communities will form and grow, and these communities will amplify the efforts of their members.
Identity Consolidation
People have identities on many systems these days, whether it is a simple login or an intricate node in a social network. By using our tools, they can begin to consolidate their federation of existing identities and friends, providing easier access to, and a consolidated view of, their presence in the online world.
Reputation
The reputation that people accumulate based on their actions on this system, and imported from their identities on other systems, gives them an incentive to be active and to be mindful of how their activity affects their reputation. This reputation has visibility in a large, and socially meaningful, community and this in turn gives them reason to treat it with care.
As a footnote, during the development of these white-papers, there were times when this toolset could have been used. For example, the petition could have been managed under the consensus interface, and the commentary system will in fact be used to manage user feedback about the tools, once developed. We are writing these tools, in part, because we want to use them ourselves. The only surprising thing is that someone hasn’t created them already. Someone has to be first, and it seems that this “someone” could be us.
Current Projects
Our software is being built through contributions from our strong volunteer community. Here are some of our current projects. For more information, or if you are interested in contributing your time and effort, please join our Mailing List or contact Silona.
Entity-based Social Network
A social network that is based on "entities" rather than individuals. A node in the network might be an individual, a business, or some other organization. In the LoTV context, the social network will facilitate communication and collaboration in our target community and our hierarchical entity-based representation within the social network allows non-profit and advocacy groups to participate as visible, named entities.
Connect-the-Dots ("CtD") legislation browsing tool
CtD is a visual user interface that is used to easily browse the connections between pending legislation, sponsoring legislators, budgetary contributions, earmarks, and so forth. CtD is designed to clearly and intelligently display any information about the meaning of these connections. This meaning will be assigned by the community, using our tools which are designed from the ground up for this purpose.
Consensus wiki ("C-wiki")
C-wiki is a wiki [1] with integrated tools to enable defined groups to build a consensus on its contents. This tool is useful for drafting formal whitepapers that reflect the combined opinion of a group of authors. In the LoTV context, this is an important format to influence legislators.
Event Calendar
The LoTV Event Calendar is an hCalendar compliant event calendar to facilitate event planning and other means of collaboration among users of the LoTV community. This calendar should accept hCalendar RSS feeds as a form of automated input and/or output. Ideally, visitors should also be able to subscribe to receive an email digest of the day's posts in the categories of their choice.
Draft Specifications
Design Principles
0. The goal of the Transparent Federal Budget Project is to create a "transparent document" which supplements the federal budget document with information about its authorship and the process of its evolution.
1. One of the attributes of a transparent document is that the history of the document and the history of the evolution of the document is accurately and permanently recorded and cannot be changed. For this reason the technical infrastructure of the Transparent Federal Budget Project must have two characteristics:
1a. All actions performed in the system must be attributed to an identified person,
and this attribution must be persistent
1b. No element of a transparent document may ever be deleted; that is, once an element is created,
it may be revised or deprecated, but the original element remains and is unchanged
2. The primary security threats to a transparent document are:
2a. Impersonation: one person impersonates another person and updates the document, creating false information.
2b. Loss of integrity: the information in a transparent document is changed without an accurate record being kept
of what change was made and what the state preceding the change was
2c. Loss of availability: the system housing the transparent document is flooded with malicious change requests,
leading to exhaustion of network bandwidth, system capacity, or storage capacity.
3. Because a transparent document requires a complete history of document versions, the technical system supporting transparent documents must make provisions for storing underlying source documents by value (that is, by copying their text into the transparent document repository) as well as by reference, if there is reason to believe that the systems housing the underlying source documents cannot be relied upon to maintain accurate copies of all versions of the underlying documents for the required retention period.
System Architecture
The Transparent Federal Budget is a new kind of thing called a TransparentDocument object.
TransparentDocument objects live in a new kind of system called TransparentDocumentRepository.
People view TransparentDocument objects using a new kind of user interface called a TransparentDocumentViewer. (The "Connect the Dots" tool is one TransparentDocumentViewer; there will probably be others.) TransparentDocumentViewers can view the contents of multiple TransparentDocumentRepositories.
People create TransparentDocument objects manually using a TransparentDocumentEditor, or automatically by parsing and importing structured (but non-transparent) documents using a TransparentDocumentBulkLoader. These tools create TransparentDocument objects by calling the interface of a TransparentDocumentRepository.
The architecture of the Transparent Federal Budget Project is illustrated in this figure.
The specification set for the technical infrastructure of the Transparent Federal Budget project therefore includes at least the following items:
1. Schema for the TransparentDocument object. 2. Interface specification for the TransparentDocumentRepository. 3. User Interface specification for at least one TransparentDocumentViewer. 4. User Interface specification for at least one TransparentDocumentEditor. 5. Interface and parser specifications for at least one TransparentDocumentBulkEditor.
Draft TransparentDocument Object Schema Specification
TransparentDocument ::= collection of TransparentDocumentElement
TransparentDocumentElement ::= TransparentDocumentDatum | TransparentDocumentPerson | TransparentDocumentOrganization | TransparentDocumentRelationship | TransparentDocumentAction
TransparentDocumentDatum ::= < Source, Citation, Parent, DatumType, ReferenceSpace, Reference, Version, PublicationDate, Content, Children >
Source ::= pointer to the Person object representing the person who added this item to the TransparentDocument
Citation ::= URI of the item in an external repository
Parent ::= pointer to TransparentDocumentDatum object which contains this item (i.e. if this is a section, Parent would point to the chapter within which the section appears)
DatumType ::= document | chapter | section | subsection | volume | page (probably need more here)
ReferenceSpace ::= USGPO | Westlaw | CFR (definitely need more here; defines the space from which the Reference element's value is drawn)
Reference ::= the information necessary to locate the item in the external repository to which Citation points
Version ::= the version number of the item
PublicationDate ::= the date and time at which the item was published (that is, published in the external repository, not the date it was added to the TransparentDocument) NOTE: This should be zulu time, or at a minimum include information about time source and time zone
Content ::= the text or other content of the item copied from the external repository (if it's not clear that the external repository will preserve it)
Children ::= list of pointers to TransparentDocumentDatum objects which contain sub-elements of this datum (e.g. if this is a section, Children might be a list of subsections)
TransparentDocumentPerson ::= < Source, Citation, name >
TransparentDocumentOrganization ::= < Source, Citation, name, OrganizationType >
OrganizationType ::= corporation | LLP | 501c3nonprofit | NGOnonprofit | governmentagency
(definitely need more here)
TransparentDocumentRelationship ::= < Source, Citation, RelationshipType, RelationshipParties, RelationshipDuration >
RelationshipType ::= description of the type of the relationship (e.g. "employment", "financial", "partnership", etc...)
RelationshipParties ::= list of RelationshipParty
RelationshipParty ::= PartyType, PartyReference
PartyType ::= description of what role the party plays in the relationship
(e.g. in an "employment" relationship, a corporation might have a PartyType of "employer"
and a person might have a PartyType of "employee")
PartyReference ::= pointer to TransparentDocumentPerson | pointer to TransparentDocumentOrganization
RelationshipDuration ::= < start-date, end-date > - NOTE 1: These should be zulu time, or at a minimum include information about time source and time zone - NOTE 2: Either field could be "UNKNOWN"; end-date could also be "PRESENT" for ongoing relationships
TransparentDocumentAction ::= < Source, Citation, ActionName, ActionSubject, ActionObject, ActionDate >
ActionName ::= description of the action which took place (e.g. "made campaign contribution", "amended paragraph", "voted YEA", "voted NAY", "joined organization's board", "fired employee", etc...)
ActionSubject ::= pointer to TransparentDocumentPerson | pointer to TransparentDocumentOrganization
ActionObject ::= pointer to TransparentDocumentDatum | pointer to TransparentDocumentPerson | pointer to TransparentDocumentOrganization
ActionDate ::= the date and time the action happened - NOTE 1: These should be zulu time, or at a minimum include information about time source and time zone - NOTE 2: The time could be "UNKNOWN" - NOTE 3: This is the time the action happened, NOT the time it was entered into the TransparentDocument
Draft TransparentDocumentRepository Interface Specifcation
Clients calling the TransparentDocumentRepository interface may be in one of three states: Unidentified, Identified, and Authenticated. The client state machine for callers of the TransparentDocumentRepository interface is illustrated by this figure.
Enrollment
account : Register_Person (name)
creates a new TransparentDocumentPerson object representing the provided name, and creates an account for that person
Session Management and Authentication
session : Start_Session (account)
conducts an authentication dialog with a user; creates a session for the user if authentication succeeds
status : End_Session (session)
ends a session
Creating and Adding Objects to TransparentDocuments
TransparentDocument : New_Transparent_Document (session)
creates a new TransparentDocument; the Source field fo the new object will be the account identified in the session
status : Add (session, *transparent_document, *object, citation)
creates a new object using the data referenced by "object" and adds it to the specified TransparentDocument; the Source field of the new object will be the account identified in the session and the Citation field of the new object will be populated using the contents of the supplied "citation" parameter. "object" can be a pointer to an instance of any element of the TransparentDocument schema except TransparentDocument. Note that creating a TransparentDocumentPerson object using Add does not have the same effect as Register_Person; a person for whom an object is created using Add does not have an account. The structure to which "object" points must contain the data to be added to the TransparentDocument.
Viewing Documents
transparent_document_object_list : Get (session, *TransparentDocument, object-type, filter)
returns a pointer to a list of objects of the specified type in the specified TransparentDocument which match the specified filter. "object-type" may be any element of the TransparentDocument schema except TransparentDocument.
I leave both the syntax and the implementation of "filter" unspecified as future work; we'll want to have discussions about exactly how this should be done, but the basic idea is that it should be possible to Get "all the people who voted yes on the amendment to change paragraph 3.7.a.ii on 12th February 2009", or "all the organizations who contributed to Senator Fogg's campaign" and so on.
