architecture for voting
Michael Mahemoff
interest in voting. What are people's thoughts on the best model for
voting?
This is a classic many-to-many pattern, where a user can vote on many
things, and a thing can be voted on by many people.
Possibilities are:
- Unique tiddler for each vote. Feels the most tiddlyesque.
- "Voters" field on each Idea (or whatever we're voting on).
comma-separated list, say.
- "Ideas" field on each voter.
- Both of the above - redundant list of voters and ideas.
I'm inclined to go with the first option - Vote as first class
citizen. As well as optimising for queries in both directions, it has
the advantage of letting you keep meta-info, such as vote time
(perhaps IP number to help prevent dupes, in the case of a public
system, as long as it wasn't exposed to the client).
Paul Downey
> I'm inclined to go with the first option - Vote as first class
> citizen. As well as optimising for queries in both directions, it has
> the advantage of letting you keep meta-info, such as vote time
> (perhaps IP number to help prevent dupes, in the case of a public
> system, as long as it wasn't exposed to the client).
sounds good. I'd suggest formalising this tiddler data model, then we
can all write individual plugins to manage voting and counting of
votes, be that for a single winner, ranked outcome, preference poll,
awarding scout badges, promotion/demotion of roles, etc, etc.
--
Paul (psd)
http://blog.whatfettle.com
rakugo
The only slight problem I have encountered is what to do with renames.
At the moment I have a votes bag where titles are like this "username
vote for tiddlerTitle"
(where this represents the user with username 'username' voting on a
tiddler called 'tiddlerTitle'. It also maintains a field modifier and
field topic (to keep in line with the comments plugin field name).
However if 'tiddlerTitle' is renamed to 'tiddlerTitle2' - the side
effect of this is every vote on tiddlerTitle would be lost. It would
require some sort of validator in TiddlyWeb to fix if this was not
desired behaviour.
Thoughts..?
Jon
On Oct 29, 12:13 pm, Paul Downey <paul.dow...@whatfettle.com> wrote:
Michael Mahemoff
>
> I'm looking at this now.
> The only slight problem I have encountered is what to do with renames.
>
> At the moment I have a votes bag where titles are like this "username
> vote for tiddlerTitle"
> (where this represents the user with username 'username' voting on a
> tiddler called 'tiddlerTitle'. It also maintains a field modifier and
> field topic (to keep in line with the comments plugin field name).
> However if 'tiddlerTitle' is renamed to 'tiddlerTitle2' - the side
> effect of this is every vote on tiddlerTitle would be lost. It would
> require some sort of validator in TiddlyWeb to fix if this was not
> desired behaviour.
This is an intrinsic issue with TiddlyWeb and most other NOSQL systems
(http://en.wikipedia.org/wiki/NoSQL). The comments plugin has exactly
the same issue. To make it even more fun, there are permissioning
issues; it's not always the case that the creator of the topic has
permission to change the votes. (By analogy, if you upload a youtube
video, you don't have permission to change the comments or ratings.)
Thus, moving all the votes over can't be a client operation.
One solution is to use GUIDs as tiddler titles, and store the
human-readable title as a field.
Another solution is to handle it as a specialised server-side
operation. Although the content owner can't change the votes through
direct RESTful data manipulation, you could argue it's okay to have a
one-off miscellaneous operation that performs the specific task of
updating the relevant votes' field.
A third solution is to say "bad luck" and do nothing, which will
therefore clear all voting. Users voted for the thing containing the
old title, not the new thing. One downside of this approach is a user
could exploit this to effectively delete all the votes if it was in
their interest to do so, whereas they are not actually permissioned to
delete the votes. However, they are not really deleting the votes, but
sweeping them under the carpet since they are no linker tied to a
valid topic. They would be orphan votes. Or, you could make it so that
users can't actually delete topics they create, but have to simply
make a new topic instead and mark the old one as "obsolete". However,
I don't like the idea that a user can't create something they've just
created. (Indeed, I heard Steve and Jeff on the StackOverflow podcast
just last week talking about this issue and that they're aiming to be
more explicit about the rules on it. ie if you create a question and
people start voting on it, can you allow it to be deleted?)
I can imagine the need for a generic tiddlyweb plugin to help with
admin of these sorts of things, e.g. for the admin to see all orphaned
items (items where a particular field doesn't point to a tiddler in
another bag).
On a separate note, we should be looking at the work Chris has
recently posted about regarding optimisation of filtered queries,
since I think both comments and votes will need to exploit that
capability in order to scale.
> On Oct 29, 12:13 pm, Paul Downey <paul.dow...@whatfettle.com> wrote:
>> On Thu, Oct 29, 2009 at 12:02 PM, Michael Mahemoff <mich...@mahemoff.com> wrote:
>> > I'm inclined to go with the first option - Vote as first class
>> > citizen. As well as optimising for queries in both directions, it has
>> > the advantage of letting you keep meta-info, such as vote time
>> > (perhaps IP number to help prevent dupes, in the case of a public
>> > system, as long as it wasn't exposed to the client).
>>
>> sounds good. I'd suggest formalising this tiddler data model, then we
>> can all write individual plugins to manage voting and counting of
>> votes, be that for a single winner, ranked outcome, preference poll,
>> awarding scout badges, promotion/demotion of roles, etc, etc.
Yes - we could do with a lot of formalising of tiddly models and votes
would be a good start. I'd suggest perhaps a core voting plugin which
people could establish further plugins around. The benefit of a core
plugin, even if it's quite raw, is it establishes the standard via
code instead of words.
Paul Downey
this from my mate Kevin:
http://www.slideshare.net/kplawver/building-whuffie
I hadn't come across about "right" and "left" handed wuffie before:
http://en.wikipedia.org/wiki/Wuffie
Michael Mahemoff
>
> related, is the notion of wuffie for the reputation building, I liked
> this from my mate Kevin:
>
> http://www.slideshare.net/kplawver/building-whuffie
>
> I hadn't come across about "right" and "left" handed wuffie before:
>
> http://en.wikipedia.org/wiki/Wuffie
Good links, thanks.
On similar topic, http://buildingreputation.com and its corresponding
wiki are interesting to check out. They're attached to the upcoming
O'Reilly book on the subject.
Tobias - http://tbGTD.tiddlyspot.com
Someone was asking whether or not my variant of a RatingMacro was
suited for TiddlyWeb.
http://groups.google.com/group/tiddlywiki/msg/dcab39bcf5accc84?dmode=source
Though I guess it is far from it, can anyone of you - with enough
background-knowledge and motivation - try to give him an educated
answer?
...or plot the TiddlyWiki-side of things for TiddlyWeb-Rating (or
voting)... though I guess that will just have to follow whatever
TiddlyWeb-rating-model is going to be the preferred in the time to
come.
Tobias
Michael Mahemoff
JonL has answered it.
Voting and rating are very similar from a server perspective. The
common thing is that there is a unique tiddler per vote/rating which
tracks the user's details and what their decision (in the case of
rating, what the rating was; in the case of vote, which direction they
voted in, or how many points in the case of a more sophisticated
weighted voting system). The difference is in the validator, since the
decision variable has different valid ranges; and the UI.
If Paul is proposing standarding, we should be looking at a common
field name for the decision field.
Tobias - http://tbGTD.tiddlyspot.com
can you elucidate (again?!?) as to why a (single) vote is not just
(part of) something like a 'tiddler field'. That way, it would be
associated with it, no matter what renaming might occur.
Maybe I missed the benefit of it being (something like) a tiddler...
other than loads of excessive (collections of) meta-data and a
question of ...who really cares about those?
Tobias.
On 11 Nov., 01:11, Michael Mahemoff <mich...@mahemoff.com> wrote:
> On Tue, Nov 10, 2009 at 5:01 PM, Tobias -http://tbGTD.tiddlyspot.com
>
>
>
> <beertob...@googlemail.com> wrote:
>
> > Hi everyone,
>
> > Someone was asking whether or not my variant of a RatingMacro was
> > suited for TiddlyWeb.
>
Paul Downey
> can you elucidate (again?!?) as to why a (single) vote is not just
> (part of) something like a 'tiddler field'. That way, it would be
> associated with it, no matter what renaming might occur.
>
> Maybe I missed the benefit of it being (something like) a tiddler...
> other than loads of excessive (collections of) meta-data and a
> question of ...who really cares about those?
I agree for simple rating, a field is sufficient, but we have a
use-case where the rewards for being rated highly go beyond
a tiddler being flagged as "interesting" but with people
being rewarded with badges, greater reputation,
administrative privileges, awards of prizes and money.
Detailed per-vote data can help fine tuning the system to ensure
the game isn't gamed too much, and as an audit trail for when it
is gamed, which is something of an inevitability.
Michael Mahemoff
Yes - most vote systems keep a record of the user's IP number and
login at the very least to help prevent being gamed.
In the case of TiddlyWeb, its security model means that if you're
writing directly to the REST services, you need to keep a separate
tiddler for each user to ensure integrity. You'd create a bag which
has permission "create" but not "write" (similar to the comments
plugin), so users can push in new votes, but can't change any existing
votes.
Tobias - http://tbGTD.tiddlyspot.com
be stored...
*specific to the generating user
*with the above mentioned previledges
**create, but no write
**regardless of the use-case
***rather required for secure interaction with the RESTful api
That, however, sounds like a somewhat cumbersome way to retrieve those
votes for a given element being voted on... as tiddlyweb doesn't seem
to compare to a relational database as for being optimized for queries
and cached or 'precompiled' query results.
I think it might be worth pursuing a scenario where both...
#votes are stored as tiddlers, as you said
#vote stats are calculated 'cron-like' to update vote-specific summary-
fields on tiddlers
**with a definable update rate ...via moderators / admins
**automatic server-side read+write
**no user interaction involved other than defining...
***what goes into these summaries
***how they're being calculated (sum, avg, etc...)
***possibly only numeric formats (nums + dates)
Considering all this, plus manageability & scope for tiddlyweb
dev's ...might it not be the slickest path to invent a tiddlyweb
flavour -- possibly in competition to LAMP -- centered (mostly)
around:
*TIddlyWeb (+ apache / cherrypy / ...)
*PYthon
*LINux
*DAtabase interface ...to actually __simplify__ things linke voting
systems
Are you guys having any thoughts about some sort of TIPYLINDA or any
other word creation and, of course, all of what comes along with it?
Tobias
On 11 Nov., 12:48, Michael Mahemoff <mich...@mahemoff.com> wrote:
Chris Dent
On Nov 11, 2009, at 12:35 PM, Tobias - http://tbGTD.tiddlyspot.com
wrote:
> That, however, sounds like a somewhat cumbersome way to retrieve those
> votes for a given element being voted on... as tiddlyweb doesn't seem
> to compare to a relational database as for being optimized for queries
> and cached or 'precompiled' query results.
Ignoring the rest of the message for others who are more involved in
the voting/reputation stuff, I just thought I would point out the new
facilities for indexed queries. Discussed here:
http://cdent.tumblr.com/post/233932281/indexed-tiddlyweb-filters
and documented (a bit) at:
pydoc tiddlyweb.filters
in recent versions.
Tobias - http://tbGTD.tiddlyspot.com
http://cdent.tumblr.com/post/233932281/indexed-tiddlyweb-filters
...will do very well, at least for retrieving the vote-tiddlers. The
missing link then would be something like a general-purpose vote-stats
module, right?
Tobias.
Tobias - http://tbGTD.tiddlyspot.com
Tobias.
Paul Downey
If we agree on a common format, how votes are collated, counted,
vizualised and acted upon can come from a wide array of different
plugins.
Tobias Beer
something to consider. Meaning: a cron-job-like-triggered module
collating the results and generating a results-index, which is what is
returned when querying for vote-results and updated in a specified
intervall.
The other big part seems to be the administration interface...
* to define a voting mechanism for an item (e.g. data-types: text,
numerical scales, booleans, dates)
* with a generic way to define how vote statstics are gathered
* an interface (vote-list) to revise (posted, flagged, recent) votes
and delete or edit them...
Tobias.
On 11 Nov., 15:08, "Tobias - http://tbGTD.tiddlyspot.com"
FND
>> [...]
>> http://en.wikipedia.org/wiki/Wuffie
>
> Good links, thanks.
> On similar topic, http://buildingreputation.com and its corresponding
> wiki are interesting to check out.
Perhaps also of interest:
http://blog.steepster.com/post/226679106/better-rating-system
It's not exactly revolutionary, but I like the frame of reference.
-- F.