Subject: ISO 11179, Part 4, Definitions - ASCII

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

This is a draft of ISO 11179, Part 4, Rules and Guidelines for the 
Formulation of Data Definitions. It is going out for balloting as a 
Draft International Standard. If you have comments, please send them 
to [email-masked]

The following is an ASCII version which may have gotten mangled a bit 
as all the cosmetics got stripped. The next message has the same 
document as a Postscript file.

Note: This proposal presumes that other useful information, such as 
the purpose for which the data was collected, the statistical 
procedures involved in data collection, and examples are separate 
items of metadata that should be stored separately from the 
definition.

--Bruce Bargmeyer
**********************************

                          ISO/IEC STANDARD 11179

                    Specification and Standardization 
                             of Data Elements

                                  PART 4

                       Rules and Guidelines For The 
                      Formulation of Data Definitions

                               January 1994


                       Rules and Guidelines For The 
                      Formulation of Data Definitions

Contents
_________________________________________________________________

Foreword

1  Scope

2  Normative References

3  Definitions

4  Summary of Data Definition Rules and Guidelines

5  Requirements


Foreword

This document is Part 4 of ISO/IEC 11179, an International
Standard concerning data element  representation.  ISO/IEC 11179
includes six interrelated parts, with each part focusing on one
aspect of data element development.  All parts shall be used in
conjunction with each other.  The six parts are titled as
follows:

  - Framework for the Generation and Standardization of Data Elements
  
  - Classification of Concepts for the Identification of Domains
  - Basic Attributes of Data Elements 
  - Rules and Guidelines for the Formulation of Data Definitions
  - Naming and Identification Principles for Data Elements 
  - Registration of Data Elements 

This document provides guidance on the construction of well-
formed data element  definitions.  See Framework for the
Generation and Standardization of Data Elements, Part 1 of this
International Standard, for discussions of all parts.

ISO 704:1987 (E) states that "a definition is a comprehensive
description of a concept by means of known concepts expressed
mainly by verbal means".  The purpose of a data element
definition is to define the meaning of a data element.

Precise and unambiguous data element definitions are one of the
most critical aspects of ensuring data shareability.  When two or
more parties exchange data, it is essential that all are in
explicit agreement on the meaning of that data.  One of the
primary vehicles for carrying the data's meaning is the data
element definition.  Therefore, it is mandatory that every data
element  have a well-formed definition; one that is clearly
understood by every user.  Poorly formulated data element 
definitions foster misunderstandings and ambiguities and often
inhibit successful communication.

To ensure consistency and quality in constructing data element
definitions, this Part of the International Standard, which
specifies the characteristics of well-formed data definitions,
has been developed.  The rules and guidelines of this standard
apply to the formulation of definitions of data elements used in
information processing systems and information interchange.  

This Part of the International Standard contains both rules and
guidelines.  Rules are mandatory and testable for compliance. 
Guidelines are  principles that shall be followed.  Objective
test criteria can be established for rules, conformance with
guidelines is assessed by judgment of reasonableness.

The data element names in this Part of the International Standard
do not follow a particular syntax.

In this standard, the term data element refers to data element
type; the shorter term is used for convenience.

This document contains one Annex, Informative References.

1 Scope

This Part of the International Standard specifies rules and
guidelines for constructing definitions for data elements.  Only
semantic structures of data element definitions are addressed;
specifications for formatting the definitions are deemed
unnecessary for the purposes of this standard.  

Although these definitional rules and guidelines pertain to data
elements, they can also be applied in formulating definitions for
other types of data constructs such as entity types, entities,
relationships, attributes, object types (or classes), objects,
segments, composites, code entries, and messages.

The definitional rules and guidelines in this Part of the
International standard do not always apply to terminological
definitions found in glossaries and language dictionaries. 
Differences exist between the rules that apply in a language
dictionary, and the rules that apply in a data dictionary.  For
example, terms in a language dictionary may have multiple
definitions in the dictionary, whereas data dictionary
definitions must be unique within a dictionary and have a single
meaning.  

Many data element  definitions include terms that themselves need
to be defined (e.g., "charges", "allowances", "delivery").  Some
of these terms may have different definitions in different
industrial sectors.  Therefore, there is a need for most data
dictionaries to establish an associated glossary of terms used in
the definitions.  The area(s) of use for each term is identified
in the glossary.  

2 Normative References 

The following standards contain provisions which, through refer-

