User:Mike-ZeleaCom/G/p/de:Difference bridge

From Wiki
Jump to: navigation, search

Contents

The difference bridge is a text comparison facility for deliberative democracy. It puts backbone into online deliberations by grounding them in concrete differences of position. It works in conjunction with peer-to-peer voting and drafting facilities, wherein the positions of voter and candidate are already formalized as text documents. In this setup, disagreements and misunderstandings are easily visualized as differences of text. The difference bridge goes a step further in allowing any particular difference to be referenced by a Web link, suitable for embedding in an online discussion. Participants may follow the link in order to summon a precise, stable view of the difference. Thus deliberations are formally anchored, at points, to the objects under discussion. Additional features of the difference bridge allow for locating other discussions of the same object across multiple forums; tracking the number of co-voters who share the same particular difference; and resolving differences by text merger.1

Functionally, the purpose of the difference bridge is (a) to reveal particular differences among the positions of voters and candidates, and (b) to dispense precise, stable reference URLs for embedding in discussions. Discussions are rational in a democracy only insofar as they are focused on differences of position. By formalizing this focus through embedded links, the difference bridge thereby contributes to the more general function of democratic social integration.2

Structurally, the difference bridge is the central component in the difference framework, the purpose of which is: (c) to interconnect the separate facilities of voting, drafting, and discussion, and (d) to interconnect the various projects and technical domains in which they are developed. This enables a rationalized architecture in which specialized and independently developed components are brought into functional coordination. The broader structural purpose is therefore one of e-democratic system integration.3

Difference framework

The difference framework defines a set of interfaces for macrocomponent facilities to cooridinate on a system-wide scale in the provision of communicative differencing. The principle supporting elements are embeddable difference URLs that serve to anchor the discussions. The interfaces required for this are not actually designed yet, but are indicated in the diagram below.


framework.png


Following a difference URL from the context of a discussion (1), the participant thereby requests a particular view from the difference bridge. The bridge reads the location of both position documents from the vote-server (1.1, 1.2), which exposes an API for this purpose. It then fetches the corresponding texts from the drafting medium (1.3, 1.4), and constructs the difference view.

Discussion medium

The discussion medium is a facility for voters, candidates and other participants to engage in dialogue and discourse. The discussion medium must allow for the embedding of difference references (such as Web links).

Vote-server

The vote-server is a facility that enables votes to be cast for candidates in the context of particular polls. The vote-server must export a public API for the lookup of voters, candidates, and the location (URL) of candidate position drafts. The details of these APIs are not yet documented.

Some difference functions may depend the number of immediate voters per candidate being relatively low (on the order of 10). It is therefore most compatible with peer-to-peer voting methods, such as liquid democracy, delegate proxy or delegate cascade. Other voting methods may be supported in a degraded mode.

Drafting medium

The drafting medium is a facility that enables candidates to draft and publish formal positions. The drafting medium must expose a public URL for each separate position document. Ideally, the medium also exposes a history of document revisions, like a wiki does. Otherwise the difference bridge may either function in a degraded mode, or it may create its own history by recording document snapshots.

Remote editing

Ideally the drafting medium also exports an API for remote editing. This is required in order to implement a cherry-picking merge facility for the erasure of position differences.

Formal positions

A formal position is a text document associated with a particular candidate, in the context of a poll. The content of the document reflects the candidate's actual position on the prospective issue of the poll. The prospective issue can either be normative (law, plan or policy) or electoral (power structure).

The crucial differences of position are not among candidates, but between voters and candidates. Voters participate and if the discussion is to stay rational, they it must stay focused on differences of position. It follows that voters must have positions. It also follows that the positions must be formalized (as concrete documents) otherwise we could not grapple with them technically. The upshot is that communicative differencing (if not rational discussion) is restricted to systems that combine peer-to-peer drafting (as with MixedInk or Votorola) and peer-to-peer voting (as with Adohocracy, Liquid Feedback or Votorola). Currently, only Votorola supports that combination.

Normative positions

Where the issue is a normative, the position document will define a proposed social norm, such as a law, plan or policy. This is similar to the practice in traditional legislatures, for example, where each separate draft of a bill is equivalent to a position document.

Electoral positions

Where the issue is electoral, the position document will define a proposed power structure, consisting of specific appointments and responsibilities. This is not traditional practise, and requires further explanation.

Documenting a power structure

Ordinarily, the document will define only a part of the overall power structure. Thus the position of an end-candidate in a mayoral poll will include appointments for the chief of police, comptroller, and so on; while the position of the appointed chief of police will include the appointments of captains, and so forth. It might or might not repeat (perhaps with differences) the top level appointments of the mayor. The definition of the power structure is thus spread out among the candidates, delegates and voters, with varying degrees of overlap.4

Cross-poll positions

A formal electoral position may appoint the elect of other polls. Thus the position of an end-candidate in a prime ministerial poll may include cabinet and committee appointments that depend on the outcome of the general elections. In a first-past the post electoral system, the appointees might be designated by their electoral district, instead of by personal name. So a candidate for prime minister may appoint the elect of Trinity-Spadina as foreign minister. The current results of the primary poll for member of parliament in Trinity-Spadina (P/tsmp) could be consulted to yield that person's name. Her position could then be consulted to yield the sub-appointments. And so on. Multiple polls would simultaneously decide the power structure at issue. 5

Difference services

