Re: [Ag Meinungsfindungstool] [MG] (proposal) Metagov as a technical plug-in framework

[Thomas von der Elbe <ThomasvonderElbe AT gmx.de>]

Hi Mark,

lol, yes I agree, my example was to extreme.

Better would be: the Chinese and Americans translate between each other. 
The Germans and the Americans too and the Chinese and theGermans also.

So no "whisper effect", nothing hidden and no data loss and still 
everybody is spared from learning Esperanto.

But since forour tools these languages do not exist yet, you might very 
well be right and several initial different languages evolve and over 
time merge into an e-dem-Esperanto. Especially since new toolsjoining 
the networkprobably start to use one of the already existing languages. 
So yes, B would be a first step towards A. Cool!

Thomas




On Wed, 14 Nov 2012 18:53, marc wrote:
> Hi Thomas,
>
> Thank you for clarifying. Indeed I misunderstood what your tool switch 
> proposal is about.
>
> I did not recognize the communication between the tools.
> So it's even better than I thought before.
>
> Unfortunately in your (Thomas') example, there is a Chinese whispers 
> effect embedded that, if projected on the tools, is a big problem I 
> think. Information can easily get lost and is completly hidden from 
> the others. Esperanto would solve this problem, but indeed introduce 
> new ones, as you already mentioned.
>
> All in all I still think B is 'just' a step towards A.
> But that's a great starting-point, and I am very curious how it will 
> evolve.
>
> @Mike:
> > > What audience would you like to attract?
> > I would first ask you to clarify how A could benefit users (or anyone)
> > more than B. (But here too, I think it was just a miscommunication.)
>
> The benefit of A for users and content contributors is that there will 
> be no information and content loss any more.
> The data is just there and can be processed by any tool, not just by 
> the one the data was entered to.
>
> The drawback of B is that there is still data loss. If not, we have 
> reached A ;o)
>
> So from my side a full ack to go towards B - it seems to be on my path 
> towards A anyway ;o)
>
> Cheers
> marc
>
> -----Original Message----- From: Thomas von der Elbe
> Sent: Wednesday, November 14, 2012 11:27 AM
> To: Start/Metagov ; AG Meinungsfindungstool
> Subject: Re: [MG] (proposal) Metagov as a technical plug-in framework
>
> Hey guys,
>
> I too believe, you are misunderstanding each other.
>
> In the end, we all want all the tools to communicate with each other.
>
> We just differ in the ways to achieve that goal. Let me use an example:
> The Chinese, the Americans and the Germans want to find an agreement.
>
> Solution A: everybody has to learn Esperanto, otherwise he can not take
> part in the negotiations.
>
> Solution B: we findout one Chinese speaks English alreadyand oneAmerican
> speaks German. And that is actually already enough! We all can
> communicate with each other through them. Puhh! Lucky us, nobody needs
> to learn Esperanto! ;-)
>
> With B we can start right away. No need to wait until everybody agrees
> on the language to be used. Wesimply find two tools which are willing to
> communicate and they work out the easiest language for them (and here
> the work, i.e. definitions, models etc. of AG Meinungsfindungstool come
> into play and can be used).
>
> The proposed tool-switch for Metagov would be the conference room, where
> everybody is invited to comeand take a seat.Nobody will be forced to
> communicate, but I believe some will want to. :-)
>
>
> Greetings,
> Thomas
>
>
>
>
> On Wed, 14 Nov 2012 9:33, Michael Allan wrote:
> > Hi Marc,
> >
> > > > ... Either:
> > > >
> > > > A. All documents must implement the agreed meta-data standard.
> > > >     Non-compliant documents are eliminated.  So fragmentation is
> > > >     solved by your solution alone.  Or,
> > > they can not benefit from the possibilities cooperation would offer
> > > them.  So yes, if the tools wants to benefit, it needs to be able to
> > > migrate the data back and forth, but they will not neccessarily be
> > > eliminated ;o)
> > If not, then the outcome cannot be A.  I must clarify that A and B are
> > alternative outcomes, alternative futures in which the fragmentation
> > problem raised by Ronald has been solved.  If there still exist at
> > that time documents that are non-compliant with your solution (the
> > meta-data standard), then the problem could not have been solved by
> > that solution alone.  So the outcome must be B:
> >
> > > > B. Non-compliant documents may implement other, rival solutions.
> > > >     So fragmentation is *not* solved by your solution alone.  You
> > > >     depend on the existence of other solutions.
> > > That's how it works today.  There are dozen of tools around that all
> > > implement their own proprietary standards.
> > Again, I speak of a future in which the problem is solved. Although
> > there exist today *proposed* solutions (such as xDebate formats,
> > Outcast, Meinungsfindungstool and ODDI), we can hardly find any
> > implementations of them.  There are maybe 2 or 3 tools compliant with
> > one solution or another, not dozens.
> >
> > So the problem is still unsolved.  We have yet to arrive at future A
> > or B and are still free to choose between them.  What we (Conseo,
> > Thomas and I) propose is a step toward future B.  Our proposed tool
> > switch will not prefer any particular solution (xDebate, Outcast,
> > Meinungsfindungstool, ODDI, etc) over another.
> >
> > > I would prefer A. But B is even a good starting point that's worth
> > > proving the goal of adding benefit to those who participate. If B
> > > fail, A will fail also.
> > Your preference (again) may be based on a miscommunication.  But if
> > you agree that a step toward B would be a good start, then all we
> > propose here is a mechanism for that first step.
> >
> > > For me B provides the most benefit to the developers and providers
> > > of specific tools and solutions.  And A provides the most benefit to
> > > the users and content contributors of the tools.
> > >
> > > What audience would you like to attract?
> > I would first ask you to clarify how A could benefit users (or anyone)
> > more than B.  (But here too, I think it was just a miscommunication.)
> >
> > Mike
> >
> >
> > marc said:
> > > Michael Allan wrote:
> > > > Ronald and Marc, (cc AG Meinungsfindungstool)
> > > > I roughly understand the solution (or counter-solution) you propose,
> > > > except in one regard.  So I have a question at the end.
> > > > Ronald said:
> > > > > No, not necessarily [defragmenting the tools]...  This is my
> > > > > proposal, how to outbalance the fragmentation of documents...  We
> > > > > agree on a set of meta data, that the tools should support per
> > > > > document...
> > > > This sounds like "defragmented" tools to me.  It's an example of that.
> > > > The tools are no longer disconnected fragments because they share two
> > > > connections: first the agreed "meta data" standard, and second, the
> > > > "consolidated overview" into which they are pushed or pulled. *
> > > That's true. At the end our working group proposes a standardized 
> > > meta data
> > > schema to interchange data between different solutions or tools. 
> > > Furthermore
> > > there is not a "consolidated overview" but defined interfaces that 
> > > can be
> > > queried by the tool A on tool B to retrieve specific data.
> > >
> > > > I think we both agree (and Marc agrees) that the tools must somehow
> > > > (in this meaning) be defragmented.  You offer a specific solution,
> > > > while we (Conseo, Thomas and I) do not.  This raises the question of
> > > > how your solution relates to what we're proposing in this thread.  The
> > > > answer hinges on how you address the problem of fragmented documents
> > > > that are *non-compliant* with your agreed meta-data standard.  Either:
> > > >
> > > >    A. All documents must implement the agreed meta-data standard.
> > > >       Non-compliant documents are eliminated.  So fragmentation is
> > > >       solved by your solution alone.  Or,
> > > they can not benefit from the possibilities cooperation would offer 
> > > them.
> > > So yes, if the tools wants to benefit, it needs to be able to 
> > > migrate the
> > > data back and forth, but they will not neccessarily be eliminated ;o)
> > >
> > > >    B. Non-compliant documents may implement other, rival 
> > > > solutions.  So
> > > >       fragmentation is *not* solved by your solution alone. You depend
> > > >       on the existence of other solutions.
> > > That's how it works today.
> > > There are dozen of tools around that all implement their own 
> > > proprietary
> > > standards.
> > >
> > > > If you prefer A, then your approach to the larger problem is at odds
> > > > with and incompatible with what we propose in this thread. **   If you
> > > > prefer B, then it is compatible.  Which do you prefer, A or B?
> > > I would prefer A. But B is even a good starting point that's worth 
> > > proving
> > > the goal of adding benefit to those who participate.
> > > If B fail, A will fail also.
> > >
> > > >     * Your solution is not entirely new, ofc.  Mark Murphy proposed
> > > >       something similar in 2007.  xDebate formats (not yet published)
> > > >       is a Semantic HTML (POSH) schemata for federated debate on
> > > >       political issues.  We discussed it with him in 2009. See:
> > > >
> > > > http://metagovernment.org/pipermail/start_metagovernment.org/2009-February/001195.html 
> > > >
> > > >
> > > >       The broader context of that discussion was his 2008 essay in
> > > >       Rebooting America: The "killer app" of public participation:
> > > >       http://rebooting.personaldemocracy.com/node/5499
> > > You are right. There is already a lot out there! We need to connect 
> > > even
> > > more ;o)
> > >
> > > >       Later in 2009, Thomas was chasing the fragmentation problem
> > > >       himself and uncovered a different solution, one that nobody ever
> > > >       thought of before.  Vote mirroring works on documents (and other
> > > >       objects) via their popular support, not their content.  But 
> > > > note:
> > > >
> > > >    ** All we propose is a neutral tool switch that is blind to 
> > > > specific
> > > >       solutions.  Like the Internet, it is open to all.
> > > For me B provides the most benefit to the developers and providers of
> > > specific tools and solutions.
> > > And A provides the most benefit to the users and content 
> > > contributors of the
> > > tools.
> > >
> > > What audience would you like to attract?
> > >
> > > Cheers
> > > marc
> > _______________________________________________
> > Start : a mailing list of the Metagovernment project
> > http://www.metagovernment.org/
> > Post to the list: Start AT metagovernment.org
> > Manage subscription: 
> > http://metagovernment.org/mailman/listinfo/start_metagovernment.org
>
>
> _______________________________________________
> Start : a mailing list of the Metagovernment project
> http://www.metagovernment.org/
> Post to the list: Start AT metagovernment.org
> Manage subscription: 
> http://metagovernment.org/mailman/listinfo/start_metagovernment.org
>
> _______________________________________________
> Start : a mailing list of the Metagovernment project
> http://www.metagovernment.org/
> Post to the list: Start AT metagovernment.org
> Manage subscription: 
> http://metagovernment.org/mailman/listinfo/start_metagovernment.org