ence in this text, constitute provisions of this Part of the
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 Part of the International
Standard are encouraged to apply the most recent editions of the
standard indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.

  ISO 704:1987, Principles and methods of terminology

  ISO 2382-4:1987, Information processing systems - Vocabulary;
  parts 1-25

  ISO Standards Handbook 10, Data Processing - Vocabulary, 1982

  ISO 1087:1990, Terminology - Vocabulary

  ISO 10241:1992, International terminology standards -
  preparation and layout

3  Definitions

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

attribute: A property or characteristic of one or more entities;
for example, color, weight, sex (ISO 2382).  A description of a
characteristic of an object including rules and/or constraints
[ISO/CD 11179];  A property inherent in an entity or associated
with that entity for database purposes.  See data attribute.

code:  (1) A set of rules that maps the elements on one set, the
coded set, onto the elements of another set, the code element
set.  Synonymous with coding scheme (ISO 2382).  (2) A set of
items, such as abbreviations, that represent the members of
another set (ISO 2382).  (3) An assemblage of symbols used to
briefly represent unique and specifically assigned words. Each
code has corresponding word or phrase that it represents. 

concept: A unit of thought constituted through abstraction on the
basis of characteristics common to a set of objects.

data:  (1)  A representation of facts, concepts, or instructions
in a formalized manner suitable for communication,
interpretation, or processing by humans or by automatic means
(ISO 2382).  (2) Any representation such as characters or analog
quantities to which meaning is or might be assigned (ISO 2382). 
(3) A representation of facts, concepts, or instructions that are
collected, organized, recorded, processed, and stored in a
retrievable form suitable for communication, interpretation, or
processing by human or automated means. 

database: (1) A collection of interrelated data, often with
controlled redundancy, organized according to a schema to serve
one or more applications; the data are stored so that they can be
used by different programs without concern for the data structure
or organization.  A common approach is used to add new data and
to modify and retrieve existing data (ANSI X3.172-1990).  (2) A
collection of interrelated data objects stored together with
controlled redundancy, according to one schema to serve one or
more applications.

data dictionary: (1) A database used for data that refers to the
use and structure of other data; that is, a database for the
storage of metadata (ANSI X3.172-1990).  (2) An inventory that
describes, defines, and lists all of the data elements that are
stored in a database (ANSI X3.172-1990).  (3) A subset of a data
dictionary/directory that provides definitions for each data
element.  See data element dictionary.

    NOTE: Data element dictionaries may exist at various levels,
    e.g., ISO/IEC Committees, international associations,
    industry sectors, companies, application systems.

data element:  (1) A named unit of data that, in some contexts,
is considered indivisible and in other contexts may consist of
data items (ISO 2382).  (2) A unit of data that in a certain
context is considered indivisible [ISO 2382/4].  (3) A named
identifier of each of the entities and their attributes that are
represented in a database (ISO 2382).  (4) A unit of data for
which the identification, description and value representation
have been specified [ISO 9735].  (5) A category of data which
represents a data element concept and properties are expressed as
a set of data element attributes, which permit it to support
information interchange in automatic or manual data processing
systems [JTC 1/SC 1 N1238]. (6) An item of data representing a
single fact about a business object in the real world. It cannot
be decomposed into more fundamental segments of information that
have useful meanings within the scope of its application. Data
elements are electronic or written representations of the
attributes of real-world object types. (7) A unit of data for
which the identification, meaning, representations and
permissible values are specified by means of a set of attributes.

data element dictionary: An information resource that lists and
defines all relevant data elements. Synonymous with data
dictionary.

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?"; a statement of the
meaning of a word or word group [Webster's Third New
International Dictionary of the English Language Unabridged,
1986].

domain:  (1) The set of possible data values of an attribute
(ANSI X3.172-1990).  (2) The set of permissible data values from
which actual values are taken for a particular attribute or
specific data element (ANSI X3.172-1990.  (3) In a relational
database, all of the permissible tuples for a given relation
(ANSI X3.172-1990). See data value domain.

name:  (1) An identifier of an entity (ANSI X3.172-1990).  (2) In
conceptual schema language, a simple linguistic object that is
used to identify an entity (ANSI X3.172-1990).  (3) A descriptive
designation of an entity or object, usually in a natural
language, by which the object is known in real life. 

relationship:  A special type of entity that is used to indicate
a dependency, an association, or a link that may be inherent
between two entities or among attributes of the same entity, and
that is represented or recorded in a database.  Synonymous with
association (ANSI X3.172-1990).  See data relationship.

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   Summary of Data Definition Rules and Guidelines

A listing of the rules and guidelines without explanations is
provided in this clause for convenience of the user.  The intent
is to facilitate ease of use of this document once an understand-

ing of the rules and guidelines is achieved.   Clause 5 describes
each rule and guideline with an explanation and examples to
ensure their exact meaning is understood.

4.1  Rules

A data definition shall:

    a) be unique (within any data dictionary in which it
    appears)

    b) be stated in the singular

    c) state what the concept is, rather than what it is not

    d) be stated as a descriptive phrase or sentence(s)

    e) contain only commonly understood abbreviations

    f) be expressed without embedding definitions of other data
    elements or underlying concepts 