The difference bridge provides the following end-user services. The most crucial service is showDifference, which provides the linking between drafting and discussion media. These are typically implemented as Web views, referenced by URL.

listVoterDifferences

 listVoterDifferences (poll, user)

The listVoterDifferences service summarizes the differences between a user and her immediate voters. For each voter, it provides a list of all differences between the voter's position and the user's. Each item links to a full showDifference view (below).

showDifference

 showDifference (poll, user1, rev1, user2, rev2, frag)

The showDifference service implements a number of separate functions. The URL and associated view are the most crucial functions. They provide the primary linkage between drafting and discussion media. The other functions may or may not be implemented in particular view instances. Where they are implemented, they will typically be incorporated within the view, as subviews and controls.

URL

 http://diff.somewhere.com/taxpol/Voter-VdomainCom/946/Candidate-CdomainCom/934#11

Each difference view is requested by a parametized URL, suitable for embedding in archival discussions (example above). If the drafting medium (or media) have a revision history, then the URL is stable, always returning the same view. The URL may target a precise fragment (frag) within the overall difference view. Fragments are isolated sections of difference, such as a difference in a single sentence.

View

Differences are shown between any two position revisions (user1/rev1 and user2/rev2). The following mockup of a single-fragment view, for example, shows one user (voter) proposing a higher tax rate than another (candidate). The difference is highlighted in colour: 

 <<< Voter-VdomainCom, rev 946      +7 co-voters with same difference: *******
 >>> Candidate-CdomainCom, rev 934
 - - - @@ ... @@ frag 11
   blah blah blah
 < The tax rate on residential property is 0.60% of assessed value, per annum.
 > The tax rate on residential property is 0.55% of assessed value, per annum.
   blah blah blah
 - - -                                         merge to:  << left  |  right >>
 This difference fragment is discussed here:
 * http://list.somewhere.com/t3645/post356
 * http://list.elsewhere.com/t87/post98
 * and so forth

The above mockup shows several additional functions that are incorporated as subviews and controls. These are discussed below.

Same difference

For each difference fragment, the user can see a tally of how many co-voters have the same difference, and who they are. Whenever an additional voter merges-in that difference, the tally automatically increments. The tally therefore serves as a simple, micro-scale voting facility, where voters may cast their votes by simple difference erasure, and candidates may detect emerging consensus.

Merge

A cherry-picking merge function is provided. For each fragment in the difference view, the user may choose to merge in either direction: either from voter to candidate (for example), or from candidate to voter. The merge will take effect in the current revision of the target document, following resolution of any conflicts. Where merge is not possible, owing to restrictions of the target drafting medium, the merge facility will provide information in support of a manual merge. For example it will provide text to copy and paste, and line numbers for the paste.

With each merge, two things occur: First, a variation of text is transferred from document to document, communicating an innovation from user to user; second, a position difference is erased, contributing to an increase of formal consensus. On the other hand, where no merge occurs, the difference is instead maintained as a focus for further discussion, and an aid to mutual understanding.

Reverse linkage

Linkage may be bidirectional. For each difference and fragment, the view may provides a list of all discussion messages that refer to it. A prototype of such a facility based on the harvesting of difference links from discussion media was developed:6

Addenda

Property settings

Notes

  1. ^ The need for a differencing facility was revealed in early alpha testing, as first discussed in the Votorola mailing list (Seeing the differences among position drafts). The initial design followed from dialogue between Michael Allan and Thomas von der Elbe in October, 2009. In particular, a proposal by von der Elbe to highlight the differences with a text annotator (Co-ment), led, by analysis, to the idea of a more flexible binding between the difference and general-purpose discussion media.
  2. ^ In addition to enabling rational discourse by the binding of discussion messages and position differences, the bridge also enables i) mutual understanding through the visualization of substantial differences, and ii) consensus building through the deliberate erasure of differences that are non-substantial, invalid or otherwise unmaintainable. It therefore serves as a micro-structural support for communicative action.
  3. ^ Overall system integration is to be defined by the larger architecture, of which the difference framework is part. The design of the larger architecture is only at the discussion stage. See User:Mike-ZeleaCom/Opening_an_architecture.
  4. ^ Where an electoral position consists of multiple nodes of appointment (such as the mayor's appointments plus the chief of police's) each node is separately comparable with another of the same type, in a separate position document. Whole electoral positions are not comparable with each other, only their nodes. The parameter for specifying the node type of the comparison has yet to be defined for the difference services.
  5. ^ It is unclear how such cross-poll positions could be specified in a proportional electoral system, where there are no district names as placeholders.
  6. ^ The harvesting code was developed by Christian Weilbach.
  7. ^ See note CWFIX in: Minders and pipes. http://mail.zelea.com/list/votorola/2013-June/001763.html
  8. ^ http://reluk.ca/mediawiki/index.php?title=User:Mike-ZeleaCom/G/p/de&oldid=1922
  9. ^ a b Dating from the first design sketch to include the patch function, which was then called "merge".8
  10. ^ http://reluk.ca/project/votorola/a/diff/
  11. ^ a b http://reluk.ca/project/votorola/s/wic/diff/
  12. ^ http://wicket.apache.org/
  13. ^ The core viewing and patching functions have been stable for years, but are yet to be tested in beta trials.
Retrieved from "http://reluk.ca/mediawiki/index.php?title=User:Mike-ZeleaCom/G/p/de&oldid=7763"