Opening an architecture

Sun Nov 22 12:18:07 EST 2009

I'm floating this as a kind of architectural "kite", just for
discussion.  I scraped together some rough sketches of 4 frameworks,
with non-technical commentary for each.  The frameworks are:

  1. Registration
  2. Differencing
  3. Classification
  4. Autocasting

This follows on Martin's recent posts about competition etc., and
talks with Thomas on the same topic.  It's all too rough to stand as a
technical proposal, so there's maybe no point in going into a lot of
detail, yet.  But it raises some broad questions, going forward:

  *  Did I miss any obvious frameworks?

  *  What's the roadmap for something like this?  Does anyone have
     experience with large-scale architectures, standards processes,
     and so forth?

  *  What big problems (tech and non-tech) are likely?

  *  Did I fail to credit anyone for ideas?  Is this being discussed
     anywhere else?

See also:

  5. Glossary
  6. Notes, references and credits

http://t.zelea.com/wiki/User:Mike-ZeleaCom/Opening_an_architecture
======================================================================

An architecture for e-democracy is "open" in as far as it provides its
users with freedom of choice, not only in political decisions, but
also in the tools that enable those decisions.  Openness hinges on a
number of technical and legal conditions (see glossary below), but
perhaps the most important criterion is technical inclusiveness.  The
frameworks of the architecture must be open to the widest possible
range of tool designs, from all suppliers.  This aspect of openness is
explicated in the framework sketches below.^[1]

1. Registration framework
-------------------------

A registration framework is for identifying users and authenticating
them as voters.  The framework below is already partly designed and
implemented, as a pre-alpha prototype.^[2]

    http://zelea.com/project/edo/registration-network.png

What the sketch above says is that different locales (X Region, Y
City, and so forth) are responsible for maintaining their own voter
registers.  They can also choose their own software for this purpose,
from any supplier.  Each supplier's "local voter register" component
is plug compatible with those of other suppliers, so they all work
together in a coordinated fashion.  Coordination is necessary so that
voters can register at the local level, and be authenticated just
once, yet vote in all polls (local, federal, and so forth).

    http://zelea.com/project/edo/registration-framework.png

Not only the voter registers are plug compatible, but also the voting
engines.  (That's what the diagram above says.)  So X Region might be
using a Liquid Feedback engine, while Y City is using a Votorola
engine and Z City is using both - some polls being voted in one
engine, some in the other.  Eventually the voters might settle on a
single engine for general use.  In any case, they will always have the
choice of trying out new engines, whenever they appear.

2. Differencing framework
-------------------------

A differencing framework is a support for deliberative democracy.  It
puts a little backbone into deliberative forums (mailing lists, Web
forums, chat networks, and so forth) by grounding the discussions in
concrete *position differences*.  A position difference is simply a
textual difference between two proposals.  Participants may use the
tools of the framework to reference a specific difference from within
the stream of an on-going discussion - anchoring it at points - so
that people have a clear understanding of what is being discussed.
The framework also links multiple discussions of the same difference
across forums, and provides additional tools for visualizing
differences, and resolving them by text merger.

    http://zelea.com/project/de/framework.png

This framework is currently under design ^[3].  What the sketch above
says, basically, is that no matter what voting engine is available to
the voter, and no matter what drafting medium, discussion medium or
differencing engine she chooses to use, the same, basic differencing
functions will be available.  So the voters are free to choose the
tools.

3. Classification framework
---------------------------

A classification framework is for categorizing polls and positions,
and creating navigable views.  The diagram below is a paper-napkin
sketch, with no real design behind it.  We can at least forsee that
classification is likely to require data input from most of the core
components, as well as the voters.

    http://zelea.com/project/edo/classification.png

Based on data from all these sources, a typical classification engine
would provide one or more specialized voter services.  One possible
service is a navigable view.  The navigable view shown below, for
example, maps the current structure of a poll by labeling it with
political interests.  A new voter could use this view to locate a
suitable point of entry in the pollspace - the position that is
closest to her own interests - where she could place an initial vote,
proceed to participate in discussion, and so forth.^[4]

    http://zelea.com/project/edo/classification-browse.png

4. Autocasting framework
------------------------

An autocasting framework is a convenience for voters who are unable to
spend much time in direct participation, but nevertheless wish to
vote.  The central component (autocaster) is a personalized voting
agent.  You (as a voter) choose a particular autocaster from among the
competing designs, and then set it to work.  It analyzes your past
voting behaviour with the help of classification engines, and based on
this it creates a working profile of your interests.  It then locates
matching candidate positions in various polls and recommends them to
you.  If you allow, it will go even further, taking your place at the
polls by casting and recasting votes on your behalf.  (You might still
override it, of course, in particular polls.)^[5]

    http://zelea.com/project/edo/autocasting.png

The diagram [above] is only a paper-napkin sketch.  No autocasting
framework has actually been designed.  Whether or not it would be a
good idea is still an open question.  But if the voters wanted it,
there is probably no way for the architects to disallow it.  Anyone
can add a new framework or component to an open architecture.

5. Glossary
-----------

architecture

  The top-level design of a system.  A collection of frameworks.

component

  A whole facility such as a voting engine (Adhocracy, Liquid
  Feedback, Votorola, etc.), or a drafting medium (MediaWiki,
  MixedInk, etc.), or a discussion medium (mailing list, Web forum,
  etc.).

framework

  A written standard that says how various components work together in
  order to provide a coordinated function.  So there is a framework
  for the function of voter registration, coordinating local
  authentication and global voting; another framework for position
  differencing, linking discussions of the same differences across
  multiple forums; and so forth.

open architecture

  An architecture that provides its users with the widest possible
  range of tool choices.  A collection of frameworks that is 1)
  public; 2) free of intellectual property exclusions; 3) extensible;
  and 4) compatible with the widest range of actual component designs,
  from all suppliers.

6. Notes, references and credits
--------------------------------

[1] Many of the suppliers who compete in e-democracy are open
    projects, staffed by people who volunteer their time without pay.
    This is perhaps another reason to strive for inclusive frameworks.
    On an individual basis, the costs of exclusion from a closed or
    arbitrarily restrictive framework can be high.

[2] The sketch of the registration framework is based on a
    rationalization of Votorola's current design.  The voting engines
    and voter registers are factored out as separate components, and
    the registers are divided into two distinct types (local and
    super).

[3] The sketch of the differencing framework is from
    http://t.zelea.com/wiki/User:Mike-ZeleaCom/p/de.  Thomas von der
    Elbe contributed to the initial discovery, and Martin Häcker to
    the early design.

[4] The mapping of pollspaces by interest was proposed by Thomas von
    der Elbe (personal discussions, October 2009).  See also his
    contributions in:
    http://wiki.piratenpartei.de/Liquid_Democracy/Votorola/Theorie

[5] The sketch of the autocasting framework came out of personal
    discussions with Thomas von der Elbe in the summer and fall of
    2009, and von der Elbe and Friedrich Lindenberg in October 2009.
    The idea of the autocaster learning from voting behaviour was
    related by Lindenberg.

-- 
Michael Allan

Toronto, 647-436-4521
Skype michael_c_allan
http://zelea.com/