Seven fundamentals of data definitions

We have gotten used to the idea of websites with user-generated content, and many have even become trusted information sources. The best of these depend on various devices to maintain a high level of accuracy. Wikis, for example, rely on versioning and redundant checking, while creative or graphical projects might use a voting system to select the best content for display. The right system depends on the nature of the project. An online database built by many editors around the world presents its own challenges, and the designers of SKYDB have discovered a few ways to ensure dependability and constant improvement. Here I will focus on data standards, which are one of the cornerstones of a useful data set, and something we've put a lot of work into. The idea of standards is simple enough: each data field is defined, and contributors use them as guidelines to ensure consistency of meaning. But actually defining the terms is only about half the work. Less obvious is the need to select the right data fields in the first place. Reality can never be abstracted to everyone's satisfaction, and it's important for authors of standards to recognize this and work around it to create categories and definitions that serve a useful purpose. Over time we've discovered a few basic qualities that are fundamental to optimizing standards:

1. Intelligibility

SKYDB is concerned mainly with data on buildings and structures, and our standards focus on these topics. Some highly technical third-party standards created by professional engineers to describe buildings would be unsuitable to an open project, because new contributors simply would not understand them. The goal is that anybody can add buildings immediately from their own neighborhood, and contributors need to find common-sense terms in the entry forms. We have learned this partly through trial and error. In the past we had a category of facade system that we called "applied masonry". The idea was that facades behaved in fundamentally different ways, depending on whether the material was a cosmetic veneer or a structural load-bearing element of the building. Most people can recognize a masonry facade, but we wanted to distinguish between masonry that actually held up the building (like you would find in a 600-year-old church), and masonry that simply covered a steel or concrete framework. The former was called an "exposed structure" facade, and the latter was "applied masonry". The problem was that few people understood this, and they frequently added the wrong type to a building. Eventually we realized that the categories were wrong. Now we just use masonry to describe the outer surface, regardless of its invisible structural role.

2. Stability

With about 3000 terms defined currently on SKYDB Definitions, there are many occasions when we want to adjust or refine a definition. It is easy to do so. What is not easy is changing all the entered data for vast numbers of buildings to match the new definition: in fact it is nearly impossible. Professional associations involved in tall buildings have gone through the ordeal of retroactively changing data standards a couple of times. In 1997, building height measurement rules changed, and in November 2009 they changed again to measure buildings from below-grade open-air pedestrian entrances rather than the main entrance. The first change was solved in a simple way: by creating 3 additional height categories. The second round was far more labor-intensive, requiring a thorough database search of buildings built on a slope or featuring open-air entrances lower than the main entrance, and then researching the correct heights again to match the new definition. When you have a few thousand data records to work with, this might be possible. When you have millions, it may not be. Editors and contributors of any database expect that the meanings they rely on will not change over time, and their needs have to be accounted for whenever a change appears necessary or desirable.

3. Universality

The idea that standards should be universal runs against cultural differences, and sounds like an attempt to declare objectivity. In fact it has nothing to do with objectivity, and can be handled in ways that respect differences, even if a preference has to be made on one side or another. A database is only valuable when it is consistent across the board, so that buildings in New York are comparable with buildings in New Guinea. Otherwise editors and users do not know what to expect. One area where we faced this problem is the data field for floors above ground. North Americans tend to count the ground floor of a building as "1", and number the floors above "2, 3, 4....". Europeans and South Americans usually call the ground level "0" or "planta baja" or "ground floor", and the next floor up is "1". So depending on whom you ask, the number of floors in the same building can be 10 or 11. For SKYDB's purposes, we decided that "floors above ground" was a simple quantity reflecting a countable number of levels in a structure. The regional differences are more of a floor naming system than a level counting system, so we went with the North American way and counted the ground floor as number "1". Few people have complained, and there are other areas where we adopted conventions from outside the United States (including favoring the metric system).

4. Specificity

No matter how much we categorize things, we always find a demand for more specific categories. For example, at the outset it seemed enough to class buildings by their basic usages, e.g. retail. But then someone wants to search for department stores or clothing stores, and we say "why not?". Then someone else wants to query for second-hand baby clothing stores, so another level or two of clothing stores might be necessary. The most efficient solution is to set up a hierarchical tree of nested categories, so that any basic type can be broken down into more specific types. It is also important that contributors can select, in many cases, the general supertype instead of getting too specific. The reasons go back to intelligibility (people might not know or understand the specific class an object belongs to), and stability (when creating sub-classes you often have to leave previously classified records at a more general level, at least until further research). So when we split movable bridges into 12 sub-types, contributors can continue to select "movable bridge" until someone with more knowledge comes along to specify the record.

5. Commonality

Standards do not exist in a vacuum. When defining some property, usually it is a term that others have been using for a long time. Occasionally there may be reasons to invent a totally new field or category, but otherwise the author of data standards has to accept and work with common existing meanings. Take gross floor area as an example. Many trade associations and governments have already defined this field and have been using it for decades. Any data collected by editors will probably match existing third-party standards, because that is all that has been published. The job of new data standards is not always to invent something new. What is important is to clarify the meaning of a field, and sometimes to smooth out differences between existing usages of the term. If existing data follows inconsistent definitions, one option is to create separate fields, while another is to allow some latitude for variances in precision. Very often, however, data standards can take data where no one has gone before. Instead of redefining a field that others have defined formally (like floor area), it may be necessary to create new fields that no one has codified before (like stairway configuration). In these cases, standards are bound not by formal third-party definitions but solely by the commonly recognized meaning of the words chosen.

6. Flexibility

Demands for flexibility sometimes run counter to demands for stability and universality. Nevertheless it is important to design standards that account for individual variances among editors and contributors, and sometimes definitions have to be loose enough to allow future changes when better knowledge is available. The real world cannot be perfectly reduced to words. No matter how carefully written, some categories will overlap others, and some will be so close to each other that it is really the editor's call which one an object belongs to. Some areas, such as architectural style and facade color, are partly subjective and require a judgment call by the editor assigning them.

7. Accessibility

People will ignore data standards if they are invisible, or if they have to look them up constantly. For this reason, SKYDB links its definitions directly to each term where it appears. When you view a building on SKYDB you can mouse-over each term to see a short definition, or click on it for greater detail. And the people entering data see definitions of each term as they select them. This helps ensure that their understanding matches the agreed meaning.