Friedrich - I agree with the logic, and the pragmatics with what you say below from a theoretical perspective. However, for I'd suggest that this may be entirely missing the argument I am trying to make with regard to why (accepting what you say below), it is still worth exploring some common technical ground between implementations. The suggestion I make is for a very different purpose. I am not being as ambitious as to try to map results I just want to be able to display each LD's different results given the same rough base community / data) - rather I would actively encourage each LD system to come up with different results in order to create the choice and diversity upon which we can build a rich set of LD decision making tools. Some will be better for certain circumstances some others. What I am arguing for is a practical form of integration between systems which maps to the human issue of getting users to use a system. For that there is still common ground that all LD implementations can benefit from, and that common ground can be more than simply using open ID so that users can more easily move from one web application to another. We also need users enough users, debating an appropriate issue in which LD makes sense. I've seen the following happen a number of times now: <ul><li>a LD software project inspires a number of developers</li><li> A small group, collects around each implementation</li><li>Discussion is mainly around theory and implementation</li><li>Interface and users lag behind</li><li>Small groups of users do not benefit from LD and revert back to simple non-delegated systems</li> <li>The various LD implementations do not gain traction </li></ul>To counter this I am proposing, that we look to come together to market the concept of LD together. We look to fund raise for trials together where possible, while allowing each implementation to go for its own funding and community projects, and we look to provide a forum where we can collect rich test data (live and archived), and allow a wider audience to compare different LD implementations. Finally I'd argue for a common import export format that minimizes the trauma of moving between one implementation and another, and maximizes our ability to run a practical trial in which several implementations take part. With regard to the aspiration that each LD implementation can inter-operate in some way with regard to actual decision making - vote mirroring or other - I'd suggest that something on those lines may emerge later down the road given, successful cooperation between LD implementations along the lines I am suggesting. I would suggest that that may be more likely by mirroring the results of a group represented by members of a particular implementation, rather than each individual, and mirroring those - but I'd agree with Friedrich to put such speculation off for a while, and see if there were a more practical basis for cooperation which concentrated on the real world problem of not having users and resources to do a big enough test project. <div class="gmail_quote">2009/12/6 Friedrich Lindenberg <<a href="mailto:friedrich@pudo.org">friedrich@pudo.org</a>> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, I like all the talk about push v. pull and how we can create a large platform, but I still fear that from a very practical standpoint, we're going down a wrong turn here. It comes down to this point: <div class="im"> > Martin Häcker wrote: >> ... But in the end, each voter casts one vote for one issue. (Does >> this leave preference based voting methods out?) > > Maybe we can get away with vote translations like the following: > > * From ranked to single (R->S), the autocaster takes the top-ranked > R as the single choice S > > * From single to ranked (S->R), it marks the single choice S as the > only choice on ranked ballot R </div>First, you'll have to realize that this is really different data, using different levels of measurement and different semantics. It's not like twitter and Facebook, where both have activity streams and thus you can make some kind of bridge. The answers you get are actively dependent on the type of voting system used in the application. Voting for or against something is subject to strategic considerations and there is no perfect system to circumvent that. There is near certainty that if you piped all the data from system A to system B without adding any votes in B, both systems would come up with completely different results (For this to happen you don't even need to do mapping between preference and majority voting, all you need is to map between two methods of counting either). If you do any kind of mapping here, you'll start to actively construe voter decisions. YOU CANNOT DO THAT. Asking the voter one question and then using that data to answer a completely different question is essentially fraud. I've sat in a lot of lectures on media market research, a pseudo-science aimed at selling ad space to potential advertisers. Even they wouldn't get away with this kind of data mangling. Any LD implementation that is intended to retain some kind of respect both on a theoretic and a practical level should actively try to keep this from happening, down to the level of shutting down API access. So: voter mapping: sure, proposal mapping: yes, graph mapping: maybe, but mapping between voting systems which differ even in the slightest way: do not do that. NEVER. No amount of XMPP will fix that. Let's rather think about how we can link debates, link arguments, link users, and maybe even build little questionnaires incorporating the different polls open on an individual issue. Sorry about the rant, but this point is crucial and it needs to be generally accepted. <div class="im"> Cheers, Friedrich -- Friedrich Lindenberg <<a href="mailto:friedrich@pudo.org">friedrich@pudo.org</a>> -- </div><div><div></div><div class="h5">You received this message because you are subscribed to the Google Groups "Votorola" group. To post to this group, send email to <a href="mailto:votorola@googlegroups.com">votorola@googlegroups.com</a>. To unsubscribe from this group, send email to <a href="mailto:votorola%2Bunsubscribe@googlegroups.com">votorola+unsubscribe@googlegroups.com</a>. For more options, visit this group at <a href="http://groups.google.com/group/votorola?hl=en-GB" target="_blank">http://groups.google.com/group/votorola?hl=en-GB</a>. </div></div></blockquote></div>