It is pretty much impossible to interact with a computer for more than a
few minutes without having to supply the name of something. It might be
the name of a website, the name of a folder or file, the name of a
printer on the network, the name of a user of the accounts package,
whatever.
Names and naming conventions are such a core part of how IT functions
that we do not consciously consider it very often. A dialog pops up, you
think of a name (either a new one or an existing one), you type it in
or select it. Then you press return and good stuff happens. Period.
Unconscious, automatic, too obvious and fundamental to merit conscious
thought.
Application designers do spend time thinking about naming. They think
about how users of their applications will interact with the names of
things that the application provides. They think about the types of
names users will be able to create. Unfortunately, some of that thinking
involves relieving the user of the need to think about it too much.
Applications can automatically control how assets will be named and in
what sort of "name space", such as a directory hierarchy, they will be
stored in.
At first blush, it would appear sensible to allow an application to deal
with the naming problem. After all, that feature gives busy users one
less thing to think about. Unfortunately, there is one big catch here to
do with lunch and the fact that there is no such thing as a free one.
If you let an application generate asset names for you, the names are
likely to be, to put it delicately, semantically challenging. Put more
bluntly, they can be gibberish. Here are some examples grabbed from
three different applications I happen to have on hand:
0,2097,1-1-1928-4149-1966-4154,00
jmae5t2seq
cccdadckdgmjdlkcefecefedghhdfjl.0
The trouble with these identifiers of course is that they are
meaningless outside the application that created them. As a result,
applications that generate this sort of gibberish name can end up owning
your data in a subtle and unpleasant way.
The standard way in which an application can own the assets you pour
into it is by using some proprietary storage mechanisms. You can
counteract this age old gambit by prescribing your own XML schemas for
your data and insisting that the applications you buy into, play nicely
with the XML formats that you control.
However, an application can also own the assets by virtue of controlling
the names allocated to them. Names that make no sense beyond the walls
of a particular application. Names that you have no control over, invest
a high degree of data ownership with the application that controls the
names.
The latter is a much more subtle (some would say insidious) way of
wrestling control over data away from its owners and into the cupped
hands of proprietary application vendors.
The easiest way to watch the world of asset naming wars is to surf the
Web. These days, a lot of asset naming conventions involve the Web.
Indeed I would suggest that one of the great asset naming conventions of
all time is at the heart of the World Wide Web's success - namely URIs
(previously known as URLs).
The Web architecture does not completely spell out the structure of
URIs. Parts of them are left under application control. You are free to
use meaningful or meaningless naming conventions at your own discretion.
The Web does not care which you choose.
I would argue that it is a very good idea to keep control over the
naming convention of your assets if at all possible. The right to name
things is a key part of asset ownership in the hyperlinked world we live
in. It is a key component of data ownership which belongs with you, the
customer, not with an application vendor. Don't give it up without a
fight.
