Proposal: Standard for storing Shogi position information

Foreword: I know that similar work have been undertaken by different people already.
I don't claim I am inventing something that others didn't think of before. If you know some sources I'd be glad to put links to them in this post.

That said, I move on to the subject with is a proposal of standard for storing positional data in Shogi. I called it Shogi FEN (or SFEN) because it is derived from FEN standard designed for chess. I write more about the standard itself on ShogiTools project's wiki. Here I try to advocate the need for a standard like SFEN.

Do we need such a standard

I think it is very important to have a standardized way to write Shogi positions. This way data are easily exchanged between programs. Let me give you some examples:

1. Imagine you have a database program that stores tsume Shogi problems. Your computer is Mac with English OS, your friend has Japanese Windows and he uses different database program and you want to share the problems with him.
2. You post some positions from games of masters as a diagram on your web page using some flash application. The application is faulty and you want to switch to other program, let's say Java applet.
3. You want to have a test suit of 100 positions for benchmarking different Shogi engines.
   

In all these situations, if there is a standard way to store positional data, there is no additional work required on your side. Otherwise there should be some conversion mechanism provided. Moreover, to be able to convert between proprietary standards you have to know them both.

What's so good about SFEN

Nothing :-). At least nothing until it becomes a standard. But what are the 'pros' of it?

It's more compact than traditional ASCII-diagram notation. The whole position data fits a sigle text line. In my opinion they are also easier to interpret by programs and quite readable by humans at the same time.

The idea of similar standard succeeded in chess world. I think we could learn from their experience and adopt similar solution.

Why wouldn't we want SFEN

I can think about only one good reason: "We already have a good standard for this and don't need another one".

If this would be the situation, I probably wouldn't bother making this post. But, as I see it, there are some solutions 'on the market', but:

1. They are not really standards -- there is many flavors of single 'standard'.
2. There is no formal specification for them -- at least none non-Japanese.

If you know of some standards, real or almost real, their specification on the net, please drop me a note. I'll be happy to post links to them and discuss them here.

Live demo

I prepared a site where you can see SFEN in action.

It's a nice moment for me, because the puzzles of my ShogiTools project start to fit together. In my earlier post about Tsume Parser I described how I translated tsume problems from shogi-l into computer-readable form.

Here I used the product of that project and made a simple converter to SFEN data.

Finally, I put all (almost 300) tsume on the page. You can see on-line SFEN to diagram conversion (and solve some tsume at the same time! ;-) ).

Note. When runing applications, don't worry if you see something like Can't contact servlet runner at 127.0.0.1:6905. MyJavaServer.com does this kind of things from time to time. Wait few moments and try again. MyJavaServer is down for good. The example has been moved to Google AppEngine.


Note 2. The page is best viewed with Mozilla browser. I could force Internet Explorer to cooperation. The elements are slightly misplaced. I think I finally won the IE battle.

Other works

After publication of the post there was some comments on shogi-l.
Bernhard C. März pointed out that there is similar way of storing Shogi positions described earlier. He gave a link to the archived shogi-l message: http://www.shogi.net/shogi-l/Archive/2002/Nsep29-03.txt.



Thank you for your attention. As always -- any comments and suggestions are welcomed.