Comments/Ratings for a Single Item

The database has a new password, which you can find by logging in and looking it up in the file that contains it.

I'm not sure what you mean.  Do you mean connect with SSH and I'll find it in clear text in a mariadb config file?

Which reminds me - is the table of piece types and their IDs/internal names finalized? If it is, I can start populating the piece<->game mappings. I have the data to populate this for about 135 games in a fairly automatic way.

Okay, sure. I have been sidetracked by other things for a while. The database has a new password, which you can find by logging in and looking it up in the file that contains it.

I think in part this class deserves a quickly found list because it's so common to want to include the compounds; it may help new developers understand the prior art in this area.

Ok, yes, this is a good point

OTOH, the tags for groupings of pieces feels like a kludge that offers very little value if the other approach is available...

This depends on what kind of search utility we can provide (elegantly), and how much convenience we think this class of games deserves. The current definition of the tag would need a search like "includes at least one of marshall/archbishop/amazon and no pieces outside of FIDE+those".

I think in part this class deserves a quickly found list because it's so common to want to include the compounds; it may help new developers understand the prior art in this area.

should KRBN-compounds be separate from Man-RBN-compounds?

In Fusion Chess, compounds with the King are royal. So, some distinction might be appropriate. You might be thinking of a game like Sac Chess for the latter, but that game also has Amazons, which Fusion Chess doesn't have. Here are some options:

• Use Pieces:Chess+Compounds more loosely
• Same as above but include child tags for variations.
• Make many fine distinctions in children of Pieces.
• Just use names of games with certain piece sets, such as Pieces:Carrera's Chess, Pieces:Fusion Chess, Pieces:Sac Chess, etc.
• A hybrid approach that uses game names for larger sets to avoid making long tags like long German words.

For pieces, I like the other approach we are taking - the new tables to allow an index of pieces and cross-reference them with the games they are in. This is powerful and I think it is most likely what people will want. There are questions posted form time-to-time asking about previous uses of specific pieces.

OTOH, the tags for groupings of pieces feels like a kludge that offers very little value if the other approach is available... Which reminds me - is the table of piece types and their IDs/internal names finalized? If it is, I can start populating the piece<->game mappings. I have the data to populate this for about 135 games in a fairly automatic way.

From a search perspective, that [numerical fields for board size etc.] makes sense. But from a browsing perspective, I think it makes sense to include tags for sizes we have many variants in.

We do already support that through the old sidebar and the new menu's RelatedPages->GamesOnSameBoard. Maybe we should expand the area where tags now live to include that, links to the Categories, links to the Related Pages (from GroupID), etc. Or, add tags into the Related Pages menu.

