Choosing appropriate names for data types and members is something every developer has to do on a daily basis, whether it be database columns, object properties, or XML schema types etc. In every case, choosing a good descriptive name is imperative to aid both our own understanding of the project, and any other developer who may be working with it, now or in the future.
As such we should make a point of having a certain level of expertise in natural language and linguistics, as well as machine code. I’m sure I’m not the only developer who keeps a thesaurus on his desk for quick reference whilst coding! In addition to having a firm grasp of linguistics, every developer ought to have an understanding of taxonomy, and how to apply that on a conceptual level – ideally to the point of borderline obsessive compulsive disorder, or beyond…
So! Lets say we’re designing a data schema which will represent a postal address value. A naive implementation might look something like this:
- Building Name / Number
- Street
- Town
- County
- Postcode
- Country
This has several problems (many of which will be strikingly obvious if you’re not British). First of all, it’s specific for UK addresses. The concept of a “County” makes no sense outside of the UK. Inversely, the concept of a “State” or “Prefecture” makes no sense to our data schema without some sort of mapping convention. The same is true of “Postcode” when contrasted with “Zip Code“. While “Postcode” might seem like enough of an abstraction, we actually need to look a lot deeper than this, and figure out exactly what it is we’re trying to represent here..
Finding the terminal hypernym
Hypernymy is a term used in linguistics to describe the semantic relation of class and sub-class. A “terminal” hypernym, a term sometimes used in the natural language processing community, is the most abstracted hypernym one can reach while still adequately describing the characteristics of the entity. For example, take the common noun “hatchback“, representing a specific type of car. In this case “car” is the hypernym of “hatchback“. We can follow this through several stages…
- “Hatchback“
- Is a type of “car“
- Is a type of “wheeled vehicle” (as opposed to a tracked or railed vehicle)
- Is a type of “vehicle“
- Is a type of “machine“
We could go on endlessly finding more and more abstract hypernyms, however I would personally draw the line at “vehicle”. “Machine” is so abstract that it’s no longer sufficient to adequately describe the entity, therefore “vehicle” is our terminal hypernym. Now where you draw that line often depends entirely on the domain being modeled, it’s up to you to decide how much abstraction is useful, and at what point it becomes cumbersome. We can follow the same procedure when describing the colour of our car…
- “Racing green“
- Is a type of “green“
- Is a type of “colour” < terminal hypernym
- Is a type of “light“
- Is a type of “electromagnetic radiation” < way beyond being useful in our domain
Can you imagine a car salesman saying to you “and what shade of electromagnetic radiation would you like that in, Mr Smith?” – you would look at him like he just landed a UFO in your front garden. But like I said, it depends entirely on the domain being modeled, Henry Ford might well have said something like “and what shade of Black would you like that in?” – where you draw the line of abstraction is entirely domain driven.
So lets apply the same rules to our address schema, we might end up with something like the following:
- Plot Identity
- “Plot” is abstract enough to represent anything ranging from a complex in a business park to a trailer in a trailer park.
- “Identity” can represent the identity of the plot whether it be a building name or a house number, or by some other means.
- Thoroughfare
- Can represent a “road“, “avenue“, “street“, or whatever local variations may exist.
- Municipality
- Is adequate to represent a “town“, “city“, or any urbanization.
- Administrative division
- Tricky one. While abstract enough to represent a “county“, “state“, “province” or “prefecture“, it could be deemed too abstract for the domain. Then again, the fact that it’s “administrative” could be too concrete!
- Postal service identifier
- As far as I’m aware, all postal /zip codes are specific identifiers defined by a domestic postal service.
- Geographical region
- Another tricky one! In most domains “country” would be plenty abstract enough, but it is not always the case (for example strictly speaking “Taiwan” is not a country, it’s a rogue state). “geographical region” is abstract enough to represent these kinds of edge cases, if your domain requires it.
It can often be a process of trial and error. On the one hand, you don’t want your data schema to be so concrete that it’s inflexible; on the other, you don’t want it to be so abstract that it’s difficult to understand what is being represented. Finding the sweet spot requires a sufficient understanding of the domain such that you can put your obsessive compulsive tendencies to work.
