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 :)<br><br>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?<br>
<br>Seems to me all systems have in common:<br><ol><li>People</li><li>Proposals</li><li>Delegations</li><li>A (singular) result based on votes by people on proposals taking into account delegations<br></li></ol>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.<br>
<br>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!<br>
<br>Maybe the result would look something like:<br><ol><li>Nodes - have types</li><ul><li>People (mapped to an Open ID URI)<br></li><li>Proposals (mapped to some sort of basic URI which you can at least view / embed, or do some very basic import with?)</li>
</ul><li>Arcs - have types</li><ol><li>Person Delegation (default)<br></li><li>Extensible Other ie Vote?<br></li></ol><li>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.</li>
</ol>In other words:<br><br><div class="gmail_quote">2009/12/4 Friedrich Lindenberg <span dir="ltr"><<a href="mailto:friedrich@pudo.org">friedrich@pudo.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- Proposals are either subject to a Discussion based on formalized<br>
suggestions (LF), comments (A) or different versions of the same text<br>
(V). In A & LF, any user can propose many Proposals, while in V a user<br>
can only have one Proposal per topic (afaik).<br>
<br>
- Negotiation happens either as an open primary voting process (LF) or<br>
via a discussion based on a difference engine (V) or via group<br>
membership (DP).<br>
<br>
- Discussion is either considered part of a future component (V), the<br>
core system (A) or to be outside of the scope of the project (LF).<br></blockquote><div><br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

- Delegations can either be given to a user regarding a certain scope.<br>
In A & LF these include issues and the categories (areas, LF) that<br>
issues are stored in. In V & A users can delegate on specific<br>
Proposals (in V delegation is for the proposal AS the user's position,<br>
in A delegation is for the users's position REGARDING the proposal).<br></blockquote><div><br>I think we will need some sort of abstract "Group" with extensible subtypes. These can provide the scope I think? <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Delegations are used either in Voting (LF, A, DP) or Negotiation<br>
(LF, V, DP?).<br></blockquote><div><br>We don't care and leave that up to implementations. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

- Voting takes place either using preference ranking (LF) or majority<br>
voting (A). LF uses terminated, partially secret voting while A uses<br>
continuous and public voting.<br></blockquote><div><br>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?<br>
<br>Also I'm pretty sure we'd need to define "votes" in some clearer way than a type of arc.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

- Authorization regarding Proposal editing is either based on group<br>
membership (LF) or a meritocratic authorization mechanism (A) or it is<br>
fully open (V). DP seems to do this based on open, but mutually<br>
exclusive groups.<br>
<br>
- Proposals are subject either to a timed process (LF, DP),<br>
spontaneous state changes (A) or an un-timed development process (V).<br></blockquote><div><br>Up to the implementation.<br><br>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.<br>
<br>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:<br>
<ol><li>Individual voters must be able to move from one system to another easily - using a single id (easy).<br></li><li>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).</li>
<li>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).</li>
</ol></div></div>