Subject: Draft ISO 11179, Part 5, Data element Naming

From: BRUCE BARGMEYER 202-260-5306 <[email-masked]>
Date: Sun, 27 Mar 1994 11:33:00 -0500 (EST)

Subject: New version of 11179-5
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "ngo.phongx" <[email-masked]>, "[email-masked]" <[email-masked]>, "bargmeyer.bruce" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 3 Mar 1994 10:15:00 EST

Editor's notes:                                   24 February 1994

This version of CD 11179-5 submitted for a second CD ballot has
been revised taking into consideration comments received from the
French and Netherlands members.  Some of the changes include:

     -     The scope section clarifies the narrow definition of
          "identification" which this standard addresses.  In
          addition, the term "identifier" has been replaced by
          "registration identifier" to emphasize this narrow scope.

     -    The normative references now only list documents at the
          DIS level and above.

     -    Each term has only a single definition, and one in
          agreement with 11179-3.

     -    A definition for "structure set" has been added.

     -    Some revision to the text of Clauses 5, 6, and 7 have
          been made for clarification (I hope!).

     -    References to predicates and versions have been deleted.

     -    Annexes A and B have been deleted.

The editor wishes to thank those members who submitted comments and
hopes this version meets with approval.

Thank You,
Judith Newton
voice +1 301 975 3256
fax   +1 301 948 6213
email [email-masked] 

                       ISO/IEC CD 11179-5

                Specification and Standardization

                        Of Data Elements

                             PART 5

              Naming and Identification Principles

                        For Data Elements

                          FEBRUARY 1994

              Naming and Identification Principles
                        For Data Elements

Contents
----------------------------------------------------

Foreword

1  Introduction

2  Scope

3  Normative References

4  Definitions

5  Principles for the Identification Structure of Data

6  Rules for Registration Identification of Data

7  Guidelines for Structured Naming Conventions

8  Thesaurus Application Guidelines

Informative Annexes

A  Example Naming Convention

B  Registration Identification Example

C  Thesaurus Example Foreword

This International Standard consists of a set of six interrelated parts, with each part focussing on
one aspect of data representation principles.  The six parts are titled as follows:

     11179-1 - Framework for the Specification and Standardization of Data Elements

     11179-2 - Classification of Concepts for the Identification of Domains

     11179-3 - Basic Attributes of Data Elements

     11179-4 - Rules and Guidelines for the Formulation of Data Definitions

     11179-5 - Naming and Identification Principles for Data Elements

     11179-6 - Registration of Data Elements

This part of ISO/IEC 11179 contains rules and guidance for naming and identifying data
elements.

 1  Introduction

This standard contains principles, rules and guidelines.  Principles establish the premises on
which the rules are based.  Rules are mandatory and testable for compliance.  Guidelines are
applications of the rules recommended for good practice.

2  Scope

This part of the International Standard describes the components and structure of data element
identification.  Identification is narrowly defined to encompass only the means to establish unique
identification of data elements within a registry.  It defines the identifying attributes; describes
the relationship of the attributes to each other; includes principles by which naming conventions
can be developed; and describes an example naming convention.  The naming guidelines
described herein can be applied to all names.

This part of the International Standard is meant to be used in conjunction with those which
establish rules and procedures for  attributing, classifying, defining, and registering data elements.

3  Normative References

The following standards contain provisions which, through reference in the text, constitute
provisions for this International Standard.  At the time of publication, the editions indicated were
valid.  All standards are subject to revision, and parties to agreements based on this International
Standard are encouraged to investigate the possibility of applying the most recent editions of
standards indicated below.  Members of IEC and ISO maintain registers of currently valid
International Standards.

ISO/IEC DIS 11179-3:1993, Basic Attributes of Data Elements

4  Definitions

For the purposes of this part of this International Standard, the following definitions apply.

4.1  attribute: A characteristic of an object or entity.

4.2  class (of entities): In a conceptual schema language, all possible entities in a universe of
discourse for which a given proposition holds.

4.3  context: An environment, such as an organization, discipline or industry, for which specific
naming conventions, including rules for uniqueness, are enforced.

4.4  data element: a unit of data for which the identification, meaning, representations and
permissible values are specified by means of a set of attributes.

4.5  data element concept: A concept which can be represented in the form of a data element,
described independently of any particular representation.

4.6  definition: A word or phrase expressing the essential nature of a person or thing or class
of persons or things: an answer to the question "what is x?" or "what is an x?".

4.7 domain: The set of permissible data values from which actual values are taken for a
particular attribute or specific data element.

4.8  headword: A common, unit, abstract noun which is syntactically dominant.

4.9  identifier: A character string or other graphic symbol used to identify a data element.

