|
| The XML format of RenjuNet database | 2008-03-17 19:30:37 |
| Very soon all the 8000+ games of RenjuNet will be available for downloads. The data format will be XML. The Idea of providing such source is to let home users browse games more conveniently. RenjuNet does not have any official Viewer program yet, but I am sure there are many interested programmers ... |
| farmer lu | 2008-03-17 19:53:15 |
seems the old "smart go" format can easily support this.
it not necessary to use xml. |
| |
| Ando Meritee | 2008-03-17 21:33:29 |
| Can someone please give me the SGF format example, based on the example data in my article? Thank you very much! |
| |
| Farmer Lu | 2008-03-17 22:44:08 |
sgf properties:
http://www.red-bean.com/sgf/proplist_ff.html |
| |
| Ando Meritee | 2008-03-17 23:19:38 |
I am not familiar with sgf and it would take me several days to be able to come up with a model of our database in sgf format. I hope someone with better skills could help us out here.
(I can use google too, but it does not help me much with actual dealing of this problem.)
I guess there are different data types possible. Some allow more complex client programs that can use statistical and search capabilities, while some other sgf documents can only give us the option to build or use a client that can basically only navigate inside moves-tree.
I just think, if someone is willing to make or find a good Viewer program that can take a good use of structure, with all these search tools etc, it would be great. If so, I would like to know, how should the data be presented then for sgf output.
The example is given in my article, it basically gives you the idea how the data is stored in renjunet until now. The example xml model that i put into my article was just very similar to existing structure. If someone wants to suggest different structure, please give me some concrete answers and examples here. It would help much more than just waiting until I learn more about sgf or other formats myself. :) |
| |
| Wenzhe Lu | 2008-03-18 00:04:18 |
For a quick look, the SGF record for first game will look like this:
(;
GM[5]FF[4]
US[Brought to you by RenjuNet]
CP[
RenjuNet © 2001
http://www.renju.net
web@renju.net
It is allowed to use this database for non-commercial purposes in the forms of OFFLINE databases only.
It is forbidden to use any contents of this database in any website or ONLINE system.
]
SW[YES]
5A[ji]
GN[Round 1]
EV[Tallinn Open]
RE[B+Resign]
PW[Ants Soosõrv]WR[8d]
PB[Ando Meritee]BR[9d]
PC[Tallinn, EST]
DT[1999-03-12]
SZ[15]TM[100]
;B[hh];W[ij];B[gg];W[ig];B[ii];W[gh]C[
btime=56 wtime=78
]
;)
|
| |
| Ando Meritee | 2008-03-18 00:39:51 |
Thank you very much!! :) I understand it better now.
I believe it is useful to keep the structure of id and data, similar to my original article, so that in the future, it would be possible to use same xml protocol not only to download games, but also upload games, and server would recognize them and append to the main database.
Then it will be possible for people to compose games offline with their client program, and then upload the xml file with maybe hundreds of games in it.
Just ideas... :)
Lets discuss further. |
| |
| Farmer Lu | 2008-03-18 14:23:29 |
>>I believe it is useful to keep the structure of id and data, similar to my original article,
to big lu :
how do you think about it ? |
| |
| Ando Meritee | 2008-03-18 16:38:46 |
SGF format was designed in the purpose of presenting "single" games with the good capabilities of adding branches into analyses of that game together with nice markup tools for board marks (good move, bad move, circle, area, ABC, etc). SGF was designed for GO game, and because nearly every go game has different opening, therefore there was never any need for structured games database for go that could link the games based on position and make search among them. For that reason, it was even ok to keep every single game in separated sgf file.
SGF is a convenient format to generate "discussions of game", or "joseki libraries", etc.
Renju however has one big difference - we can have thousands of games with same opening moves, or even same 10-20 moves. It allows to create programs that can use search criteria such as "setting a requested position on the board" together with filters of "player name", "year", "result", "tournament name", etc.
Renlib format, unlike sgf, was built on the idea that renju games have similar beginning, therefore it's "default search" option is to search among similar games.
Of course, I must admit that I am really very beginner in the matters of data formats, and that is why I opened this topic, so that smarter people than me could give their opinion and example how the data should be formatted, and I could then just trust their expert opinion, use their example model, and create the server's database output accordingly.
Most players have tried out the old DOS version of Stepanov's renju database program. It had very nice capabilities about search, and we used it for maybe over 10 years, but today it is unfortunately too outdated. In most new computers it cannot even be opened. Also, despite great efforts by Stepanov and Sinyov, it was too tiring for them to keep it updated frequently, and players missed the chance to have an offline database with most fresh games.
I hope, having such "open source" protocol for our game database will solve these problems as more people will have an opportunity to design any kind of reader program, and it might be an exciting challenge for all programmers who are renju fans at the same time.
In my opinion, the viewers do not have to use all the capabilities that the structure offers. Some viewers are perhaps just designed to collect the "moves" of each game record only, while ignoring the rest, thereby just creating a kind of anonymous moves library, just to learn more opening theory perhaps. It would be simple and compact, and maybe some people would like such version, too. It is their free choice.
My hope is that the format we will use is good and well-structured enough to allow the creation of all kinds of software - tiny ones (move-trees only), classic ones (search capabilities and move-trees), and advanced ones (classic + an option to produce data for uploading to server). |
| |
| Frank Arkbo | 2008-03-25 05:38:39 |
I think XML is the best format to use for export of RenjuNet tournament games. It's readable in an text editor and thus possible to use even without a reader. Making a new reader requires less effort than for example SGF. The XML format can also be extended in future.
If XML is the chosen format then I will update RenLib as soon as possible. But if the format is for example SGF then RenLib will not be able to read, because I don't have the time or motivation to dig into the details of SGF, and since RenLib is already prepared to read a preliminary XML format that work effort will be wasted. |
| |
| Wenzhe Lu | 2008-03-25 22:25:21 |
| Hi Frank, I agree with you that XML looks to be a good format for RenjuNet database. BTW, Renlib has already had a simple SGF reader. Through we may need to update it a little bit if we want to get more information. |
| |
| Oleg Mostovlyansky | 2008-04-09 17:31:28 |
XML is good format, because allow various data structuring... is universal.
In sample provided by Ando:
<game id="23" tournament="25" round="1" rule="1" black="1" white="2" bresult="1" wresult="0" btime="56" wtime="78" opening="11" alt="j9" swap="R">
<move>h8 i9 g7 h9 g9 i7 i8 g8</move>
<info>...</info>
</game>
This is adapted to current RIF rules ("bresult" and "wresult" - is not abundantly? :-) ); but no problem to add more alternatives, swaps etc. From my point, here is lack of possibility to input comments inside game - for any move, not only <info> for whole game... but it is no problem to modify the structure of <move> tag, hopefully. |
| |
| Ando Meritee | 2008-04-09 17:47:14 |
Thanks for these suggestions. About bresult and wresult, I added them both because theoretically a 0:0 score may also apply in some rare cases. For example both players were disqualified, but their game may still have some interest for viewers. Maybe it is not very important situation, and I can omit the wresult. Also, maybe non-RIF rules can allow different scoring, like 2:0 or 2:1 for one game.
About the comments for each move, it is a good idea. It has not been implemented yet.
In future, we can expand the format. Any good ideas?
|
| |
|