Seeing the differences among position drafts

[Michael Allan]

To David Mason and David Hilvert,

davidm wrote:
> I think adding the structure components to the poll wiki would be
> the way to go. A discourseDB type approach where there are yes/no
> vote- able propositions, with data for and against, contributed and
> refined by individuals, with the ability to link in other pages via
> properties and queries, could work best for the benefits of Votorola
> and SMW without trying to do too much. A diff or visual tool to
> compare two pages might be useful as an add on, but only if those
> pages are carefully structured. A timeline could be constructed in
> SMW using tools like
> http://tw.rpi.edu/proj/semhis.wiki/index.php/Main_Page

You feel safer with tight integration.  That's cool.  I'm interested
in seeing what you propose.  So maybe the best approach, instead of
choosing between A and B, is to do both in parallel.  The architecture
can support that.  The pollserver can have any number of pollwikis,
and they can be located anywhere.  So if you want to push forward with
setting up a demo pollwiki/DiscourseDB, I don't see any obstacles.

For my part, I'm keen to go in the direction of B.  It's a parallel
approach in itself.  We reach out to forums that already exist, and we
retool them with our voting/drafting controls.  If the controls are
sufficiently lightweight (like URLs), then we won't even need the
permission of the forum administrators.  We just go in there and start
doing it.  We do it simultaneously across many forums, and many media.

Either way, the users are already out there and talking.  Theory says
they're talking aimlessly and to no effect.  So (A) we can try to
attract them to an improved discussion medium, and ask them to test it
out.  Or (B) we can go to where they're already talking, offer them
something more concrete to talk about (text diffs), and show them some
real effects in return (text shifts and growing consensus).

Thomas and I were talking about something like B a couple of months
ago, but we never went ahead with it.  All we had back then (all we
foresaw) were voting controls and views.  I think the text diffs are
the crucial, missing ingredient.

David Hilvert wrote:
> ...  Questions that would arise include how to handle differences in
> HTML and other formatting between pages (ignore this?), extraneous
> text not part of the draft but part of the web page, and
> rearrangements of sections.  (This would be applicable to diffs in
> general.)

If our solution incorporates a third party Web tool, then we have to
feed it the wiki source.  We don't want to see HTML in the diff,
unless it's actually in the wiki source.

The most important diffs are between drafters in a voter-candidate
relation.  We can expect them to work together to minimize the format
diffs (noise), and maximize the real diff signals.

Diffs across branches (or between trees) are more likely to have
format noise.  But it matters less there.  Cross-branch text flows are
going to be relatively thin.  The main reason for cross-branch diffs
is to compare candidates in consideration of a vote shift.  But vote
shifts are less common than text flows, and probably less dependent on
detailed text differences.

> More difficult issues would include how to follow the movements of
> text fragments and replacement of words with synonyms in the case of
> a rewrite.
>
> Unfortunately, searching the web doesn't seem to immediately suggest
> an appropriate tool.  Traditional diff algorithms are covered in
> some depth, however (e.g., see http://en.wikipedia.org/wiki/Diff ).
> One place to start might include tools designed specifically for
> determining originality of works, since this is a subset of the
> larger problem of determining changes in general.

I think this is an ordinary application, with no special requirements.
So the standard algorithms and tools ought to suffice.  In my mind,
the biggest question is how to keep the URLs short.  Here's the
current diff between me and my candidate:

  http://host.domain.dom/diff/vop/Mike-ZeleaCom/946/ThomasvonderElbe_GmxDe/934
 
It's awfully long.  I don't see how to shorten it, except maybe with a
"tiny URL" service.  Or maybe drop the candidate's username, and keep
a history of vote shifts, for looking up the candidate by rev time.

> Perhaps for Votorola, it would be most appropriate at first to use
> manual mark-up of the sort Thomas demonstrates, since a drafter will
> usually have an idea of which other drafts his own can be best
> contrasted with (e.g., the draft of a delegate).  In this way, the
> drafter shares his own knowledge of the differences in drafts with
> readers, rather than relying on an automatic tool to attempt to
> reconstruct such knowledge.  (Although an automatic tool could be
> used as a fallback initially, and might serve as a complete
> replacement for human mark-up in the long run.)

We may have to experiment.  For my part, I like the idea of plain-jane
diffs.  They're accurate, neutral and they apply between any two
texts/revisions.  They're stable.  Discussions can grow on them, like
vines on a supporting trellis.  (I always thought that support would
come straight from the P2P voting structure.  Now it looks like we
need the finer structure of the text diffs.)

This fits neatly with social theory too, because the diffs are "ought
statements".  They draw a contrast between fact and ideal, what is and
what ought to be.  They make claims of validity that can only be
redeemed through discussion.  So it's exactly at these points of
difference that the background consensus of a candidate norm is tested
and renewed by communicative reason.

-- 
Michael Allan

Toronto, 647-436-4521
Skype michael_c_allan
http://zelea.com/