4.10 lexical: Of or relating to words or the vocabulary of a language as distinguished from its
grammar and construction.

4.11 modifier: A word or words which help define and differentiate a name within the database.

4.12 name: The primary means of identification of objects and concepts for humans.

4.13 property: A component of the name of a data element which expresses the category to
which the data element belongs, e.g., "file," "date," "name."

4.14 referent: A component of the name of a data element which reresents the logical data
grouping (in a logical data model) to which it belongs; e.g., "employee."

4.15 registration authority: Any organization authorized to register a data element; the attribute
which stores this.

4.16 semantics: The relationships of characters, groups of characters, words, or terms to their
meanings.

4.17 separator: A symbol or space enclosing or separating a component within a name; a
delimiter.

4.18 structure set: a method of placing objects in context, revealing relationships to other
objects.  Examples include Entity-Relationship Models, taxonomies, and ontologies.

4.19 syntax: The relationships among characters or groups of characters, independent of their
meanings or the manner of their interpretation and use.  The structure of expressions in a
language, and the rules governing the structure of a language.

4.20 thesaurus: A controlled vocabulary arranged in a known order in which relationships among
terms are displayed and identified.

5  Principles for the Identification Structure of Data

5.1 Identifying Attributes

A set of four related attributes serves to name and identify each data element for the purpose of
differentiating data elements within a registery.  These attributes are:

          name

          context

          registration identifier

          registration authority 

The fundamental principles for these attributes are stated below.

5.2  Name and Context

Each data element is assigned one or more names.  Each name has special utility within a
particular context.  Rigorously structured names may be created for data administration, a
preferred name may be specified by users, shortened names may be generated for particular
software environments such as a particular programming language or database management
system.

Names for many data elements may be developed within each context.  A naming convention
(usually a set of rules) is established for each context to specify how names are formulated within
that context.  The naming convention covers all pertinent aspects of the context.  This includes,
as applicable:

     a.   the purpose of the context, e.g., industry preferred name;

     b.   the authority which establishes the name;

     c.   semantic rules governing the source and content of the words used in the name,
          e.g., words derived from data models, words commonly used in the discipline,
          etc.;

     d.   syntactic rules covering required word order;

     e.   lexical rules covering controlled word lists, name length, character set, language;
          and

     f.   a rule establishing whether or not names within this context must be unique.

These aspects of a naming convention are detailed in Clause 7, which provides guidelines for
developing a naming convention for a rigorously structured context.

5.3  Registration Identifier and Registration Authority

At least one unique registration identifier is required for a data element.  The registration
identifier does not change as long as the domain and definition of the data element do not
change.  Each registration identifier is assigned by a registration authority; therefore, registration
identifiers are unique within a registration authority.

As a data element may be assigned registration identifiers by multiple registration authorities, the
registration identifier and the registration authority are both necessary for identification of a data
element.  If particular aspects of a data element change, then a new version of the data element
is registered.

The registration identifier is the universal means for identifying a data element and can serve as
the basis for exchanging data among information systems, organizations, or other parties who
wish to share a specific data element, but may not utilize the same names or contexts.  the unique
registration identifier is also useful for language translation when the registration identifier is
associated with contexts established for more than one natural language.

This standard does not specify the format or content of the unique registration identifier to be
assigned by any registration authority.

Requirements for a Registration Authority are specified in Part 6 of the International Standard.

6  Rules for Registration Identification of Data

     1.   Each data element shall have a unique registration identifier within a registration
          authority.

     2.   The combination of registration identifier and registration authority shall constitute
          a unique identification for a data element.

     3.   To be assigned a registration identifier, a data element shall have been:
                    derived according to Part 2,
                    attributed according to Part 3,
                    defined according to Part 4,
                    named according to Part 5, and
                    registered according to Part 6.

     4.   A data element shall have at least one name within a context.

7  Guidelines for Structured Naming Conventions

The following are guidelines that could be used to develop a naming convention to produce
rigorously structured names for a particular context.  Annex A is an example of a specific naming
convention that is consistent with these principles.

The guidelines are described in general terms with examples furnished.  Rules are derived from
the principles by which names are developed; these rules form a naming convention.  Names
formed according to these rules can be easily translated into languages other than the original
because of the simplified syntax. Syntax, semantics and lexical rules vary by organizations such
as corporations or standards-setting bodies for business sectors; each can establish rules for name
formation within its context.

As discussed in subclause 7.1.1.1, each data element is formed from a set of components selected
from the structure sets within its context.

