Opening an architecture

Martin Häcker mhaecker at schwarz-online.org
Sun Nov 22 16:16:16 EST 2009


Hi Michael,

> 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.

There is already work starting on this - even though it is still in it's infancy, for some early notes, see here: <http://wiki.piratenpartei.de/Benutzer:Pudo/Liquid_Democracy_-_OpenID_Extensions>

> 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.

For the liqd.de aproach we have always considered this not doable yet and have fallen back to just using Folksonnomies <http://en.wikipedia.org/wiki/Folksonomy> to create this categorisationing.

I do like your ideas to help this process by datamining. (We haven't really started tinking about this yet)

> 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.)

I'd like to stay away from automatic voting for quite some time to come as this opens up a can of worms I'm not sure we are ready to handle yet. Making it propose interesting polls is a really neat idea though, and being able to run it on your own machine would be extra sweet (you control the environment it runs in)

Nice work!

Regards,
Martin





More information about the Votorola mailing list