(We should also settle on and publicize some conventions on how to enter fields for infinite boards, boards without a well-defined number of files/ranks (different geometries, e.g.), etc. Similarly for games with variable number of players. There are also some oddities that will push whatever design we choose; I recall but can't find at the moment a game where some pieces treat the board as 2D and others as 4D?)

My issue with Chess+Compounds or FIDE+Compounds is that there are different sets of compounds. Fusion Chess and several related games also include royal compounds. To distinguish these, we might use Pieces:Chess+RBN-Compounds for games with the pieces of Capablanca's Chess and Pieces:Chess+KRBN-Compounds for games with the pieces of Fusion Chess.

I would be OK with that, but I think RBN-compounds-only are the majority and might warrant the shorter if less-clear name. And maybe Man-R-B-N-compounds are also common enough to warrant their own tag (and again we get into a discussion on whether changes like royalty are actually a piece property or a rule variation; should KRBN-compounds be separate from Man-RBN-compounds?).

I don't think individual pieces should be tags. I'd rather that be an explicit database table. But I do think "usual equipment" and "FIDE+compounds" and similar classes of piece sets could be useful as tags.

Yes, tags can't do some things that the database table is intended for, such as keep track of the names used for the same pieces in different games. Instead of using tags for individual pieces, it may make sense to use tags for common sets of pieces with tags like Pieces:Chess, Pieces:Shogi, Pieces:Xiangqi, etc. My issue with Chess+Compounds or FIDE+Compounds is that there are different sets of compounds. Fusion Chess and several related games also include royal compounds. To distinguish these, we might use Pieces:Chess+RBN-Compounds for games with the pieces of Capablanca's Chess and Pieces:Chess+KRBN-Compounds for games with the pieces of Fusion Chess.

And yes, I think numerical fields should be kept separate rather than incorporated into tags. That gives us more flexible searching ("at least 90 cells but at most 130"), and I can't imaging a parametrized tag ("#CellCount=x") looking good.

From a search perspective, that makes sense. But from a browsing perspective, I think it makes sense to include tags for sizes we have many variants in.

I agree with "Board" because of terrain. Maybe something even more generic like "Playing Field", except that I prefer the brevity of "Board".

I also prefer the brevity of Board. While the word might most literally refer to a contained 2D playing area, Chess variants are classed as board games, and the word is normally used for the playing area in any Chess variant, even if it doesn't follow the planar geometry of a literal board.

I would prefer to keep the categories, if only to have a short list of important information; when posting a new game, checking a few of those boxes is (or eventually will be) easier than perusing all the existing tags. The main question to answer, if we agree that this is worth keeping, is how to reconcile the overlap. I think a mechanism to include the categories as tags would serve that purpose fairly well, but would require an efficient way to index the pages of each category (dynamically, since pages' categories can change).

Indeed, one of the first uses of tags to my mind was to subcategorize the "Shape" category. Hence #Shape:Board and #Shape:Cells.

I think we should keep 2D; while no one will peruse it directly, they might be searching for something and want to exclude non-2D variants. (This does suggest though that some very large tags might need rethinking on how to list their pages.) Also, maybe dimensions should be a numeric parameter instead. (Note that "4D" is actually supposed to mean "4 or more dimensions".)

"Usual Equipment" is usual for people who want to sit down to a regular chess set and play a variant. I would suggest, if tags rather than categories, that #UsualEquipment be its own tag, and each of the deviation types can be a completely separate tag, applicable to both usual-equipment and different-equipment games. "Modest" is probably useful especially for people wanting not-very-different games; see e.g. the comment thread on this SE post.

On Crossover, I think there will be some base games (e.g. Checkers) that deserve child tags, but if a base game has only one (maybe two) chess crossovers, then it should just be tagged with the parent Crossover. (I wouldn't oppose, however, individual tags even for one-game bases. It makes the tag itself more informative, if less useful for searching. If we restructure tags in a way that makes recursive searching possible, then this would work.)

Single player and multiplayer could be replaced by the number of players numerical field.

And yes, I think numerical fields should be kept separate rather than incorporated into tags. That gives us more flexible searching ("at least 90 cells but at most 130"), and I can't imaging a parametrized tag ("#CellCount=x") looking good.

I don't think individual pieces should be tags. I'd rather that be an explicit database table. But I do think "usual equipment" and "FIDE+compounds" and similar classes of piece sets could be useful as tags.

I agree with "Board" because of terrain. Maybe something even more generic like "Playing Field", except that I prefer the brevity of "Board".

I would also personally use 'Geometry' rather than 'Board'. It's a bit more general.

I think Board is a bit more general, because it can also be used for board size, board dimensions, or other board differences like having terrain.

And a game could be both 3-D and Rectangular, or both 3-D and Hexagonal ...

There is no requirement that a page should get only one child tag with a particular parent. A page could be tagged both Board:3D and Board:Hexagonal, for example. I have been tagging some of my own games with multiple Rules: children tags, which is the same principle.

I have also sped up tagging of similar games by including a copyable string of all the tags a user has added to a page. I have been able to copy and modify strings from one game to quickly tag others.

I think rebuilding from the ground up with a cohesive strategy makes sense. I'm not sure, though, that everything needs to be done with tags. I think it also makes sense to have some integer parameters that can be searched. Number of players and number of board cells as searchable parameters makes more sense to me than tags for 'multi-player' or 'large' or 'small'.

I would also personally use 'Geometry' rather than 'Board'. It's a bit more general. 3-D, for example, is a geometry. And a game could be both 3-D and Rectangular, or both 3-D and Hexagonal ...

I'm now thinking about how to build tag structures from the ground up. We could have parent tags to designate tags about specific types of features. For example, Board, Piece, Goal, Rules, and Players. These would cover most of the ways in which a variant might differ from Chess. Board could replace UnusualBoard and include its children plus Standard for the 8x8 Chess board. Piece could be used for individual pieces. Goal could be used for differences in how the game is won or drawn. Rules could include children for various common rule deviations. Players would mainly just get a number. One way to think of these is as parameters that the child tag gives specific values to.

A lot to think about here. Thank you for posting this for feedback first. I will consider and reply with my thoughts later today. But my first thought is that we don't need to do it all at once. We can apply tags corresponding to the more obvious categories first. Tags and categories can coexist for a while.

One of the quickest ways to populate the tags is to convert categories into tags. However, I don't think that a direct translation of every category into a tag of the same name is the way to go. So, I want to plan things out first by discussing the individual categories:

chess

This category is for pages on Chess, which we have a lot of despite being mainly about variants.

1D, 2D, 3D, 4D

I don't think the 2D category needs to be translated into a tag. 2D is the assumed default, and it is such a large category, I don't think anyone ever browses through it. We currently have a 3DBoard tag, which may be a little more informative than just the tag 3D. I wonder if 3D-Board or 3dBoard would be better, since it will not put a space between two capital letters when displaying the name.

Large, Small

These respectively mean larger and smaller than the 8x8 64 square Chess board. We already have a Large tag. Small would also work. These may have children for various common sizes, particularly for those created for contests for boards of particular sizes. So, based on values for BoardCols, BoardRows, BoardLevels, and BoardCells, it could be given an appropriate child tag instead.

Multiplayer

Seems useful, but it could be combined with the PlayerCount value to create appropriate child tags.

Oriental

This could be a child of Regional, which we already have a tag for. Regional:Oriental might be appropriate for the tag name. However, most of the regional variants are oriental, since we understand Indian and Muslim forms of Chess as historical rather than regional. So, it might be appropriate to just name the region, such as Regional:Chinese, Regional:Japanese, etc.

Historical

Okay.

Dice, Cards

Possibly include as children of Random. So, Random:Dice, Random:Cards.

Wargame

Okay. This is mainly a separate category from Chess variants, and we might not have many here.

Shape

This is it. Shape:Board and Shape:Cells are not categories. Perhaps Shape should be translated to UnusualBoard.

Hexagonal, Round

Can be children of UnusualBoard. Round may be translated to RoundBoard, which we already have a tag for.

IncompleteInfo

Okay. It sort of works how info is an incomplete spelling of information.

Other

Too vague to be useful. It does not need to be translated into a tag.

Usual-Moving, Usual-MovingOpponent, Usual-MultiMove, Usual-BoardRules, Usual-Winning, Usual-Setups, Usual-Capturing, Usual-Other, Usual-Modest

These categories all describe ways in which a variant played with the same equipment as Chess differs from Chess. The last two are not particularly informative. Other means a difference not included by the previous ones, and Modest means a small difference, though it could fit any of the previous differences. What has always bothered me about these categories is that they are not supposed to be used for games played on different boards than Chess. Yet the same things that distinguish games played with the usual equipment from Chess also sometimes distinguish other variants from Chess, and apart from Other, which I dismissed above, we have never had anything like these available as categories for other games.

One possibility is to give these all the same parent name. I prefer the longer UsualEquipment, because it is more informative. We could translate them to UsualEquipment:DifferentPowersOfMovement, UsualEquipment:MovingOpponent'sPieces, UsualEquipment:Multi-Move, UsualEquipment:DifferentRules, UsualEquipment:DifferentObject, UsualEquipment:DifferentSetup, and UsualEquipment:DifferentCapturing.

But I will note that we already have some tags that cover some of these without the usual equipment part. The Goal parent tag can be used for different goals. The Multi-Move tag can be used for any game allowing multiple moves. I also want to create a Piece parent tag for identifying individual pieces in a game. This might replace my attempt to create separate tables for piece information.

Crossover

We already have this as a parent tag, and it is probably more useful that way. It might be better to go through the crossover games and create more informative child tags for them.

Singleplayer

Okay, though probably uncommon. Perhaps renaming the tag Solitaire.

XiangqiBased, ShogiBased

These don't have to be children of Regional or Oriental, because people in the west have sometimes created games based on Xiangqi or Shogi. One problem with Oriental, mentioned above, is that some games based on Xiangqi or Shogi might have been given the Oriental category despite being of western origin.

I corrected a bug that allowed anyone to tag a page without being signed in. I also deleted an anonymous tag. I think it was making Shape:Board a parent of RoundBoard.

When a tag is both the parent and the child of another tag, both of these relations are ignored, and the tag is listed separately as related. I have done this with the Shape and Geometry tags.

Ok, good. This is better. I had concerns about the other approach.

I brought these two ideas together by adding the ability to tag parent tags.

It appears that what I intended and what I programmed were two different things. When I finally looked at my own tags, I saw that the children were the tagged items, but I had expected the parents to be the tagged items. I guess it gets confusing when you're working with tags as tagged items. Nevertheless, this works out. When I view my own tags, it's more logical to see a tag followed by its children than to see it followed by its parents. Tagged pages are like leaves, and tagged tags are like branches.

Editors may now delete relations between tags. I also modified the Tagged Pages section to show up only when there are tagged pages, and I moved the button for deleting the whole tag to the bottom.

I'm working on code to delete individual parent/child relations, but I have commented it out for now, because it seems to be deleting whole tags.

what's to stop a user from making circular references - e.g., two tags that are both parents of each other?

Nothing for now. I could add code to stop this, but if it isn't recursive, it might allow three-way or larger loops.

If you search for games with a tag, does it return games tagged with child tags of the requested tags?

There is presently no searching of tags other than having the tagged pages listed on an individual tag page. This list includes only directly tagged pages.

if you apply a tag to a game, does it also apply the parent tags?

No, tags are not inherited by virtue of parent/child relation.

if the answer to both of these questions is no, what does any of this accomplish?

Links to parent and children tags are provided for further browsing and context. They are not used in any recursive fashion that would result in an infinite loop if two tags were tagged as each other's parent. If two tags do end up that way, editors may decide to delete one relation and better clarify the descriptions or choose to merge the two tags into one if they are too similar in meaning.

This allows anyone to add a parent, and it allows a tag to have multiple parents.

Be careful with this - this concept, known as multiple inherritance, usually leads to problems.  For example, what's to stop a user from making circular references - e.g., two tags that are both parents of each other?  This becomes particularly problematic when you attempt to leverage the hierarchy.  If you search for games with a tag, does it return games tagged with child tags of the requested tags?  Or, conversly, if you apply a tag to a game, does it also apply the parent tags?  And if the answer to both of these questions is no, what does any of this accomplish?