The impossible problem of naming things

Is there any situation more socially awkward than not knowing someone’s name and having to describe them to someone else?

“Erm, you know that tall guy? Kinda slim? Talks fast? Short brown hair? In the engineering department?”

Even deciding what attributes to use to describe them is fraught with difficulties.

And in Building Information Modelling is there anything more contentious than how to name something?

No system ever seems to satisfy everyone’s requirements. The British Standard, Publicly Available Standard, and International Standard documents do a good job but they’re far from perfect. Whether it’s zone, document type, or classification system, there’s always some part of it that just doesn’t seem to work properly for users.

Files, library objects, layers, instances of objects, and even classification systems themselves suffer from this problem.

Why?

Why is it so difficult to name things?

Many decry “dinosaurs” who don’t want to change, or the standards bodies that don’t know about the real world, or simply poor implementation.

But I believe it is because of the unresolvable conflicts between human needs and information management needs.

Humans need names to be readable, simple, understandable, and easy to remember. For information management we need names to be easy to process, flexible, yet also rigidly structured.

Human needs

There’s a good reason why giving people names is a concept used in every human society, it allows us to make reference to people easily.

Sure, a person’s name doesn’t really tell us anything about that person, but given context at least we can work out who is being talked about.

Construction projects have many documents and we need a way to reference specific ones, so naturally we use “names”. However, we can’t just give them names like Steve or Roger, instead we try to inject some context and logic into them with names like AH-CHT-Z1-00-DR-M-55_11_20-1001.

Assuming we have memorised the standard, we can have a good guess about what this document contains, but it still leaves an awful lot to the imagination and is not very readable.

It is also a huge assumption that everyone would know what all the codes stand for, so it’s not very simple.

It’s not particularly memorable either,

Information needs

The concatenation problem

To create a contextual name we have to concatenate different information, and we have to be selective about which information to include, which means potentially useful information is excluded.

We also have to shorten down descriptions to simple codes, e.g. DR = Drawing, M2 = Model, ZZ / XX =???.

And then to actually process that name back into useful data it must be split up and inferred based on the position and short codes. It’s all very difficult to process.

The multiple problem

There’s the multiple problem, what happens when a document covers more than one zone, level, type, role, or classification? Ideally there should be a list of possible values, but we can’t put that in a concatenated name, certainly not without making it overly long. The workaround is to just class them as multiple or none applicable without specifying what the multiple even are. A name isn’t flexible enough to allow for these possibilities.

The string problem

There’s also the problem that a name is always just a string of characters. To enforce the structure of a string of characters is a very difficult thing to do. See the code needed just to validate email addresses, which doesn’t even take into account the content itself. In this respect, names are too flexible and not rigidly structured enough.

Are names necessary?

With all these problems, it brings us to an important point. In a digital, structured data environment do we even need names or naming conventions?

Rather than a name, uniqueness could be ensured using proper Globally Unique IDs.

All the current fields in a name could instead be a list of properties that, without the restriction of having to form a name, could eliminate the need for short codes and use much more readable full words.

For humans, we could have unlimited length descriptions, and even additional fields in any format appropriate.

This could avoid the concept of concatenating fields which is just a compromise between humans and information and makes data dumber.

Conclusion

Let’s forget about names. A name should be anything anyone wants it to be. If we need more context then look at the attached raw data. Because after all, the data is where the focus should be.

One thought on “The impossible problem of naming things

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s