Data element names should be formed from the names of components, each assigned meaning
(semantics) and relative or absolute position (syntax) within a name.  They are subject to lexical
rules.  They may, but need not, be delimited by a separator symbol.  The domain, the set or
range of values of each component, should be rigorously controlled by an authority, e.g., a data
administrator within a corporation or an approving committee for an international business sector
naming standard.

          Semantic rules convey meaning through logical reference.

          Syntactic rules relate components in a consistent, specified order.

          Lexical (word form and vocabulary) rules reduce redundancy and increase
          precision.

7.1  Principles Governing Semantic Content of Names

Semantics concerns the meanings of components and the separators which enclose or delimit
them.

7.1.1 Semantics of Components

Components consist of discrete terms to which meaning is ascribed through logical reference. 
The components described in this International Standard are:  referents, properties, and
modifiers.

7.1.1.1  Referent

Using a modeling methodology, as for instance an Entity Relationship Diagram (ERD) or object
model, is a way to locate and discretely place all data elements in relation to their higher-level
model entities.  The attributes of entity-relationship model entities equate to data elements which
are related to each other through further application of the methodology.  In the object model,
data elements are expressed as object attributes.

Many of these model attributes remain constant among model entities; for instance, the location
of a real-world object such as a building or piece of equipment, address for a person or business,
and many codes widely distributed throughout the enterprise, such as social security number used
as the identifier of an employee.

Models provide one classification scheme for data elements.  Data elements may be identified
with their originating modeling entities by mapping the referent to the model entity name. 
Examples of these names are: Employee, Cost, Training, and Member.  The Framework provides
examples of the mapping between referents and ERD and object model entities.

7.1.1.2 Property

A set of properties is developed from the set of components in the taxonomy.  This set must
consist of terms which are discrete (the definition of each does not overlap the definition of any
other), and complete (taken together, the set represents all information concepts required for the
specification of data elements).  A property may contain a headword (a word of syntactic
dominance). 

Examples of properties include Name, Count, Code, Rate, Velocity, Length Measure, Height
Measure, and Number.

The property will occur naturally in the definition of a data element.

Using components from two structure sets provides a complementary way of categorization. 
Both referent and property components of data elements are utilized to form a name which
contains vital information about the data element, and also excludes extraneous or irrational
elements which may be introduced when no conventions are employed.

7.1.1.3  Modifier

Modifiers may be attached to properties and referents if necessary to uniquely identify a data
element.  These modifiers may be derived from structure sets specific to a context.  In the rules
for a naming convention, a restriction in the number of modifiers is recommended.

A modifier serves to constrain the meaning of another component. Semantic limitations are
delineated for modifiers to reduce redundancy and increase incidence of data reuse through
recognition of synonymous elements.  A mechanism such as a thesaurus of terms facilitates this
effort (see Clause 8; Annex C).

7.1.2  Semantics of Separators

Components are delimited by separators.  These may or may not have semantic meaning.  A
simple rule stating that separators will consist of one blank space or exactly one special character
(for example a hyphen or underscore) regardless of semantic relationships of components
simplifies name formation. 

Alternatively, semantic meaning can be conveyed by separators by, for example, assigning a
different separator between the modifier and head word in the property than that which separates
the other modifier(s).  In this way, the separator serves as a signal to the user and identifies the
property clearly as different from the rest of the name.  Example: in Employee-Birth-State_Name,
the property separator is an underscore; other components are separated by hyphens.

Some languages, such as German and Dutch, commonly join grammatical constructs together in
a single word (resulting in one word which in English might be a phrase consisting of nouns and
adjectives).  These languages may use a separator which is not a break between words, such as
a hyphen, space or underscore, but instead capitalize the first letter of each grammatical construct
within a single word.

7.2  Principles Governing Format of Names

7.2.1  Syntactic Guidelines

A naming convention specifies the arrangement of components within the name.  This
arrangement may be specified as relative or absolute, or some combination of the two.

     1.   Relative arrangement specifies components in terms of other components,
          e.g., a rule within a convention might require that a modifier must always
          appear before the component being modified appears.

     2.   Absolute arrangement specifies a fixed occurrence of the component, e.g.,
          a rule might require that the property is always the last component in the
          name.

7.2.2  Lexical Guidelines

These rules concern allowed and disallowed words in components, synonyms, abbreviations,
component length, etc.

8  Thesaurus Application Guidelines

A thesaurus in which the user can find a variety of synonyms, near-synonyms and homographs
for name components is a valuable tool.  It can provide semantic linking between preferred name
terms and other terms.  In addition to guidance for use of homographs (words with the same
spelling representing different concepts), a thesaurus can direct the user through choices
involving:

          equivalence - in which one word or term is preferred over others for expression
          of a concept;

          hierarchy - in which a relationship between broader and narrower terms is
          expressed by levels of superordination or subordination; and

          association - in which two or more terms are semantically or conceptually
          associated, whether they belong to the same hierarchy or different hierarchies.

