Each kind of name is drawn from a "namespace", and each namespace has a structure. Some of that structure is externally imposed; for example, e-mail addresses must conform to RFC 822 (or its modern equivalent?). Other structure may be self-imposed, e.g. "E-mail addresses are initial + surname, and `ties' will be disambiguated by <insert algorithm here>".

We give our (team Sidai's) specific ideas about names for things in our blessed-names doc.

There are "better" and "worse" namespaces. This document sets out our criteria for what's better.

(If you think you have a good angle on "how to name things" -- whether files, users, or anything else sysadminish -- please speak up!)

Ease-of-use by users is the #1 criterion.

Users like a comparatively simple namespace, and the best indicator that the namespace is working is its predictive power; that is, if a user knows the name of one thing, they can predict what the name of another similar thing is.

Ease-of-change is the #1 sys-administrative criterion.

We know that a system that is easier to change is a win in the long run. Naming that makes this possible is Good.

The Shannon information content of a name is its crucial property.

(The information content of a name is, loosely speaking, its ``surprise factor''. A name like /tmp/ab4kg.2144 carries little information, whereas a name like /home/fred/i_am_an_axe_murderer carries quite a bit.)

Ease-of-use and ease-of-change are in direct tension for Shannon information reasons! Ease-of-use tends to need high-information-content names, and ease-of-change needs low-information-content names. That's why good naming is Pretty Hard.

Good names don't outlive their natural lifespan:

If you name a chunk of disk space /proj/wibble, then that stuff (and that name) should go away after `Project Wibble' is over. If it "can't", then something's wrong.

The same principle applies to e-mail addresses, hostname, etc.

More: ToDo! ToDo! ToDo!