Comments/Ratings for a Single Item

I'll go over some options for semantic URLs here using an example. Here is the actual URL for the example:

http://www.chessvariants.com/index/msdisplay.php?itemid=MSliuyang

Here are some options for a semantic URL:

http://www.chessvariants.com/game/liuyang
http://www.chessvariants.com/CharlesGilman/game/liuyang
http://www.chessvariants.com/charles_gilman/game/liuyang
http://www.chessvariants.com/author/CharlesGilman/game/liuyang
http://www.chessvariants.com/inventor/CharlesGilman/game/liuyang
http://www.chessvariants.com/member/CharlesGilman/game/liuyang

The first is simple, but it doesn't distinguish between editorial content and member-contributed content. The second does this by adding a PersonID, but it introduces a mixed case URL. The third does this by adding a userid, which will normally be lowercase. One advantage of using the PersonID over the UserID is that this is what is used in the Item table to identify the author, whereas the UserID would have to be looked up from the Person table after it was retrieved from a row in Item. Furthermore, writing a mixed case PersonID in lowercase still works. So, for the sake of avoiding an extra step, PersonIDs may be preferable.

Whichever is used, there is one catch to putting the author's id first, and this is that someone could use an id that matches a directory name. So it may be preferable to frame the semantic URL in a pseudo-directory that doesn't match the name of any existing directory. The last three do this with different names for the pseudo-directory. If inventor is used, the PersonID used would be the InventorID instead of the AuthorID.

As I've thought about it more, my main concern has not been about
distinguishing user content from editorial content. That was more David
Howe's interpretation of my concern. My concern has been about not lending
the authority of this site to someone's personal opinions or preferences,
particularly in regard to the naming of pieces. This can be handled in part
through appropriate organization and automatically-placed disclaimers. So I
don't think it is necessary to name the author in the semantic URL. Also,
Tim Berners-Lee recommends against this practice.

What I have in mind is to represent MS itemids with three different
pseudo-directories: invention, report, and opinion. Invention would be for
a game page written by the game's inventor. Report would be for a game page
written by someone other than the game's inventor or for reporting actual
usage or convention, as in a Piececlopedia article. Opinion would be for
non-game articles in which the author puts forth his own ideas for the sake
of shaping usage or convention, as opposed to reporting on what these have
been. This is why piece articles have been distinguished from Piececlopedia
articles. The Piececlopedia is an encyclopedic reference on what usage and
convention have been, whereas the piece articles express suggestions by the
author. For some of the other types, it may be appropriate to use the type
name. I may go over what types of pages belong to each type to better
decide how to structure and organize types.

I have started to implement the semantic URLs, but maybe I will change
opinion to ideas, since it better captures the creative aspect of the
content, and these are not like opinion pieces you might read in a
newspaper.

Any indexed page on this site can now be reached with an URL like this:

http://www.chessvariants.com/page/ItemID

For it to work, just replace "ItemID" with the page's actual ItemID. For
game pages, at least, the ItemID tends to be the name of the game. This
makes this a convenient way for quickly typing the URL to a page you want
to go to without having to remember its path.

I was thinking of preceding the ItemID with /id/, but given the name of
this site, /page/ seemed more appropriate.

Note that this works through redirection. So you will still see the page's
actual URL when you go to it.

I'm thinking of creating a new set of semantic URLs, using either /game/ or /rules/. Since this site is all about games, the use of /game/ seems too generic. So, I'm leaning toward /rules/. This would be used for pages on this site that describe the rules of a game, and it would be followed by the game's GameID, which is a new thing we've started working on. Unlike ItemIDs, which are generally for particular pages, and which do not follow any standardized naming conventions, the GameID would usually be a lowercase version of the game's name with hyphens in place of spaces and the nearest ASCII characters in place of foreign characters. In a few cases, the GameID would include something extra for disambiguation with another GameID for a game with the same name. The purpose behind the GameID will be to more easily group together pages on the same game and to provide a basis for suitable semantic URLs. The /rules/, or possibly /game/, semantic URLs would replace /invention/ and /report/ for member-submitted games, and it would also work for HTML pages, giving URLs more consistency than they currently have. Any thoughts or opinions before I proceed further with this?

I prefer /game because it generates URLs that seem more natural for sharing.  If I want to share a link to Opulent Chess, I think http://www.chessvariants.com/game/opulent-chess is preferable to http://www.chessvariants.com/rules/opulent-chess.  And, presumably, this page would also have links to the Zillions page, GC page, etc., so it would be the game's home page, and not just the rules.  If you wanted a separate launch page, though, then I guess that would be /game and the existing page would be /rules, but a separate page for just two or three links seems unnecessary.

Where I used to use /invention/ for games described by their creators and /report/ for other games, I am now using /rules/ for all game rule pages stored in the database. Semantic URLs with the pseudo-directory /rules/ will now appear on this site instead of these. But in case you used /invention/ or /report/ URLs in hardlinks or on another site, the /invention/ and /report/ URLs will still work. They are just deprecated now.

This is done in conjunction with generating XML sitemaps that include all indexed pages that are not hidden, deleted, or reported to have broken links. Note that the sitemaps are for robots and spiders, not for public view.