4.2  Guidelines

A data definition should:

    a) state the essential meaning of the concept 

    b) be precise and unambiguous

    c) be concise 

    d) be able to stand alone

    e) be expressed without embedding rationale, functional
    usage, domain information, or procedural information

    f) avoid circular reasoning

    g) use the same terminology and consistent logical structure
    for related definitions


5   Requirements

5.1 Premise

Data elements exist and are used for specific purposes. 
Differences in use will require different operational
manifestations of some rules and guidelines.  For example,
different levels of specificity for data element  definitions are
generally required in different contexts.  Guideline 5.3.a)
below, provides an example of this need for varying levels of
specificity for different definitions.  The implementation of
Guideline a), "state the essential meaning of the concept" is
highly context dependent.  The primary characteristics deemed
necessary to convey the essential meaning of a particular
definition will vary according to the use of the data element  in
a particular environment.  Primary and essential characteristics
for defining concepts such as "airport" in the commercial air
transportation industry might be specific, where a more general
definition may be adequate in a different context.  For a
discussion of relationships between concepts in different
contexts and how characteristics are used to differentiate
concepts, see ISO 704, Clause 3.

5.2  Rules

To facilitate understanding of the rules for construction of
well-formed data element  definitions, explanations and examples
are provided below.  Each rule is followed by a short explanation
of its meaning.  Examples are given to support the explanations. 
In all cases, a good example is provided to exemplify the
explanation.  When deemed beneficial, a poor, but commonly used
example is given to show how a definition should NOT be
constructed.  To further explain the differences between the good
and poor examples, most examples are followed by a statement of
rationale behind them.

