There is a common practice amongst weblog softwares to display date information in the URI for a particular item. However, if we expand weblog software to manage an entire sites worth of content, dates should not appear in most URIs. If I publish documentation for a particular version of software that I am working on, the date the document was published isn’t going to be very important. However, the name of the software package and its version number might be.
By looking at the URI of this particular entry, would you prefer to see /2003/05/08/SiteURIs or /tech/comp/software/web/SiteURIs as the URI? The only time a date is important in URI is when the information at that URI is specific to a specific date. For instance: /news/2003/05/08/TodaysEvents.
A URI should never change. Therefore, if I’m stuck with a date in the URI for a particular piece of content, then, regardless of how often I update it, that date will be there for ever. That just doesn’t make sense. Dates should be optional and available to be used on none, some, most, or all of the content.
While any particular piece of content may fall into multiple categories, it should have one, and only one, permanent location. This helps to keep everyone linking to the same place and keeps users from wondering if they’ve been to a particular link found on another site. This means that, while this entry may appear at /tech/comp/software/web/2003/05/08/ and at /personal/crazythoughts/2003/05/08/ its permanent, official location should be in one and only one place, determined by the author.
Ocassionally, a particular category may need to be divided or moved entirely due to reorganization of content or too many items being categorized in the same fashion. Because of this, the system should be able to locate any item and redirect the user to the proper location. Since, after 50,000 pieces of content have been created, generating unique names for each piece of information might become difficult, the use of ID numbers is encouraged. If I should decide that web should be its own category under tech (resulting in /tech/web/SiteURIs for this entry) the system should detect that this item has been relocated and redirect the user to the proper location.
However, in doing that, we now, once again, have to deal with the fact that the official URI has changed. Even though we are nice enough to provide the user with a redirect, I’d rather I didn’t have to. So, that leads me in the direction of using /SiteURIs as the URI for this particular entry. It’s easy to type, it states what the user will find at that location, and it doesn’t suffer the problems that can come with reorganizing a site. Unfortunately, this isn’t the first time, nor will it be the last, that I write an article about “Site URIs”. One solution would be to preface the title with an ID number: /29945_SiteURIs, but that adds junk to the URL that might not need to be there. If we’re going to add junk, we might as well make it useful junk. Perhaps the date of the entry: /2003/05/08/SiteURIs. However, now the URL is longer than before, and the date, in this case, isn’t really important. Plus, imaging making a “Contact” page or a “Resume” page and having it at a url like /2001/06/04/Resume. That just doesn’t make sense. Especially since, it’s 2003 now, and I’ve updated my Resume 37 times since then.
I’m inclined to say that the BEST solution is to use category style URIs /tech/web/SiteURIs and redirect if there is a newer, permanent location. In order to facilitate this in a simple, easy fashion, it might be wise to include an ID number in the URL: /tech/web/29945_SiteURIs. It’s a little but of unneeded information that will help locate a relocated item much easier. Additionally, if for some reason a particular item becomes retitled, the ID number is still accurate.
I’d like input from readers, potential users, developers, and designers. Please comment here, post in your own weblogs, or email me directly.