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

Re: [sgf-std] New SGF property: transposition / links

Expand Messages
  • Lauri Paatero
    Hi, I think idea is good, but there are several problems with initial proposal that need some resolution: 1. N property Property N is inteded to be
    Message 1 of 12 , Jul 30, 2008
    • 0 Attachment
      Hi,

      I think idea is good, but there are several problems with initial
      proposal that need some resolution:

      1. N property

      Property N is inteded to be user-visible and editable name for node. So
      duplicated exists, and preventing user from giving same node name twice
      in file is bad solution.

      I think it would be better to define some other property (for example
      AC[ int ]), that could be used to reference node in all cases it is
      machine referenced. (I have planned such id for other uses, but I would
      prefer having single standard one.)

      Proposal: define new invisible-to-user property AC[nro] for node, and
      use that to reference to node.

      2. Loops

      I would like to say loops are not allowed, bu:

      If we consider following chain of editing
      1. create file which contain new properties;
      2. edit file with editor that does not know new properties (they
      continue to exists a long time).
      3. Open file again with editor understanding new properties.

      Now at step 3 we may have loops, as at step 2 there is no way new rules
      are followed, even though editor was SGF4-compliant.
      So I think we should not add new restrictions to what is valid file.
      Loops will exists, and programs need to be able to deal with them.
      Also nodes with TP might not be leaf nodes anymore.

      So in essence new limitations would invalidate SGF4-compliance of
      program, which is exactly what standards are supposed to prevent.

      Proposal: No new restrictions to SGF4 file structure.

      3. Link interpretation

      I think we should have 2 types of links:
      - Just jump to location, as user would have moved to location (so TP
      does not need to be leaf)
      - Continue with referenced subtree, as proposed here.

      t.
      Lauri Paatero


      Arno Hollosi wrote:
      >> The SGF file format has succeeded by being a file format. Specifying
      >> the way a program interacts with a user should be left up the program
      >> author.
      >>
      >
      > Sometimes the GUI or interaction with the user has to be addressed in
      > the specification. That's the reason why we have a ST[] property. I am
      > just trying to find out if someone thinks there may be issues.
      >
      >
      >> I hope/imagine that most programs will make the presence or
      >> absence of N[]'s and TP[]'s invisible to the user.
      >>
      >
      > I think that depends. When I am editing I'd like to know whether my
      > change is copied multiple times within the SGF tree or is a local
      > modification only. Furthermore, when I know that the subtree is copied
      > (and maybe transformed) I know that I should avoid comments like "upper
      > right corner" or "B5 should be at C17".
      >
      > /Arno
      >
      > ------------------------------------
      >
      > SGF spec: http://www.red-bean.com/sgf/
      > Contact: Arno Hollosi <ahollosi@...>Yahoo! Groups Links
      >
      >
      >
      >
      >
    • Mark Lentczner
      The big issue I see to resolve is the semantic of the link. I see several possibilities discussed in the thread, and I m going to try to restate the
      Message 2 of 12 , Jul 30, 2008
      • 0 Attachment
        The big issue I see to resolve is the semantic of the link. I see
        several possibilities discussed in the thread, and I'm going to try to
        restate the concisely:

        1) Identity
        The node referenced is the identical position as the node with the
        link. Presumably they have the same position *after* each has applied
        any moves.

        2) Duplicate Sub-tree
        The nodes that follow the referenced node are equally applicable to
        the position at this node.

        3) Jump
        The referenced node should be offered to the user as a possible follow
        on to this node. The position at the referenced node could be wholly
        different.

        Identity seems to have a number difficulties in definition and
        resiliency:
        - just how "identical" do the positions have to be?
        - i.e.: same number of prisoners? or just same delta? passes?
        - same comments? markup?
        - what about differing in only a tenuki move?

        Duplicate Sub-tree has the downside that now each node can no longer
        be transformed into a single game position, since the state of the
        game will depend on if you took a jump to get there.

        Jump gets around these difficulties, but at the expense of being a
        different kind of navigation that the existing options.

        One way to approach the choice is to look at the use cases and see
        which admits the most flexibility. The use cases I see are:

        A) Joseki dictionary desire to not replicate whole sub-trees when a
        position can be arrived at via two different move sequences. This use
        case could be broadened to include color and spacial transposition, or
        differing in tenuki.

        B) Tsumego. Like joseki, a desire to not replicate whole sub-trees.
        Here the game state identity requirement might be more rigorous.
        GoProblems.com already does this automatically by identifying
        identical positions in the tree: If one has follow on nodes and the
        other doesn't -- they are "spliced".

        C) General annotation need to have variant lines or main lines
        reference other lines within the tree.

        It seems to me that the Jump semantic supports all of these. If there
        is a need for identical position at both ends, it is easy enough for
        the creation tool to enforce that.

        The only thing that then needs to be addressed is the intended user
        navigation: Is it displayed as an option? Is it followed
        automatically? One could support both by this rule: If the LI[]/TP[]
        property appears as the only property in a node, then the link should
        be immediately followed, replacing the game state with the state at
        the target node. On the other hand, if there are any other
        properties, including just a comment (even an empty comment!), then
        the user is offered link as a sort of 'remote variation', and can
        choose, as they would choose a variant, to continue in that part of
        the tree.

        - Mark
      Your message has been successfully submitted and would be delivered to recipients shortly.