howard@cpocd2.UUCP (Howard A. Landman) (02/23/88)
This set of postings is derived from a HyperCard stack that I developed as a way to keep track of the games and fuseki I had been entering for an opening library for the Godb program. As such, it includes references to full games (with and without commentary), and also partial games if the first moves are given or can be readily deduced. It does not include any other category of Go literature, such as life-and-death or endgame problems. One has to draw the line somewhere. In posting this stuff, I decided to format the data as normal UNIX text so as to make it available to as many people as possible. The format is such that it should be easy to write a HyperTalk script to rebuild the stack from the text file. (I already wrote a script to generate the text from the stack.) When I write such a script, I'll try posting the (empty) stack to comp.binaries.mac. This should save space, since the full stack is over 250 KB but the text file and empty stack are only about 166 + 24 = 190 KB. THE TEXT (parts 2 and 3 of this series) WILL NOT BE POSTED TO ANY MAC-RELATED GROUP; THOSE WHO WANT IT SHOULD GRAB IT FROM rec.games.go NOW. The data in this first release are, necessarily, biased by the limitations of my own Go library. I would very much like to expand beyond those boundaries, and you can help me. Here's how: 1. You can enter new information, and send me a text file containing (preferably) just the extra information. I'll add it to the stack for the next release, whenever that happens. For my address and preferred formats, see point 4 below. 2. You can send me old unwanted Go magazines and books; see the address below. I prefer English, and can muddle through both German and Japanese, but certainly won't reject anything else! Then I'll (eventually) add them to the stack. Eventually, I may also want to borrow sources that I don't have, at least long enough to enter the games, but I haven't exhausted the libraries of my friends yet. Stay tuned. 3. Accuracy is at least as important as volume, so you can do me and everyone else who uses this stack a BIG favor by picking a portion of the stack to check for mistakes. It will help if you have the appropriate source. I'm sure there are quite a few errors, especially of omission, since I added some fields to the card partway through entering the data. This process may not be finished (I still don't have an "official" way of noting that the game was played on a 13x13 board, for example). Suggestions are welcome. 4. Since my whole reason for doing this was to get games entered (that is, all the moves, in addition to the information in this stack), I would greatly appreciate any machine-readable game records that you could share. Preferred media are, in this order, email, 3.5" Mac floppy, DEC TK50 tape, 5" IBM floppy, 9-track 1600 BPI tape in "tar" format. Since translators are easy to write, I don't care exactly in what format the games are encoded, as long as you tell me what it is. My software can handle branches and even reconvergence, so if your format can include that kind of information, please leave it in. I hope to publish what I have, in a format compatible with this stack, later this year. 5. In some cases, more than one reference is given for a single game. I found a few of these "by hand", but it is probable that more still lurk undiscovered. Can you find one? Can you identify any of the mystery games at the end? I hope you enjoy this little tour of Go history. I wish the elegance of this stack approached the elegance of the game itself, but I must confess I spent more time entering the data than polishing the user interface. Howard A. Landman Usenet: {hplabs,oliveb}!intelca!mipos3!cpocd2!howard CSNet: howard%cpocd2.intel.com@RELAY.CS.NET USMail: 1725 S. Westwood Mesa, AZ 85210 Phone: (602) 839-2225 (Home) (602) 961-2205 (Work) What follows is a detailed explanation of the fields. The wording assumes you are entering new data, but you should read this even if you are just a passive user. In the text file, each field begins with a keyword terminated by a colon, and ends with a newline. I am painfully aware that what follows may be taken as a portion of a language in which to specify Go games. I don't wish to add to the confusion in this area; if a good standard emerges this year or next, I reserve the right to change the format of the next release to conform to it. On the other hand, I have spent some time thinking about these issues, trying to make a sensible format, and this posting reflects some of my conclusions, particularly on how the score should be reported. First some general conventions. Not all the data is certain. An item which may be in error is marked with a trailing question mark. An item that is almost certainly in error (i.e., is just a wild guess) is marked with two question marks. Sometimes it's better to have a wild guess than no data, especially for the date. In some cases, these guesses are based on the known dates of someone's career. Question marks immediately following (no space) a data item apply only to that item; question marks preceded by a space apply to all preceding items in the field. Date: contains the date the first move of the game was played, in the format YYYY-MM-DD. It wasn't possible to use normal HyperCard dates because HyperCard can't represent any date earlier than Jan 1, 1904, and many of the games took place before then. Thus, in order to get normal ASCII sorting to handle the dates correctly, it is necessary to stick to the format given. If a game is ever entered that took place before 1000 AD, it should still have four digits for the year, including a leading zero. Because the date is the main index for the cards, THIS FIELD IS REQUIRED, NOT OPTIONAL. If you don't know the date, use a single question mark. Black: and White: give the names of the players. Normally this is one name each, but team games have been played, and there is one such in the stack. All names are given family name first, which is the natural order for Oriental names. If the name would normally be ordered differently, a comma marks the place it was reversed. Thus, we might see "Takagawa Kaku" or "Redmond, Michael", but not "Eio Sakata" or "Janice Kim". BRank: and WRank: Is given in the numerical scale, with a few exceptions. Professional ranks are followed by upper case letters, as in "9D". Amateur ranks use lower case, as in "1k" or "1d". (For those of you on machines which are totally case-insensitive, I have no apologies. Get a real machine.) Sometimes it is impossible to tell which is which from the source. Take your best shot; we can argue about it later, if it matters. The special state of being a professional who has not yet achieved 1D is called "insei"; I thought about calling this "1K" but it seemed like an abuse of the system. For the most part, I don't recognize the rank "10D", which is really a title like "Meijin" or "Honinbo". Event: The event, of which the game was a part. This should be as specific as possible. Sequence numbers are preferred over dates, that is, "12th Honinbo Title" is better than "1956 Honinbo Title", primarily because there is already a field for the date. Put general information before more specific information, as in "7th Kisei tournament, playoff, game 3". "WAGC" means World Amateur Go Championship. Place: Where the (first move of the) game was played. In this case, proceed from the most specific to the most general, by analogy with mailing addresses. For example, "Tan Oak room, Student Union, U.C. Berkeley, California, USA". If you have to leave anything out, leave out the most general part. If the location is in a well-known major city, you can stop with the city ("Tokyo" being a common example). In a few cases where very many games are played (e.g. "Nihon Kiin"), not even the city need be given. Score: This is the final score ON THE BOARD, that is, ignoring komi. Black ahead is represented by positive numbers with explicit leading "+"; White ahead is represented by negative numbers. If the number given is an estimate (common when one side resigns), append an "E" to it. Japanese rules are assumed; if the counting is by Chinese rules or Ing rules, add a "C" or "I" respectively. This field may be left empty if the game ended in resignation and you don't have any way of guessing. Komi: The number of points given by Black to White to compensate for the priviledge of moving first. This will almost always be non-negative, but there is one game in the database with negative komi (given in lieu of an extra handicap stone). In handicap games, and games before 1945, komi is almost always zero. Result: The score after komi is taken into account, that is, usually, (Score - Komi). This should have an explicit sign, just as Score. If White resigns, the Result is "+R"; if Black resigns, "-R". An estimate of the margin of victory may be included; "+4.5R" means "when White resigned, Black was ahead by about 4.5 points, counting komi". Handicap: The number of handicap stones placed by Black. If this was zero, leave the field empty. Some ancient games place both Black and White stones on the board to begin; this is repesented as, e.g., "2+2 (tasuki)". Source: Each line represents a reference in the literature that describes this game. Since this stack only includes games so described, each card must have at least one line in this field, so THIS FIELD IS REQUIRED. Most games have only one reference. A few have two, which indicates different sources for the same game. Therefore, THIS FIELD MAY BE REPEATED (in HyperCard, it is a scrolling field with one line per reference). Always put references in decreasing order of completeness; full game with commentary, then full game, then partial game. Some common abbreviations: AGJ American Go Journal GR Go Review GW Go World Comment: Anything else you would like to say about the game, etc. This may be, for example, a note on the historical interest of the game ("first occurrence of Shusaku 1-3-5"), or a correction to errors in the source ("p.17 gives players the wrong colors"). Sometimes it can be difficult to tell whether to put something in the Event or Comment field. There's nothing to prevent this field from being repeated, but my HyperCard stack only allows one comment line at the moment; for compatibility, you may want to stick with that limit. (The raw data follows in parts 2 and 3.)