Comments/Ratings for a Single Item

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?

After I added the ability to name a parent in a tag using the colon, I saw that there were various tags that should have a parent/child relation based on meaning, and it seemed like it would be awkward to rewrite their names. I was also thinking about adding the ability to tag tags. I brought these two ideas together by adding the ability to tag parent tags. Instead of allowing tagging in the footer, the info page for a tag includes a form for adding a parent. This works the same as the tagging form and uses the same script. This allows anyone to add a parent, and it allows a tag to have multiple parents.

Ditto — thanks

Confirmed

On Windows, neither Firefox nor Edge show the child tag either. Ad blocker enabled or disabled doesn't make any difference.

When I looked at the code for displaying children, it was inside an if (fpdip()) block, which I use for testing code before others are ready to see it. I have now removed that condition. So, it should work for others now.

Same behavior here. On Windows, neither Firefox nor Edge show the child tag either. Ad blocker enabled or disabled doesn't make any difference.

I'm using Firefox 86.0.1 on an Artix Linux stratum on a desktop Bedrock Linux system (so effectively Arch Linux's FF); I have both uBlock Origin and uMatrix enabled with no exceptions set up for this site, but temporarily enabling an exception for the stuff that isn't in its dark red list (i.e. mostly ad servers ⁊c., so basically just enabling google fonts and paypal objects) doesn't make anything show up. Also I'm connecting over Tor, which sometimes affects things, though idþ that's given me any issues here before.

I checked the page source, and that doesn't include the string ‘grand’, so it's probably something serverside?

That's really weird, since I created these two tags expressly for testing the ability of a page to show both a parent and children, and that's what I got. When I look at the Parent:Child page, I see both its parent and its child. Under what conditions are you viewing the page, such as browser, OS, desktop or mobile, and ads blocked or not?

We seem to be seeing different things then. https://www.chessvariants.com/tag/Parent%3AChild lists the #Parent child under the heading ‘Parent’, but #Parent: Child: Grandchild is, for me, nowhere to be found on that page.

Parents are listed, but at present children seem to be absent

There are few parent tags, but children are listed for each one of them. Most tags have no children, and for those, no children are listed.

Since any parents or children are listed on the page for a tag

Parents are listed, but at present children seem to be absent

I forgot a ! operator. I made the correction, and it now works properly.

It looks like the restriction is being applied over‐eagerly: I tried adding the square‐removal tag to Cheshire Cat and Wormhole Chesses but in both cases it tells me I mayn't tag a deleted page.

I have added a restriction against tagging hidden, unpublished, or deleted pages.

When you add a tag, you will now get feedback instead of being sent right back to the same page. When a tag has no description, you will be asked to provide one.

Tags can now handle extended parent-child relationships, such as grandparent-grandchild relationships. For example Parent: Child: Grandchild.

I have made relationships between tags a matter of tag syntax rather than something stored separately in the database. A colon is now used in a tag to indicate that it is a child of the tag named to the left of the colon. The page for a particular tag will list its parent if it contains a colon, and it will list its children if it does not. Most tags do not have parents or children, and nothing extra will be listed for these. Visit the Drops tag and its children for examples.

I have also added the hashtag character to the beginning of displayed tags for the sake of visually distinguishing them as tags. Since it is done through PHP rather than CSS, it does not affect the link above.

To make it easier to reuse the same tags and for different members to use the same tags, the form field for entering tags is now populated with a datalist of all tags currently in the database. As you type in a tag name, tags that match it will show up underneath. You may select a pre-existing tag or create a new one.

For the sake of giving tags a standardized look, for the sake of preventing the appearance of similar tags that differ only in case or spacing, and for the sake of being able to always use tags as the basis for ItemIDs, I have standardized tag names. When displayed, tags may use spaces, and each word will be capitalized. When stored in the database, tags will not have spaces, and capitalization will be used to tell one word from the next. In converting from a stored tag to the displayed version, it will add a space any time a lowercase letter is followed by a capital letter, and it will also add a space after a colon. The only tag this had an unwanted effect on was SimpliFIDE. So, I manually changed that one to Simpli-FIDE to make it look like a whole word.

