Mapping

[David Bovill]

Hey thanks for that - very useful. I'm going to continue playing naive and
dumb - essentially because I am, and also it helps me catch up faster :)

Lets start somewhere really dumb and see how far we can get? Also i'm going
to take a different view on this - I'm not going to be talking formally
about data structures - I'm just going to be thinking lazily and graphically
with regard to what someone wanting to create a mashup site (say a site
which integrates / offers different LD sites), might be like. So what would
an LD mashup site want / need exposed to it?

Seems to me all systems have in common:

   1. People
   2. Proposals
   3. Delegations
   4. A (singular) result based on votes by people on proposals taking into
   account delegations

All systems have those. And as I think it makes no sense at this stage to
try and establish any universal way of mapping all the twiddly bits within a
system - based on the lovely "carrier airplane" argument, lets keep it as
simple as possible.

So what would this "result" look like? I'd suggest some sort of graph with
appropriate minimal markup sufficient for reconstruction of a basic picture
of an LD vote by any system, which any system could then perhaps re-run to
enhance add features only it's community provides, but which has now a
starting point in terms of basic data and relationships which mean that
rerunning a vote using a different system is not as painful as manually
importing all the data. The aim here would be in part the ability to take a
large LD discussion and vote, and allow different systems to test-out how
this would run in practice using their implementation, easily comparing them
with other implementations. I'd certainly like that sort of test-data if I
were to delve back into implementing an LD system!

Maybe the result would look something like:

   1. Nodes - have types
      - People (mapped to an Open ID URI)
      - Proposals (mapped to some sort of basic URI which you can at least
      view / embed, or do some very basic import with?)
   2. Arcs - have types
      1. Person Delegation (default)
      2. Extensible Other ie Vote?
      3. A result is a graph marked up in some standard way, made up of arcs
   and nodes, with numeric values associated with the above in some clever
   generic way that hasn't been thought through.

In other words:

2009/12/4 Friedrich Lindenberg <friedrich at pudo.org>

>
> - Proposals are either subject to a Discussion based on formalized
> suggestions (LF), comments (A) or different versions of the same text
> (V). In A & LF, any user can propose many Proposals, while in V a user
> can only have one Proposal per topic (afaik).
>
> - Negotiation happens either as an open primary voting process (LF) or
> via a discussion based on a difference engine (V) or via group
> membership (DP).
>
> - Discussion is either considered part of a future component (V), the
> core system (A) or to be outside of the scope of the project (LF).
>

We don't care how proposals are discussed (we just allow each implementation
to do it their own way and give them an option to provide a URL that
provides a view of the entire discussion). Nor do we care about negotiation
at this stage - again we can "view" this from the optionally provided
proposal (embed) url.


> - Delegations can either be given to a user regarding a certain scope.
> In A & LF these include issues and the categories (areas, LF) that
> issues are stored in. In V & A users can delegate on specific
> Proposals (in V delegation is for the proposal AS the user's position,
> in A delegation is for the users's position REGARDING the proposal).
>

I think we will need some sort of abstract "Group" with extensible subtypes.
These can provide the scope I think?

- Delegations are used either in Voting (LF, A, DP) or Negotiation
> (LF, V, DP?).
>

We don't care and leave that up to implementations.


> - Voting takes place either using preference ranking (LF) or majority
> voting (A). LF uses terminated, partially secret voting while A uses
> continuous and public voting.
>

Not sure. Either we don't care and this is returned in the marked up graph,
or we want to import enough data to an implementation in order to at least
re-construct the result if not the discussion, in which case we want some
vote-type markup added? If we did not have the latter we can still have
automatic vote-mirroring I think if each implementation is required to be
able to construct some sort of sensible result automatically from the data
using appropriate defaults it defines internally?

Also I'm pretty sure we'd need to define "votes" in some clearer way than a
type of arc.

- Authorization regarding Proposal editing is either based on group
> membership (LF) or a meritocratic authorization mechanism (A) or it is
> fully open (V). DP seems to do this based on open, but mutually
> exclusive groups.
>
> - Proposals are subject either to a timed process (LF, DP),
> spontaneous state changes (A) or an un-timed development process (V).
>

Up to the implementation.

Now I am quite sure all of the above can be torn to shreds :) But I'm also
fairly sure that something along the aims of the above would be useful to
all. Users could move from one system to another using openID, they could
visit a central site (I'm offering the liquiddemocracy domains - where they
can go shopping for an implementation, compare, comment on, make
recommendations for systems based on viewing the quality of deliberation and
decision making of an implementation given the same data - comparing like
for like.

Where I am coming from with this is to provide a marketing platform for LD
implementations, and yes maybe make some baby steps towards interoperation
of systems - but not really focusing on that. The aim is to advocate the
fact that there are many shapes and forms democracy can take, not just
parliamentary, and to make parliamentary democracy look like the rigid and
very limited-to-purpose beast that it is. Encouraging new LD implementations
and presenting them graphically, visually in the context of a thriving
collaborative ecosystem of democracy experiments. For this more minimal and
dare I say practical vision of cooperation between LD implementations, we'd
need a few things I think in place:

   1. Individual voters must be able to move from one system to another
   easily - using a single id (easy).
   2. No lock in. Communities using an LD implementation need to be able to
   move relatively easily to another competing system, retaining the record of
   past activity needed to avoid reentering duplicate info (hard).
   3. No threat of the centre. The common marketing platform should be at
   the service of all LD implementations / wider community, be owned by them
   and not compete with them, and this should be legally enshrined in a robust
   guarantee. (sorted).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20091204/b2eb6be0/attachment-0007.html>