A thesaurus for components used in the name may be developed and distributed to interested
parties by the registrar; in addition, development of subject area thesauri should be encouraged.

A thesaurus may be used to describe structures in verbal representation as a supplement to
graphic depiction.  Preferred terms become component names; relationships between preferred
terms express the position of components in the structure.

A controlled vocabulary is an advantage for thesaurus use.  Control can be built into a thesaurus
through scope of descriptors, linking of synonyms and near-synonyms through equivalence, and
the resolution of homographs.  These are all functions which users of classification structures
need to navigate through the system.
 ANNEX A  (INFORMATIVE)  

EXAMPLE NAMING CONVENTION

These rules are derived from the guidelines described in Clause 7. Examples are included.  They
may be applied to the development of  context names at the discretion of the subject area
authority.

A.1  Semantic Rules

     a.   Referents represent things of interest to the enterprise which may, for instance, be
          found in an enterprise model structure set.

          Example: Cost

     b.   One and only one referent shall be present.

     c.   Properties shall be derived from the classification system structure set and
          represent the class, or category, of the data.

          Example: Total Amount

     d.   One and only one property shall be present.

     e.   Modifiers may be derived as determined by the subject area authority and will be
          added as needed to describe the data element and make it unique within a
          specified context.  One modifier may be part of a property; the order of other
          modifiers is not significant.  Modifiers are optional.

          Example:  Budget Period Total Amount

A.2  Syntactic Rules

     a.   The referent shall occupy the first (leftmost) position in the name. 

     b.   Modifiers shall precede the component modified.  The order of modifiers shall not
          be used to differentiate data element names.

     c.   The property shall occupy the last (rightmost) position.

          Example: Cost : Budget Period : [Total  Amount]

                 referent    :       modifiers         :  [property]

A.3  Lexical Rules

     a.   Nouns are used in singular form only.  Verbs (if any) are in the present tense. 

     b.   Name components and words in multi-word terms are separated by spaces.  No
          special characters are allowed.

     c.   All words in the name are in mixed case.
          
     d.   Abbreviations, acronyms, and initialisms are allowed.

               Example: Cost Budget Period Total Amount

 ANNEX B  (INFORMATIVE)  

IDENTIFICATION EXAMPLE

(ENGLISH LANGUAGE)

The identification structure of an example data element 

is as follows:

DATA ELEMENT 
                                |
     1:1 | contains
------------------------------------------------------------------
|REG AUTH      REG ID              NAME           CONTEXT        |
|                                                                |
|ISO           848575         ACCOUNT_AMOUNT      USA_GICS       |
|                                                                |
|                             Cost Budget Period   FIN-EDI       |
|                             Total Amount                       |
|                                                                |
|IEEE          193847         Transfer-Cost-Amount Engineering   |
|                                                                |
|                             our_cost_$           Contracts     |
|                                                                |
|                                                                |
|                                                                |
|                                                                |
|                                                                |
------------------------------------------------------------------

     The component structure for this element is as follows:

     REFERENT:                          
     Cost                               
      \                                      
       \                           PROPERTY:
        \                     Total Amount
         \                         /
          \         MODIFIERS:    /     
           \        Budget Period
            \            /
             \       NAME:
          Cost Budget Period Total Amount

ANNEX C  (INFORMATIVE)

THESAURUS EXAMPLE

An excerpt from a possible thesaurus of structure terms, including structural information as well
as synonym and homonym resolution.

key:
     BT -  Broader Term
     NT -  Narrower Term
     UF -  Use For 
     USE - Use the following term instead
     RT  - Related Term
     SN  - Scope Note

THESAURUS EXCERPT

     COST
          SN  Amount the organization spends to procure
              goods or services.
          BT  Contract
          NT  Petty Cash
          UF  Expense
          RT  Budget
          RT  Amount

     Expense
          USE Cost

Note that although the thesaurus entry can show that COST is related to both Budget and
Amount, the exact nature of the relationship is not explicit.

Italics are used to denote deprecated terms.  This is the method used to distinguish preferred
terms among synonyms.

One or more levels of hierarchy can be shown by listing several broader and narrower terms. 
This is a thesaurus design decision.

The scope note reflects the definition as described in Part 4 of this Standard.

From: [email-masked]
Date: Thu, 3 Mar 1994 10:28:00 EST

RFC-822-headers:
Date: Thu, 03 Mar 1994 10:15:25 +0000
From: Judith Newton <[email-masked]>
Subject: New version of 11179-5
To: [email-masked], [email-masked],
 [email-masked], [email-masked], [email-masked],
 [email-masked], [email-masked], [email-masked]