I have now added the ability to use this page to view all of your tags in one place. Look for the "Your Tags" menu item in the menu headed by your name. This link will add a query string to the URL that includes a value for personid. You will also be able to delete your tags from this page.

It is now possible to edit the short and long descriptions of tags. A form will appear on the Tag Info page for a particular tag if you are an editor or you have added at least half of the instances of a particular tag. So, if you introduce a new tag, you should be able to edit its details immediately after creating it. Just go to the page for the tag and enter its details.

Editors may now delete member-created tags. On the Tag Info page for a particular tag, an editor will find individual buttons for deleting the tag for particular items in case some items have been mistagged, and a button at the bottom for completely deleting the tag in case it's simply inappropriate.

Bringing together the two things I was getting at, categories should be exhaustive and mutually excusive, but tags don't have to be. A book I'm reading on SEO points out that categories should be used for important parts of site structure. When this site began, it was all HTML pages, and each page had to go into a particular directory. Given that we had to place each page somewhere, categorization made sense. But now that we have lots of content in the database instead of in HTML files, finding a particular place for each page is no longer as much of an issue. So, instead of organizing the site around the site structure, we have the opportunity to organize it around the nature of Chess variants. It's hard to come up with a strict categorization of Chess variants unless we make it about just one feature. For example, Chess variants could be categorized by their number of dimensions. If we wanted to categorize by cell shape, as well, we may start to have problems. A 3D game could use hexagonal cells, for example. If we use categories, what we find is that various Chess variants will fall into a variety of different categories, and some that fall into some of the same categories will also fall into different categories. There seems to be no easy way to sort or arrange Chess variants by categories. Instead of falling into strict categories, Chess variants differ from Chess to varying degrees and in different ways. So, it seems more natural to organize Chess variants around the ways they differ from Chess and around some other salient features than it does to try to strictly categorize them all. A tagging system works better for this than a categorization system. What I propose, then, is to use the existing categories for automatically generating some tags, then use tags rather than categories.

The main drawback I see to this is that categories are stored in the database much more efficiently than tags are. To find out the categories for a page, we just have to check one column in one row, but to find out the tags for a page, we have to find every row for that game in the Tags table. Additionally, if we allow public tagging, this increases the number of rows for each page. However, it isn't necessary to search the whole table, since the use of indexes narrows the search to just the rows we need to find.

One option is to repurpose some of the categories and add new ones, using them to note various ways in which games differ from Chess. This would make categories the main way to organize the variants, though they wouldn't work like strict categories. This would be more efficient and uniform than using tags, but the use of tags could give people more freedom to organize variants in ways that make sense to them. For example, people might want to use tags for family relations between games, or inventors might want to organize their games around different categories than the ones we've chosen to use. So, while tagging is less efficient and public tagging will lack uniformity, it does offer some advantages.

I'm not sure how we could use both categories and tags to organize the site. It seems like there would be a lot of overlap between how each got used, and there doesn't seem to be need to have both. Some of the advantages of tagging could be had by reworking the categories, but switching to a tagging system could offer other advantages besides these, though there would also be a cost in performance.

It may be suitable to begin many tags with the word different. Here are some we could have

Different Pieces - A tag for games that include pieces not used in Chess

Different Powers of Movement - A tag for games in which some Chess pieces move differently than they do in Chess.

Different Board - A tag for games played on something other than the 8x8 Chess board

Different Board Shape - A tag for games whose boards are not squares, rectangles, or parallelograms

Different Cell Shape - A tag for games played on boards whose spaces are not squares

Different Topography - A tag for games whose boards are not merely 2D grids of spaces, including circular, cylindrical, torus, and multi-dimensional boards, though not boards that merely differ in cell shape.

Different Rules - A tag for games whose rules differ from those used in Chess

Different Manner of Setup - A tag for games that do not begin with all pieces on the board in fixed positions

Different Means of Capture - A tag for games that allow capture by means other than displacement or en passant

Different Outcome of Capture - A tag for games in which capture has other effects than merely the removal of the captured piece from the game.

Different Winning Conditions - A tag for games with different winning conditions than Chess.

Different Draw Conditions - A tag for games with different drawing conditions than Chess.

Different Kinds of Equipment - A tag for games that use equipment other than a board and pieces.

