StratML Narrative - Case Use of Votorola?
Michael Allan
mike at zelea.com
Thu Oct 28 16:24:23 EDT 2010
(still catching up)
Owen and I discussed this somewhere, but I can't find where. All I
found is this test page:
http://okidoke.referata.com/wiki/User:Michael_Allan/StratML_test
<pre><nowiki>STRATML CONTENT</nowiki></pre>
I figured we'd encode StratML very simply (at least for starters) as
shown above. Although you could use Semantic Forms to provide a
user-friendly editing interface and pretty views, the difference
bridge will always bypass it and expose the drafters to the raw source
text.
Thomas von der Elbe wrote:
> ... the need for Vote Processing. Its basically meant as a filter,
> right? So a user can answer all kinds of questions, e.g.: How many
> votes for this proposal are not older than 4 weeks? How many
> members of Greenpeace which are from Berlin voted for it?
As I understand, Alex mainly wants to couple the voting results to
administrative actions. For example, when a consensus of 60% or more
is held for 6 weeks, then the consensus draft is automatically
promulgated (enters the regulation books, is enforced). So it's a
one-way coupling from public sphere (freely communicative and
insulated from power) to the administrative system (highly constrained
and powerful). I sometimes think of it as a "wire system" between the
cockpit and engines.
It could run as an independent service in the network, probably on the
administration's own servers. At least that's what Alex and I figured.
The voting might proceed through a sequence of administrative states
in which voters are expected to react in certain ways. For example,
maybe not all voters would be qualified to vote in all stages of the
process. Rules like that cannot be enforced in the public pollservers
because they must remain insulated from power (force). So we figured
we'd need a remote "vote processor" for that. It could enforce the
rules on its own "turf" by way of vote mirroring and filtering (as you
say), among other techniques.
Or it might just be a matter of providing additional, organization
specific information to the voters ("this rev of this draft is now in
force"). Whatever such information could not be provided via the
common infrastructure (pollservers, pollwiki, etc) could instead be
provided by the organization's own "vote processor".
But I agree with Alex: if we're to work together on practical stuff
then the #1 priority is to finish the basic prototype. That mostly
means a top-level UI over the network. I'm hoping to return to that
in the next few days.
--
Michael Allan
Toronto, +1 647-436-4521
http://zelea.com/
More information about the Votorola
mailing list