A data definition shall:

    a)  be unique (within any data dictionary in which it
    appears)

       EXPLANATION - Each definition shall be distinguishable
       from every other definition (within the dictionary) or
       the specificity of the concept is lost.  One    or several
       characteristics expressed in the definition must dif-
       
       ferentiate the concept to be defined from other concepts.

       EXAMPLE -

          1) good definitions:

          "Goods Receipt Date" - Date on which goods are received
          by a given party.

          "Goods Dispatch Date" - Date on which goods are
          dispatched by a given party.

          2) poor definitions:

          "Goods Receipt Date" - Date on which goods are
          delivered.

          "Goods Dispatch Date" - Date on which goods are
          delivered.

       REASON - The definition "Date on which the goods are
       delivered" cannot be used for both data elements "goods
       receipt date" and  "goods dispatch date."  Instead, each
       definition must be different.
    
    b) be stated in the singular

       EXPLANATION - The concept expressed by the data
       definition shall be expressed    in the singular. 
       (Exceptions are made if the concept itself is plural.)

       EXAMPLE - "Article Number"

          1) good definition: Reference number identifying an
          article.

          2) poor definition: Reference number identifying
          articles.
       
    c) state what the concept is, rather than what it is not

       EXPLANATION - When constructing definitions, the concept
          cannot be defined exclusively by stating what the
          concept is not.  

       EXAMPLE - "Freight Cost"

          1)  good definition:  Costs incurred by a shipper in
          moving goods, by whatever means, from one place to
          another under the terms of a contract of carriage.

          2)  poor definition:  Costs which are not related to
          packing, documentation, loading, unloading, and
          insurance.

    d) be stated as a descriptive phrase or sentence(s) (in most
    languages)

       EXPLANATION - A phrase is necessary (in most languages)
       to form a precise definition that includes the essential
       characteristics of the concept.  Simply stating one or
       more synonym(s) is insufficient.  Simply restating the
       words of the name in a different order is insufficient. 
       If more than a descriptive phrase is needed, use
       complete, grammatically correct sentences.


       EXAMPLE 1 - "Agent Name"

          1) good definition:  Name of party authorized to act on
          behalf of another party.

          2) poor definition:  Representative.

       EXAMPLE 2 - "Nature of Transaction"

          1) good definition:  Indication of the type of contract
          under which goods are supplied.

          2) poor definition:  Transaction type.
       
       REASON 'Representative' and 'Transaction type' are
       near-synonyms of the names, which is not adequate for a
       definition.

       e) contain only commonly understood abbreviations

       EXPLANATION - Understanding the meaning of an
       abbreviation, including acronyms and initialisms, is
       usually confined to a certain environment. In other            
       environments the same abbreviation can cause
       misinterpretation or confusion. Therefore, to avoid
       ambiguity, full words, not abbreviations, shall be used
       in the definition.  

          Exceptions to this rule may be made if an abbreviation
          is commonly understood such as 'i.e.' and 'e.g.'or if
          an abbreviation is more readily understood than thefull
          form of a complex term and has been adopted as a term
          in its own right such as 'radar' standing for 'radio
          detecting and ranging'.  

          All acronyms must be expanded on the first occurrence.

       EXAMPLE 1 - "Tide Height"

          1) good definition:  The vertical distance from mean
          sea level (MSL) to a specific tide level.

          2) poor definition:  The vertical distance from MSL to
          a specific tide level.

       REASON- The poor definition is unclear because the
       acronym, MSL, is not   commonly understood and some users
       may need to refer to other sources to determine what it
       represents.  Without the full word, finding the term in a
       glossary may be difficult or impossible.


       EXAMPLE 2 - "Unit of Density Measurement"

          1) good definition:  The unit employed in measuring the
          concentration of matter in terms of mass per unit
          (m.p.u.) volume (e.g., pound per cubic foot; kilogram
          per cubic meter).

          2) poor definition:  The unit employed in measuring the
          concentration of matter in terms of m.p.u. volume
          (e.g., pound per cubic foot; kilogram per cubic             
          meter).
          
       REASON - M.p.u. us not a common abbreviation and its
       meaning may not be understood by some users.  The
       abbreviation should be expanded to full words.
    
    f) be expressed without embedding definitions of other data
    elements or underlying concepts

       EXPLANATION - The definition of a second data element or
       related concept should not appear in the definition
       proper of the primary data element .  If the second
       definition is necessary, it may be attached by a note at
       the end of the primary definition's main text or as a
       separate entry in the dictionary.  Related      
       definitions can be accessed through relational attributes
       (e.g., cross-reference).  

       EXAMPLE 1- "Sample Type Code"

          1) good definition:  A code identifying the kind of
          sample collected.  
    
          2) poor definition:  A code identifying the kind of
          sample collected.  A sample is a small specimen taken
          for testing.  It can be either an actual sample for
          testing, or a quality control surrogate sample.  A
          quality control sample is a surrogate sample taken to
          verify results of actual samples.

       REASON - The poor definition contains two extraneous
       definitions embedded in it.  They are definitions of
       'sample' and of 'quality control'.

       EXAMPLE 2 - "Documentary Credit Number"

          1) good definition:  Reference number assigned by
          issuing bank to a documentary credit.

          2) poor definition:  Reference number assigned by
          issuing bank to a documentary credit.  A documentary
          credit is a document in which a bank states that it has
          issued a documentary credit under which the beneficiary
          is to obtain payment, acceptance, or negotiation on
          compliance with certain terms and conditions and
          against presentation of stipulated documents and such
          drafts as may be specified.

5.3  Guidelines (Guiding Principles)