Different Number of Players - A tag for games played with fewer or more than 2 players.

Some of these might not be necessary and could be replaced with more particular tags. For example, "Multi-Player" probably works better than "Different Number of Players." For one-player variants, we could use a "Solitaire" tag, and that covers all possibilities for this one. Some of the most broad ones might be used to consolidate groups of more particular tags instead of being used for the games themselves.

Let's think about the difference between categories and tags. In my Wordpress blog, I use both. Categories are fewer in number, and they tend to be mutually exclusive, though it doesn't always work that way in practice. I can assign multiple categories to a post, and I sometimes do, but there is the general intent that they should be exclusive of each other. The tags on my blog are more particular, and the same posts may have multiple tags without it being an issue.

Last.fm seems to use tags rather than categories to organize its site. I can go to an artist page or an album page and add tags. Many of the tags on last.fm are genre tags, and it makes sense to allow users to enter tags, because genre is something of a subjective matter, and different people sometimes organize the same music into different genres. By recording how multiple people tag artists and albums, they can show the most popular tags and usually get the genre correct without having to hire staff members to meticulously go through all the music there and place each artist or album into the proper genre. They also allow members to edit the text of tag pages, so that we can get descriptions of the genres people tag various music with.

The tags that are appropriate for Chess variants are usually less subjective than genres. Tags about ways in which games are different from Chess usually convey objective facts about these games, not merely subjective opinions. But people could use them for subjective opinions too.

One difference between categories and tags is that categories should be exhaustive, while tags don't have to be. For example, we have an Other category, but it would not make sense to have an Other tag. With tags, we could shift the emphasis from an exhaustive categorization of games to tagging how various games differ from Chess. With the exception of games playable with a Chess set, the general idea would be to assume similarity with Chess except when differences are tagged. The tagging system is also more open-ended and flexible than the categorization system. Anyone can add a new tag, but to add a new category, someone has to edit the structure of the Categories column in the Item table, then update some scripts.

The options before us are

1. To use both categories and tags and figure out how they can work together.
2. To improve the category system and forget about using tags.
3. To replace the category system with a tag system.

Non-Standard Capturing is still a bit vague. "Different Means of Capture" is more precise, and I could add "Different Outcome of Capture" for games like Shogi.

Let's first look at how much can be said in 64 characters. This is less than half the size of a tweet. Looking at the tags I came up with earlier today, the longest is "Promotion Only to Captured Pieces" at 33 characters. If I changed that to "Promotion Only to Captured Piece", I could make 32 characters the maximum length for a tag. Sometimes, the tag itself will be self-explanatory. Let me look for an example where longer descriptions will be helpful. 

Non-Standard Capturing

Longer: Capture by means other than displacement or en passant. (90 characters)

Full: Apart from en passant capture, pieces in Chess capture by displacement. This involves moving to the space the piece is on and taking its place. In a way, en passant is a variation on capture by displacement. It involves moving to the space the captured Pawn would have moved to if it hadn't been allowed a one-time double move. The rule of en passant capture effectively allows the normal capture of a piece that was granted a special move. But capture by displacement and this variation on it are not the only ways pieces can be captured in games. Checkers capture other checkers by jumping over them. In games like Ultima and Rococo, pieces capture by a variety of different means, such as moving one space short of a piece, moving away from a piece, surrounding a piece on two sides, leaping beyond a piece, and forming geometric arrangements between pieces. These are just some examples, and you will find other means of capturing pieces in other games. This tag is for games that allow capture by any means not employed in Chess.

If we're going with long tag names, I'm not sure if tagSentences will be necessary.

Right now, tags are allowed to be in UTF-8, which would allow for foreign language tags. This could make conversion to pseudo ItemIDs difficult, especially if someone uses all Chinese characters or something. Also, foreign language tags would be harder to vet. So, I'm considering the idea of requiring tags to be in ASCII, which is what all ItemIDs are required to be in.

I temporarily altered taginfo.php to test some things, and I found out that even if I have it print $_REQUEST or $_GET as the very first thing it does, it has already converted the %2B to a space. An additional urlencode will not help, because the problem is that "chess%2Bcompounds" has already become "chess compounds". It must be that the apache RewriteRule command, which is used to create the semantic URL in .htaccess does URL decoding on its input. What works is to replace %2B with %252B. %25 is the code for the % sign, so that this converts to %2B, which will then convert to +. What fixed this is to use str_replace() on the output of urlencode(), like so:

