All original works on this website
unless otherwise noted
are copyright protected and licensed under
a Creative Commons License.
| ||
Inspired by the W3C article Cool URIs don't change [URI] a scheme for perstistent URIs shall be sketched.
The goal is to get human readable URIs which are persistent for any time. The basic idea is: If you have no hint how to order the thoughts, time is perhaps a good choice. And even if you have another idea, adding time doesn't do any major harm.
This section will describe how I decide to use URIs like http://www.zib.de/prohaska/2004/06/uri/ or http://www.zib.de/prohaska/2004/publications/ or http://www.zib.de/prohaska/2001/projects/bone/.
Namespace
All of the URIs will be located below a base URI, e.g. your homepage. In my case all URIs are below http://www.zib.de/prohaska/.
Acronym
Suppose your like to create a new URI for some thought, which might be just a note, a specification or a full fledged project. The first step is to choose an acronym for the thought. This will later be the last part of the URI.
Category
You might want to choose to put the topic into a certain category, e.g. projects. This might look somewhat more sorted to the outside.
Persistence
The basic idea is that URIs live forever and never loose any information. As a consequence you should edit the content at a certain URI only to fix or add content. But you should never remove ideas. Therefore you should think about the timeframe of your topic.
Timeframe
Try to estimate the timeframe of the thought. Will it be stable for this year or only for this month? In very rare cases you might even decide that the thought will be stable forever. Before doing this you should perhaps carefully read Cool URIs don't change [URI] another time. The basic problem is that ideas change astonishingly fast. If you exclude time from the URI you'll have no chance to reconsider in the future. Anyhow, you might release version 1.0 of a software or a specification, which is required to never change in the future. In this case, excluding time might be ok.
You should have strong evidence that during your chosen timeframe it will be feasible to only add content without requiring a major cleanup. If you e.g. start a project which will last for this year, assuming that you only add information to the URI for at least one year is reasonable. If you are just writing down a thought it might perhaps be more reasonable to assume that you will add information the next month. Then you will step back, see how the idea evolved and reconsider how to continue. So you don't know if a major cleanup will be required next month. Therefore choosing a month as a timeframe is rather reasonable. I don't think you'll ever need a timeframe of days when dealing with a personal homepage. This might be different if you're dealing with a team of people which might perhaps generate thoughts which require more revisions after a shorter period of time.
Generating an URI
Depending on the timeframe you give your thought, you should now put together an URI which is made up of the base part, a year, optionally a month, optionally a category and the chosen acronym. This URI documents the starting point of your idea. Examples of such URIs where already given above. If you chose to attach no timeframe, you should consider to use a version. E.g. http://www.zib.de/prohaska/software/fancytool/1.0/ wouldn't be too bad.
If ideas finally evolved to a point where they need major cleanup which would require deletion of content you should continue the work at a new URI. This continuation should be clearly noted on the outdated URI and the new URI could point back in history to its source. You should use e.g. a new URI if you need to split a topic which grew too large into several subtopics, or if you just want to separate some thoughts into an unrelated topic and delete them from the original URI, or if you just like to do some cleanup, e.g. remove older publications from a list and only keep the newest and most important ones.
[URI] Cool URIs don't change,
http://www.w3.org/Provider/Style/URI.html
A lot of the presented results were developed in discussions with Peter Prohaska.