This document provides a standard to use when creating data names. Standardized
data names facilitate data sharing, data consistency, and communication between
organizational areas in the Service. Standardized data names also assist the
data administration effort, by making it possible to eliminate data redundancies
and inconsistencies.

2.5.7.1.1
(11-26-2001)Scope

The scope of this document is Servicewide. It applies to all Service
personnel, as well as contractors, who create, gather, store, manipulate,
report and, in general, use Service data in carrying out their functions.
It also applies to all personnel and contractors who document and maintain
Service data on a data dictionary.

Adherence to these standards if required for any mainframe application
exclusive of applications written in AM They are also to be used for any small-scale
ADP application as defined in the Small-Scale Applications Handbook (IRM 2553.23).
While the use of standards is desirable from the standpoint of ease of systems
maintenance in development of standalone microcomputer-based systems, it provides
the greatest benefit in the large mainframe and networked mini/microcomputer
environments where the potential for data sharing is greater.

These standards must be used in the analysis and design stages of systems
development. They must also be followed in the programming stage of systems
development for all COBOL applications and, to the extent possible ,
for programs in other languages. Users of languages which cannot conform to
these standards must cross-reference nonstandard names with
standard names on the Service-wide Data Dictionary or the Mini/Micro Data
Dictionary. (Refer to Exhibit 300-1 for definitions .) This
cross-referenced list will provide input to overall IRS strategic data planning
in the future.

At a minimum, data names must be documented in a manual
dictionary. However, use of an automated data dictionary is recommended.

2.5.7.1.2
(11-26-2001)Background

The Paperwork Reduction Act of 1980 highlighted the fact that data is
a resource and has value and associated cost. It emphasized the need to make
efficient use of the resource and minimize the cost to the Federal Government of
collecting, maintaining, using and disseminating information.
This philosophy became known as Information Resources Management (IRM).

This philosophy surfaced at the IRS when, in November 1981, the Assistant
Commissioner (Computer Services) initiated action directing
an effort be undertaken to standardize data element names and codes across
the Service. The concept of data as a valuable organizational resource has
been further defined by Treasury Directive 81-04 formerly
known as 81-02.A (Responsibilities of a Data Administrator.)

2.5.7.1.3
(11-26-2001)Distribution

Distribution of this Handbook is made to all personnel who use Service
data in carrying out data processing and information resources management
functions.

2.5.7.2
(04-01-2005)Responsibilities

All Service personnel and contractors within the scope of this document
are responsible for using these naming standards. This responsibility
is specified in the ADP Software Standards and Guidelines
under the Development Phase (IRM 2548.3:(1)) and in the
Small-Scale Applications Handbook (IRM 2553.23).

The Office of Standards and Data Administration is
responsible for the central data administration function
in the Service. This includes assisting in the implementation and use of these
naming standards; approving names and abbreviations created using this standard;
reviewing and documenting acceptable acronyms ; encouraging
the use of data dictionaries by Service personnel; and promoting data sharing and
consistency by documentation of standard data names in the
Servicewide Data Dictionary and the Mini/Micro Data Dictionary.

Application for a standards waiver should follow the procedure in IRM
2.5.1, Systems Development.

2.5.7.3
(11-26-2001)Objective

The objective of using these naming standards is to
develop a name which is unique and self-explanatory. A reader should gain
some knowledge of the entity from the name alone.

2.5.7.3.1
(11-26-2001)General

Only alphabetic (A-Z), numeric (0-9), and special characters (e.g. hyphen,
colon, underscore ) which are appropriate to the language
being used are allowed in a name. No blanks are permitted.

The first character of the data name must be alphabetic (A-Z).

Data names may not start with a verb.

The maximum length of a name (including special characters)
is 30 characters.

Each name must be unique.

Each name must be clear and accurate to reflect a condensed version
of the data description.

Abbreviate only when it is necessary to reduce a name to 30 characters
or less. Effective with this transmittal, names in COBOL
applications will not contain abbreviations for words of
four characters or less.

Each name must contain a class word. A class word specifies the nature
of the data and must be the right-most word in the name (e.g., TAXPAYER-BIRTH-DATE).
Exhibit 300-2 contains the list of preferred class words. Other class words
must be submitted to the Central Data Administrator for approval when the
data cannot be identified by examples from Exhibit 300-2.

2.5.7.4
(11-26-2001)Procedures for Developing a Name

This section comprises the procedures for developing a name.

2.5.7.4.1
(11-26-2001)Describing an Entity

