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

[Michael Allan <mike AT zelea.com>]

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