A data definition should:

    a) state the essential meaning of the concept 

       EXPLANATION -  All primary characteristics of the concept
       represented should     appear in the definition at the
       relevant level of specificity for the context. The   
       inclusion of non essential characteristics should be
       avoided. The level of detail     necessary is dependent
       upon the needs of the system user and environment.

       EXAMPLE 1 - "Name of Celestial Body"

          1) good definition (for the intended context, 'space
          exploration'): Name of any planet, satellite, asteroid,
          captured comet, meteor swarm, or other natural physical
          body including the sun, held by the gravitational
          system of the sun and revolving around it.

          2) poor definition (for the intended context): Name of
          any planet or physical body in the universe.

       REASON - In this context (space exploration), it is
       necessary to specify what may be considered a 'celestial
       body'.  The poor definition is too vague.

       EXAMPLE 2 -   "Invoice Amount"

          1) good definition:  Total sum charged in respect to an
          invoice. 

          2) poor definition:  The total sum of all chargeable
          items mentioned on an invoice, taking into account
          deductions on one hand, such as allowances and              
          discounts, and additions on the other hand, such as
          charges for insurance, transport, handling, etc.

    b) be precise and unambiguous

       EXPLANATION - The exact meaning and interpretation of the
       defined concept   should be apparent from the definition. 
       A definition should be clear enough to     allow only one
       possible interpretation.

               EXAMPLE - "Shipment Receipt Date"

          1) good definition: Date on which a shipment is
          registered as having been received by the receiving
          party.

          2) poor definition: Date on which a specific shipment
          is delivered.

       REASON - The poor definition does not specify what
       determines a 'delivery'.  'Delivery' could be understood
       as either the act of unloading a product at the           
       intended destination or the point at which the intended
       customer actually obtains the product.  It is possible
       that the intended customer never receives the product
       that has been unloaded at his site or the customer may
       receive the product days after it was unloaded at the
       site.

    c) be concise 

       EXPLANATION - The definition should be brief and
       comprehensive.  Extraneous qualifying phrases such as
       "for the purpose of this data dictionary," "terms to      be
       described," shall be avoided.

       EXAMPLE - "Character Set Name"

          1) good definition:  The name given to the set of
          phonetic or ideographic symbols in which data is
          encoded.

          2) poor definition:   The name given to the set of
          phonetic or ideographic symbols in which data is
          encoded, for the purpose of this data dictionary, or,
          as used elsewhere, the capability of systems hardware
          and software to process data encoded in one or more
          scripts.

    d) be able to stand alone

       EXPLANATION - The meaning of the concept should be appar-
       
       ent from the definition.  Additional explanations or
       references should not be necessary for understanding the
       meaning of the definition.

       EXAMPLE - "School Location City Name"  

          1) good definition: Name of the city where a school is
          situated.

          2) poor definition:  See "school site".

       REASON - The poor definition does not stand alone, it
       requires the aid of a second definition (school site) to
       understand the meaning of the first.

    e) be expressed without embedding rationale, functional
    usage, domain information, or procedural information

       EXPLANATION - Although they are often necessary, such
       statements do not      belong in the definition proper
       because they contain information extraneous to  the
       purpose of the definition.  If deemed useful, such
       expressions may be     placed in other data element
       attributes (ISO/IEC 11179, Part 3). 

          1) The rationale for a given definition should not be
          included as part of the definition (e.g. if a data
          element  uses miles instead of kilometers, the reason
          should not be indicated in the definition).

          2) Functional usage such as: "this data element  should
          not be used for ..." should not be included in the
          definition proper.  

          3) Remarks about procedural aspects (e.g., this data
          element  is used in conjunction with data element "xxx"
          should not appear in the definition.  

       EXAMPLE - "Field Label"

          1) good definition: Identification of a field in an
          index, thesaurus, query, database, etc.

          2) poor definition:  Identification of a field in an
          index, thesaurus, query, database, etc.,  which is
          provided for units of information such as abstracts,
          columns within tables.

       REASON - The poor definition contains remarks about
       functional usage. This      information starting with
       "which is provided for..." must be excluded from the
          definition and placed in another attribute, if it is
       necessary information.

    f) avoid circular reasoning 

       EXPLANATION -  Two definitions shall not be defined in
       terms of each other.  A     definition should not use
       another concept's definition as its definition.  This
          results in a situation where a concept is defined with
       the aid of another concept  that is, in turn, defined
       with the aid of the given concept.  
    
       EXAMPLE - "Employee ID Number" - Number assigned by an
       employer to identify an individual employee.  "Employee-
       Person" corresponding to the employee ID number.

       REASON - Each definition refers to the other for its
       meaning.  The meaning is not given in either definition.

    g) use the same terminology and consistent logical structure
    for related definitions

       EXPLANATION - A common terminology and syntax should be 
          used for similar or associated definitions.

       EXAMPLE - The example for rule 5.2.a) above also
       illustrates this idea.  Both     definitions pertain to
       related concepts and therefore have the same logical
       structure and similar terminology.
    
          1)  "Goods Receipt Date" - Date on which goods were
          received by a given party.

          2)  "Goods Dispatch Date" - Date on which goods were
          dispatched by a given party.


________________________________________________________

Annex (informative)
________________________________________________________

Bibliographic references

TRADE/WP.4/R.765/Add. 1, United Nations Economic and Social
Council, 30 July 1991.