str_replace("%2B", "%252B", urlencode($key))

I was thinking of a direct text replacement for spaces to/from underscores (followed by urlencode-ing the rest); but I don't know how we're directing the semantic URLs, so maybe that's not possible/easy.  The semantic URL is passing the tag with a space whether I use + or %2B, so decoding in taginfo.php won't help.  Anyway, I was mostly using "chess+compounds" on the assumption that we'd avoid multi-word tags, so I don't have a big problem with changing it.

If parent / tag-tags are used exclusively as we've described them so far, then I don't think a game page needs the parent tags included: the applied tag is descriptive enough, and viewing the taginfo will elaborate.  I agree that tag-tags are more flexible, but they seem more complex and less clear (a pretty common tradeoff).  It's also possible that tag-tags may serve both as parents and as more meta-information (though I have no examples in mind).

For the kinds of tags, I was mostly thinking along those lines, a more flexible category system.  Indeed, I had the same thought about usual equipment.  Earlier, other uses of tags came up, e.g. opinion descriptors (complexity, tactical depth, ?).  I've been avoiding repeating existing categories, but Usual Equipment as a parent to the existing categories there would be good.  If we have a parent Object (or "Goal"?), I would be inclined to skip "Win by Checkmate", and make the parent "Different Goal".  Can we make an existing category play the role of a parent to tags?  (It can be done informally by just listing it in the TagParagraph.)

For your specific tags, a few already exist as categories and I would prefer not to reproduce them.  Some seem to me too narrow or too broad, but that's without searching (and some of mine turned out to be narrower than I thought).  I've thought before of adding database information for which pieces are used in games, but that seems like a lot of work to get filled in, so your pieces-as-tags idea sounds good.

Here are some possible tags I have thought of.

• Different Pieces
• Compound Pieces
• Hopping Pieces
• Novel Pieces
• Supernumerary Pieces
• Neutral Pieces
• Move Opponent's Pieces
• Multi-Move
• Double Move
• Move Multiple Pieces
• Different Board Rules
• Cylinder Board
• Torus Board
• Vanishing Spaces
• Movable Spaces
• Different Object
• Stalemating Player Wins
• Checkmated Player Wins
• Lose All Pieces to Win
• Capture Piece to Win
• Eliminate Type of Piece to Win
• Random Setup
• Free Setup
• Alternate Setup
• Captured Pieces Change Sides
• Drop Captured Pieces
• Exchange Captured Pieces
• Promotion Only to Captured Pieces
• Absorb Captured Pieces
• Pieces May Combine
• Pieces May Split Apart
• Non-Standard Capturing
• Small
• Large
• 3D
• 4D
• Hexagonal
• Round
• Unusual Board Shape
• Cards
• Dice
• Three-Player
• Four-Player
• Multi-Player
• Based on Shogi
• Based on Xiangqi
• Oriental
• Historical
• Chinese
• Japanese

We could also include tags for specific pieces, particularly the popular fairy pieces, such as Cannon, Vao, Mao, etc.

While it's more flexible, tagging tag pages would lack one feature of using a tagParent. With a tagParent, the parent tag might be included on any page that includes the child tag. For example, if "Different Object" were the parent of "Stalemated player loses", then "Different Object" would automatically be added to any page with the "Stalemated player loses" tag. This might be desirable, though it could also lead to too many tags on a page. As a tag on the tag page, "Different Object" would appear as a tag in its tags section, and people could follow it to find tag pages for different types of object.

Using underscores for spaces is not an option. The only two options are + used by urlencode() and %20 used by rawurlencode(). When a plus sign is part of a tag, it gets converted to %2B. The raw URL works with this, but the semantic one does not. Using urldecode() on the tag value should fix this.

I like the idea of being able to tag tag pages. Different tags will be appropriate for different kinds of pages. For example, a meta tag like "Object" could be suitable for particular tags like "Won by Checkmate", "Won by Capture", "Won by Stalemate", "Won by Total Elimination", "Won by Winning Race", etc. This is more flexible than giving something a parent tag, since it allows particular tags to have multiple meta tags.

