UGSDatabases
Tsumego-database
What do we like from problem-collections like GoProblems?.com, what do we dislike? What other features could we imagine?
Benjamin: For me, goproblems.com's strongest point is (besides nice GUI for users) that everybody is allowed to add his own problems. Its weak points are:
- no easy GUI to edit the problems (must be done offline)
- just the creator (and admins) may add variations and judge what's right or wrong
These lead to many errors in problems that don't get corrected at all or very late. Another, more general question is the difficulty of when a slightly inferior move is still judged correct and when it's considered to be an error. There's no convention for this, which also leads to a lot of misunderstandings when the site.
My idea for a more wiki-like database would be to allow everyone to add his own variations, but to allow NOONE to judge what's right or wrong! How should this work? Well, just let the users decide the status of the groups for their custom-variations (like "ko" or "black is dead") and use this to have the server find out which of them is best. Here's a mail I wrote to the UGS-mailinglist that explains this further:
Okay, the key point is that I'm not planning a minimax over all variations, but only over those that users did add and judge - this will be a relatively small number. Each moves outcome (under best continuation for both) is stored in the db and only updated if a (relevant) new variation was added by someone.
Let me give an example, a problem where it's blacks turn, no variations are there at the beginning: First user thinks he solved it, so he enters a five-move-sequence after which white is dead (what he enters after move five). Now, as there are no different variations to compare yet, the computer supposes everything was optimal play, thus giving all five moves and the start-position the value "dead" and marking black 1 as correct. After this, the second guy finds that, after black 3, white can make a Ko whith another sequence 4 to 8 and enters it. Now my algorithm works up to the top from the new rated move 8 which is marked with "Ko", giving moves 4 to 8 the same value. Now it looks at move 3, currently marked "Dead" and realizes Ko is better for White, thus giving 3 the new value "ko", working to the top and giving 2, 1 and the starting position this value as well.
I hope you got the idea now. So even if a new variation changes the problems solution drastically, only a small part of the current var-tree has to be looked at.
So, the key idea was to do a minimax-search not over all possible moves, but just over all user-entered variations, which is quite a small number. This works fine if the users assign a value to each leaf-position that the computer can read, so that it can judge which one is better. >My first idea was a static mapping of status (like "B is dead) to number (e.g. the better for black, the higher the number), but now I realized this will become difficult when thinking of Kos or Semeais:
- Which is better, a one-approach-move-ko for the whole group or killing half of it directly?
- Or, e.g. in a semeai, would a ko or a seki be better?
So, to deal with complicated results, we would need to allow for finer evaluation.. Of course, most ko-evaluations depend strongly on the rest of the board (like Endgame), but it is possible to give local values assuming a "normal" board position exactly the way endgame-calculations are done. So my proposal would be to judge local results by their endgame-value, so "black is alive with barely 2 eyes" could get the value "2 points for black" or less if white has some territory there, too. For Kos, their average-values could be calculated according to mathematical endgame-theory - anyone good at this? For example, a simple one-point-ko where white can take first would get the endgame-value of 1/3 point for white. This way, all kinds of results should be dealt with correctly.
The other question is how the users should enter the results: For non-ko-positions, this could be done easily in the same way as counting on go-servers is done, i.e. by marking dead stones manually. A score-estimator could be used for open borders for problems that are about life and death only; otherwise, if the exact endgame is important, all endgame-variations can also be entered and thus be taken into account by the evaluation-routine. >In the GUI, some additional helpers like "mark all black stones as dead" could be useful. To deal with kos correctly, my idea would be to have an auto-detection that goes into "ko-mode" once a stone in a ko is beaten. To judge a ko-situation, we have to know what happens if white wins and, oh wonder,what happens if black wins it. Allowing normal ko-fights in local problems doesn't make sense, so I'd propose a special "ko-rule" for tsumegos: Once a ko is beaten first, two variations are considered, the black-wins- and the white-wins-variation: In the black-wins-variation, white isn't allowed to recapture the ko at all until either
- black passes or
- black takes another ko
and vice versa. The length of a variation and the number of white passes in the b-wins-var could then be used to auto-detect approach-move-kos and the number of local ko-threats, whose value could be calculated by a nice formula.
Phhh, that was quite much and complicated stuff, I think. But my impression is that all this efford would pay off very well, because it will give us a database, where no user ever has to judge what is correct or what is wrong. Instead, they will just enter the variations they found and mark dead stones at the very end, letting the db decide what's correct by using the current variation-knowledge. This means no long discussions about what's right or wrong ever occur, because each time someone sees a new move, he or she just enters it. This way, all users knowledge will always be combined in the best way, so even if almost everybody goes wrong, as long as one person sees a better move, the db will know the right result.
Another gain is the possibility to evaluate by how much a move is wrong, so instead of the binary results of right and wrong, e.g. a move that just loses one point killing a 20-stone-group could be said to be "almost perfect", while a move that just gives ko get's the answer "not good enough here".
What do you think of this idea?
Access rights for databases
A game record database is assumed, of course, but:
- who has rights to modify game records?
- Will there be version control
- Will we have ownership rights
- Will there be seperate rights to add, modify/remove content?
With questions like these, it definitely sounds like we're going to need a new game format specification.
Benjamin: I think removing content should be confirmed by an admin. But anybody is allowed to add comments and stuff. For reviewing games with many comments, there should be good filtering options (like "don't show comments by kyu players" or whatever). Some function like "recent changes" here should also be available.