Format for standards tables

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

Folks:

OK, if you're interested in the standards debate or want to know what data
administrators do for a living, this post is for you.  Otherwise, delete
it now or save it for a night when you're suffering from insomnia.

I record, communicate and occasionally create standards for a living.
That's what Data Librarians do; we're a subspecies of Data Administrators.
My group is trying to get the various pieces of Pioneer Hi-Bred
International to agree on common definitions for widely-shared terms, and
to use common lists of codes for widely-shared data.  A task, as my boss
put it the other day, akin to herding cats.

First, I agree wholeheartedly with the people who say we can't agree on a
single, unified standard for most things.  Sure, we could conceivably
publish a standard, but there's no way in the world we could get it
universally adopted.  (There's an ISO standard for shoe sizes, but I still
have to try on everything between a 9 1/2 to an 11 to find the right fit.)

The only field where I've seen wide-scale standard-setting for language
pulled off is journalism, where the Associated Press style guide is
ruthlessly enforced.  This is because nobody wants to re-edit all the AP
copy to a local style.  (Even so, most places have some exceptions to the
guide, and it only applies in the AP newsrooms.)  Until there's a similar
compelling reason to force homogenization in technical writing, it's safe
to say we're going to keep doing our own thing.

Which brings us to Doug Montalbano's very good idea of using a reference
table for variant standards. (I love that term and I'm going to start using
it at work.)  However, there are a couple of issues that need to be
considered.

First, because the volume of data is going to be pretty large, we're going
to need some sort of search capability.  I suggest using a relational
database like Access or Paradox (Just examples, not recommendations. Mac
and UNIX people can re-sheath their weapons. Please.)  Although I love
hypertext, and I use WinHelp for the company Glossary, I suspect the
maintenance burden on something like this would rapidly mushroom out of
control if you had to hand-maintain the links.

Second, the table itself requires standardization and stewardship.  For
example, consider the Audience column.  Are "Programmers" the same thing
as "Application Developers?"  System analysts?  Business Analysts?  Data
Administrators?  Does "Computer Industry" encompass "Programmers" or is it
a completely independent term?  The problem is replicated to a lesser
extent in the Source column. There, you mostly need to worry about
standardizing titles so it isn't "TI Manual xxxx," in one place and "Texas
Instruments Manual xxxx" in another and "xxxx, a TI Manual" in a third.
Definition and Term probably don't need much supervision, since they're
supposed to vary with each definition, although you may at least want to
enforce some copy-editing standards there.

There are no "right" answers here, but if we don't create consistent ones,
we're going to have an incoherent mess.  (We've got some systems suffering
from precisely this problem.)  Once set, the standards should be
implemented through some sort of restriction on data entry, preferably a
pick-list type of arrangement.

Once the restriction is implemented, somebody has to be responsible for
adding new entries, making corrections, and deleting or consolidating old
ones.  The person who does this is usually called a Steward. (Although
ironically, there's no truly standard term.) They may or may not be the
people who set up and maintain the definitions for each entry on the pick
list.  Oh, they'll also have to deal with people who would rather DIE than
describe their "application developers" as "programmers" in a public forum
and they're gonna hold their breath and turn blue and letterbomb you and
publically declare your stupidity for failing to make the change they want
and....

Whoops.  Got a bit carried away there.  Things aren't really that bad
in-house here, but given some of the exchanges we've seen on the list, I
can see it happening.  Stewards need to be pretty thick-skinned.

There is another whole knot of technical and data issues surrounding
synonym searches, duplicate entries, and so forth.  But that's another post
for another day.

Doug
ENGSTROMDD -at- phibred -dot- com