Loading ...
Sorry, an error occurred while loading the content.

Re: ** SGF FF[5] **

Expand Messages
  • YAMAKAWA Kazuki
    ... (snipped) Hi, dears, It s exciting to start SGF[5] discussion. How about that we define SGF[5] s preceding target Implementing the ability to record the
    Message 1 of 6 , Feb 6, 1999
    • 0 Attachment
      Arno Hollosi wrote:
      > Hi,
      > the results of the CFV are: 7 votes for FF[5], 0 votes against.
      > Therefore we start discussing FF[5]. I'll post an announcement to
      > rec.games.go as well. The following issues should be discussed
      > (suggestions by voters):
      (snipped)

      Hi, dears,

      It's exciting to start SGF[5] discussion.

      How about that we define SGF[5]'s preceding target
      "Implementing the ability to record the whole of and
      the all kind of, as far as known, Go game" ?
      In another saying, a SGF[5] will be a perfect document
      of a played Go game.

      Then our point of view will be more clear, I guess.

      Thanks.
    • John Fairbairn
      Hi I m new to this forum, and newcomers are supposed to be circumspect. But in the hope that I can represent at least one section of ordinary users, may I make
      Message 2 of 6 , Feb 6, 1999
      • 0 Attachment
        Hi

        I'm new to this forum, and newcomers are supposed to be circumspect. But
        in the hope that I can represent at least one section of ordinary users,
        may I make the following comments.

        1. Even though I favour standardisation, I am dismayed by what I have
        seen so far. There seems to be a trend to make the spec fit the needs of
        the big fish - the databases, IGS, or Nihon Ki-in. Ordinary users seem
        to have different needs. Arno tells me that most SGF files he gets from
        other people are incorrect. That tells me that most users want to
        prepare their files in ways that the spec won't let them. Human nature
        demands that the spec should change to suit them, rather than users be
        dragooned into complying with an increasingly complex spec. Is the fact
        that most features in FF4 are unused, and the fact that FF4 is going to
        have a short life, not a sign that the standardisation is moving too
        fast?

        2. I am inclined to believe that, rather than make the spec cleverer and
        cleverer, the database or other software should be made cleverer. For
        example, splitting EV and RO might suit the needs of current software,
        but I don't see why the search engine could not be programmed to scan a
        single line of free text for whatever the database regards as key words.

        3. While I am not up to Jan's level, with Mark Hall I have a database of
        about 6,000 games. Most are in .GO format but I am rapidly converting to
        FF3 (I rejected FF4 for reasons that may become apparent below.) I come
        across so many things that the spec either doesn't allow or consider. In
        general it seems to me that the heavy emphasis by some people on modern
        games leads to overlooking many important things. For example, the old
        (or not so old - it is still used in the Oteai) handicap system (B-B-W
        etc) is VERY important because it affects the result of the game,
        relative standing of the players, etc) yet there is nowhere to put it (I
        was told to put it in Game Comment because HA won't allow text - I think
        that is absurd).

        4. I also find the DT date a major problem. Apart from the simple date,
        there are lunar dates. I believe in the ISO standard, so I convert such
        dates, but most people can't (or, worse, do what Invincible does and
        pretend they are Gregorian). Often old dates are given as era years
        (e.g. Kaei 1) but conversion would often require two western years
        because of the lunar/solar overlap. How does one deal with the (rather
        common) types exemplified by: "Early Qing era" or "Spring 1934" or "1894
        or 1895" or "Published 1985-01-01~02-03" or or "Played before he became
        a pro" or "Played 1845-03-03 and through the night till 9pm the
        following day" [nb putting 1845-03-03,04 would omit the interesting
        point that they played non-stop].

        5. I find EV and RO a problem in various ways. First the split seems
        artificial and secondly EV can be defined in different ways by different
        people. I prefer both "Meijin Final" and "Meijin League" (and also
        simply "Meijin") to be in EV, partly because these are seen as
        significant separate items in biographies of players (e.g. the number of
        times one has won a Final, or appeared in one, or appeared in a League,
        are listed as discrete achievements).

        6. An even bigger problem with EV is that tournament names have yet to
        be standardised. At the risk of seeming rude, I would say that much of
        the energy spent on rather esoteric parts of the spec could more
        fruitfully be spent here. (A couple of examples: is it Kisung, Kiseong,
        Kisong, Gisung, Korean Kisei, Kisei or what? Is it Women's Honinbo or
        Ladies' Honinbo (or Ladies Honinbo, which may throw some search
        engines]? Is it just Meijin or Old Meijin and New Meijin? Is it Hayago
        Senshuken, Hayago Championship, Lightning/Speed/Fast Go Championship?

        7. Players' names are a major problem, especially Korean. For many there
        are 5 or 6 current variants. I can claim to have offered a standard for
        these in my Names Dictionary (now out of print!) as virtually every name
        that can appear in a significant game record is there, but a strategy
        for making anyone follow the "standard" is beyond me.

        8. I find RE a problem. Many old games are left unfinished. They are not
        void. The reason they were left unfinished may be interesting (one
        player was losing so broke off, it was a ceremonial game, it was just
        meant to try a fuseki, etc etc). I have also recently encountered a
        "both players lost" game - is that covered? To me, it is also logical to
        include in the RE rubric information such as "No further moves known" or
        "White connects the ko" [it is wrong to play these moves out as part of
        the record - historical research often hinges on niceties such as these:
        e.g. one record says W connects the ko, another says B.

        9. TM: Don't forget that players may be given different times (as in
        some pro-am games)

        10. I have more points but I would be overegging the pudding to go on.
        The conclusions I draw from my own experience are (1) that FF5 would be
        an advance if it actually went backwards a little bit - in particular it
        should allow free-form text where possible; (2) most urgent effort is
        needed to standardise tournament names and player names; (3) the needs
        of ordinary users - people who enter game records, not programmers or
        anyone else with too much of a vested interest - should be given greater
        weight. (It would be of interest to know what the commonest "mistakes"
        of ordinary users are.)

        --
        John Fairbairn
      • Arno Hollosi
        From: David Fotland ... I agree and favor compatibility as well. The question is if we can abandon some seldom used features in favor
        Message 3 of 6 , Feb 8, 1999
        • 0 Attachment
          From: David Fotland <fotland@...>

          > I'd like to make a very strong plea for backwards compatibility.
          > SGF was conceived from the start to be extensible in a way that
          > new files can still be read by old software, and old files read
          > by new software.

          I agree and favor compatibility as well. The question is if we can
          abandon some seldom used features in favor of better defined entities.

          > Can we put a time limit on FF[5]?

          I'd say a reasonable time-limit would be discussing proposals during the
          next 6-8 weeks, and another 4-6 weeks to get the details fixed and the
          spec written. FF[5] could be ready by May.


          From: Dave Dyer <ddyer@...>

          > The core "shell" of SGF is a specification that will allow tools
          > to be written to read, write and manipulate collections of games
          > in SGF format, with no knowlege at all about what game type is contained.

          I agree that the new spec shouldn't be game-specific. As far as I can see,
          most changes will happen to the game-info properties, with some slight
          modifications elsewhere. Plus restructuring of the spec according to the
          property set concept. As most of as use SGF only for Go, I'd appreciate
          if you'd point out things which are too Go specific.

          /Arno
        • Arno Hollosi
          ... Could you describe the needs of an ordinary user? While creating FF[4] I posted to rec.games.go that I like suggestions by users about their needs. IIRC, I
          Message 4 of 6 , Feb 8, 1999
          • 0 Attachment
            John Fairbairn <JF@...> wrote:

            > There seems to be a trend to make the spec fit the needs of
            > the big fish - the databases, IGS, or Nihon Ki-in. Ordinary users seem
            > to have different needs.

            Could you describe the needs of an ordinary user?
            While creating FF[4] I posted to rec.games.go that I like suggestions by
            users about their needs. IIRC, I got about 5 replies, ALL of which were
            about program issues and not file format issues. To me it seems that
            there are only few programs which are truly user-friendly.

            > Arno tells me that most SGF files he gets from other people are incorrect.

            Apart from the usual DT[Jan 4th 1991] or RE[Black wins] most errors are
            made by the programs. Most of the time when using variations. Is
            reading/writing variations really so tough? The range of errors that
            I come across never ceases to amaze me.
            Standard call: Use SGFC to check the output of your application !!!

            > That tells me that most users want to prepare their files in
            > ways that the spec won't let them.

            I argue that it's because of sloppy programs and not because of SGF.

            > Human nature demands that the spec should change to suit them,
            > rather than users be dragooned into complying with an increasingly
            > complex spec.

            I agree. But the spec itself should (almsot) be transparent to the user.
            But this is the task of applications. Of course the spec should make
            it easy to create SGF compliant applications.

            Coming back to the "big fishes": this is why I think "property sets"
            are a good idea. "Little users" use the basic sets which suit there
            needs. And the "big fishes" use extended sets to store all the
            information they want to store.

            > but I don't see why the search engine could not be programmed to scan a
            > single line of free text for whatever the database regards as key words.

            This is true. However, if you want to have interchangeable SGF games
            you would need to specify those key words. Otherwise everyone would
            have to write a conversion program for their database. And if we can
            agree on key words, why not make them properties, such as EV & RO?

            > ... the old handicap system (B-B-W) ...
            > ... DT date a major problem ...
            > ... EV and RO a problem in various ways ...
            > ... find RE a problem ...
            > ... TM: Don't forget that players may be given different times

            These issues will be addressed in FF[5].
            Also, see Jan's suggestions for team players and other information.

            > "Played 1845-03-03 and through the night till 9pm the
            > following day" [nb putting 1845-03-03,04 would omit the interesting
            > point that they played non-stop].

            I think that this information should be put into GC and that DT
            should contain 1845-03-03,04.

            > (1) that FF5 would be an advance if it actually went backwards
            > a little bit - in particular it should allow free-form text where possible

            Yes. Many of us agree on this.

            > (3) the needs of ordinary users - people who enter game records,
            > not programmers or anyone else with too much of a vested interest

            I agree. As pointed out above, most users are concerned about the
            program interface and the functions provided.

            > (It would be of interest to know what the commonest "mistakes"
            > of ordinary users are.)

            Of users: formatting of game-info properties (as most programs don't
            provide a specific interface that does the formatting for them).
            The most errornous property is TM (if entered manually - not on
            sever games for apparent reasons), closly followed by DT and RE.
            Other "errors" are e.g. making sibling variations in an application
            which displays variations as childs. (Done by removing move with AE and
            making new move within one node - illegal since FF[4]).

            Of programs: variations in all forms: empty variations "()", Ishi style
            variations (sgf2misc), completely trashed variations (some versions of
            WinMGT), basically everything you can make wrong with '(' and ')'.
            Other errors include multiple properties (e.g. two C[] in one node),
            wrong values (e.g. LB[1:bc] instead of LB[bc:1], or LB[bc:]), splitted
            property ID's (e.g. W (linebreak) L[43] - during mailing/posting --
            which @#$% mail clients split words ??????).

            AGAIN: Standard call: Use SGFC to check the output of your application !!!

            > (2) most urgent effort is
            > needed to standardise tournament names and player names;

            True. But this is beyond the scope of the spec, though we could recommend
            using your dictionary. I can't think of a way to enforce this. If the
            "big fish" adopt that recommendation then step by step those names will
            be accepted. E.g. it's my experience that Jan's spelling is regarded
            as a de-facto standard by many users.

            /Arno
          Your message has been successfully submitted and would be delivered to recipients shortly.