Author: Dann Corbit
Date: 11:25:36 03/07/06
Go up one level in this thread
On March 04, 2006 at 04:07:05, Mark Boylan wrote: >On March 04, 2006 at 02:56:12, Keith Kitson wrote: > >>Just reading through the thread on Opening books, proposals etc. it strikes me >>that we are in danger of presenting the solution before we have a firm grip on >>requirements....always a dangerous approach. >> > >Good point. > >>My suggestion for the requirements of the software would be: >> >>1. A stand-a-lone system portable to all platforms > >I agree. Me too. >>2. Able to accept all formats of opening book and convert to any other >>recognised format > >Not all formats are known or freely licensable. One standard format would be >ideal. The PGN standard is our target for durable output. It is already spelled out and we know that it works. Furthermore, every chess program worth two cents can read and write that stuff. >>3. Software written to enable easy addition of new formats by developer > >I suggest a reference implementation that can be used intact or adapted for the >application. But I still feel that a standard file format is needed. I think that we should aim to form a comprehensive enough format so that new formats are NOT constantly needed. That way, we can exchange book information in a simple way. >>4. Comprehensive editing facilities >> >>These requirements are independent of the language to be used to write the >>application. >> > >A variety of reference implementations can be provided. Someone will want to use .NET, but not everyone on Linux wants to install MONO. Someone will want to use Java but not everyone wants that either. Someone will want to use wxWindows but that's no good for Mac. Someone will want to use the Mac native API calls. We should not care about the GUI for a SQL book project. Once a database standard has requirements gathered, is designed, written and debugged, a thousand editors will fall out from it in one month. >>I suspect the main problem is justifying the writing of a system and finding a >>developer/s to write and implement. >> > >I don't know. From the response, I'd say that lots of people are and popular >interest is the best justification. I guess that most of the good chess engines are $100,000 projects that were done just for the fun of it. >>Perhaps if this were made a commercial concern, i.e. with a cost for the package >>it may be viable to write and support such an application. >> > >Many bigger projects than this have been completed without comercial >justification. Think Apache. GCC. PostgreSQL. ACE. The list goes on and on. Of course, all three of those now have serious commercial merit and are used commercially by fortune 500 companies. >>I'm not sure if there would be any contravention of owners existing book format >>rights if a package was written to match the above requirements. i.e. would >>chessbase complain about catering for their book format etc. >> >>KK > >I don't think that the idea should be to leverage an existing format, commercial >or otherwise. I think the best format is one that has yet to be defined. I agree. On the other hand, we should look at what people are using now and make sure that we don't overlook some vital feature that would mean critical functionality is missing. >I understand Dann's point of view with leveraging SQL. But I really don't think >we're talking about a storage format here. I think we're talking about a format >for exchange. I think that SQL is the perfect solution for a chess database, >engine UI, or book authoring system to store data. But when I want to send a >friend an opening book, it should be a simple file in a well known format. Even the format is irrelevant. I don't care if it is ISAM or HTML or Oracle. But I want to access it with ANSI/ISO SQL. >The PGN specification has some unavoidable problems. For instance, it is >impossible to tell if the "Fischer, Robert" in a particular game is a resident >of Iceland who was once world champion, or Bob, the club player who lives down >the street. Without requiring them to sign the file with public keys, it's any >database's guess. The FIDE database has unique ID values associated with the players. We should use their ID values to avoid ambiguity when possible. >But somehow, the PGN has stood the test of time as the >ultimate format for the exchange of chess games. That's because it's easy to use >and it does the job as well as any format can. > >Opening books are less ambiguous than game databases. A chess position is a >chess position no matter how you write it, no matter how you encode it. Opening >books are really just trees of positions and evaluations. What's needed is a >format for exchange that's easy to use and does the job as well as any format >can. > >I think we need a PBN format. (Portable Book Format)
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.