We need to give some thought to what tags we will use. We can use the categories in the Item table as guidelines. Some of these categories are good, but there are some things I have wanted to change about them. In particular, there are a bunch of categories that are intended to imply a game played with the usual equipment, yet they would also be useful for games that are not played with the usual equipment. Using the What is a Chess Variant?  page as a guide, we could use tags that indicate various ways that a game could deviate from Chess, and sometimes tags for how a game is similar to Chess. A tag such as "Playable with a Chess Set" may be suitable for games played with the usual equipment. But it might be overkill to include tags for several features common to Chess, such as "Won by Checkmate", "Normal Castling", "2D", etc. Tags such as these would cover most of the variants on the site, which would make them less useful for navigation. "Playable with a Chess Set" is useful though, because it is more narrow than these, and sometimes a Chess set is the only equipment someone has for playing Chess variants.

chess+compounds was working before; taginfo.php was already decoding urls.

Suggest that semantic URLs use underscores for spaces instead?  They seem easy to understand as replacing a space, less likely to be actually used in a tag name, and easy to replace in taginfo after decoding.

I think we need to come to a decision on tag relationships.  I think three things have been floated:

1. using TagParent in the database to build a treelike hierarchy
2. allowing tags to have tags via their taginfo page (this gets away from the idea that only games will have tags)
3. no formal relationship, just using the tag names (as I've done so far, with the colon-separated tag names)
4. no relationships

I agree with Fergus that 3 isn't great.  Is 1 flexible enough for what we'd want to do?  Any other ideas?

Originally 1 was my intent (hence the database column TagParent).  If we go that way (or something similar), how should the list of games with a parent tag be displayed?  Just those with the parent tag, not any of the descendents?  Or all games with the parent or descendent tags in one list?  Or several lists, one for each descendent tag?  (I think a list of games with the parent tag but none of the descendents could be useful, e.g. to find "unique" applications of the tag's description.  Having all the lists on the one page is redundant, but perhaps useful?)

Maybe using urldecode() in taginfo.php will allow tags with plus signs.

I fixed a problem with parsing semantic URLs. It was expecting complete words without spaces, which wouldn't allow for phrases. I changed that. Now, a semantic URL like http://www.chessvariants.com/tag/Chess+Cubed will work. However, the CSS is not working for http://www.chessvariants.com/tag/Chess+Cubed/. I think it interprets this as another directory level. Instead of using "../g/", using "/g/" should fix that.

I was thinking of URL encoding the semantic URLs, but I noticed that Chrome was doing it automatically when I clicked the link. I'm not sure how universal this behavior is, though. So I have urlencoded them anyway for safe measure. I decided on urlencode() rather than rawurlencode(), because plus signs look cleaner for spaces, and the choice had no effect on whether your chess+compounds tag would work. In every case, whether I used urlencode(), rawurlencode(), or left it unchanged, it didn't work. So, plus signs should be avoided in tags.

It's also time to change the tag links on this page to semantic URLs. The code I'm using in the footer for a tag URL is this:

printf ("<A HREF="http://www.chessvariants.com/tag/%s" CLASS="tag">%s</A> ", urlencode($key), $key);

Note that $key happens to be the tag in this line of code, and you might be using a different variable for it.

Fixed. Next time, post your bug reports for Game Courier in an appropriate section.

In my current game of Shogi, it won't let me play bishop takes bishop. An error message appears instead. 

Where there is an entry for the tag in tagDetails, it would be helpful to include the tagSentence after the name of the tag in this list. This will help people better understand what each tag means, and it will let us know which tags still need descriptions.

I would like to avoid cryptic tags. These tags are meant to be read by people, not simply by machines. Generally, the tag alone should be enough to inform someone what it means. The "shape:board" tag is cryptic. Every board has a shape. Something like "Unusual Board Shape" might work better. Phrases would be less cryptic than using a colon between two different words. Also, I'll be using a colon in the pseudo UserIDs for tag pages. This is partially in the works, though more needs to be done.

I have changed the collations in the tagDetails table to utf8_general_ci, and I have extended the size of the tags to 64 to match the size in the Tags table.