Write a sentence or a paragraph containing a full
but concise description of the entity (user, system, run, module, report,
form, file, record, group, data element, schema, subschema ,
area, set) explaining what it is. This description should be retained as a
part of the data dictionary entry.

A close relationship must exist between a data name and its description;
one should reflect the other. A general
or broad description requires a general name.

Do not use the source or destination of the entity. Avoid: This entry
comes from Run 123 and goes into Run 456.

Do not specify the processing done on the entity. Avoid: This amount
is the result of price times quantity.

Attach system/function names or form numbers to data items only when
the description limits its use to a particular function.
For example: EXAMINATION-CASE-START-DATE and COLLECTION-CASE-START-DATE could
be used with system names attached because their descriptions would be basically
different.

2.5.7.4.2
(11-26-2001)Eliminating Nonessential Words

Eliminate those words in the description which are not essential to
the meaning. Note that these words are deleted only for the purpose of deriving
a name; the full description remains intact in the data dictionary entry.

Unnecessary words usually include articles, conjunctions, prepositions,
and some modifiers. However, in some cases these types of words may be necessary
to the meaning.

2.5.7.4.3
(11-26-2001)Arranging Words in a Meaningful Order

Arrange the remaining words by placing the class word as the last word
on the right of the name, and reorganizing the other words into a meaningful
order. Some change in the form of a word may be necessary; that is, a verb
may be changed to a noun or adjective (example: collect to collection or collected).

In some instances, a good description (as suggested above) will not
result in an adequate name. If, after reworking the description, the resultant
name is still unacceptable, then persons involved in name development must
use their knowledge of the subject data in selecting key words for the name.

2.5.7.4.4
(11-26-2001)Substituting Common IRS Acronyms

Always use common IRS acronyms (required acronyms) for groups of words
in the name (e.g., IMF for Individual Master File, DLN for Document Locator
Number). A list of these acronyms is included as part of Exhibit 300-3 and
Exhibit 300-4. (Note: Those items which are marked by two pound signs are
required acronyms and must always be used.)

Separate the remaining words and required acronyms with the appropriate
special character.

The list of required acronyms is maintained on the Servicewide Data
Dictionary as values under the data element ACRONYMS. The list is also maintained
on the Mini/Micro Data Dictionary. (See note above for both lists.)

) Count the remaining alphanumeric characters and special characters.
Substitute accepted acronyms or abbreviations found on the lists of acronyms
(Exhibit 300-3 and Exhibit 300-4) or approved abbreviations (Exhibit 300-5
and Exhibit 300-6) until the name has 30 or fewer characters (including approved
special characters).

When only the singular form of a word is given as the abbreviation's
meaning, the plural of the word may be assumed acceptable and vice versa,
if that form will make the name more meaningful. Similarly, tenses different
from those listed in the meaning may be assumed acceptable without an addition
to the approved abbreviation list. For example:

On list: COLM Column INCR Increase

May assume: COLMSColumns INCRD Increased

The list of accepted acronyms is maintained as values under the data
element ACRONYMS on the Servicewide Data Dictionary. (Note: Accepted acronyms
are those items which are not indicated by two pound signs and are used only
to reduce a name to 30 characters or less.) Additionally, this lists is maintained
on the Mini/Micro Data Dictionary and the note above applies.

The list of approved abbreviations is on the Servicewide Data Dictionary
as values under the data element APPROVED-ABBREVIATIONS. A list of abbreviations
related to small-scale applications is maintained on the Mini/Micro Data Dictionary.

2.5.7.4.6
(11-26-2001)Summary of Steps

Exhibit 300-7 contains four examples of developing valid names by following
the steps described above which are:

Write a description of the entity.

Eliminate the nonessential words from the description.

Arrange the remaining words in a meaningful order, with the class word
to the right.

Always substitute required acronyms.

Insert the appropriate special character between the remaining words and
required acronyms.

Substitute approved abbreviations or accepted acronyms if the name is
over 30 characters.

2.5.7.4.7
(11-26-2001)Developing a New Abbreviation

) If there is no appropriate abbreviation on the approved list, use
the following steps to develop an abbreviation.

Eliminate vowels right to left to make the most meaningful abbreviation.
Never delete the first letter of the word.

Drop nonessential consonants. Use phonetic sounds to help select only
those letters needed to understand the abbreviated word(s). For example: Block
BLK Opening OPNG

Use a shorter form of the word when the word is lengthy and the shorter
form can be understood. For example: Function FUNC Geographical GEOG

Do not abbreviate a word so as to cause confusion in meaning. For example:
Use: AUTH for Authority Not: AUTHOR for Authority