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

RJ proposals

Expand Messages
  • Robert Jasiek
    This letter contains proposals about several prperties. ... AN simpletext Function: Provides the name of the person, who made the annotations to the game.
    Message 1 of 5 , Feb 7 8:55 AM
    • 0 Attachment
      This letter contains proposals about several prperties.

      ---------
      AN

      simpletext

      Function: Provides the name of the person, who made the
      annotations to the game.

      Notes: "annotations" has to be specified more clearly.
      Does it include the recorders or is another property needed
      for them? Especially professional games can have recorders
      (or mechanical record tools)!

      ---------
      BR
      WR

      simpletext

      [additionally NEW:]

      PR

      list of composed number ':' simpletext

      [NEW] Functions:
      Provides ranking information on the [black/white] player[s].
      Information may describe rank value, rank unit, rank class,
      rank system, rating value, rating unit, rating system. A
      go server rating unit may consist of or include '?' for an
      uncertain rating and '*' for an established rating. For
      "kyu" and "dan the abbreviations "k" and "d" may be used.

      [PR:] The first property value gives the player standard order
      number that must be given by PO. The second property value gives
      the ranking information.

      Example:
      ;PO[1:Super Internet][2:China Power][3:Tiny Trinidad]
      PR[1:7d*][2:5 dan professional China 6147 ELO Chinese
      professional rating system][3:27k]

      ---------
      [NEW: player order]

      PO

      list of composed number ':' simpletext

      Function: Provides the player names and their standard move
      order. Numbers must be 1,2,3,... Typically players move in
      standard move order. If a game tree uses B and W, then the
      moving player is given due to the standard move order. If
      a game tree uses M, then for each move the player is explicitly
      given by his PO number. If PO is not used, then PB and PW
      specify the player names and the players move in B-W order.

      Notes: This property can be used for multi-player games and
      for games with special rules.

      Related: PR, M, B, W

      ---------
      [NEW: move]

      M

      composed number ':' simpletext |
      composed number ':' simpletext ':' move |
      composed number ':' simpletext ':' real

      Function: This is the most general way to specify a move.
      In a game tree one may either use B and W or use M.
      The number specifies the player due to PO. The number 0
      [zero] means any player.
      The simpletext specifies the move type, see below.
      The property value move specifies coordinates referring to
      the move type. If a move type requires coordinates,
      then they must be given (marked * below).

      Move types:

      B :
      black; depending on the game phase, it can also be an
      added (confirmation) stone instead of an alternately played
      stone; *
      W :
      white; depending on the game phase, it can also be an
      added (confirmation) stone instead of an alternately played
      stone; *
      n :
      colour n; must be a player number specified by PO; if only
      two colours occur in a game tree, then B and W must be used
      instead; depending on the game phase, it can also be an
      added (confirmation) stone instead of an alternately played
      stone; *
      pass :
      regular pass; successive regular passes can a) end a game
      phase and start a subsequent game phase according to the
      rules or b) end a variation; rules with free handicap can
      require a player to pass until all handicap stones are set;
      verbal actions, etc. with the meaning of explicit passes or
      result agreement are given as regular passes; time stops
      running according to the rules after successive regular passes
      valued pass :
      passes while specifying a value according to the rules;
      requires a real value that sets the new sum komi value;
      can be used for bidding komi, environmental token go, auction
      go
      pass for ko :
      a pass that specifies one ko according to the rules; no
      stone is placed but coordinates are verbally specified; *
      resume :
      offers a resumption; successive offers of resumption let the
      game continue with the situation (game phase, position,
      prisoners, move right) just before the first regular pass
      of the last preceding succession of regular passes having
      introduced the current game phase (possibly time resumes
      running according to the rules)
      resume opponent :
      like resume but resumption is immediate with the opponent
      having the right to move [Nihon Kiin 1989 rules]
      request :
      offers a phase request other than a regular pass or a
      resumption; successive offers of such requests start a new
      game phase according to the rules [in WWGo 1996 or Japanese
      1997 rules there are requests to play-out-to-completion, e.g.]
      remove :
      offers a removal of a stone; no stone is placed but the
      specified stone is removed from the game if all players
      [or player 0] offer its removal during the current game
      phase; *
      capture :
      offers a capture of a stone; no stone is placed but the
      specified stone is removed from the board and added to the
      prisoners if all players offer its capture during the
      current game phase; *
      score :
      offers to include the specified coordinate in the score;
      a specified coordinate is included in the score if all
      players offer it during the current game phase; [particular
      types of scores like "alive", "dead", "seki" can be given by
      the properties C or LB]; *
      add B :
      adds a black stone without causing removals; can be used for
      filling-in, e.g.; *
      add W :
      adds a white stone without causing removals; can be used for
      filling-in, e.g.; *
      undo :
      restores the situation to the state just before the prior
      move that is not restored yet and no undo itself [necessary
      to keep a record while undoing on a server or due to illegal
      moves]

      Notes: The list is sufficient for any widely used rule sets, esp.
      incl. Nihon Kiin 1989, WWGo 1996, IGS, Ing 1991, and allows
      multi-player games. [I could give examples later.]

      Related : B, W, PO

      ---------
      DT

      simpletext

      [additional] Functions: If possible, the simpletext is
      interpreted as information in ISO-standard format using
      the Gregorian calendar and the following syntax. Otherwise
      the simpletext is not automatically interpreted. [...]

      ---------
      EV
      RO

      simpletext

      [NEW:] make RO obsolete and allow EV to include information
      about the event context [like congress], the event title,
      the event stage, the type (or round number) of a game within
      a stage, etc.

      ---------
      [NEW: sponsor]

      SP

      simpletext

      Function: Provides information about the sponsors.

      ---------
      [NEW: referee]

      RF

      simpletext

      Function: Provides information about the names and functions
      of all referees.

      ---------
      [NEW: time keepers]

      TK

      simpletext

      Function: Provides information about the names and functions
      of all time keepers.

      ---------
      [NEW: commentators]

      CO

      simpletext

      Function: Provides information about the names and functions
      of all (officially) involved commentators.

      ---------
      [NEW: persons involved]

      PI

      simpletext

      Function: summarizes all involved persons other than the
      players; makes several game info properties redundant
      [this is my preferrence]

      ---------
      RE

      composed simpletext ':' simpletext

      [completed:]

      The second property value states all details.

      First property value:

      "0" or "Draw" :
      jigo, tie
      "B+" or "B+<real>" :
      B win in a 2 colour game
      "W+" or "W+<real>" :
      W win in a 2 colour game
      "M+" or "M+<real>" :
      multi-colour game with a win of one or more players
      [details should be given]
      "B+R" or "B+Resign" :
      B wins by resignation in a 2 colour game
      "W+R" or "W+Resign" :
      W wins by resignation in a 2 colour game
      "M+R" :
      multi-colour game ends by resignation
      "B+T" or "B+Time" :
      B wins by time in a 2 colour game
      "W+T" or "W+Time" :
      W wins by time in a 2 colour game
      "M+T" or "M+Time" :
      multi-colour game ends by time
      "B+F" or "B+Forfeit" :
      B win by forfeit (due to illegal action) in a 2 colour game
      "W+F" or "W+Forfeit" :
      W win by forfeit (due to illegal action) in a 2 colour game
      "M+F" or "M+Forfeit" :
      win by forfeit (due to illegal action) in a multi-colour
      game
      "Void" :
      result "no result", result "maximal allowed move number"
      (constant game end [used on IGS, e.g.]), legally and finally
      suspended play
      "Adjourn" :
      adjourned game that can be resumed or reloaded [details
      might say "lunch break", "net break", "mutually agreed
      adjournment with B losing by forfeit after 30 days", etc.]
      "?" :
      unknown
      "BW+" :
      B and W win in a 2 colour game
      "BW-" :
      B and W lose in a 2 colour game
      "M-" :
      all players lose in a multi-player game

      ---------
      RU

      simpletext |
      composed simpletext ':' simpletext |
      composed ':' simpletext

      [extended] Functions: The first property value, if given,
      uses database rules names, where mandatory. A second
      property value gives detailed information on rules,
      tournament rules, tournament system specifications, etc.

      Example: EV[EGC 1997]RU[:Ing 1991 rules of play with 8 komi
      for boards 17+, Nihon Kiin 1989 rules of play with 5.5 komi
      for boards 1-16, EGF tournament rules, EGF GP guidelines,
      EGF GP regulations, MacMahon with bar at 4d and super group,
      10 rounds]
      Example: RU[NZ:New Zealand rules of 1975 with positional
      superko]

      ---------
      HA

      [to be clarified]

      ---------
      KM

      [note: see value pass in property M, complex RU; revision
      necessary?]

      ---------
      time needs revision and fit various systems incl. Canadian,
      Nihon Kiin, IGS

      ---------
      FG, printing, and book layout could be refined, but the
      experts should give their opinions here.

      ---------
      IY

      [NEW: make it a general property}
      [different coordinate scales?]

      ---------
      [NEW: automatic translation]

      CN
      CV

      autotext

      Functions: Provides comments on a node or a variation. The
      comments can be translated by computer editors due to a table
      of ~500 standard words with English as standard column.
      autotext is a string of standard words.
      Example:
      CV[joseki right fuseki wrong]
      would be translated to German, e.g., as
      "Joseki richtig Fuseki falsch"
      Example:
      CN[attack strategy]
      ->German: "Angriff Strategy"

      [I know, only if you like translations, otherwise I will not
      mention it any longer:)]

      --
      robert jasiek
      http://www.snafu.de/~jasiek/rules.html
    • Robert Jasiek
      This letter is about: - moves in general (property M) - multi-player games - game recording after the alternation phase ... [...] Simple examples: (Note: the
      Message 2 of 5 , Feb 10 6:02 AM
      • 0 Attachment
        This letter is about:
        - moves in general (property M)
        - multi-player games
        - game recording after the alternation phase

        Robert Jasiek wrote:
        > ---------
        > [NEW: move]
        >
        > M
        >
        > composed number ':' simpletext |
        > composed number ':' simpletext ':' move |
        > composed number ':' simpletext ':' real
        [...]

        Simple examples:
        (Note: the numbers refer to the players in player order PO.)

        Normal alternation:
        (;M[1:B:jj];M[2:W:ii];M[1:B:hh];M[2:W:gg];M[1:pass];M[2:pass])

        Illegal play:
        (;M[1:B:jj];M[1:W:jk]RE[W+F:black moved twice in a row and used
        a white stone])

        Agreement phase included:
        (;SZ[3]RU[:International Rules with area scoring]
        ;M[1:B:aa];M[2:W:bb];M[1:pass];M[2:pass];M[0:remove:aa]
        ;M[1:pass];M[2:pass]RE[W+9])

        Disagreement in agreement phase:
        (;SZ[3]RU[:International Rules with area scoring]
        ;M[1:B:aa];M[2:W:bb];M[1:pass];M[2:pass];M[1:pass]
        ;M[2:remove:aa];M[0:resume]C[alternation phase is
        resumed];M[1:pass];M[2:W:ab];M[1:pass];M[2:W:ba]
        C[removes surrounded stone at aa];M[1:pass];M[2:pass]
        C[agreement phase entered the second time]
        ;M[1:pass];M[2:pass]RE[W+9])

        Multi-colour game:
        (;M[1:1:jj];M[2:2:jk];M[3:3:kj];M[1:1:dd];...)

        -------------------
        What is M good for?
        -------------------

        - regular alternation
        - any game phases after alternation independent of the rules
        - agreement / confirmation / scoring / counting
        - illegal moves
        - team games
        - multi-colour games
        - special move types like Nihon Kiin's pass for ko
        - undo without loss of information

        Currently B and W only allow the alternation phase with
        two players and legal moves. We can hardly avoid an
        additional property M that enables all the above
        possibilities.

        It would be easy for us to continue to pretend that all
        rules in the world are simple rules, but in reality
        they are more sophisticated and we have to respect this
        by an appropriate property model.

        What do you think?

        --
        robert jasiek
        http://www.snafu.de/~jasiek/rules.html
      • YAMAKAWA Kazuki
        == against M == (but for concept of PO, PR) Reasons: 1. M is still not satisfactory for general moves for all games. e.g. Chess, Shogi, etc. Move property
        Message 3 of 5 , Feb 14 10:47 PM
        • 0 Attachment
          == against 'M' == (but for concept of PO, PR)

          Reasons:
          1. 'M' is still not satisfactory for general moves for all games.
          e.g. Chess, Shogi, etc.
          Move property value type should be defined by each game.
          I agree to reserve 'M' for move's propertyID, however.
          2. SGF has unverbal assumption that sgf is read by computer mainly,
          and normal moves are treated according to rule.(i.e. e.g. Stones
          surrounded by opposite color stones are to be removed and counted
          to opponent's captured stones by the application.) In another words,
          'M' ignores this assumption and lacks remedial directions to the
          application.
          3. Generalization is not always good and SGF is intended to being
          compact file format and practical in normal use, I think.
          4. 'M' breaks backwards compatibility. W[], B[] is satisfactory for
          normal moves, also compact. W[], B[] should be applicable in the
          future SGFs, I think.
          5. 'M' differs to traditional move's concept. i.e. Some of 'M's
          are not counted as a move.
          'M''s nature seems to be a SGF node, not match with a custom move.

          == Alternatives == s:simple text p:point n:number
          property : property type
          E[s:s] RM[p] : node
          P[s]+ PO[n]+ PR[s]+ : game-info
          PLY[s or n] : move

          //game Event//
          There are events which influence to the game, even they are not
          moves.
          So I propose game Events concept and propertyID 'E' and a custom
          writing rule -- a game tree ends with a node which contains 'E[]'.
          This wraps FN[] concept that I proposed before.
          Resignation, Referee judgment, Time expired, Agreed draw, etc.
          are game events that influences game result or game sequences,
          However they are not counted as moves, they are critical for the game.
          So, I propose we call them game Events and its ID 'E'.

          E[s:s] == [event performerID : eventID]
          performerID: B, W, A(all), R(referee or Rule)
          eventID: (W|B)resigned, (W|B)timedup, (A)enter_scoring,
          (A)agreed_draw, (A)agreed_void, [(R)official_break ]
          (R)for(B|W|A), (R)illegal_color, (R)illegal_turn,
          (R)illegal_removal, (A)adjourned, (A)resumed, [(W|B|A)undo ? ]
          IDs with [] are not sure of its neccesity or appropriateness.

          //ReMoval//
          RM[(-)*point]*. -- *:appears 0 or more times.
          ReMoved stones illegally.
          '-' means forgotten/left stones which were captured.
          So, if RM[fg] appeared, application should remove a stone at [fg], and
          captured stones +1. RM[-fg] is contrary, application should add a stone
          at [fg], and captured stones -1, to the context of the game.
          //Player//PlayerRank//
          P[player1][player2][pleyer3]+ :game-info: same meaning as RJ's PO[].
          PR[player1's rank][2's][3's]+ just dont have index entity
          This is used for 3, and more than 3 players game, when the writer
          wanted to describe the order.
          Otherwise, PW[player2] PB[player1,player3] should be used.

          SGF applys multiplier rule for propertyID and values, like LISP
          language.
          i.e.g. LISP 1+(1 2 5) == 1+2+3
          I prefer not introduce more and more syntaxes.

          //PlayerOder//
          PO[playersIndexNumber]+ Specifys order a cycle. Abnormal order like
          [1][2][1][2][3] can be able to specify. Normal order is omittable.

          //PLaYer who performed the move//
          PLY[players_ID_number] : this is a move's attribute : to indicate
          the player who performed the move if needed. This is mainly to
          describe that the move was illegal because the performer was not
          to move. In the case, as the game have Joker players, this is useful.
          e.g. When PW[ama2,ama4,proW]PB[ama1,ama3,proB] and the rule is that
          each pro can move only 3 moves throughout the game.
          (;...P[ama1][ama2][ama3][ama4][proB][proW] PO[1][2][3][4]
          .....;B[hg]PLY[5];W[fd]PLY[6];B[jg]....
          This kind of game are taken place sometimes in Japan, such as new
          years holiday attractions. We do sometimes for fun, too.

          e.g.
          1 ;B[cd];E[A:enter_scoring])
          2 ;B[cd];E[W:resigned] TL[5]) == W resigned 5 seconds after B put a move
          3 ;B[cd];E[B:resigned] TL[20])== B resigned 20 seconds after B put a
          move
          4 ;B[cd]BL[0];E[B:timedup]) However this is double booking, to clarify
          the game actually finished.
          5 ;B[cd]RM[cb];E[R:illegal_removal])== B forfeit on illegal removal of
          White stone at cb.
          6 ;B[cd];E[A:agreed_draw])
          7 ;B[cd];E[R:forW(|B)])== e.g.WWGO match period was during
          1998-09-16,12-23,
          according to WWGO rule, the win/lost was
          decided,
          8 ;B[cd];B[ce];E[R:illegal_turn])
          9 (;P[player1][player2][player3][player4] PO[1][2][3][4]
          ;B[dd];W[pp];B[pd]PLY[1];E[R:illegal_turn]C[It was to be played by 3,
          but 1 performed. So, B-team forfeit.])

          Note: To my opinion, RE[] is just a result and for database use, in
          another words, if E[] is, RE[] can be known, however, E[] is not always
          detectable by RE[]. So, I think E[] is essential. Think about e.g.2 and
          3.

          --------------------------------------------------------------
          > From: Robert Jasiek <jasiek@...>
          > This letter is about:
          > - moves in general (property M)
          > - multi-player games
          > - game recording after the alternation phase
          > Robert Jasiek wrote:
          > > ---------
          > > [NEW: move] > > M
          > > composed number ':' simpletext |
          > > composed number ':' simpletext ':' move |
          > > composed number ':' simpletext ':' real
          > [...]
          > Simple examples:
          > (Note: the numbers refer to the players in player order PO.)
          > Normal alternation:
          > (;M[1:B:jj];M[2:W:ii];M[1:B:hh];M[2:W:gg];M[1:pass];M[2:pass])
          > Illegal play:

          > (;M[1:B:jj];M[1:W:jk]RE[W+F:black moved twice in a row and used
          > a white stone])

          I think we can assume this don't occur in real game, so that ignoring
          this case, is appropriate.
          Adding to that, I wanna point out B and W should be regarded as
          color first. Because, most of us are interested in stones sequences,
          and SGF's main purpose is to revive it. I dare to say that who put
          the move is the second. This way of thinking reflect to the Shells
          concept.
          Generalization is good, but on the same time throwing away too rare
          case is also important, that is practical, I guess.
          (With E[], this case is able to be recorded, however.)

          > Agreement phase included:
          > (;SZ[3]RU[:International Rules with area scoring]
          > ;M[1:B:aa];M[2:W:bb];M[1:pass];M[2:pass];M[0:remove:aa]
          > ;M[1:pass];M[2:pass]RE[W+9])

          > Disagreement in agreement phase:
          > (;SZ[3]RU[:International Rules with area scoring]
          > ;M[1:B:aa];M[2:W:bb];M[1:pass];M[2:pass];M[1:pass]
          > ;M[2:remove:aa];M[0:resume]C[alternation phase is
          > resumed];M[1:pass];M[2:W:ab];M[1:pass];M[2:W:ba]
          > C[removes surrounded stone at aa];M[1:pass];M[2:pass]
          > C[agreement phase entered the second time]
          > ;M[1:pass];M[2:pass]RE[W+9])

          I don't think to record this process is necessary.

          > Multi-colour game:
          > (;M[1:1:jj];M[2:2:jk];M[3:3:kj];M[1:1:dd];...)
          > -------------------
          > What is M good for?
          > -------------------
          > - regular alternation
          > - any game phases after alternation independent of the rules
          > - agreement / confirmation / scoring / counting
          > - illegal moves
          > - team games
          > - multi-colour games
          > - special move types like Nihon Kiin's pass for ko
          > - undo without loss of information
          >
          > Currently B and W only allow the alternation phase with
          > two players and legal moves. We can hardly avoid an
          > additional property M that enables all the above
          > possibilities.
          >
          > It would be easy for us to continue to pretend that all
          > rules in the world are simple rules, but in reality
          > they are more sophisticated and we have to respect this
          > by an appropriate property model.
          >
          > What do you think?
          >
        • Robert Jasiek
          (answering several letters) The property M need not be used or used in the way proposed earlier. It has only been a starting point for discussion about moves,
          Message 4 of 5 , Feb 15 6:02 AM
          • 0 Attachment
            (answering several letters)

            The property M need not be used or used in the way proposed
            earlier. It has only been a starting point for discussion
            about moves, move types, game phase events, etc. To simplify
            discussion, let us currently exclude more than two colours,
            valued passes, a distinction of different resume types, undo,
            move types of games other than go. These will be reconsidered
            later.

            Since I cannot presume that all of you are familiar with the
            essential contents of my web pages, first I give an overview
            information on relevant topics: move, game phases, game phase
            events. Below you find my comments on E and other comments.

            MOVE

            A game is divided in smallest units of actions, the moves.

            (The word may have other meanings in different contexts,
            however, for a record standard that allows information
            procession by computers the smallest units of actions are
            needed.)

            A move can be executed due to a player, due to all players,
            due to referees, or otherwise due to rules. A player can be
            Black, White, or All. In team games or for illegal moves
            black or white can be more specified.

            A move is of a type. The principle types are:

            play
            pass
            pass for ko
            offer a resumption
            offer a request
            offer a removal
            offer a capture
            offer to include in score
            add stone

            Minor types that can be regarded as events:
            resign
            offer no result
            offer adjournment

            Notes:
            "move" is the English word for any type of moves, play is the
            English word for placing a stone. A pass is a move. Imprecise
            rules or verbal behaviour might suggest differently; still as
            a smallest unit of action, a pass can only be considered to
            be a move. Passes have different meanings depending on the
            context of actual game phases. E.g. during an alternation
            phase a pass offers to stop the alternation phase, during a
            confirmation phase a pass offers to stop the confirmation
            phase. A pass_for_ko must not be mixed with regular passes;
            neither places any stone but their meanings are very different.
            The various offers above are all different and also different
            from other moves. Like regular passes, resumptions or requests
            can cause new game phases, however, only passes cause the next
            regular phase call. Removal and capture must be distinguished;
            the relevance of prisoners might be derived from RU, but only
            if the standard RU entry can be exactly given, which is not
            possible for all rules.

            GAME PHASES

            A simplified general structure of game phases can be given as
            follows:

            setup
            alternation
            stop
            agreement
            end
            scoring
            result agreement

            Notes:
            Some rule sets (like the Nihon Kiin 1989 rules) have much more
            complicated structures. Setup sets handicap stones and may
            include intervening passes. Alternation consists of plays and
            passes, typically in B-W order. Stop is an event that ends
            alternation and starts agreement. It is caused by a sufficient
            number of successive passes, depending on the rules. The word
            "stop" suggests that the phase before, alternation, can be
            resumed. According to most rule sets, agreement is the phase
            of causing final removals/captures. It might occur alternately,
            based on verbal agreements, or due to rules. In case of
            disagreement resumption of alternation is possible. End is an
            event that ends agreement and starts scoring; passes are required.
            The word "end" means that now the score of the game is fixed
            because resumptions are no longer possible. Scoring is the phase
            that consists of just one moment, when the rules' score definition
            applies to the situation. In practice, this one moment seems to
            last longer, since mechanical procedures of calculation are applied.
            After the scoring the result agreement finalizes scoring.
            - Japanese style rule sets are more difficult. In particular they
            have no agreement phase but a confirmation phase instead. Final
            captures are part of the scoring phase; which stones are captured
            is "defined" by the rules. Other rules, which use agreement, leave
            the decision about removals/captures for the players. (Note: removals
            do not make any prisoners, unlike captures.)

            EVENTS

            [The EV property is not addressed here.]

            An event occurs if a game phase ends and a new game phase starts
            or if a special incident occurs. The following attempts to list
            the most important classes of events [I will make a more thorough
            list later]:

            start game
            start alternation
            start agreement
            start confirmation
            resume alternation
            start play-out-to-completion
            start scoring
            start result agreement
            end result agreement
            special end resignation
            special end time
            special end no result
            special end both lose
            special end forfeit
            special end both win
            special adjournment
            special unknown
            referees' adjustment of situation

            ***

            IMPLEMENTATION: Property E for EVENT

            If we do not include all in just one M property, we can
            also use other properties, part of which have been
            mentioned earlier. The most important new property then
            is E for game phase event.

            This specifies a move type if
            - B is used as a play but not a regular play,
            - W is used as a play but not a regular play,
            - B or W is used as a pass but not a regular pass,
            - AB, AW, AE are used as a move (not for setup), or
            - a node contains a special move type and none of B, W, AB, AW, AE.
            Events can also be special incidents, see in the list below.

            Property type: simpletext : simpletext
            Value meanings: who : type

            Possible values for "who":
            B : black
            W : white
            A : all players
            R : rules
            D : decision by referees

            Possible values for "type":

            pass_for_ko
            resume
            request
            remove
            capture
            score
            add
            start_game
            start_alternation
            start_agreement
            start_confirmation
            resume_alternation
            start_completion
            start_scoring
            start_result_agreement
            end_result_agreement
            special_end_resignation
            special_end_time
            special_end_no_result
            special_end_both_lose
            special_end_forfeit
            special_end_both_win
            special_adjournment
            special_unknown
            special_adjustment

            Notes:
            It is convenient to specify just one coordinate per region
            used for move types remove/capture/score. E overrides the
            normal meanings of B, W, AB, AW, AE if used in the same node.

            Examples:

            (;HA[0]RU[NZ:1978];E[A:start_game];E[A:start_alternation]B[aa]
            ;...;B[jj];W[];B[];E[A:start_agreement];E[A:remove]AE[dd][dp][pp]
            C[the 3 strings including dd, dp, pp are removed from the board]
            ;E[A:start_scoring]RE[B+1:];E[A:start_result_agreement]C[both
            players agree on the score];E[A:end_result_agreement])

            (;RU[Japanese:Nihon Kiin 1989];...;B[];W[];E[A:start_confirmation]
            B[aa];W[ab]E[W:pass_for_ko]C[W passes for the ko at ab];B[ca]
            C[B dissolves ko];W[]C[W says: We shall end confirmation.];B[]
            C[B says: I agree.];E[A:start_scoring]E[A:capture]AE[dd][dp][pp]
            C[the 3 strings including dd, dp, pp are removed from the board and
            added to the prisoners];...)

            (...;E[W:special_end_resignation]RE[B+R])

            (;RU[:Conway ko rules];...;B[aa];W[ab];B[aa];C[both agree to end
            the game with "no result"]E[A:special_end_no_result]RE[Void:
            infinite ko cycle possible])

            (;RU[GOE:Ing 1991];...;B[aa];W[ab];B[aa]C[illegal invariation]
            E[D:special_end_forfeit]RE[W+F])

            (...;B[];W[];E[A:start_agreement]C[a moonshine life is on the
            board and the players disagree];E[A:resume]C[alternation phase
            resumed with B to move next];...)

            (...;B[ad];E[B:special_adjustment]AW[ac]C[B takes last liberty
            of ac but both players forget that ac must be removed and play
            on with an illegal position];...;E[D:special_adjustment]AE[ac]
            C[the referee finally intervenes and removes stone without
            liberty];...)

            YAMAKAWA Kazuki wrote:
            > == Alternatives == s:simple text p:point n:number
            > property : property type
            > E[s:s] RM[p] : node
            > P[s]+ PO[n]+ PR[s]+ : game-info
            > PLY[s or n] : move

            I like the idea of E. The property RM is redundant if AB, AW, AE
            are overridden in their meaning by special E events. For P, PO,
            PLY there are many possibilities. We agree that the player
            order must be clear somehow, so some solution here will be fine.
            For ranks and teams additional properties are suitable.

            > writing rule -- a game tree ends with a node which contains 'E[]'.

            I have used E[A:end_result_agreement], but E[] is also fine.

            > Resignation, Referee judgment, Time expired, Agreed draw, etc.
            > are game events that influences game result or game sequences,
            > However they are not counted as moves, they are critical for the game.
            > So, I propose we call them game Events and its ID 'E'.

            Whether one interpretes them as moves, as events, as offers,
            or something similar, it is clear what they shall be good for:)
            I agree that E is a useful annotation.

            > (A)agreed_draw,

            What is an agreed draw? IMO, a draw can only be the result
            of a score or of a referee's special declaration.

            > (A)agreed_void, [(R)official_break ]
            > (R)for(B|W|A), (R)illegal_color, (R)illegal_turn,
            > (R)illegal_removal, (A)adjourned, (A)resumed,

            IMO, my list above covers these well while using a clearer
            classification, however, details will have to be discussed
            later anyway.

            > [(W|B|A)undo ? ]

            We should discuss this separately.

            > //PLaYer who performed the move//
            > PLY[players_ID_number] : this is a move's attribute : to indicate
            > the player who performed the move if needed. This is mainly to
            > describe that the move was illegal because the performer was not
            > to move. In the case, as the game have Joker players, this is useful.

            I agree that this is a useful property.

            > Note: To my opinion, RE[] is just a result and for database use, in
            > another words, if E[] is, RE[] can be known, however, E[] is not always
            > detectable by RE[]. So, I think E[] is essential.

            Yes, some events end the game, but most do not.

            Shigeru Mabuchi <mab@...> wrote:
            > Similarly, for BR[] and WR[], we use
            > BR[std-expression : free expression or details]
            > and RL[] overrides BR and WR for multiplayers game.

            I like the concept of overriding properties.

            > MoveMadeby[color : player : details]
            > eg. ;B[dd]
            > ;W[qq]
            > ;B[dq]MM[B:1: wrong turn, Black got penalty of 5 points]

            MM has essentially the same function as E and PLY. We agree
            on the principle.

            (Penality points during the game should be discussed later.)

            > MM[] only appears once and the
            > order can be recalculated easily)

            Later we will have to state the exact meaning of recalculation.

            > RE[ std-expression : details or exceptions ]

            > Robert has already given a good list so I will skip this.
            > However, an adjourned game should be more specified,
            > because there are many games that are adjourned with
            > consensus that it will never be resumed.

            My value "Void" refers to a finally ended game, "Adjourn"
            refers to a game that is expected to be resumed after a break.

            > RE[S : Game stops ] -> no adjournment is expected
            > (If anyone has a better word for 'stops' to differentiate
            > with 'Adjourn', please suggest)

            "stop" is often used for stopping a game phase, so we can
            use "Void" as above. Also see details in my earlier letter.

            > RE[A : lunch break ] -> May continue later

            I would write: RE[Adjourn:lunch break]

            > DT[ standard expression : extra infos, maybe program-dependant]
            [...]
            > DT[1870-11-10 : #JC:Keio 3 ]

            John, do you think that the standard expression must be optional?
            I guess that not all traditional dates can be tranformed into ISO.

            > RU[ abbr : details or exception if necessary]
            > We should provide keywords for major rules so that
            > program can parse them more easily.
            > For example:
            > RU[JPN] Japanese Rule
            > RU[CNN] Chinese Rule
            > RU[ING] Ing's Rule
            > RU[NET] IGS/Internet Rule
            > RU[AGA: with minor modification] AGA Rule
            > RU{ETC: details]

            IMO, the current standard expression or the ones above
            have little information. E.g. Ancient Chinese is entirely
            different from current Chinese. I would prefer to see
            either no standard expressions or a long list of widely
            used written rule sets like:

            NK49
            NK89
            WAGC80
            KOR??
            CHN88
            TWN52
            Ing75
            Ing86
            Ing91
            NZ75
            NZ78(?)
            AGA91
            WWGo96
            IGS91
            IGS97
            NNGS95
            LGS??
            ...

            Shigeru Mabuchi <mab@...> wrote:
            > BC[number:number] Define board coordinates
            > 1st number is type of X coordinates
            > 2nd number is type of Y coordinates
            > 1st number
            > 0 = A - T (skip I)
            > 1 = A - S (use I )
            > 2 = 1 - n
            > 3 or above: Reserved
            > 2nd number
            > 0 = 19 - 1
            > 1 = 1 - 19
            > 2 = 1 - 19 (Oriental characters = Kanji/Hanji)
            > 3 or above: Reserved
            >
            > The above specs will cover all known coordinate types,
            > and we can expand if necessary.

            I like the idea of a user orientated coordinate system that
            interprets the SGF internal coordinate system. (The details
            can be generalized a little later.)

            --
            robert jasiek
            http://www.snafu.de/~jasiek/rules.html
          • YAMAKAWA Kazuki
            Just a partial comments. (I writes more later.) ... Defining E[] for semantic property and substitute the combination of E[] and AB,AW,AE, for RM[], seems
            Message 5 of 5 , Feb 15 12:02 PM
            • 0 Attachment
              Just a partial comments. (I writes more later.)

              Robert Jasiek wrote:
              > The property RM is redundant if AB, AW, AE
              > are overridden in their meaning by special E events.

              Defining E[] for semantic property and substitute
              the combination of E[] and AB,AW,AE, for RM[], seems good.
            Your message has been successfully submitted and would be delivered to recipients shortly.