Seeing the differences among position drafts

[davidm]

Have you looked into the Semantic Mediawiki universe at all? I have
been spending a lot of time there, and it adds a quite important layer
around regular Mediawiki.

Mediawiki on its own supports the fully public hypertext pages, pages
that can only be edited by a user in their userspace, categories, and
templates (which are strongly recommended to be used in any case over
tables for repetitive content).

With Semantic Mediawiki, you gain richly typed page properties/links,
forms, queries and views, as well as an RDF interface. There is a
large universe of extensions that add features like more dynamic
forms, ACL, maps, calendars, timelines, etc.

I wouldn't want this universe to distract from the core Votorola work.
But I think for now exploring some of these features would yield a lot
more benefit than just using MW as a page management system. It could
be used for annotation of text, however I would today think that the
user's own comment text (I support this because...), followed by an
actionable statement ([[supports::Budget increase for daycare
services]]) might be a more practical way. Please take a look at
http://www.discoursedb.org, a SMW site, for a structured example.

Here's a site I've been working on, around a generic representation of
government:

http://subvention.zooid.org/wiki/L1

I could work through some scenarios if anyone would like to explore
this.

David


On Oct 15, 8:26 am, Michael Allan <m... at zelea.com> wrote:
> To David and Thomas,
>
> I think the visualization of textual differences is going to steer the
> whole course of the design, as far as the voting/drafting UI goes.
> More at bottom.
>
> David Hilvert wrote:
> > One approach might be to adapt the existing history view to present a diff
> > between arbitrary pages, rather than merely between versions of a single page.
> > While this might not effectively cover the case where your draft draws from
> > only some small part of someone else's draft, it might be a reasonable start.
>
> Another approach (stepping back) is to implement a diff in the
> pollserver.  Or (further back), a general-purpose diff tool for Web
> pages.
>
> >http://www.gossamer-threads.com/lists/wiki/foundation/121420
> >http://el-tramo.be/software/wigit
>
> > In particular, git very naturally handles sharing of changes.  (On the other
> > hand, git might be too restrictive for use with Votorola.)
>
> It's interesting, because git (distributed revision control) has
> similarities to recombinant text (our pattern of collaboration).  But
> I don't think the toolset meshes; like you say, it's too restrictive.
> We need wider degrees of textual variation, finer scales of cherry
> picking, and persistent differences in the face of bidirectional text
> flow.
>
> There are recombinant toolsets (textbender, TextFlow and MixedInk).
> They aren't suitable, either.  Basically they don't grapple with the
> essential problem, in our case, which is visualization.
>
> Thomas von der Elbe wrote:
>
> > I agree, that the difference between two texts must become more visible.
> > That is also why I liked the co-ment tool so much. Highlighting things
> > plus commenting on them is very easy with it.
> > So one could highlight the improvements in ones own text as well as the
> > parts in the candidates text, which one wants to improve (and comment
> > all this of course). Friedrich from Adhocracy.org said, its not so
> > difficult to integrate co-ment.
>
> (I couldn't find a MediaWiki extension for doing text annotation.
>  Maybe there's a wiki somewhere that is already set up, so we can try
>  it out?  After all, we're not restricted to drafting in our own
>  pollwiki.  We don't even have to use a wiki, it can be almost any
>  drafting medium.)
>
> > But now I used the wiki-way for the vohall-poll.
>
> So this is now a perfect demonstation.  The differences are visible
> and the text can begin to flow.
>
>  http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/p/vohall
>    |
>    v
>  http://t.zelea.com/wiki/User:Mike-ZeleaCom/p/vohall
>
> Either I'll transfer it, or Thomas will, or his voters.  Any remaining
> yellow marks will reflect an actual difference of opinion between our
> voters (Thomas's and mine).  This difference will then become the
> topic of discussion.  Generalizing on this, it seems we've discovered
> two rules:
>
>   a) Text flows across a differential, like water over a weir.
>
>   b) Where text does not flow, there is something to discuss;
>      otherwise not.
>
> The entire debate on social norms (laws, plans and policies) can
> therefore be mapped, in perfect detail, by a survey of textual
> differences.  This is a strong statement, and very interesting.
>
> Visualization is the key to (a) and (b).  It's like it were controlled
> by a light switch: turn on the light, and the text and conversation
> begin to flow; turn it off and they freeze.  The upshot is that (up
> front) we only need design the visualization tools; we don't have to
> think about transfers and mergers.
>
> Some possible requirements that follow from (a) and (b):
>
>   1. In the pollspace browser, the text subtrees within the vote trees
>      must be shown.  It must be clear which delegates/candidates have
>      substantial texts, worth comparing.
>
>   2. In the pollwiki, links must be provided to upstream and
>      downstream texts.
>
>   3. Wherever multiple texts are shown in a list/tree, it must be
>      possible to select any two of them, and generate a visual diff.
>
>   4. URLs for the diffs must be stable, short and precise.  They must
>      be embeddable in email and other discussion media.  They will
>      serve as anchors for the discussion.  According to (b), there is
>      nothing else to discuss, so this is crucial.
>
>      By precise, I mean the URL must ref a specific portion of the
>      overall diff, like a single word or phrase (a single area of
>      yellow highlighting in Thomas's example).  By stable I mean the
>      URL must remain valid, even after the two texts are modified.
>
> Anyway, this is what I'm thinking.  As far as the voting/drafting UI
> is concerned, these requirements might be sufficient to carry us into
> beta.
>
> --
> Michael Allan
>
> Toronto, 647-436-4521
> Skype michael_c_allanhttp://zelea.com/