Meta-Tool

[Michael Allan]

David Bovill wrote:
> 1. You are proposing mirror-mapping delegations and votes, but
> accepting that different implementations would reach different
> results?

For me, the answer depends on what perpective I take.  (Sorry for the
long reply on this point, I'm trying to offer a wide target for others
to critique.)  It depends on whether I look:

  a) Objectively at a single vote
  b) Subjectively *as* a voter
  c) Objectively at the collective results

(a) Looking objectively at a single vote, I would answer "yes" it can
generally be accepted.  For example, translating an IRV vote (C) to a
single-transitive vote (B) will usually give a different result.  The
situation is analogous to the translation of a book.  We understand
that the translated result is always somewhat different than the
original author's intent.  Nevertheless, we recognize that making
texts available to readers in other languages is a useful thing.  The
translation therefore has utility.  For a similar reason, we might
accept the imprecision of a translated vote.

(b) Utility is also something the voter sees.  From this perspective,
however, the voter will probably answer "no"; but the meaning of this
answer is logically reversed.  She will *not* accept that two engines
(for example) should reach different interpretations of her vote, but
in the enlarged scope of this perspective - covering two engines and a
whole society - this is an argument for vote mirroring.  To illustrate
the argument, here are two engines side by side, as a voter might see
them.  This is from:
http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring#IRV_to_single_transitive

  (b-1) Before mirroring 
  ------------------------------------------
  engine: C     |  engine: B
  method: IRV   |  method: single transitive
  ------------------------------------------
  (G)-->(S,T)   |  (G)-->nil

In engine C, the voter (G) is casting for S and (second choice) T.  In
B, she is abstaining.  These are obviously very dissimilar votes.

  (b-2) After mirroring 
  ------------------------------------------
  (G)-->(S,T)   |  (G)-->(S)

The situation after mirroring is less dissimilar.  It is still
imperfect, but it better reflects the intention of G.  This is useful
to G, because it means that her vote is now correctly seen by the
users on engine B.  Those users will understand that G too is a voter,
and has a view to express.  For this reason, G will probably accept
mirroring.  By the same token, I think she will reject the unmirrored
situation (if given a choice).

(c) The single voter's view can be expanded to a collective view.
>From this view, the answer is probably the same.  Differences are not
acceptable, and mirroring is the best way to reduce them.

  (c-1) Before mirroring 
  ------------------------------------------
  engine: C         |  engine: B
  method: IRV       |  method: single transitive
  ------------------------------------------
  result: S=1, T=1  |  result: K=1, U=3


  (c-2) After mirroring 
  ------------------------------------------
  result: S=1, T=1  |  result: S=1, T=1, K=1, U=3

The mirrored results (c-2) combine the otherwise separate results of
both engines.  Voters and candidates of C that were formerly hidden
from view are now revealed on B.  Mirroring therefore reduces the
differences between the results of C and B, when viewed side by side.
If C were to mirror too (deploying a pull-autocaster of its own) then
the collective results would be even closer between the engines - as
close as technically feasible.

The argument is that mirroring is a device to more accurately reflect
the wider social reality.  I think this was on Thomas's mind when he
discovered this device.  We were talking at the time, and I recall he
was rejecting the notion that voters should be divided, and their
votes split.  He was looking for a way of bringing them together.)

> 2. May problems not happen if voters are present in both systems?
> Perhaps voting inconsistently in both systems?

Maybe the simplest rule is: "the later vote overrides the earlier".  A
new, real vote on B therefore overrides an older mirrored vote
(originally from C).  In the reverse direction, assuming C has also
deployed an autocaster, the new B vote is mirrored back to replace the
older real vote.  So I guess there's no conflict in this case.  The
user can move back and forth, with no ill effects. (?)  The
autocasters will faithfully pull the vote shifts across.

However, if C does not deploy an autocaster, then all B's votes will
be invisible to it, including those of C's own users who are
moonlightling on B.  In that case, C's results will be inaccurate.
(But if you accept the arguments of b and c, they will have been
grossly inaccurate to begin with.)

> 3. May a voter say H ... not object to the mapping, saying something
> like "Hell, if I knew I could delegate then I'd have opted not for
> T, but would have delegated to K!" - which would have changed the
> result?

H was voting -->(T,S).  She now wants to vote -->(K).

She just shifts her vote to K.  She can do this on B.  She can also do
it on C - provided C allows for an unrestricted choice of candidates
or (in a normative context) positions/proposals.  (Note it doesn't
matter for this purpose, whether or not C mirrors from B.)

This changes the result, but the change is a correction.  The earlier
result was wrong, because it didn't accurately reflect H's intent.
(Maybe better we say it didn't reflect her *interest*.  Interest can
be unknown at first, or only vaguely guessed.  It might then be
discovered along the way, or refined.)

> However, it looks promising enough for me to think that the import / export
> functions could be useful. So my last questions are:
> 
>    1. do you have a markup that you would propose using?

We have nothing that would make for a proper standard - not from
Votorola.  Our pollserver takes a snapshot of voter input every four
hours or so.  Here's the latest copied from the BGE poll, for example
(with email addresses obfuscated):

  http://zelea.com/var/tmp-public/

We could export these raw votes, without too much trouble.  (I bet
other engines could, too.)  I'm guessing this kind of thing would
eventually evolve into the "vote monitoring" interface, on which the
autocaster and other clients must depend.

>    2. how about a common vote graphing service?
> 
> I'd like to work on the vote graphing, as I've been interested in that area.
> It also seems like so far none of the implementations have visual mapping of
> the vote graphs? So what I'd propose is setting up a web service, which
> receives vote-graphs is some standard markup, and returns images, and later
> a range of interactive maps that can be embedded in LD implementations.

It sounds *more* than useful.  I imagine external, integrated views
(and controls) are going to be the UI of choice for most users.  They
could easily evolve into Thomas's meta-tool, with all sorts of fancy
features.

Votorola only has a rudimentary view of the votes, at the moment.
It's built into the pollserver Web UI.  We no longer think it belongs
there.  Ideally it would be factored out and expanded into something
more sophisticated, separate from the voting engine:

  http://t.zelea.com:8080/v/w/Pollspace/?u=Mike-ZeleaCom&p=BGE

Logically, I guess a voting engine is just a pool of votes and an
archive of counts - a database and a filebase - and not much else.
Deploying it in such a stripped down fashion doesn't preclude a local
binding with other components (UIs and so forth) to form an integrated
system on a single node (like most of us have now) but it does allow
for the possibility of a more open style of integration across the
net.  I supect the architecture wants to go in that direction.  On a
smaller scale, that's the direction that Votorola's been taking.
(Thomas's ideas have broken the design up even further, and given it
more scope to expand outward.)

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/