Docstoc

DATA NAMING PROCEDURES FOR THE LC2IEDM DATA MODEL

Document Sample
DATA NAMING PROCEDURES FOR THE LC2IEDM DATA MODEL Powered By Docstoc
					                        NATO UNCLASSIFIED
                Releasable for Internet transmission



               ATCCIS WORKING PAPER 3-1

                            Edition 5.0

DATA NAMING PROCEDURES FOR
  THE LC2IEDM DATA MODEL




                      ATCCIS Baseline 2.0
                        18 March 2002


ARMY TACTICAL COMMAND AND CONTROL INFORMATION SYSTEM
                  WORKING GROUP
                        SHAPE, BELGIUM



       At the direction of the ATCCIS nations, the information
       contained in this document may be made freely
       available, on request, to any person, business or
       government organisation irrespective of national
       membership of NATO.




                      NATO UNCLASSIFIED
                Releasable for Internet transmission
WP 3-1, Edition 5.0              NATO UNCLASSIFIED                                18 March 2002
                         Releasable for Internet transmission


                                PROPRIETARY RIGHTS
The proprietary rights to the Data Naming Procedures for the LC2IEDM Data Model
specifications contained in this Working Paper are reserved to those nations, Belgium,
Canada, Czech Republic, Denmark, France, Germany, Hungary, Italy, Netherlands,
Norway, Poland, Portugal, Spain, Turkey, United Kingdom and United States, who, acting
collectively, comprised the ATCCIS project on 15 April 2002.
These nations have indicated that the ATCCIS specifications for Data Naming Procedures
for the LC2IEDM Data Model contained in this Working Paper may be made freely
available to any person, business, organisation or national government on request to see
them. Further these specifications may be used in any information system, application or
specification at the user’s risk and without cost or specific authority, but no commercial,
financial or proprietary advantage may be taken from the use of information contained in
or derived from the contents of this Working Paper.
        NATO and member Governments assume no responsibility for possible
infringements of any inventions, trademarks, copyrights, etc., embodied in this Working
Paper. It is the sole responsibility of anyone using the information to acquire the
necessary rights.




                                           ii
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
   WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                             18 March 2002
                               Releasable for Internet transmission

                                       Record of Changes
            Edition            Date                                    Comments
   Edition 1.0           26 Nov 1993    Incorporate review comments from ATCCIS meeting PWG III-12 and
                                        submitted to be placed under ATCCIS Configuration Control.
   Edition 2.0           2 June 1995    Changes from ATCCIS meeting PWG 21 incorporated.
   Edition 3.0           31 Mar 2000    At ATCCIS meeting AWG IV-16, maximum length of entity names changed
                                        from 50 to 80 characters, and maximum length of attribute names changed
                                        from 80 to 160 characters. Additional examples for role-naming of attributes
                                        plus minor editorial corrections.
   Edition 5.0           18 Mar 2002    Document for ATCCIS 2000 End of Phase V.




   Configuration Control Authentication:


                      _____________________________________________
                      Maj R. de Solis ATCCIS Configuration Control Manager.

Contributing Nations/Agencies: AFNORTH, BE, CA, CZ, DA, FR, GE, HU, IT, NL, NO,
PL, PO, SHAPE, SP, TU, UK, US.


                                                iii
                                     NATO UNCLASSIFIED
                               Releasable for Internet transmission
WP 3-1, Edition 5.0               NATO UNCLASSIFIED                                 18 March 2002
                          Releasable for Internet transmission

                                       PREFACE
Introduction
        NATO operations require deployed forces to form part of combined and joint
coalition formations. Earlier operations focused on general war requirements. Recently
NATO forces are increasingly employed in Crisis Response Operations. Both such
operations require all participating national units to operate in cooperation with each other.
To operate effectively force commanders require a common view of the operational area
that is both timely and accurate, and supporting command and control (C2) systems need
to pass information within and across national and language boundaries. Moreover, C2
information must be provided to the strategic levels of command including national
organisations. Additionally, NATO forces must interact with non-NATO nations, non-
governmental bodies, and international and national aid organisations.
       The Military Committee approved MC 245 on 18 June 1976, and the North
Atlantic Council later noted this on 6 August 1976 (PO/76/87). MC 245 was a statement
of the military requirement for interoperability between automated data systems. This
visionary statement remains valid today. It led to the start of the ATCCIS programme in
1980.

Army Tactical Command and Control Information System (ATCCIS)
        The objective was (and still remains) to see if interoperability can be obtained at
reduced cost and developed according to technical standards agreed by Nations and
prescribed by NATO. The aim given to the programme was to identify the minimum set
of specifications, to be included within C2 systems, to allow interoperability between
national C2 systems. The programme has gone through the stages of: operational analysis,
technical concepts, proof of concept, transition to operational use, demonstration, and
maturing of the specification. The ATCCIS programme is not a formal NATO
programme. Rather it is a voluntary and independent activity by the participating nations
and is sponsored by SHAPE. The nations and HQs that are active in the ATCCIS
programme are: Belgium, Canada, Czech Republic, Denmark, France, Germany, Hungary,
Italy, Netherlands, Norway, Poland, Portugal, Spain, Turkey, United Kingdom, United
States, Regional Headquarters Allied Forces North Europe (RHQ AFNORTH) and
Supreme Headquarters Allied Powers Europe (SHAPE).
        The ATCCIS specification is a managed interface between C2 information
systems. When incorporated into a system it enables interoperability of information
between any other system that also incorporates the specification. Battlespace data is
transferred as information. The meaning and context of the information is preserved
across national and system boundaries precisely and without any ambiguity.
        The information exchange requirements, upon which ATCCIS is founded,
encompass the spectrum of Joint and Combined Land Operations. Thus ATCCIS meets
the requirements of the Land Component Commander of Allied Joint and Combined
Operations (including Article 5 and Crisis Response Operations). Systems may be wholly
different from each other and need not necessarily conform to any hardware or software
                                            iv
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 3-1, Edition 5.0               NATO UNCLASSIFIED                              18 March 2002
                          Releasable for Internet transmission
standard. Typically systems will be acquired through national or NATO acquisition
programmes and their architecture will conform to the national or NATO policy prevailing
at the time.
       In a community of ATCCIS-enabled C2 systems nations, command levels and
organisations can share:
      •   Situational awareness
      •   Orders, plans and intentions
      •   Capabilities and status of friendly and enemy forces.

Concept
        The ATCCIS specifications consist of two main components: a data model and a
replication mechanism. The Land C2 Information Exchange Data Model, LC2IEDM, is
the fundamental product. It is a product of the analysis of a wide spectrum of allied
information exchange requirements by 16 nations. It models the information that allied
land component commanders need to exchange (both vertically and horizontally). It
serves as the common interface specification for the exchange of essential battlespace
information. The function, implementation and the display of the host C2 application is
not the concern of ATCCIS. System developers incorporate the ATCCIS specification
and include a single interface to it. Thereafter no further interfaces are required to
interoperate with any other ATCCIS enabled system. The LC2IEDM is in its 5th
generation (version 5). The previous version, LC2IEDM v2, is the core of the NATO
Reference Model and is also a view model of NATO Corporate Data Model (STANAG
5523 / AdatP-32). The LC2IEDM v5 is offered to the NATO Data Administration Group
as a revision to the view model.
        The ATCCIS Replication Mechanism, the ARM, is complementary to the
LC2IEDM data model. When a C2 application changes the state of information that it
holds, and which is recognised by the ATCCIS specification, this information is
automatically replicated to all other co-operating systems that have agreed to exchange
this information. The meaning and context of the information is preserved and requires no
additional processing on receipt to make it useful. System managers are able to decide to
whom information flows, when and over what communications medium. It should be
noted that communication protocols and communication systems are not part of ATCCIS,
since the transfer facility employs agreed international standards. Currently, X.400, X.25,
and TCP/IP are included within the specification.




                                            v
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 3-1, Edition 5.0                    NATO UNCLASSIFIED                                            18 March 2002
                               Releasable for Internet transmission
     The ATCCIS specifications enable interoperability at Degree 31 and functions at
NATO Level 5 of System Interconnection2.

ATCCIS Programme
        The ATCCIS work has been conducted in programmed “Phases,” each with a
specific aim:
       •   Phase I (1980-1983) was an initial “Feasibility Study” into the ATCCIS concept.
       •   Phase II (1985-1990) identified the military and technical concepts required to
           achieve C2 interoperability by the automatic exchange of data.
       •   Phase III (1992-1997) was the “proof of concept” phase. Phase III concluded
           with a successful demonstration of multinational C2 interoperability between
           national prototypes for ATCCIS-compliant systems.         Interoperability by
           controlled, automatic data exchange, free of the need for common hardware,
           software, operating system, or database management system (DBMS) was
           demonstrated.
       •   Phase IV (1997-1999) concentrated on the refinement of the specifications and
           transition to operational use. CA, DA, FR, IT, GE, NL, NO, PO, SP, UK, and
           US were participants in the supporting programme of work. Phase IV included a
           Command Post Exercise involving nine national ATCCIS-compliant systems.
           Results from the Command Post Exercise concluded that ATCCIS was a
           workable solution for C2 interoperability that was achievable using the ATCCIS
           specifications.
       •   Phase V (2000-2002), known as “ATCCIS 2000,” had the aim of completing and
           maturing the ATCCIS specifications, suitable for building fieldable systems. The
           programme concentrated on extending the ATCCIS specifications to support
           “combined joint task forces” and “crisis response operations.” Further, the work
           included developing the necessary procedures to adopt and maintain all ATCCIS
           components as NATO standards.




1
     The NATO Policy for C3 Interoperability [NC3B Sub-Committee AC/322 SC/2-WP/72 (Revised)
Version 4.3]: “Seamless sharing of data that involves the automated sharing of data amongst systems based
on a common exchange model.”
2        STANAG 5048 - The Minimum Scale of Connectivity for Communications and Information
Systems for NATO Land Forces (Edition 5. Promulgated 16 February 2000 by NC3B Sub-Committee
AC/322 SC/1). “Two systems which are open to each other, and which conform to minimum standards for
information definition and transfer such that there are no fixed constraints on the extent of access by users of
one system to the other, but dynamic constraints are applied to each system, in accordance with the current
operational situation, such that only a user-defined subset of the total information base of one system is
available to the other.”
                                                    vi
                                     NATO UNCLASSIFIED
                               Releasable for Internet transmission
WP 3-1, Edition 5.0              NATO UNCLASSIFIED                             18 March 2002
                         Releasable for Internet transmission

Future
       The ATCCIS programme merged with the Multilateral Interoperability Programme
(MIP) in early 2002. The ATCCIS ethos was passed to the enlarged MIP and MIP has
taken the responsibility of keeping and further developing the ATCCIS specifications.
The nations and HQs that are active in the enlarged MIP programme are: Australia,
Belgium, Canada, Czech Republic, Denmark, France, Germany, Italy, Netherlands,
Norway, Poland, Portugal, SHAPE, Spain, Turkey, United Kingdom, and United States.
In addition Austria, Hungary, Bulgaria and RHQ AFNORTH are expected to join; and
Switzerland, Finland, Lithuania, Sweden, NATO Consultation, Command, and Control
Agency (NC3A), NATO HQ Consultation, Command, and Control (C3) Staff and NATO
Data Administration Organisation Staff have expressed interest.
       These nations wish to achieve international interoperability of Command and
Control Information Systems (C2IS) at all levels from corps to battalion, or lowest
appropriate level, in order to support multinational (including NATO), combined and joint
operations and the advancement of digitization in the international arena. The enlarged
MIP will build, in an evolutionary way, on the baseline of interoperability already
provided by the MIP and ATCCIS products.




                                         vii
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 3-1, Edition 5.0                           NATO UNCLASSIFIED                                                                     18 March 2002
                                      Releasable for Internet transmission




                                                                CONTENTS

    1. INTRODUCTION .............................................................................................................. 1
         1.1      Purpose..................................................................................................................... 1
         1.2      Scope ........................................................................................................................ 1
         1.3      Structure of the Paper............................................................................................... 1
    2. IDEF1X MODELLING TECHNIQUE .............................................................................. 3
         2.1      IDEF1X Language ................................................................................................... 3
                  2.1.1        Background ...................................................................................... 3
                  2.1.2        Fully Attributed Data Model ............................................................ 3
                  2.1.3        Definitions........................................................................................ 3
                  2.1.4        Generalisation Hierarchies (Entity Subtypes) .................................. 3
                  2.1.5        IDEF1X Naming Guidelines ............................................................ 4
                  2.1.6        Role Names ...................................................................................... 5
                  2.1.7        IDEF1X Diagramming Conventions................................................ 5
         2.2      Application of IDEF1X within ATCCIS.................................................................. 5
                  2.2.1        Data Dictionary Support................................................................... 5
                  2.2.2        Management Procedures .................................................................. 6
         2.3      The ERwin/ERX Database Design Tool .................................................................. 6
                  2.3.1        General Facilities.............................................................................. 6
                  2.3.2        Support for Logical and Physical Data Modelling........................... 6
                  2.3.3        Support for Generation of Database Schemata ................................ 7
    3. IMPACT OF INTERNATIONAL STANDARDS WORK ON NAMING
       PROCEDURES .................................................................................................................. 9
         3.1      Introduction .............................................................................................................. 9
         3.2      Data Naming Procedures.......................................................................................... 9
                  3.2.1        ATCCIS Working Paper 7L............................................................. 9
                  3.2.2        Naming Proposals under the United States DoD Data
                               Administration Initiative .................................................................. 9
                  3.2.3        Naming Standards under the United Kingdom MoD Data
                               Administration Initiative .................................................................. 9
                  3.2.4        Relevant Work by ISO on Naming Procedures ............................. 10
                  3.2.5        ISO Data Management Standards .................................................. 10
                  3.2.6        Relevant Work by NATO on Naming Procedures......................... 11
         3.3      Conclusions ............................................................................................................ 11
                  3.3.1        International Standard .................................................................... 11
    4. THE ATCCIS DATA MODELLING NAMING CONVENTIONS................................ 13
         4.1      Introduction ............................................................................................................ 13
                  4.1.1        Purpose ........................................................................................... 13

                                                                 viii
                                            NATO UNCLASSIFIED
                                      Releasable for Internet transmission
WP 3-1, Edition 5.0                           NATO UNCLASSIFIED                                                                   18 March 2002
                                      Releasable for Internet transmission

                   4.1.2        Guiding Principles.......................................................................... 13
          4.2      Keywords Used to Construct the Syntax of a Name .............................................. 13
          4.3      Entity Names .......................................................................................................... 14
                   4.3.1        Syntax for an Entity Name (Independent and Dependent
                                Entities) .......................................................................................... 14
                   4.3.2        Syntax for a Category Entity (Entity Subtype) .............................. 14
                   4.3.3        Rules for Naming Entities .............................................................. 14
                   4.3.4        Additional Rules for Naming Categorisation Entities (Entity
                                Subtypes)........................................................................................ 15
                   4.3.5        Supporting Management Procedures ............................................. 16
          4.4      Attribute Names ..................................................................................................... 16
                   4.4.1        Syntax for an Attribute Name ........................................................ 16
                   4.4.2        Rules for Naming Attributes .......................................................... 17
                   4.4.3        Supporting Management Procedures ............................................. 18
          4.5      Relationship Names................................................................................................ 18
                   4.5.1        Syntax for Relationship Names...................................................... 18
                   4.5.2        Rules for Relationship Names........................................................ 19
                   4.5.3        Supporting Management Procedures ............................................. 19
          4.6      AIRD Implementation Restrictions........................................................................ 19
     5. EXAMPLE OF APPLICATION ...................................................................................... 22
          5.1      Introduction ............................................................................................................ 22
          5.2      Example Entity Naming ......................................................................................... 22
          5.3      Examples of Entity Naming in a Generalisation Hierarchy ................................... 23
          5.4      Examples of Attribute Naming .............................................................................. 24
          5.5      Example of Relationship Naming .......................................................................... 26
     6. CONCLUSIONS .............................................................................................................. 28
          6.1      General Approach .................................................................................................. 28
          6.2      Other Naming Conventions.................................................................................... 28
          6.3      Class Words ........................................................................................................... 28
          6.4      Prime Words........................................................................................................... 28
          6.5      Generic Terms ........................................................................................................ 28
          6.6      Modifiers ................................................................................................................ 28
          6.7      ATCCIS Information Resource Dictionary............................................................ 28


                                                                Annexes
A.         List of Reserved Class Words..................................................................... A-1
B.         List of References ....................................................................................... B-1
C.         Glossary                ............................................................................................ C-1
D.         Reference: Working Paper 7L

                                                                  ix
                                            NATO UNCLASSIFIED
                                      Releasable for Internet transmission
WP 3-1, Edition 5.0                     NATO UNCLASSIFIED                                                  18 March 2002
                                Releasable for Internet transmission




                                               LIST OF FIGURES
Figure 1.   Example of a Fully Attributed IDEF1X Model.................................................. 3
Figure 2.   Example of an IDEF1X Generalisation Hierarchy............................................. 4
Figure 3.   Example of Entity Naming ............................................................................... 22
Figure 4.   Example of Entity Naming within a Generalisation Hierarchy........................ 23
Figure 5.   Further example of Entity Naming in a Generalisation Hierarchy................... 24
Figure 6.   Example of Attribute Naming .......................................................................... 25
Figure 7.   Further Example of Attribute Naming.............................................................. 26
Figure 8.   Example of Relationship Naming..................................................................... 27



                                                LIST OF TABLES
Table 1. Selected RDBMS Product Naming Constraints .................................................. 7
Table 2. AIRD Implementation Restrictions on Name Lengths ...................................... 19




                                                       x
                                      NATO UNCLASSIFIED
                                Releasable for Internet transmission
WP 3-1, Edition 5.0              NATO UNCLASSIFIED                              18 March 2002
                         Releasable for Internet transmission


1.   INTRODUCTION

       1.1    Purpose
       The purpose of this paper is to describe the naming conventions that support the
ATCCIS Data Modelling work. The paper is intended to be utilised by those involved in
the ATCCIS Data Modelling exercise and assumes that the reader is familiar with the
concepts of ATCCIS, data modelling and IDEF1X in particular.

        1.2    Scope
        The naming conventions proposed in this paper are aimed at supporting the
requirements of the ATCCIS programme. They are based on the proposal already
formulated in ATCCIS Phase II and documented in Working Paper 7L [Ref. 1]. In this
paper, the fundamental principles of the Working Paper 7L proposal have been revised to
take account of the particular requirements of the current ATCCIS programme, and
experience gained within the nations of applying a structured naming convention since the
publication of Working Paper 7L. It is not the function or intention of ATCCIS to review
and rationalise the various naming proposals currently being proposed by various external
agencies throughout the nations.
       The ATCCIS naming conventions as specified in this paper apply to logical data
modelling only.

        1.3     Structure of the Paper
        The paper describes the syntax and rules of naming conventions that will support
the IDEF1X data modelling process. In Chapter 2 the constraints imposed by the adoption
of the IDEF1X data modelling technique and the automated ERwin tool are examined in
sufficient detail to illustrate the context in which the data naming procedures are to be
applied within ATCCIS; and to determine any constraints that may be imposed on those
procedures. Chapter 3 discusses the relevance of work in the naming standards arena. In
Chapter 4 the naming conventions are described in detail, in order that they may be
applied within the context of a fully attributed entity relationship IDEF1X data model. In
Chapter 5 the naming conventions are applied to a series of example data models.
Conclusions are presented in Chapter 6.




                                            1
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                         2
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                     18 March 2002
                            Releasable for Internet transmission


2.   IDEF1X MODELLING TECHNIQUE

        2.1      IDEF1X Language

        2.1.1 Background
        The principal concern of this paper is to propose naming procedures to support the
application of the IDEF1X technique within ATCCIS. This Chapter describes the
constraints on naming as described in Thomas Bruce’s textbook [Ref. 2] on IDEF1X. It
acts as an input to the formulation of the ATCCIS Data Naming conventions, which are
specified in detail in Chapter 4.

       2.1.2 Fully Attributed Data Model
       IDEF1X is a graphical language for describing data structures. The role of such a
graphical language is to facilitate a means of communication between the data modeller
and the subject area experts in developing and validating a data model. The final goal of
applying IDEF1X is a fully attributed entity relationship diagram. Such a diagram
comprises entities, attributes and relationships, each of which must be named. Figure 1
below illustrates graphically the names that must be assigned during the modelling
process.

                                            ENTITY 1

                                              attribute 1

                                              attribute 2
                                              attribute 3


                                                       relationship 1
                                        ENTITY 2

                                            attribute 1 (FK)
                                            attribute 4

                                            attribute 5
                                            attribute 6




                  Figure 1. Example of a Fully Attributed IDEF1X Model



        2.1.3 Definitions
        The application of the IDEF1X technique, described in Reference 2, for the design
of data models and databases; it gives the following definitions:
        a.    An entity is defined as “any distinguishable person, place, thing, event or concept
              about which information will be kept.”
        b.    An attribute is defined as “a property of an entity.”
        c.    A relationship is defined as “a constraining association between two entities.”

                                                   3
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0                NATO UNCLASSIFIED                                    18 March 2002
                           Releasable for Internet transmission

         2.1.4 Generalisation Hierarchies (Entity Subtypes)
         2.1.4.1 Within an IDEF1X model it is possible to construct a Generalisation
Hierarchy; this procedure is sometimes referred to as Entity Subtyping. A Generalisation
Hierarchy is a hierarchical group of entities that share common characteristics. To
illustrate this concept, consider several types of specialised organisations: CONVOY and
UNIT (shown in Figure 2). All of these will have several common attributes as well as
some attributes, which are unique to the particular type of organisation. The common
attributes are grouped together to form a generalisation entity (generic parent); in this case
ORGANISATION. The attributes that are unique to each particular type of organisation
are then grouped into category entities (often referred to as entity subtypes): CONVOY
and UNIT in our example.              Each category entity inherits the properties of
ORGANISATION. The category discriminator is an attribute that determines to which
category (entity subtype) a generic parent instance belongs; in the example the Category
Discriminator is organisation-category-code.



                                 ORGANISATION                           ENTITY
                                                                        SUPERTYPE




                                           organisation-category-code   CATEGORY
                                                                        DISCRIMINATOR




                                                                        ENTITY
                  CONVOY                    UNIT
                                                                        SUBTYPES




               Figure 2. Example of an IDEF1X Generalisation Hierarchy


        2.1.4.2 The naming procedures must include provisions for naming generalisation
entities (entity supertypes), category entities (entity subtypes) and category discriminators.
The naming rules proposed for entities cover both entity supertypes and subtypes. The
naming rules for attributes apply to category discriminators.

      2.1.5 IDEF1X Naming Guidelines
      2.1.5.1 The IDEF1X language [Ref. 2] includes the following guidance for the
naming of entities, relationships and attributes within the context of IDEF1X Data Model.
        a.   Entity and attribute names must be singular,
        b.   Entity names may be up to 80 characters long,
        c.   Attribute names may be up to 160 characters long,
        c.   Choose a name that will clearly communicate what the entity or attribute represents,

                                                   4
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                                        18 March 2002
                             Releasable for Internet transmission

              as well as distinguish it from the other entities and attributes with similar names,
        d.    Use a “verb phrase” to name a relationship,
        e.    Find meaningful names for associative entities (i.e., those entities used to resolve a
              many to many relationship).

       2.1.5.2 These useful guidelines should be incorporated into any proposed naming
standard, which is intended to support the use of IDEF1X to construct data models.

        2.1.6 Role Names
        When an attribute migrates to a dependent entity (such as a subtype, associative
entity, or child), it is sometimes necessary to specify a role name to provide context for its
use.
        a.    Such names should begin with the host entity name (e.g., the role name of the key
              attribute of the subtype POINT for LOCATION might be point-id).
        b.    They should conclude with the parent attribute name (e.g., the role name of a POINT
              migrating to POLYARC-AREA under the relationship “is-used-to-define/has-as-its-
              bearing-origin” might be polyarc-area-bearing-origin-point-id).

        c.    Class Words will be reserved and will not be used as a Prime Word.3 Use of a Class
              Word as a Modifier should be avoided


       2.1.7 IDEF1X Diagramming Conventions
       The convention used in ATCCIS, when applying the IDEF1X technique, is to
show entity names in upper case (e.g., UNIT) and attribute names in lower case with the
individual words in both cases joined by a hyphen (e.g. POLYARC-AREA, object-type-
nationality-code). The hyphen convention applies only to the logical data model; the
physical model uses underscores.

        2.2      Application of IDEF1X within ATCCIS

        2.2.1 Data Dictionary Support
        The information contained within the validated Data Models will need to be
captured in a data dictionary. The term Data Dictionary is used within this paper in the
context of an ISO Information Resource Dictionary (IRD). The definition of the
information to be stored in the ATCCIS Information Resource Dictionary (AIRD) is
defined in ATCCIS Working Paper 4-1 [Ref. 3]. This includes information relating to the
entities, attributes and relationships contained in the IDEF1X data model diagrams as well
as supporting information such as range of attribute values, entity and attribute
descriptions. Both the ERwin tool and the AIRD must be capable of supporting the
proposed naming convention.


3       A Prime Word is a noun representing a concept (entity) to which data objects belong. A Class
Word is used to specify the logical type of information. Details are specified in Chapter 4.

                                                    5
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                             18 March 2002
                             Releasable for Internet transmission

      2.2.2 Management Procedures
      2.2.2.1 The management procedures required to support and control this method of
working will mandate the use of the ATCCIS naming conventions.
         2.2.2.1 The use of the naming conventions is intended to be validated using the
facilities provided by the AIRD.

        2.3      The ERwin/ERX Database Design Tool

       2.3.1 General Facilities
       ERwin/ERX [Ref. 4] is an application, which provides the facility to draw and
manipulate IDEF1X data model diagrams. The application supports both the creation of a
data model and also the generation of a physical database schema (for a selected
proprietary RDBMS product) from that model.

        2.3.2 Support for Logical and Physical Data Modelling
        2.3.2.1 Display Options. The application provides the following display options
for the logical data model:
        a.    only the entities and relationships
        b.    entities, relationships and key attributes
        c.    fully attributed entity relationship model.

       These display options correspond with the stages of production of a fully attributed
data model. The application features a number of editors that allow the diagram to be
annotated and also provide the ability to record supporting information. The Entity and
Attribute Editors are used to name the entity, define whether it is an independent or
dependent entity and to define its primary key attributes, and non-key attributes.
        2.3.2.2 Restrictions on Names. The application places no restrictions on the names
that are assigned to the entities and attributes in the diagram. If the unique name option is
set, the application will prompt the user if an attempt is made to duplicate the name of an
entity or attribute. Foreign keys are automatically migrated from the independent to the
dependent entity upon construction of a relationship between the two.
       2.3.2.3 Entity and Attribute Definitions. Definitions for entities and attributes are
entered using the “Entity Definition” and “Attribute Definition” editors respectively. The
application does not mandate that every entity and attribute is to have a definition; it is
user defined. A report can be generated to check for non-existence of definitions.
        2.3.2.4 Changes to Attribute Names. The “Update Attribute Name” feature
contained in the “Attribute Definition Editor” enables an alteration to a key attribute name
to be cascaded throughout the diagram.




                                                    6
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0              NATO UNCLASSIFIED                              18 March 2002
                         Releasable for Internet transmission

         2.3.3 Support for Generation of Database Schemata
         2.3.3.1 Physical Schema Generation. The “SQL Physical Schema” option can be
used to derive a “first-cut” database schema from the logical model. This process involves
assigning table names to the entities defined in the logical model and field names to the
attributes. The user is prompted to select a target proprietary database. The choices
provided in the current release of the product include Oracle, Informix, Ingres, SQL
Server and Sybase. The selection of the product (version 3.52) determines the choice of
data types, maximum length of table names and data field names, together with
restrictions on the use of Null clauses.
       2.3.3.2 Constraints on Size of Names. The maximum sizes in characters of field
and table names supported by each selected product are shown in Table 1.
                 Table 1. Selected RDBMS Product Naming Constraints
    Database Product       Max. Table Length       Max. Field Length
       Informix 9.x                18                      18
        Ingres 6.4                32                       32
        Oracle 8.x                 30                      30
     SQL Server 7.x               132                     128
       Sybase 11.x                30                      30




        2.3.3.3 Generation of the Physical Schema from the Logical Design. Editors are
used to assign table names, field names, data types and field options to the entities and
attributes in the logical model. ERwin automatically uses the first “n” characters of the
entity name as the default table name and fills in each field name with the first “n”
characters of the associated attribute name; where “n” is the maximum Table or Field
length for the selected database products as shown in Table 1. When making these default
assignments, any embedded spaces and hyphens are transformed to underscores. This
process does not alter the entity or attribute names contained in the logical model.




                                               7
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                         8
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0               NATO UNCLASSIFIED                                  18 March 2002
                          Releasable for Internet transmission


3.   IMPACT OF INTERNATIONAL STANDARDS WORK ON NAMING
     PROCEDURES

        3.1    Introduction
        As ATCCIS is a standards based architecture it is important to establish whether
there are any relevant initiatives in the international standards arena, which will satisfy the
requirement for a naming convention to support the ATCCIS data modelling work
described in Chapter 2.

        3.2      Data Naming Procedures

       3.2.1 ATCCIS Working Paper 7L
       3.2.1.1 Background. ATCCIS Working Paper 7L (WP 7L) was published in June
1989 at a time of rapid development in the area of Data Management standards. It was
based on standards for a naming convention, which were at that time emerging from the
United States National Institute of Standards and Technology (NIST) [Ref. 5]. At the time
Working Paper 7L was written, it was believed that this NIST standard would be offered
to ISO for consideration as an International Standard.
        3.2.1.2 Submission to ISO. The NIST naming standard was subsequently offered
for consideration by ISO. However, ATCCIS has been unable to find any evidence that
this submission resulted in an ISO standard, or indeed is likely to within the near future.
        3.2.1.3 The Architectural Modifier. The naming convention proposal made within
WP 7L assumed that data elements (attributes) will be named within ATCCIS without the
benefit of the context provided by a fully attributed data model, generated using a
structured analysis technique such as IDEF1X. Within the original WP 7L proposal,
context is provided by the use of an architectural modifier.

        3.2.2   Naming Proposals under the United States DoD Data Administration
                Initiative
         The United States Department of Defense has issued a series of draft publications
that include proposals for naming data elements as part of its Data Administration
initiative [Ref. 6 & 7]. These guidelines state that data elements should be named
according to logical and not physical characteristics. They are based on WP 7L but have
been developed to support the particular requirements of the DoD Data Management
programme. This naming procedure concentrates on the process of naming standard data
elements, which can be considered as the attributes of an IDEF1X data model for
comparison purposes. It does not specifically address the naming of entities and
relationships within the context of an IDEF1X Data Model.

        3.2.3   Naming Standards under the United Kingdom MoD Data
                Administration Initiative
        3.2.3.1 The United Kingdom is currently developing a Data Management strategy
to be applied across the Ministry of Defence.

                                              9
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 3-1, Edition 5.0                NATO UNCLASSIFIED                             18 March 2002
                           Releasable for Internet transmission
        3.2.3.2 The draft strategy statement published in June 1992 stated that several
naming standards were investigated for their suitability to support the UK MoD-wide
requirement for a data naming standard [Ref. 8]. At that time the conclusion reached was
that the proposals contained within WP 7L were the most suited to provide the basis for
the definition of the MoD naming standard.
        3.2.3.3 Some Data Management Groups within the UK MoD also conducted some
exploratory work to apply the WP 7L naming scheme within their business areas [Refs. 9,
10 & 11]. As a result of this initiative the UK MoD formally agreed a Data Naming
Standard in July 1993 [Ref. 12]. Like ATCCIS this standard includes rules for naming
entities and relationships as well as attributes (data elements). The procedure is not the
same as the ATCCIS Data Naming Convention defined in this working paper, but the
fundamental principles are similar. The UK MoD Data Naming Standards have been
adopted for the UK Defence Command and Army Data Model (DCADM) [Ref. 13].

       3.2.4 Relevant Work by ISO on Naming Procedures
       3.2.4.1 The ISO guideline for structured naming conventions IS 11179 [Ref. 14]
provides general guidance for naming of “data elements”.
        3.2.4.2 The ATCCIS Naming Conventions as specified in this working paper are
fully conformant to the IS 11179 with respect to naming of both entities and attributes. As
IS 11179 has a wider scope than the ATCCIS Naming Conventions, is does not only focus
on entity-relationship models. Therefore it is using more general concepts in the
structured naming conventions (e.g. “object classes” instead of entities, and “properties“
instead of attributes). While IS 11179 is focussed on naming of data elements only, WP 3-
1 will also provide conventions for naming of relationships.

        3.2.5 ISO Data Management Standards
        At the May 1992 meeting of ISO/IEC JTC1 SC21, database standards in each of
the following four areas reached the status of International standards:
        a.   Reference Model of Data Management
        b.   Information Resource Dictionary System (IRDS)
        c.   Database Language (Revised 1992) SQL 92
        d.   Remote Database Access (RDA).

       It is important for ATCCIS to consider what constraints these standards will place
on any proposed naming convention.
       3.2.5.1 IRDS. Working Paper 7L established the principle that any proposed
naming standard must be consistent with IRDS. At the time WP 7L was published, the
IRDS dictionary standard was being developed in parallel by both ISO (JTC1 SC21/WG3)
and ANSI (ANSI X3H4) [Ref. 15]. The emerging ANSI IRDS structure included at that
time the following naming concepts:
        a.   Access Name (sometimes referred to as the “short name”).
        b.   Descriptive Name (sometimes referred to as the “long name”).

                                              10
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                   18 March 2002
                            Releasable for Internet transmission

        c.    Alternate Names (aliases).

        The concept of separate long and short names has not been incorporated into the
recently accepted International Standard. The International Standard allows names to be
of any length up to 128 characters. It is also possible to construct compound names.
        3.2.5.2 SQL-1992. SQL-92 restricts the number of characters that can be included
in the name of a Table, Column, or Constraint to a maximum of 128.
        3.2.5.3 Programming Language Standards. At the physical implementation level,
the various programming languages have varying restrictions on the length of a name. In
some languages these restrictions are quite severe.

       3.2.6 Relevant Work by NATO on Naming Procedures
       NATO is currently conducting data modelling activities under the lead of the
NATO Data Administration Group (NDAG). One task in the work schedule for the
development of the “NATO C3 Corporate Data Model” has been the specification of a
Naming Convention [Ref. 16]. The development of the present draft of the NATO Data
Naming Convention was partly influenced by previous versions of the ATCCIS Naming
Convention (WP 3-1 and WP 7L).

        3.3      Conclusions

       3.3.1 International Standard
       3.3.1.1 There is no accepted International Standard at present, or envisaged for
Naming Conventions that ATCCIS can utilise. Therefore ATCCIS Working Paper 7L still
represents the foundation on which to construct a naming convention to support the
ATCCIS Data Modelling work. The proposals within WP 7L should:
        a.    be consistent with the recently agreed International Standards on Data Modelling
        b.    specifically support the IDEF1X analysis approach to the ATCCIS data modelling
              work
        c.    take account of practical experience of applying derivatives of the WP 7L naming
              convention within the nations.

       3.3.1.2 The ISO standards for Data Management imposed a maximum length of
128 characters for Table and Field names. Most of the current generation of databases in
the commercial market impose much more severe restrictions on the length of Table and
Field names (see Table 1). Therefore, it will be necessary to maintain separate logical and
physical names. The naming convention proposed in this paper addresses logical naming.




                                                11
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        12
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0                    NATO UNCLASSIFIED                                 18 March 2002
                               Releasable for Internet transmission


4.   THE ATCCIS DATA MODELLING NAMING CONVENTIONS

        4.1      Introduction

       4.1.1 Purpose
       The naming conventions described in this Chapter only refer to the IDEF1X
portion of the Dictionary metamodel described in Working Paper 4-1 [Ref. 3]. The
purpose of a naming convention is to provide a structured method by which standard
names for data objects can be developed to support the construction of IDEF1X data
models. The ATCCIS naming convention assumes the use of the English language. The
procedures must cover the naming of the following IDEF1X conceptual objects:
        a.    entities (independent and dependant entities as well as entity subtypes)
        b.    attributes
        c.    relationships.


       4.1.2 Guiding Principles
       4.1.2.1 Readability. The naming conventions should provide names that are
completely comprehensible to the user. This means that even though a name conforms to
a convention and may suffer some awkwardness in word flow, it must be readable to the
user. The user must be able to derive the basic meaning of the data object by looking at
the name. This is particularly important within ATCCIS to assist validation of the
IDEF1X data models by subject matter experts.
       4.1.2.2 Brevity. Names should be as short as possible while still retaining meaning
and uniqueness within the ATCCIS data model. Conflicts between brevity and clarity
should always be resolved in favour of clarity.
      4.1.2.3 Syntax. Each name must be constructed according to the syntax of the
naming convention.
     4.1.2.4 Context. Data objects are named based on their context within the
ATCCIS Data Model and not according to any physical characteristics.

       4.2    Keywords Used to Construct the Syntax of a Name
       4.2.1 The syntax of the naming convention is defined using three different types
of keyword. These are defined below:
        a.    Prime Word (PW). A Prime Word is a noun, which is used to represent the data
              grouping (entity) to which the data object belongs.
        b.    Class Word (CW). A Class Word is used to specify the type of information
              contained in a set of data values.
        c.    Modifier (M). A Modifier is used to refine, describe or render a name unique if this
              cannot be achieved by a Class Word or Prime Word alone.




                                                 13
                                     NATO UNCLASSIFIED
                               Releasable for Internet transmission
WP 3-1, Edition 5.0                   NATO UNCLASSIFIED                                         18 March 2002
                              Releasable for Internet transmission
      4.2.2 In the subsequent specification of syntax, < > will be used to delimit
keywords, and [ ] will be used to denote the optionality of a component word.

        4.3      Entity Names

       4.3.1 Syntax for an Entity Name (Independent and Dependent Entities)
       4.3.1.1 A Prime Term, as defined below, will be used to name independent and
dependent entities. A Prime Term will consist of a Prime Word (PW) that may be further
modified to construct a name that is representative of the entity and its context within the
ATCCIS Data Model. The syntax of a Prime Term is:
                            Prime Term = <PW> [<M>] ... [<M>] 4

       4.3.1.2 The position of the Prime Word within the Prime Term was given careful
consideration by the ATCCIS team. It was recommended but not required that the Prime
Word should be the first keyword within the Prime Term for the following reasons:
        a.     Its position in the Prime Term is always known, providing ease of reference.
        b.     This approach is consistent with the way that the military traditionally classify
               objects by placing the major concept first.
         The disadvantage of this approach is that the resulting Prime Term is often not so
naturally readable in comparison with the alternative syntax in which the Prime Word is
the last keyword, in the Prime Term.5

       4.3.2 Syntax for a Category Entity (Entity Subtype)
       4.3.2.1 In the case of a Category Entity (Entity Subtype) the syntax is extended to
allow optional modifiers before the Prime Word. The syntax of the Category Entity Prime
Term is:
             Entity Subtype Prime Term = [<M>]...[<M>]<PW>[<M>]...[<M>] 6

       4.3.2.2 This syntax may only be used when the Prime Word is the same as that at
the Entity Supertype level.

        4.3.3    Rules for Naming Entities
        a.     The sequence of words within the Prime Term will conform to the syntax specified
               in Section 4.3.1. The Prime Word will always be the first word within the name.

4         Example: The Prime Term (i.e. the name) of the entity ACTION-OBJECTIVE consists of the
Prime Word ‘ACTION’ and the Modifier ‘OBJECTIVE’.
5         Experience in developing and evolving the LC2IEDM has shown that entity names strictly
conforming to the recommendation have been found impractical and several of the model’s entity names
violate this recommended convention. A way around this would be to declare the first word of every entity,
or every entity name as a prime word, but this would cast doubt on whether Prime Word remains a useful
concept. In many languages, modifiers precede the word being modified.
6         Example: The Prime Term (i.e. the name) of the category entity GOVERNMENT-
ORGANISATION-TYPE consists of the Modifier ‘GOVERNMENT’ and the Prime Term of the supertype
entity ‘ORGANISATION-TYPE’.

                                                    14
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                      18 March 2002
                            Releasable for Internet transmission
        b.    Prime Words can also be used as Modifiers within an Entity Name.
        c.    A Prime Word must be a noun or sequence of nouns. Where more than one word is
              required to accurately name an independent entity, the combination of these words
              may then be regarded as the Prime Word. For example, OBJECT-ITEM and
              OBJECT-TYPE may be regarded as instances of Prime Words.
        d.    A Prime Word must not be contained in the list of reserved Class Words.
        e.    Plurals of Prime Words or Modifiers are not permitted.
        f.    The Prime Word will often be the name of an independent entity within the Data
              Model. In some cases, the Prime Word may be the name of a subtype in a category
              hierarchy (e.g., ROUTE as a subtype of CONTROL-FEATURE; UNIT as a subtype
              of ORGANIZATION; FEATURE and ORGANISATION as subtypes of OBJECT-
              ITEM).
        g.    A Modifier is an adjective or noun that is used to further refine or describe a Prime
              Word in order to name an entity.
        h.    The use of abbreviations or acronyms shall be avoided.
        i.    Only Arabic alphabetic characters (A-Z) are permitted within a Prime Word or
              Modifier. Numbers are not permitted unless they form an integral part of a “Real
              World” entity name. For instance, “ADATP3-ELEMENT” is permitted, while
              names such as “TEST3” are not. Special characters are not permitted.
        j.    Each word of a Prime Term is separated by a hyphen (“-“).
        k.    Prepositions (at, by, from, in, to, of) are not permitted within a Prime Term.
        l.    Articles (a, an, the) are not permitted within a Prime Term.
        m.    Conjunctions (and, or, but) are not permitted within a Prime Term.
        n.    Verbs are not permitted within a Prime Term.
        o.    Gerunds (words ending in “ing”) are permitted to be used as Modifiers.
        p.    Sufficient modifiers will be used to adequately describe the concept.
        q.    The entity name should appear in capital letters on all IDEF1X diagrams.
        r.    In principle there is no limit on the length of the name provided that it is consistent
              with the specified syntax. However, see the implementation restrictions relating to
              the supporting AIRD Dictionary in Section 4.7.
        s.    Where the Entity Name contains more than one Prime Word (Prime Words being
              used as modifiers), the actual choice of Prime Word within the syntax should be
              chosen such that the concept being modelled is clearly described. In most instances,
              the Prime Word will describe the major concept represented by the Entity.
        t.    When naming non-subtype-children, where possible, the Entity Name of a child
              (other than a subtype) should contain the Prime Word (or entire Prime Term) of the
              entity name(s) of its parent(s). See Rule 4.3.4(c).

        4.3.4    Additional Rules for Naming Categorisation Entities (Entity Subtypes)
        a.    The sequence of words within the Prime Term will conform to the syntax specified
              in Section 4.3.2.




                                                 15
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                                        18 March 2002
                             Releasable for Internet transmission
        b.    The modifiers before the Prime Word are only to be used when it is agreed by the
              ATCCIS Data Modellers that the concept being modelled cannot be adequately
              named using the normal syntax for a Prime Term (Section 4.3.1).
        c.    It is not mandatory to migrate the Prime Word from the Generalisation Entity (Entity
              Supertype) to the related Category Entities (Entity Subtypes).
        d.    Rules (b) to (t), as specified in Section 4.3.3, apply.

        4.3.5 Supporting Management Procedures
        The following management procedures are required to support the naming of
entities and entity subtypes:
        a.    A list of Prime Words together with their definitions will be maintained by the
              ATCCIS Project within the AIRD.
        b.    A list of standard phrases7 will be maintained under configuration control within the
              AIRD.
        c.    A list of approved abbreviations for Class Words will be maintained within the
              AIRD.

        4.4      Attribute Names

       4.4.1 Syntax for an Attribute Name
       4.4.1.1 The attribute name will consist of two distinct component terms; the prime
term and the generic term, in which the Prime Term occurs first and the Generic Term is
juxtaposed at (i.e., added to) the end of the Prime Term.


                      Attribute Name = Prime Term + Generic Term 8


        4.4.1.2 To distinguish attribute names from entity names, attribute names are
written in lower-case characters with their words separated by hyphens.
        4.4.1.3 The Prime Term is the same as that defined for naming entities in Section
4.3. It will be the name of the parent entity of the attribute being named. A key attribute,
which is migrated within an IDEF1X Data Model, may be named in one of two ways
depending upon whether IDEF1X role naming is used. If role naming is not employed,
then the attribute must maintain the full-migrated name as it occurs in the parent:

                 Attribute Name = Name of Parent Entity + Generic Term


           4.4.1.4 Where IDEF1X role-naming is used, the attribute name shall be
constructed according to the following structure:

7       A standard phrase is a term being a combination of several words, which however is considered one
term because of its common use (e.g. “Ministry-of-Defence” or “Rule-of-Engagement”).
8       Example: The Attribute Name ‘PERSON-birth-date’ consists of the Prime Term ‘person’ and the
Generic Term ‘birth-date’.

                                                   16
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                                         18 March 2002
                             Releasable for Internet transmission


             Attribute Name = Name of Host Entity + Role-named Generic Term


        where the “role-named generic term” conforms to the rules for the construction of
a Generic Term. It is desired (but not mandatory) that the role-named generic term ends in
the identical generic term used by the attribute in the parent entity.
        4.4.1.5 Example: When location-id migrates from entity LOCATION to its sub-
entity POINT, the role-named attribute in the host entity POINT might be point-location-
id rather than simply point-id. Whether point-location-id or point-id is chosen as the role
name should be decided in favour of best semantic clarity.
       4.4.1.6 The Generic Term identifies the set of values that can be associated with
the Prime Term. The syntax of the Generic Term is:

                          Generic Term = [<M>]......[<M>] < CW> 9


        4.4.2     Rules for Naming Attributes
        a.     The Prime Term will be constructed according to the rules and syntax defined for
               naming entities specified in Section 4.3.
        b.     The Generic Term will be constructed according to the syntax defined above.
        c.     Class Words will be reserved; and will not be used as a Modifier or Prime Word.
               Use of Class Words as Prime Word modifiers should be avoided.
        d.     All Class Words used must be from the authorised ATCCIS Class Word vocabulary.
               The list of authorised Class Words will be maintained in the AIRD.
        e.     A Class Word must be a noun.
        f.     Plurals of Class Words or Modifiers are not permitted.
        g.     A Modifier is an adjective or noun that is used to further refine or describe the
               Generic Term.
        h.     Abbreviations or acronyms should not be used within the Generic Term. (See rule
               x).
        i.     Only Arabic alphabetic characters (a-z) are permitted within a Class Word or
               Modifier. Numbers and special characters are not permitted.
        j.     Each word of the attribute name is separated from the next by a hyphen (“-“).
        k.     Prepositions (at, by, from, in, of, to) are not permitted within an attribute name unless
               the attribute name is a recognised fixed term considered as one word e.g. “angle-of-
               attack”, “department-of-defense”, “method-of-control”, “unit-of-measure”.
        l.     Articles (a, an, the) are not permitted within an attribute name.
        m.     Conjunctions (and, or, but) are not permitted within an attribute name.
        n.     Verbs are not permitted within an attribute name.


9       Example: The Generic Term ‘birth-date’ consists of the Modifier ‘birth’ and the Class Word ‘date’.

                                                   17
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                    18 March 2002
                            Releasable for Internet transmission
        o.    Gerunds are permitted to be used as Modifiers.
        p.    Sufficient modifiers will be used to adequately describe the Generic Term and make
              it readable.
        q.    Each attribute name will contain at least one and only one Class Word (use of
              additional class words should be avoided).
        r.    Prime Words may be used as Modifiers within the Generic Term.
        s.    Plurals of Class Words or Modifiers are not permitted in the construction of the
              generic term.
        t.    A unit of measure suffix will not be applied within the Generic Term. Unit of
              measure should be defined within the definition of the attribute or its associated
              domain and not as part of its name.
        u.    The use of ATCCIS generic terms will be controlled to ensure consistency of
              approach to naming.
        v.    In principle there is no limit on the length of an attribute name providing that it is
              consistent with the specified syntax, but within the supporting AIRD a limit of 160
              characters is imposed (See Section 4.7).
        w.    Attribute names will be displayed on IDEF1X diagrams in lower case text.
        x.    Use of abbreviations is to assist in the formulation of shortened physical names.
              Special dispensation has been given for the demonstration data modelling to allow
              “id” to be used instead of “identifier”.

        4.4.3 Supporting Management Procedures
        The following management procedures are required to support the allocation of
attribute names:
        a.    A list of ATCCIS reserved Class Words and their definitions and approved
              abbreviations will be maintained in the AIRD.
        b.    A list of generic terms and their definitions used within the ATCCIS project will be
              maintained in the AIRD.


        4.5      Relationship Names

        4.5.1 Syntax for Relationship Names
        The syntax for describing relationships within an IDEF1X Data Model is:


                 <parent-child relationship> / <child-parent relationship>




                                                18
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0                   NATO UNCLASSIFIED                                          18 March 2002
                              Releasable for Internet transmission
        The IDEF1X diagram places the relationship in context with its parent and child
entities. A parent-child relationship identifies the relationship between the parent entity
and the child entity. The child-parent relationship identifies the relationship between the
child entity and the parent entity. The parent-child and child-parent relationships are
separated on an IDEF1X diagram and its supporting documentation by a slash (/)10. The
parent-child verb phrase is sometimes termed the “relationship verb phrase.” The child-
parent verb phrase is referred to as the “inverse verb phrase.”

       4.5.2 Rules for Relationship Names
       The following rules should be followed in constructing both the parent-child and
child-parent relationship names:
        a.    Both the parent-child and child-parent relationship will consist of a verb phrase.
        b.    The verb phrases must be meaningful so that they represent business rules that can be
              verified by the user community. For example, the use of words such as: “has,”
              “uses,” “relates to,” and “does” indicates a weak relationship, which should be
              rationalised within the ATCCIS Data Model.
        c.    Where a dependent entity is used purely to resolve a many-to-many relationship
              (termed an associative entity) the production of a <parent-child relationship>/<child-
              parent relationship> may not be meaningful. In this case a single verb phrase is
              assigned to each side of the associative entity; and the associative entity is read
              through. This concept is illustrated in Figure 6 (see Chapter 5) for the associative
              entities ACTION-TASK, RULE-OF-ENGAGEMENT and ACTION-TASK-RULE-
              OF-ENGAGEMENT.
        d.    The verb phrases will be expressed in lower case characters.
        e.    Hyphens will be used as the separator between words. Spaces are not permitted.
        f.    The maximum length of the “verb phrase” and “inverse verb phrase” including
              hyphens are both restricted to 60 characters.

        4.5.3 Supporting Management Procedures
        The parent-child relationship and child-parent relationship text will be maintained
in the AIRD.

        4.6     AIRD Implementation Restrictions
        In order to implement the AIRD it has been necessary to specify some maximum
lengths for the various components of the naming convention. These have been chosen so
as not to be restrictive to the application of the naming convention. The maximum lengths
are shown in Table 2.
              Table 2. AIRD Implementation Restrictions on Name Lengths
                           Component                     Maximum Length (Characters)
                           Class Word                               16
                           Prime Word                               80



10This may be changed in the future, as ERwin allows the user to store both the verb phrase and the inverse
verb phrase separately.

                                                    19
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 3-1, Edition 5.0                    NATO UNCLASSIFIED              18 March 2002
                               Releasable for Internet transmission

                          Attribute Name                     160
                           Generic Term                       80
                            Entity Name                      80
                         Verb Phrase Name                     60
                      Inverse Verb Phrase Name               60




                                                 20
                                     NATO UNCLASSIFIED
                               Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        21
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                                  18 March 2002
                             Releasable for Internet transmission


5.     EXAMPLE OF APPLICATION

       5.1     Introduction
       In this Chapter the naming conventions proposed in Chapter 4 have been applied to
some example Data Models. The Data Models shown in this Chapter have been
constructed purely to illustrate the use of the proposed naming convention.

       5.2      Example Entity Naming
       Figure 3 shows the application of the entity naming procedures. The application of
the syntax is shown against each name. The Prime Word list generated by this example is:
          ACTION
          CANDIDATE-TARGET-LIST
          OBJECT-ITEM
          OBJECT-TYPE
          REFERENCE
          REPORTING-DATA

                                           <PW>
                                                                                    <PW>
                                           ACTION                           CANDIDATE-TARGET-LIST
             <PW> <M>
            ACTION-EFFECT
                                                           <PW>
                                                         REFERENCE

                                                                       <PW><M>
                                                                     ACTION-TASK

                                                    <PW>
                       <M> <PW> <M>             REPORTING-DATA
               OBJECT-ITEM-ACTION-EFFECT




            <M> <PW> <M>
     OBJECT-TYPE-ACTION-EFFECT        <PW>
                                  OBJECT-ITEM
                                                                          <PW>        <M>   <M>
                                                                     REPORTING-DATA-RELATIVE-TIMING


              <PW>
          OBJECT-TYPE
                                                         <PW>        <M>   <M>
                                                    REPORTING-DATA-ABSOLUTE-TIMING

                                 <PW>
                             ORGANISATION




                             Figure 3. Example of Entity Naming



                                                    22
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0                       NATO UNCLASSIFIED                                                                   18 March 2002
                                  Releasable for Internet transmission

      5.3     Examples of Entity Naming in a Generalisation Hierarchy
      Figure 4 and Figure 5 show examples of naming entities and entity subtypes within
a Generalisation Hierarchy. These particular examples generate the following Prime
Words. Figure 4 shows the Prime Word: CAPABILITY and Modifiers: ENGINEERING,
FIRE, MISSION, MOBILITY and STORAGE.
        CAPABILITY
        OBJECT-ITEM
        FACILITY – BRIDGE, MASS-GRAVE, MINEFIELD
        FEATURE – CONTROL-FEATURE, GEOGRAPHIC-FEATURE, METEOROLOGIC-
           FEATURE
        MATERIEL
        ORGANISATION – CONVOY, UNIT
        PERSON

                                                          CAPABILITY
                                                           capability-id
                                                           capability-category-code
                                                           capability-subcategory-code
                                                           capability-day-night-code
                                                           capability-unit-of-measure-code


                                                                           capability-category-code

                        FIRE-CAPABILITY
                         fire-capability-id (FK)                                      STORAGE-CAPABILITY

                         ammunition-type-id (FK)                                       storage-capability-id (FK)
                                                                                       materiel-type-id (FK)
                      MISSION-CAPABILITY
                      mission-capability-id (FK)                                     MOBILITY-CAPABILITY
                      mission-capability-category-code                                mobility-capability-id (FK)
                      mission-capability-level-code                                   mobility-capability-category-code
                      mission-capability-qualifier-code                               mobility-capability-terrain-type-code



                                                   ENGINEERING-CAPABILITY
                                                   engineering-capability-id (FK)
                                                   engineering-capability-facility-height-dimension
                                                   engineering-capability-facility-length-dimension
                                                   engineering-capability-facility-width-dimension
                                                   facility-type-id (FK)




        Figure 4. Example of Entity Naming within a Generalisation Hierarchy




                                                                      23
                                        NATO UNCLASSIFIED
                                  Releasable for Internet transmission
WP 3-1, Edition 5.0                     NATO UNCLASSIFIED                                   18 March 2002
                                Releasable for Internet transmission

                                                         <PW>
                                                        OBJECT-ITEM




      <PW>                                                                                      <PW>
     FACILITY                                                                                   PERSON

                               <PW>                                       <PW>
                           FEATURE                                       ORGANISATION



                                                                <PW>
                                                              MATERIEL
                                            <M>   <PW>                                  <PW>
              <PW>
             BRIDGE                       CONTROL-FEATURE                                UNIT




                                            <M>   <PW>                                   <PW>
          <PW>
                                        GEOGRAPHIC-FEATURE
        MASS-GRAVE                                                                      CONVOY




        <PW>                               <M>   <PW>
       MINEFIELD
                                      METEOROLOGIC-FEATURE




      Figure 5. Further example of Entity Naming in a Generalisation Hierarchy

        5.4      Examples of Attribute Naming
            5.4.1 Figure 6 and Figure 7 show some examples of naming attributes
according to the procedures proposed in Chapter 4. It is interesting to note that on the
IDEF1X diagram it is not really necessary to repeat the prime term within the names of
non-key attributes as the diagram itself provides the context of the attribute in relation to
its parent entity.
          5.4.2       Figure 7 includes some examples of the use of standard phrases. The
examples are:
        a.      stock number
        b.      supply class
        c.      dummy indicator.




                                                     24
                                      NATO UNCLASSIFIED
                                Releasable for Internet transmission
WP 3-1, Edition 5.0                         NATO UNCLASSIFIED                                                    18 March 2002
                                    Releasable for Internet transmission

    OBJECT-ITEM                                                                                     ACTION
                                                        RULE-OF-ENGAGEMENT                          action-id
     object-item-id
                                                         rule-of-engagement-id
     object-item-category-code                                                                      action-category-code
     object-item-name                                    rule-of-engagement-name                    action-name
     object-item-alternate-identification-text           rule-of-engagement-description-text
                                                         owning-organisation-id (FK)

                                                                               is-a-constraint-on



                         object-item-category-code                 ACTION-TASK-RULE-OF-ENGAGEMENT
                                                                    action-task-id (FK)
                                                                    rule-of-engagement-id (FK)
                                           is-the-owner-of




                                                                          is-constrained-by               action-category-code
                ORGANISATION
                                                             ACTION-TASK
                  organisation-id (FK)
                                                             action-task-id (FK)
                  organisation-category-code
                                                             action-task-category-code
                  organisation-nickname-name
                                                             action-task-minimum-duration
                                                             action-task-estimated-duration
                                                             action-task-maximum-duration
                                                             action-task-planned-start-date
                                                             action-task-planned-start-time
                                                             action-task-start-precision-code
                                                             action-task-start-qualifier-code
                                                             action-task-planned-end-date
                                                             action-task-planned-end-time
                                                             action-task-end-precision-code
                                                             action-task-end-qualifier-code
                                                             action-task-priority-code
                                                             action-task-verb-phrase-code
                                                             action-task-detail-text
                                                             candidate-target-list-id (FK)




                                  Figure 6. Example of Attribute Naming




                                                                 25
                                          NATO UNCLASSIFIED
                                    Releasable for Internet transmission
WP 3-1, Edition 5.0                              NATO UNCLASSIFIED                                                                                 18 March 2002
                                         Releasable for Internet transmission

 OBJECT-TYPE                                                  ORGANISATION-TYPE-ESTABLISHMENT-ORGANISATION-TYPE-DETAIL
  object-type-id                                               established-organisation-type-id (FK)
  object-type-category-code                                    organisation-type-establishment-index (FK)
  object-type-dummy-indicator-code                             detail-organisation-type-id (FK)
  object-type-name                                             organisation-type-establishment-organisation-type-detail-quantity
  object-type-nationality-code                                 detail-organisation-type-establishment-index (FK)

        object-type-category-code                                                                     identifies-establishment-for-detail-organisation-in
                                         is-specified-as-part-of
                                                                             is-specified-through
                    ORGANISATION-TYPE
                     organisation-type-id (FK)                                          ORGANISATION-TYPE-ESTABLISHMENT
                     organisation-type-category-code                                     established-organisation-type-id (FK)
                     organisation-type-description-text       is-made-up-through         organisation-type-establishment-index
                                                                                         organisation-type-establishment-effective-date
         PERSON-TYPE                                                                     organisation-type-establishment-environment-condition-code
          person-type-id (FK)                                                            organisation-type-establishment-name
                                                                                         organisation-type-establishment-operational-mode-code
          person-type-category-code                    is-specified-as-part-of
          person-type-subcategory-code                                                           is-specified-through
          person-type-rank-code
                                                 ORGANISATION-TYPE-ESTABLISHMENT-PERSON-TYPE-DETAIL
                                                 established-organisation-type-id (FK)
                                                 organisation-type-establishment-index (FK)
   MATERIEL-TYPE                                 detail-person-type-id (FK)
    materiel-type-id (FK)                        organisation-type-establishment-person-type-detail-quantity
                                                                                                                                           is-specified-through
    materiel-type-category-code                                      ORGANISATION-TYPE-ESTABLISHMENT-MATERIEL-TYPE-DETAIL
    materiel-type-reportable-item-text
                                                                      established-organisation-type-id (FK)
    materiel-type-stock-number-text        is-specified-as-part-of    organisation-type-establishment-index (FK)
    materiel-type-supply-class-code
                                                                      organisation-type-establishment-materiel-type-detail-materiel-type-id (FK)
                                                                      organisation-type-establishment-materiel-type-detail-quantity
                                                                      organisation-type-establishment-detail-materiel-type-establishment-index (FK)

                                                                                 identifies-establishment-for-detail-materiel-in
                                                                                            MATERIEL-TYPE-ESTABLISHMENT
                                      is-made-up-through
                                                                                             established-materiel-type-id (FK)
        is-specified-as-part-of
                                                                                             materiel-type-establishment-index
                                            is-specified-through
                                                                                             materiel-type-establishment-category-code
  MATERIEL-TYPE-ESTABLISHMENT-MATERIEL-TYPE-DETAIL                                           materiel-type-establishment-effective-date
  established-materiel-type-id (FK)                                                          materiel-type-establishment-environment-condition-code
  materiel-type-establishment-index (FK)                                                     materiel-type-establishment-name
  materiel-type-establishment-materiel-type-detail-materiel-type-id (FK)
  materiel-type-establishment-materiel-type-detail-major-part-indicator-code                     identifies-establishment-for-detail-materiel-in
  materiel-type-establishment-materiel-type-detail-quantity
  materiel-type-establishment-detail-materiel-type-establishment-index (FK)




                                  Figure 7. Further Example of Attribute Naming



       5.5     Example of Relationship Naming
       Figure 8 shows an example of relationship naming in accordance with the
guidelines provided in Chapter 4.




                                                                          26
                                               NATO UNCLASSIFIED
                                         Releasable for Internet transmission
WP 3-1, Edition 5.0                                  NATO UNCLASSIFIED                                                                                         18 March 2002
                                             Releasable for Internet transmission

                                                                                     LOCATION




                                                                                             location-category-code


 GEOMETRIC-VOLUME                                                                                                                                            SURFACE
                                                                      POINT                                               LINE
                                                                                                                                     is-the-boundary-for /
                                                                                                                                     is-bounded-by
                                 geometric-volume-category-code
                                                                                                                                     POLYGON-AREA
           bounds-on-the-top                                                                                                                                    surface-category-c
                                                is-the-centre-for /           is-used-as /       is-defined-using /
                                                has-as-its-centre             makes-reference-to is-used-in-the-definition-of
bounds-on-the-bottom                                                                              P
                               SPHERE-VOLUME
                                                                                          LINE-POINT

  VERTICAL-DISTANCE
                                                                                                                                 is-part-of-the-boundary-for
                                               point-category-code                          is-used-to-define /
                                                                                            has-as-its-bearing-origin
                                                                                                                                       POLYARC-AREA
                                                                                is-the-vertex-for /
                                                                                is-defined-using
  is-specified-for       ABSOLUTE-POINT
                                                                                            FAN-AREA


                                                                                                                                   TRACK-AREA
                                RELATIVE-POINT                                 is-beginning-point-for /
                                                                               is-defined-using is-ending-point-for /
                                                                                                  is-defined-using

                                                                                                                                         CORRIDOR-AREA
                                                                                                      constitutes-the-set-of-waypoints-for /
                               used-for-expression-of /                                               is-defined-using
                               expressed-with-reference-to
                                                                                                               ORBIT-AREA
                                                                         is-first-point-for /
                               COORDINATE-SYSTEM
                                                                         is-defined-using
                                                                                            is-second-point-for /
                                                                                            is-defined-using
                                                                          is-the-centre-for /                                           ELLIPSE
                                                                          has-as-its-centre
                                                                                                    is-the-second-conjugate-point-for /
           SURFACE-VOLUME                                                                           has-as-its-second-conjugate-point
                                                                          is-the-first-conjugate-point-for /
                                                                          has-as-its-first-conjugate-point
                                                                                                                                                    is-used-to-define /
                                                                                                                                                    is-defined-using




                                       Figure 8. Example of Relationship Naming




                                                                                 27
                                                   NATO UNCLASSIFIED
                                             Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                                    18 March 2002
                            Releasable for Internet transmission


6.    CONCLUSIONS

        6.1      General Approach
        The logical data modelling naming procedures documented in Chapter 4 of this
paper apply to the ATCCIS programme. They are based on the principles proposed in
Working Paper 7L, which have been enhanced to meet the specific requirement to name
entities, relationships and attributes within the context of an IDEF1X Data Model. The
major differences from Working Paper 7L are:
        a.    the omission of the architectural modifier, as entities and attributes will be named
              within the context of a Data Model.
        b.    the non-inclusion of the Qualifier within an attribute name; instead this information
              will be recorded in the supporting data dictionary.
        c.    insistence that the Prime Word should be the first keyword within the Prime Term.

        6.2     Other Naming Conventions
        It is not the function of ATCCIS to rationalise naming conventions proposed by
external agencies within the nations. The experiences of these agencies in applying
structured naming conventions will continue to be assessed for its relevance to the
ATCCIS naming conventions.

      6.3    Class Words
      A list of standard Class Words together with their definitions is contained in
Annex B. All Class Words are also documented in an Annex of Working Paper 5-5 [Ref.
17].

       6.4     Prime Words
       The list of Prime Words used by ATCCIS together with their definitions need to be
maintained in the AIRD. The content of this list will be derived from validated and agreed
Data Models.

      6.5    Generic Terms
      The list of the Generic Terms used by ATCCIS need to be maintained in the
AIRD. The content of this list will be derived from the Data Modelling activity.

6.6     Modifiers
        It is not intended to maintain a standard list of Modifiers.

6.7     ATCCIS Information Resource Dictionary
        The specification of the ATCCIS Information Resource Dictionary based on the
ISO IRDS principle has been defined and documented in WP 4-1. The AIRD needs to be
capable of maintaining the lists of Class Words, Prime Words and Generic Terms, as well
as their association with entity and attribute names.

                                                28
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED              18 March 2002
                      Releasable for Internet transmission




                                      29
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        30
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                        Releasable for Internet transmission




                                    ANNEX A


                      LIST OF RESERVED CLASS WORDS




                                        A-1
                              NATO UNCLASSIFIED
                        Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        A-2
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                               18 March 2002
                            Releasable for Internet transmission

                                         Annex A

                      LIST OF RESERVED CLASS WORDS
It is the intention to re-issue this Annex as changes to Class Words are agreed within the
ATCCIS community. See change record for agreement details.
Reserved Class Words
The approved Class Word abbreviation is shown in brackets after the Class Word name.
         1. angle (angle)
The rotational measurement between two lines and/or planes diverging from a common
point and/or line.
         2. code (code)
A combination of alphabetic letters, and/or digits and/or special characters that represents
a specific object or entity. This class word is used only when there is a limited set of
possible values.
         3. coordinate (coord)
The geodetic designation of the location of a line or plane.
         4. date (date)
The designation of a specific year, month, and day period of time in the Gregorian
calendar using Universal Time as a standard of reference.
         5. dimension (dim)
A measured linear distance.
         6. duration (dur)
A non-monetary numeric value representing aggregated chronological units.
         7. fraction (frac)
A unit-less ratio of two numbers indicating a proportion. The value must be in the range
from 0 to 1.
         8. identifier (id)
A sequence of one or more numbers, alphabetic characters and/or special characters that
serve to uniquely identify some object but have no readily definable meaning.
         9. index (ix)
A sequence of one or more numbers, alphabetic characters and/or special characters that
serve to uniquely identify some object but have no readily definable meaning. [Index
enables the distinction of incidences in associative entities that would otherwise be
identical because the value of the other key attributes (which are all foreign-key attributes)
are the same].
         10. name (name)
A designation of an object and/or entity expressed in a word or phrase.
         11. quantity (qty)

                                             A-3
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0                  NATO UNCLASSIFIED                                        18 March 2002
                             Releasable for Internet transmission

A non-monetary numeric value.
         12. rate (rate)
A numerical proportion related to two measurements.
         13. temperature (temp)
A measure of heat in an object or space.
         14. text (txt)
An unformatted character string usually in the form of words.
         15. time (time)
A designation of a specified chronological point within a 24-hour period measured from
midnight Universal Time.
Units of Measurement
Some Class Words are associated with units of measurement. The following units have
been chosen for ATCCIS data modelling:
        angle:            Degrees11.
        coordinate:       Degrees, with positive values measured eastward from the zero
                          meridian or northward from the equator.
        date:             This is expressed as a composite field YYYYMMDD where YYYY
                          represents a year, MM represents a month in values from 00 to 12,
                          and DD represents a day in values from 00 to 31. An expression of
                          the form YYYY0000 indicates that only the year YYYY is being
                          specified. An expression of the form YYYYMM00 indicates that
                          only the year YYYY and month MM is being specified.
        dimension:        Metres.
        duration:         Seconds.
        quantity:         The units, when they exist, are specified on an attribute-by-attribute
                          basis.
        rate:             The units, when they exist, are specified on an attribute-by-attribute
                          basis.
        temperature: Degrees Celsius.
        time:             This is expressed in the form HHMMSS where HH represents an
                          hour, MM represents a minute, and SS represents a second.




11     Until the end of ATCCIS Phase III units of radians were used as units of measurement for the Class
Word angle.

                                                  A-4
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 3-1, Edition 5.0         NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                                  ANNEX B


                         LIST OF REFERENCES




                                      B-1
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        B-2
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0             NATO UNCLASSIFIED                            18 March 2002
                        Releasable for Internet transmission

                                      Annex B

                            LIST OF REFERENCES

1.      ATCCIS Working Paper 7L – Operational and Procedural Requirements for Data
        Management and Standardisation – Edition 1.0, June 1989.
2.      Designing Quality Databases with IDEF1X Information Models - Thomas A.
        Bruce - Dorset House Publishing - Chapter 5 Names and Definitions.
3.      ATCCIS Working Paper 4-1– ATCCIS Information Resource Dictionary (AIRD) -
        Definition of Structure and Contents – Edition 2.0, 2 June 1995.
4.      The ERwin/ERX User Documentation.
5.      NIST Special Publication 500-149 – Guide on Data Entity Naming –October
        1987.
6.      Draft DoD Manual 8320.1M – Data Management Procedures – March 1994.
7.      DoD Manual 8320.1-M-1 – Data Element Standardisation Procedures – April
        1998.
8.      MOD Data Management Strategy – Strategy Statement – Draft Version 1.0, June
        1992.
9.      Data Management for the Royal Air Force – Draft Data Administration Standards
        – D/DLIS(RAF)/330/4/4.
10.     Q Functional Area – Draft Data Standards Catalogue.
11.     PE Data Management Group – Draft Data Definition Framework for PE.
12.     UK MoD's formal agreement to the Data Naming Standard – July 1993.
13.     UK MoD’s Options 1 and 2 for Proposed Formalised Language Syntax - 16
        February 1995
14.     ISO 11179-5 1995 – Information Technology - Specification and Standardization
        of Data Elements - Part 5: Naming and identification Principles for Data
        Elements, International Organization for Standardization – 1995.
15.     ATCCIS Working Paper 25 – Technical Standards for CCIS's – Edition 4, 25
        February 1994.
16.     Working Paper 7 AC/322(SC/5-WG/3)WP7 – NATO C3 Data Naming Convention
        – Version 0.1, April 2000
17.     ATCCIS Working Paper 5-5 – The Land C2 Information Exchange Data Model –
        Edition 5.0, 18 March 2002.




                                         B-3
                              NATO UNCLASSIFIED
                        Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        B-4
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0         NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                                  ANNEX C


                                GLOSSARY




                                      C-1
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        C-2
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 3-1, Edition 5.0                 NATO UNCLASSIFIED                             18 March 2002
                            Releasable for Internet transmission

                                            Annex C

                                        GLOSSARY
AFNORTH               Allied Forces Northern Europe
AIRD                  ATCCIS Information Resource Dictionary
ANSI                  American National Standards Institute
ATCCIS                Army Tactical Command and Control Information System
AWG                   ATCCIS Working Group
CIS                   Command and Information System/ Communications and Information
                      Systems
CW                    Class Word
C2                    Command and Control
DOD                   Department of Defense
IDEF                  Integrated Computer Aided Manufacturing (ICAM) Definition
                      (language); Integration Definition (language)
IDEF0                 IDEF for Activity Modelling
IDEF1X                IDEF for Data Modelling
IRD                   Information Resource Dictionary
IRDS                  Information Resource Dictionary System
ISO                   International Organization for Standardization
LC2IEDM               Land Command and Control Information Exchange Data Model
MOD                   Ministry of Defence
NATO                  North Atlantic Treaty Organisation
NDAG                  NATO Data Administration Group
NIST                  US National Institute of Standards and Technology
OSI                   Open System Interconnection
PWG                   Permanent Working Group
RDA                   Remote Database Access
RDBMS                 Relational Database Management System
SFA                   Sub-Functional Area
SHAPE                 Supreme Headquarters Allied Powers Europe
SQL                   An international database language (formally known as Structured
                      Query Language)
STANAG                NATO Standardization Agreement
WP                    Working Paper


                                              C-3
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 3-1, Edition 5.0           NATO UNCLASSIFIED                18 March 2002
                      Releasable for Internet transmission




                        (This page intentionally left blank)




                                        C-4
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
         UNCLASSIFIED
Releasable for Internet transmission




            ANNEX D


Reference: Working Paper 7L




                  1
      NATO UNCLASSIFIED
Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




          (This page intentionally left blank)




                           2
              NATO UNCLASSIFIED
        Releasable for Internet transmission
WP 7L                  UNCLASSIFIED                  June 1989
              Releasable for Internet transmission




             ATCCIS Working Paper 7L




   OPERATIONAL AND PROCEDURAL REQUIREMENTS FOR
     DATA MANAGEMENT AND STANDARDIZATION(U)

                          Edition 1.0
                          June 1989




                               3
                    NATO UNCLASSIFIED
              Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                   June 1989
                           Releasable for Internet transmission


                                    FOREWORD
      (NU)      This is Edition 1, ATCCIS Working Paper 7L prepared by the Office of the
Director of Information Systems for Command, Control, Communications, and Computers
(ODISC4), Headquarters, Department of the Army, in support of the SHAPE-sponsored
Army Tactical Command and Control Information System (ATCCIS) Phase II study
effort. Additional data and analyses will be required to complete the assessments of
options and standards coverage and to extend the interoperability parameter methodology.
      (NU)      This draft document is being provided at this stage of development at the
request of the U.S. Representative to the ATCCIS Permanent Working Group (PWG) in
order to: (1) inform people as to the progress of this SHAPE support activity, (2) provide
information to people involved in interoperability activities, and (3) invite comments and
additional information. Background information relating to the overall ATCCIS effort is
contained in the Preface of this Working Paper. It should be noted that Oxford English
spelling conventions are used throughout the paper in accordance with standing NATO
guidelines. Additionally, emerging international and NATO technical terminology is used
throughout the paper. Other ATCCIS working papers will be using this terminology in
future editions.
      (NU)      ODISC4 provides the U.S. delegate to the ATCCIS PWG, which consists
of military, technical, and analytical representatives from France, Germany, the United
Kingdom, the United States, SHAPE, and the SHAPE Technical Centre, and observers
from the Allied Forces Central Europe (AFCENT). The ATCCIS Steering Group
provides overall direction and approval of the ATCCIS PWG work effort and includes
representatives from the PWG nations and commands, plus Belgium, Canada, and the
Netherlands, with additional representation (observers) from the Allied Data Systems
Interoperability Agency (ADSIA), the NATO Communications and Information Systems
Agency (NACISA), and the Tri-Service Group for Communications Electronic Equipment
(TSGCEE). The Command and Control Division, U.S. Army Combined Arms Combat
Development Activity, provides military expertise; the U.S. Army Communications-
Electronics Command and IDA provide technical expertise, with additional support
provided by the National Institute for Science and Technology (NIST); and IDA provides
analytical expertise in support of the U.S. contributions to the overall ATCCIS effort.
Further details concerning the ATCCIS Phase II study can be found in the ATCCIS Work
Plan.12




12   (U) ATCCIS Phase II Work Plan, Edition 2, IDA Memorandum Report M-263, September 1986,
     UNCLASSIFIED.

                                               4
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                             UNCLASSIFIED                                June 1989
                         Releasable for Internet transmission


                                    PREFACE
1. (U) In 1978, NATO's Long-Term Defense Plan (LTDP) Task Force on Command and
Control (C2) recommended that an analysis be undertaken to determine if the future
tactical Automatic Data Processing (ADP) requirements of the nations, including that of
interoperability, could be obtained at a significantly reduced cost when compared with the
approach that had been adopted in the past. The Task Force also recommended that the
analysis should determine whether tactical ADP systems could be developed according to
technical standards prescribed by NATO and agreed upon by the nations.
2. (U) In early 1980 the then Deputy Supreme Allied Commander Europe initiated a study
to investigate the possibilities of implementing the Task Force's recommendations. Three
nations, those with experience in fielding automated tactical command and control
information systems, participated in Phase I of the study, with Supreme Headquarters
Allied Powers Europe (SHAPE) as leader and coordinator. The study group reported, at
the end of Phase I, that the nations could increase interoperability and potentially reduce
costs by using a common development approach. It was also recommended that Phase II,
the definition of an operational and technical concept and an analysis of the likely impact
of a common Central Region (CR) (tactical) command and control information system,
should be initiated.
3. (U) The ATCCIS study, under the direction of a steering group chaired by SHAPE and
consisting of representatives from the CR nations and Allied Forces Central Europe
(AFCENT), was established in 1984. Concurrently, a permanent working group (PWG)
was formed which consists of military, technical, and analytical representatives from
France, Germany, the United Kingdom, the United States, SHAPE and AFCENT, and
technical support from SHAPE Technical Centre (STC) to progress the Phase II effort.
The Phase II study effort commenced in January 1985.




                                            5
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 7L                                         UNCLASSIFIED                                                          June 1989
                                     Releasable for Internet transmission




                                     TABLE OF CONTENTS
FOREWORD ..............................................................................................................        4
PREFACE ...................................................................................................................    5
1.      INTRODUCTION .............................................................................................             9
        1.1     Derivation......................................................................................               9
        1.2     Purpose..........................................................................................             10
        1.3     Scope .............................................................................................           10
        1.4     Structure of the Paper....................................................................                    10
2.      BACKGROUND FOR DATA STANDARDIZATION....................................                                               11
        2.1     NATO Policy ................................................................................                  11
        2.2     Overview of Existing and Emerging Standards ............................                                      13
        2.3     Operational Rationale for Data Standardization ...........................                                    17
3.      CONCEPT OF DATA .......................................................................................               18
        3.1      Concept of Data ............................................................................                 18
        3.2      Categorization of Data Concepts ..................................................                           18
        3.3      Data Element Concepts .................................................................                      19
        3.4      Data Element Alias .......................................................................                   19
4.      STRUCTURE OF DATA ..................................................................................                  20
        4.1     Generic Element ...........................................................................                   20
        4.2     Data Element.................................................................................                 21
        4.3     Data Element Alias .......................................................................                    23
5.      DATA MANAGEMENT GLOSSARY.............................................................                                 24
        5.1     Background ..................................................................................                 24
        5.2     Common Information Exchange Language (CIEL)......................                                             24
        5.3     Common Information Exchange Glossary (CIEG).......................                                            25
6.      NAMING CONVENTION ................................................................................                    27
        6.1     Introduction ...................................................................................              27
        6.2     Definitions.....................................................................................              28
        6.3     Syntax for Naming Convention ....................................................                             28
        6.4     Generic Element Name .................................................................                        28
        6.5     Data Element Name ......................................................................                      29
        6.6     Rules for Naming Convention ......................................................                            30
        6.7     Relation of Recommended Naming Convention to Other Standards                                                  32
7.      ATTRIBUTE LIST ............................................................................................           34
8.      DATA MANAGEMENT POLICY AND PROCEDURES...............................                                                  35
        8.1     Introduction ...................................................................................              35
        8.2     Standardization Procedures for Data Elements and Other Standard
                Elements........................................................................................              35
        8.3     Life Cycle for Standard Elements .................................................                            37
        8.4     Enforcement of Standard Elements...............................................                               41
        8.5     Exemptions and Waivers...............................................................                         41


                                                                  6
                                           NATO UNCLASSIFIED
                                     Releasable for Internet transmission
WP 7L                                   UNCLASSIFIED                                                  June 1989
                               Releasable for Internet transmission
9.   CONCLUSIONS AND RECOMMENDATIONS ............................................                              42
     9.1     Conclusions ...................................................................................   42
     9.2     Recommendations .........................................................................         42


APPENDIXES
    A                 CATEGORIZATION OF DATA CONCEPTS
    B                 LIST OF CLASS WORDS AND DEFINITION BY CATEGORY
    C                 ARCHITECTURAL MODIFIERS AND PRIME WORD LIST
    D                 "OF-LANGUAGE" NAMING CONVENTION
    E                 ATTRIBUTE LIST
    F                 NATIONAL INITIATIVES ON DATA MANAGEMENT
    G                 BACKGROUND, OBJECTIVE, AND ADDITIONAL GUIDANCE
    H                 DISTRIBUTION LIST

GLOSSARY
REFERENCES




                                                         7
                                     NATO UNCLASSIFIED
                               Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




         (This page intentionally left blank.)




                          8
              NATO UNCLASSIFIED
        Releasable for Internet transmission
WP 7L                                 UNCLASSIFIED                                       June 1989
                             Releasable for Internet transmission


                                  ATCCIS Working Paper 7L

     OPERATIONAL AND PROCEDURAL REQUIREMENTS FOR
       DATA MANAGEMENT AND STANDARDIZATION13 (U)
1.   introduction

        1.1 Derivation
(U)     This working paper has been produced in support of Task 4-B-4 [Ref. 1] of the
SHAPE-sponsored ATCCIS study for a tactical command and control (C2) system
concept for the year 2000 and beyond.
(U)     The critical need for NATO data management standardization has been clearly
identified by both the Allied Data Systems Interoperability Agency (ADSIA) [Ref. 3] and
SHAPE [Ref. 4]. SHAPE Technical Centre (STC) has developed a general approach and
has recommended standardizing data management methodologies [Ref. 5], but data
management standards in several areas need to be developed for uses throughout NATO,
including ATCCIS.
(U)     Data element standardization14 supports the sharing of information and data
through uniform data representation, consistent interpretation, and common understanding.
Data element standardization is necessary to define and implement Information Exchange
Requirements (IERs). Specific objectives of data element standardization are to:
        a. Ensure that data are treated as a Command and Control Information System
             (CCIS)-wide resource to be shared to facilitate the coordination, control, and
             management of IERs
        b. Reduce the cost of managing data by eliminating duplication and redundancy
        c. Provide an approach to data element standardization for use throughout
             ATCCIS and, potentially, other CCISs
        d. Provide a means to ensure consistency of data throughout NATO and
             cooperating national databases and information systems.
(U)     Data element standardization provides an opportunity to improve the quality and
consistency of specification of current and future IERs. Data element standardization
presupposes that national agreement is reached in formulating and structuring the required
data elements.
(U)     The complete development of an integrated database to meet these requirements is
both an operational and technical undertaking, and will evolve over a long period of time.
Working Paper 7N15 will present the overall process of developing the necessary technical
basis for the generation of an integrated set of databases for future systems. This paper
addresses the operational input to that overall process.




13          (U) Reference for spellings in ATCCIS is the Oxford English Dictionary, Oxford University
Press, Oxford, 1971 (21st Printing, 1981).
14          (U) Note: Data element standardization specifies the definition and representation of data
elements, but in no way specifies which data elements "should be" parts of IERs. Data standardization
provides guidance for expressing requirements, but not for the requirements themselves.
15          (U) Working Paper 7N on Technical Requirements for Data Management and Standardization
is currently being developed by the ATCCIS PWG Technical Group. Publication date to be determined.
                                                  9
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                 June 1989
                          Releasable for Internet transmission

       1.2 Purpose
(U)    The purpose of this working paper is to provide an operational input to data
management and to provide specific recommendations for data standardization. By
providing specific recommendations, this paper is intended to promote detailed
discussions that could result in early promulgation of standards.

        1.3 Scope
(U)     The scope of data element standards encompasses data used to support CCIS
missions and goals in support of coalition warfare and the entire spectrum of conflict
(peace, transition to conflict, and conflict). It also encompasses data required to support
some agencies external to the armies. Standardized data elements should be used in
specifying IERs for all CCISs.
(U)     Standardization procedures provide for the documentation needed to coordinate
data sharing across the armies. Data element standardization is necessary but not
sufficient for the technical specification of an automated database (see Working Paper
7N for a discussion on the technical issues involved). Information system redesigns
provide the opportunity to align existing data requirements with the standardized data
elements. Where appropriate, data elements currently used in existing CCIS databases
should be considered for adoption as standardized data elements.
(U)     This paper accomplishes several goals:
        •    Recommends that a NATO glossary be developed that defines all the terms to
             be used to name and characterize the structure of data elements
        •    Recommends a naming convention for the identification of data elements
        •    Recommends an attribute set for characterizing data representations
        •    Identifies requirements and proposes an approach for the policies and
             procedures necessary to implement and maintain effective data management.

        1.4 Structure of the Paper
(U)     Chapter 2 provides the background for data standardization. The approach for data
standardization is based on structural attributes rather than how the data are used. Chapter
3 presents the basic concepts for data standardization, including the concepts of data, data
element, data value, and data field. Chapter 4 presents, based on proposed draft
International Standards Organization (ISO) standards, the conceptual framework for the
structure of data. Chapter 5 discusses the need for a Glossary to support data
standardization. Chapter 6 proposes a data element naming convention. Chapter 7
presents a set (viewed as a minimum set) of attributes need to specify (e.g., in a data
dictionary) administrative, representational, and relational information about data
elements. Chapter 8 discusses requirements, policies, and procedures for data
management. A key element of the data management concept is the role of functional
experts to specify information standards. The paper concludes in Chapter 9 with a
summary of the conclusions and recommendations.




                                            10
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                                  UNCLASSIFIED                                         June 1989
                              Releasable for Internet transmission


2. BACKGROUND FOR DATA STANDARDIZATION
(U)     Interoperability for ATCCIS is defined as the exchange of information that
preserves meaning and relationships.16 Data standardization is required to provide
consistent structure for representing these meanings and relationships for data elements
that support the IERs. In this context, the term "data element" refers to the lowest level or
simplest expression of data that is to be represented, stored, processed, or transmitted.
(U)     The data management problem is how to identify, name, and structure data
elements in a consistent (and nonredundant) fashion to support NATO degree five
interoperability, while reducing, or at least controlling, the cost of modifying or
developing ATCCIS-conformant systems. Data management is required for correlating
IERs, designing databases, formatting and analysing message texts, and identifying
manual procedures.
(U)     An immediate solution for the data management problem in Allied Command
Europe (ACE) is required. Further, there is not yet an integrated solution (or approach)
defined for NATO in data management. A discussion of the policy and recommendations
provided to date is given in Sections 2.1 and 2.2.
(U)     Each data element in a CCIS needs to have associated with it:
        •    A unique name that is structured to prevent data redundancy
        •    Representations for data values (e.g., formats, range of acceptable values)
        •    Indication of the accuracy of the data element (e.g., four significant places)
        •    Specification of the unit to be used (e.g., litres)
        •    Additional structure to represent the relationships of this data element to other
             data elements (e.g., associating a facility name with a logical address)
        •    Supportive descriptive text.
An overview of concepts for data and data standardization is presented in Chapter 3 and 4.
(U)     The concepts to be used for names and structure must be consistent with
international standards and be able to present hierarchical and other relationships. Names
themselves will be given structure. Specifically, naming conventions include a
fundamental descriptor, some modifiers, and some additional qualifiers. The descriptors
and modifiers would specify not only the type of that data element, but also a clear
indication of what that data element is. One of the underlying principles of data
standardization is that data elements are based on "what is represented" rather than on
"how the data are used." Modifiers would also indicate, where appropriate, the
organizational context or meaning for the data element.

        2.1 NATO Policy
(U)     The ATCCIS Permanent Working Group (PWG) understands that NATO policy
for data management is the responsibility of the NATO Communications and Information
Systems Committee (NACISC). However, no NACISC policy statements have been
found for data management. This section summarizes the progress being made to
establish the need for and to develop NATO policy for data management.
(U)     The Chairman of ADSIA has clearly stated [Ref. 6] the need for a policy for data
management in the NATO CCIS:17


16          (U) The basis for interoperability in ATCCIS is the degree five interoperability concept as
defined in the 15 December 1987 draft NATO Interoperability Planning Document (NIPD) [Ref. 8].
17          (U) The NATO CCIS or NCCIS is the aggregation of NATO Headquarters systems, NATO
Command systems, NATO Agency systems, national-NATO dual-role systems, and national systems that
interface to NATO.
                                                   11
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                   June 1989
                          Releasable for Internet transmission
               The introduction of automated data bases in NATO Commands and
               Headquarters over the past decade has raised the need for interoperability
               standards for automated information exchange among data bases and for a
               scheme for data management to insure data integrity and consistency with
               CCIS data bases. Various NATO authorities are already forced to address
               those activities to satisfy specific system needs, and this number is
               increasing....[S]erious attention should be given to:

               -    The establishment of a NATO data management policy,
               -    The development of a NATO CCIS data dictionary,
               -    The development of          interoperability   standards   for   database
                    information exchange.
(U)     The NATO Interoperability Management Plan (NIMP) [Ref. 7] specifically
identifies standards and rules for representing data as procedural standards and assigns the
responsibility for these standards to ADSIA. Further, the NIMP states:
               In order for the information exchange to be effective, it is necessary that the
               meaning and relationships associated with [information received from other
               facilities] is common and preserved, irrespective of the interoperability
               service and transmission media. A single common definition for all
               operational information throughout NATO is needed to achieve this goal.
               (Emphasis added)

               ...[A] common information exchange glossary [is] essential to the
               development of unambiguous and operationally satisfactory information
               procedural standards.

                It is NATO policy to maximize the commonality of the different system-
                dependent standards where there exists a validated operational requirement
                and where this is economically acceptable.          The areas in which
                commonality shall be sought include operational terminology, expression at
                the representational level and system architecture.
(U)     An early draft of the NATO Interoperability Planning Document (NIPD) Volume 2
[Ref. 8] had an annex (Annex D, now discarded) that described a Common Information
Exchange Language (CIEL) that was a predecessor to the current ADSIA initiative to
develop a NATO Glossary of Operational Terms (GLOT). Details are provided in
Chapter 5. The NIPD will address formal specification of IERs and the development,
configuration management, testing concept, and documentation plan for NATO Common
Interoperability Standards (NCIS). The NIPD is still in development, with drafts of the six
volumes planned for completion in 1989 and agreement in 1990. Drafts of Volume 2
(Formal Specification of IERs), Volume 3 (Plan for Development of NCIS), and Volume 4
(Plan for Configuration Management of NCIS) have been completed [Ref. 9]. Volume 2
will specify the six degrees of NATO interoperability.
(U)     Data management continues to be carried as an open issue on the agendas of the
Information Systems Working Group (ISWG) and the ADSIA Plenary.18 The ISWG has
been invited [Ref. 10] by the ADSIA Plenary to develop a NATO policy on (1) data

18        (U) Both the ISWG and ADSIA are part of the NATO Communications and Information
Systems Organization (NACISO), whose executive body is the NACISC.
                                              12
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                    June 1989
                           Releasable for Internet transmission

management and (2) the use of database management systems in the NATO CCIS.
ADSIA would use this policy for the identification and collection of related
standardization requirements.

        2.2 Overview of Existing and Emerging Standards
(U)     This paper will recommend an integrated framework for data management that
brings together the efforts and development already initiated in a number of NATO
Technical Memorandums and other papers, as well as from international commercial
standards. Selected NATO standardization agreements (STANAGs) were reviewed to
identify potential bases for data management standards. This section summarizes the
status of standards and recommendations from these sources.

                2.2.1     Existing and Emerging ISO Standards
(U)     The International Standards Organization (ISO) and the International
Electrotechnical Commission (IEC) Joint Technical Committee 1 (JTC1) has issued a draft
standard, DP 7826, on the representation of data elements [Ref. 11]. This draft proposal
sets out standard procedures for the identification and representation of existing and new
coding systems, without providing any guidance on specific coding systems. It also
specifies a technique for interchange of coded representations and the requirements for the
administration of International Coding System Identifiers (ICSIs). This will permit the use
of more than one coding system, reduce the possibility of ambiguity, reduce the need for
human intervention, and diminish the time required to negotiate interchange of coded
representation agreements.
(U)     ISO/IEC DP 7826 identifies three types of data element attributes: administrative,
relational, and representative. These are the types of attributes described in this Working
Paper and recommended for ATCCIS in Chapter 7.
(U)     Substantial work has been done cooperatively by ISO/IEC JTC1/SC14 and
American National Standards Institute (ANSI) X3L819 during the last three years, and a
draft proposal for data management is expected sometime in 1989. Once accepted by the
working groups, this draft proposal will be offered to ISO for adoption [Ref. 12]. The
general approach to the structure of data (Chapter 4) was derived from discussions with
ISO/IEC JTC1/SC14 and ANSI X3L8.

                2.2.2     STANAGs and TSGCEE Recommendations
(U)     The purpose of AAP-6, NATO Glossary of Terms and Definitions (English and
French) [Ref. 13], is to standardize operational terminology used throughout NATO,
thereby promoting mutual understanding. The criterion for inclusion is that the term be of
a general military application. While earlier editions put qualifiers immediately following
the term, such qualifiers are now embedded in the definition. In addition, terms and
definitions are not to be composed of, nor contain, abbreviations and acronyms. A term
and definition are only included in the glossary when they have been agreed upon by all
nations in both English and French.
(U)     An early standard, no longer in effect, was ADatP-1 (STANAG 5550) [Ref. 14],
NATO Standard Data Elements, Data Items, and Codes. This standard was developed to
specify the rules and procedures in developing standard data suitable for use in both
manual and computer-assisted environments for the exchange of information between
national and NATO authorities.

19         (U) A member of the U.S. Technical Advisory Group to ISO/IEC JTC1/SC14 and of X3L8 is
an active participant in the ATCCIS PWG and contributed to this Working Paper.
                                               13
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                       June 1989
                           Releasable for Internet transmission

(U)     The terms defined in ADatP-2 [Ref. 15], Automatic Data Processing (ADP) NATO
Glossary, English and French, are derived from glossaries, dictionaries, and vocabularies
from ANSI, American National Directory for Information Processing (ANDIP), ISO,
International Business Machines (IBM), and ACP 167. The definitions are annotated by
source and may include abbreviations, examples, notes, diagrams, accepted synonyms,
contrasting terms, related terms, and cross-references for multiple uses. When
harmonization is being examined for multiple uses of a term, this information is noted.
(U)     ADatP-3 (STANAG 5500) [Ref. 16], NATO Message Text Formatting System
(FORMETS), provides the rules, constructions, and vocabulary for standardized character-
oriented message text formats that can be used in both manual and computer-assisted
operational environments.
(U)     Allied Communications Publication (ACP) 167(F) [Ref. 17], Glossary of
Communications-Electronics Terms, provides definitions of terms used by
communications, electronic warfare, and operational personnel for Allied networks.
(U)     STANAG 5621 is one of many operational standards that provide procedures for
embedding data fields into (character-oriented) message text formats. However, it does
not provide a structured method for the integration, identification, or naming of data
elements that is applicable across multiple media. Users provide free-form names for
data fields. Associated with each data field is a set format identifier, whose first character
indicates whether the data field set format is designed for columnar information.
(U)     STANAG 4222, Standard Specification for Digital Representation of Shipboard
Data Parameters, is a naval standard that addresses naming conventions [a product of the
NATO Industrial Advisory Group (NIAG) WG6]. This STANAG addresses the
specification of digital representation of shipboard embedded data parameters only.
(U)     The NATO Technical Common Interoperability Standards (TCIS) Transition
Strategy [Ref. 18] recommends a number of ISO standards for use until the TCIS are
available. These technical standards include ASN.1 (ISO 8824), ASN.1 Basic Encoding
Rules (ISO 8825), and Association Control Service Elements (ASCE, ISO 8650), which
could support the procedural standards recommended in this Working Paper for data
management.

               2.2.3     Other NATO Directives and Recommendations
(U)     In 1985, STC published a Technical Memorandum (TM), Data Management
Standardization for ACE ACCIS, TM-776 [Ref. 5]. This paper recommends
standardization of the architecture, functionality, and structure of the Data Management
Subsystem (DMS) of the ACE Automated Command and Control Information System
(ACCIS). These areas of standardization include data management methodologies and the
tools needed to design, build, and maintain the ACE ACCIS databases. TM-776
accomplished the following:
        •   Recommended standard data elements and relationships be placed into an ACE
            common data structure.
        •   Identified a schema as consisting of a definition of all application object types,
            including their attributes, relationships, and static constraints, where a database is an
            instance of a schema.
        •   Identified the need for a methodology for formal definition of data elements based on
            standardized terminology, including the use of naming conventions.
        •   Identified the requirement that the Data Management Subsystem (DMS) at every
            ACE ACCIS node must agree upon the semantics and syntax of the information
            exchange.

                                                14
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                       June 1989
                           Releasable for Internet transmission
        •    Stated that a classification method must be based on the principle of sorting data
             according to the type of information provided by their values, independent of their
             use in particular databases, messages, or applications.
        •    Defined a data element as a basic unit of data which has a name, a definition, and a
             set of values for representing particular facts. A data element and its definition
             should not include any application or usage information.
        •    Stated that determination of names following rules and classification of data elements
             brings out common data features and helps the correlation process. A method of
             analysing, defining, and controlling data elements has three components: a type
             classification of data elements, syntax rules for the structure and completeness of
             formal definitions, and a controlled vocabulary of permitted terms for formal
             definitions. (Note: the concept of generic element is introduced in Chapter 3 to
             provide for these features.)
(U)    In April 1986, ADSIA revised a working paper, "The Need for Standardization of
Data Management and Data Base Information Exchange in the NATO CCIS" [Ref. 3], on
the need for standardization of data management. The following actions were
recommended and agreed to, but without any binding commitments of the nations to
implement them:
        •    NATO Communications and Information Systems Agency (NACISA) to identify and
             collect the requirements for database management systems and for standardization of
             database schemes, file transfers, database information exchange, and configuration
             management procedures
        •    Subsequently, ISWG to develop a NATO policy on data management and on the use
             of database management systems in NATO CCISs
        •    ADSIA to coordinate the development of technical and procedural standards for
             databases
        •    ADSIA to develop the procedural standards for database information exchange
        •    TSGCEE Subgroup 9 on Data Processing and Distribution to develop technical
             standards for database schemes and file transfer
        •    NACISA to control the implementation of the developed standards and NATO policy
             paper to ensure the interoperability of command and control systems within the
             NATO CCIS.
(U)     In October 1988, SHAPE distributed AM 96-1-4, Data Management [Ref. 4]. This
manual concentrates primarily on administrative aspects of data management, specifically
the responsibilities of a Data Administrator and a Database Administrator.20 It states:
        •    The purpose of data management is to provide methods to ensure data availability,
             security, integrity, quality, and interoperability, and to provide data sharing.
        •    Defines data as representing the elementary facts, descriptions, and qualifications
             about things of interest to some headquarters, unit activity, or enterprise.
        •    Defines an attribute as a definitive characteristic of a data element or data item that
             quantifies, identifies, or describes its representational, administrative, or relational
             concept.
        •    Defines the role of a data dictionary as an automated tool that provides a centralized
             library of metadata covering all aspects of all types and structures of data residing in

20      (U) AM 96-1-4 is binding only on SHAPE. As such, it does not necessarily provide for
NATO-wide policy.
                                                15
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                      June 1989
                           Releasable for Internet transmission
            databases, file systems, and manual systems within an organization.            Aspects
            identified are:
            -    origin and ownership of data
            -    attributes (name, number, code language mnemonic, synonyms, format, range of
                 values)
            -    definitions
            -    usage (applications, reports, physical forms)
            -    location (files, schemas)
            -    destination (data flows)
            -    security classification
            -    relationships
            -    dispositions.
        •   Asserts: Evolution towards an ACE ACCIS will only succeed from the data
            management point of view by ensuring that the standardization of data definitions,
            the control of the data, and the maintenance of its overall integrity are systematically
            established on a command or site basis.
        •   Asserts: The fundamental key to data management is the early definition and
            identification of data elements and, later, data fields. The definition and
            corresponding name should be clear, accurate, and meaningful, but reference should
            be given to connotation, which relates to the interpretation that bears upon the
            specific context of usage of data.

                2.2.4    Other Data Management Standards
(U)      The naming convention and rules presented in this paper have been derived from
an emerging standard from the National Institute for Science and Technology (NIST),
Guide to Data Entity Naming Conventions [Ref. 19], that is expected to be offered to ISO
in the near future. Specifically, the general format of the convention is consistent with this
publication. However, the rules have been expanded to support the concepts and structure
of data consistent with the needs in NATO, SHAPE, and ATCCIS, as well as the emerging
ISO taxonomy. The attribute list presented in Chapter 7 is a superset of the element level
of ISO/IEC DP 10027, Information Processing Systems--Information Resource Dictionary
System (IRDS) Framework of 1 April 1988. The attribute list (as well as the rules) has
been expanded to incorporate needs that have been identified in NATO, SHAPE, and
ATCCIS. The overall guiding philosophy has been to integrate all possible sources of
information on data management, standardization, standards, structure, classification, and
typing.
(U)      The concepts and constructs contained within this paper are consistent with the
emerging IRDS standard, ISO/IEC DP 10027. The IRDS specifies the Element Entity
(i.e., data element) as the lowest level of the dictionary framework. Unfortunately, the
IRDS does not address the constructs that make up the Element Entity, nor does it provide
a convention that can be used to support the Element Entity. This paper supports and
completes the Element Entity as defined within ISO/IEC DP 10027 by providing an
approach that will facilitate the standardization and management of the IRDS's Element
Entity.
(U)      In ACE Directive 80-57, SHAPE has recommended use of the Structured Analysis,
Design, and Implementation of Information Systems (STRADIS) Methodology (AM 96-1-
2 [Ref. 20] and AM 96-1-3 [Ref. 21]) as an an ACE formal life-cycle methodology for the

                                                16
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                 UNCLASSIFIED                                         June 1989
                             Releasable for Internet transmission

implementation of all software projects.21 It includes extensive activities related to data
identification and analysis as part of its structured requirements analysis phase. STRADIS
gives rules and guidance to be followed by management and implementors, and it gives
recommendations on which methodologies should be used for the data analysis and
database design phases. Specifically, STRADIS recommends [Ref. 5]:
        •     Use of the Yourdon data analysis technique (structured analysis, using data flow
              diagrams) [Ref. 22, 23, 24]
        •     Structured walkthroughs [Ref. 23, 25]
        •     Data normalization [Ref. 26]
        •     Automated support tools, including EXCELERATOR and DATA DESIGNER.
The STRADIS Project Data Dictionary is viewed as a repository for project metadata, the
contents of which are to be compared with, and be expected to lead to eventual merging
with, existing conceptual schema. The STRADIS also generates Project Entity-
Relationship, Key-based, and Fully Attributed models that are considered prototype
external schema for particular functional areas [Ref. 4].

        2.3 Operational Rationale for Data Standardization
(U)     Command and control of military forces is accomplished through information and
is often supported by automation. The information flow required to support command and
control has evolved over the years to a current system that is highly complex and often
automated. Military leaders today are faced with unparalleled dynamics in the coalition
warfare environment and an information level that is growing exponentially.
(U)     The proliferation of automated office and tactical information systems has
increased by varying factors in each nation's tactical formations. Similarly, the ACE
ACCIS System Design and Integration Contract, War HQ's project, along with national
plans for the tactical forces, will provide additional command and control information
systems at the various echelons and headquarters within ACE. NATO has identified the
need for these systems to be interoperable, and that information management is a required
strategic and operational capability.
(U)     The ability to effectively command and control forces on the battlefield and
manage information resources requires that operational, procedural, and technical
standards be agreed upon and implemented. The current Operational and Procedural
standards identify less than half of the IERs required by tactical forces. The current
methods of exchanging information [e.g., Message Text Formats (MTFs), voice, and
formatted data] result in redundant transmission of information, misunderstanding, and
inconsistency in interpretation, and they place an additional burden on limited tactical
communications systems.
(U)     Data standardization, including agreed operational definition of the information to
be exchanged among the nations, is one of the key issues identified in the ATCCIS study.
While the focus for ATCCIS is the next generation of tactical systems, this work must be
started now.




21         (U) STRADIS was developed by the McDonnell Douglas Corporation. It is still proprietary
and distribution in ACE is limited. The two-volume document has been revised to five volumes, but these
have not yet been procured by SHAPE.
                                                   17
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 7L                                  UNCLASSIFIED                                          June 1989
                              Releasable for Internet transmission


3. CONCEPT OF DATA
(U)    Agreement is needed for a concept of data in order to provide an overall
mechanism to express precise meanings and relationships of data to be exchanged in
support of interoperability requirements. This chapter and Chapter 4 present fundamental
concepts on data and data structure that are technical in nature. They are presented here
for completeness, since much of the discussions in Chapters 6, 7, and 8 are based on these
concepts.

         3.1 Concept of Data
(U)      In information systems, the basic unit of information is data. In this context, data
refers to that unit that contains, but is not limited to, such things as: raw number, word(s)
of text, codes, or graphical pixel representation. Formally, data may be defined as a
representation of a person, place, thing, or concept in a pre-defined format or structure
from which information can be derived.22 The distinction between data and information is
that, in and of itself, data has no meaning. Information has some contextual meaning
attached to it, such that the use of that information can relate it to an aspect of the real
world. As an example, the individual pixels (data) that make up a graphical image have
the intended meaning (information) only when related to other pixels in a predefined way.
When stored in manual or automated information systems, the actual occurrence of data is
called a data value.
(U)      The October 1988 AM 96-1-4 [Ref. 4] identifies a hierarchy of three fundamental
data concepts:
        •     Data Element. This represents a named piece of data that is of interest to an
              organization. In order to make sense, it should be carefully and unambiguously
              defined, together with other characteristics or attributes that can help to express its
              content. A data element represents a master identification and description of the
              logical need for some item of data in an organization.
        •     Data Value. Represents a discreet "instance" of a data element and is what is of most
              interest to the end user--actual data upon which processing is undertaken and
              information is derived.
        •     Data Field. The smallest unit of data that has meaning in describing information; the
              smallest unit of named data.
(U)     The logical connection between these concepts is as follows. The data element is
the object of management within a data management and standardization program. Each
data element is functionally described, together with a set of data values that are
acceptable for each standardized data element that is adopted. Thus, each data element
has a set of specified data values that an appropriate authority has deemed correct and of
interest to the organization. The data field is the physical location of an instance of a data
value within an operational database. This means that the only entities that may occupy a
data field are the acceptable data values that have been deemed acceptable for the
associated data element.




22          (U) Data is defined in ISO 2382 (and in DP 7826) as "a representation of facts, concepts, or
instructions in a formalized manner suitable for communication, interpretation, or processing by humans or
by automatic means."
                                                    18
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                    June 1989
                           Releasable for Internet transmission

         3.2 Categorization of Data Concepts
(U)      Each of the three data concepts (data element, data value, and data field) can be
categorized in two ways. The first is to distinguish qualitative data from quantitative data;
this is known in ISO as data classification. The second categorization is by data type, in
which there are traditionally six types: character string, bit string, float (or floating point),
fixed-point, integer, and boolean (logical).
(U)      The purpose of the two categories, data classification and data typing, is to provide
a common framework for discussing data concepts and to ensure data is consistently
treated and processed in software. Appendix A contains a further discussion of data
classification and data types, including the definitions of each data type.

        3.3 Data Element Concepts
(U)     A generic element is a concept of data. It is distinguished from other concepts of
data in that every generic element has a precise, well-defined set of those possible values
that the generic element can take on. This means that, whenever a value is considered, it
is always possible to determine whether that value is one permitted to be taken on by the
generic element. As an example, the term "aircraft" is a concept of data that, standing
alone, is not a generic element, since there is not a clear agreement as to the entire set of
possible values. On the other hand, a two-character country code-of-world is a generic
element commonly used in international commerce, where ISO has the responsibility for
maintaining the agreed set of values.
(U)     The term data element is used to identify those generic elements that have been
assigned an organizational context, including an organizational description of what the
data element is. For example, the concept "date" is a generic element. A related data
element "personnel information last modified date" has an organizational context. One of
the difficult problems in data management is that the distinction between generic elements
and data elements is vague and subject to interpretation.
(U)     The concepts of generic element and data element introduced above are both
constrained by needing an agreed set of acceptable values. This limitation is called a
domain. The two types of domains, specific and general, are discussed in Appendix A,
Section III.

        3.4 Data Element Alias
(U)     One of the problems in data element standardization is deciding how to handle
previously defined data elements and implementing concepts in separate systems that are
essentially the same data element. To standardize such a data element, a single data
element representation is adopted as a standard, and the other occurrences are treated as
data element aliases. A data element alias can differ from the standardized data element in
the content of administrative, representational, or administrative attributes. Such
attributes, as well as the concept of data element alias, are treated more fully in Chapter 4.




                                               19
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                  June 1989
                          Releasable for Internet transmission


4.      STRUCTURE OF DATA
(U)     The concepts discussed in this paper are taken from ANSI X3L8, Project 993T
(this work is currently being drafted as an ISO DP by Working Group 4 of ISO/JTC1, SC
14). There are differences between these concepts and related concepts in ACE Manual
96-1-4. The ISO source was taken because it specifies further the concept of data element
and its relationship to common sets of data values. This allows for the economy of scales
in data standardization, and enhances the potential for reduced data redundancy and
enhanced interoperability. ACE Manual 96-1-4 does not go far enough in defining these
concepts.
(U)     Additionally, through the use of a generic element, the structure of the data
element can be standardized on a set of values as opposed to the manner in which the data
are used. The latter approach (standardizing on use) introduces multiple occurrences into
what might otherwise be a single data element and increases the potential for data
redundancy. Indeed, when standardization on use occurs, multiple data elements can be
created for a single data element since the name of the data element will reflect how those
data are used, and not what they are. It must be emphasized that NATO standardization
must occur on structure and NOT on use of a data element. (This is, in fact, the approach
recommended by STC for ACE ACCIS: "...classification...is based on the principle of
sorting data according to the type of information provided by their values...independently
of their use." [Ref. 5]) The use of uniform structures eliminates the problem mentioned
above, and improves communications and interoperability since there is a common data
foundation. This foundation does not require systems or individuals to use a "translation"
or "bridge" to interpret the contents of a data element or group of data elements, as in an
IER.

         4.1 Generic Element
(U)      A generic element is a structure in data management that is used to specify a set of
data values. Such a set can be used to support several data elements. A common set of
values can be used by many different data elements that identify what different things are
in relation to the real world or organizational environment. In other words, a generic
element has no organizational reference associated with its structure. As an example, the
data value for COUNTRY CODE OF WORLD "FR" has no context in and of itself--one
can assume it stands for France--but there is no understanding of what it represents in an
organizational reference. Contexts of such a generic element could be geographic,
political, biographic, or economic, as well as military. Thus, the code structure can be
used in many contexts to form different data elements, while still conforming to a single
agreed to structure.
(U)      The generic element is specified by a collection of attributes that convey the
technical information associated with a given generic element. These attributes are
divided into three categories: administrative, relational, and representational. The
administrative attributes address the descriptive type of information about the generic
element. The most important attribute is the name of the generic element, which is
unique and structured for identification purposes. (A full discussion of the naming of the
generic element and data element is provided in Chapter 6.) The relational attributes give
information about the generic element's connection to a controlling organization or
agency. The representational attributes identify information about a common set of data
values.
(U)      Figure 1 illustrates the structure of a generic element. It shows that a generic
element is composed of three types of attributes. One of these attributes will be its name.
                                             20
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                  June 1989
                           Releasable for Internet transmission

A proposed set of attributes for generic elements has been compiled from various national
and international documents. These attributes are discussed in Chapter 7.


                                          Generic
                                          Element




         Administrative                    Relational                 Representational

     RPW-2-1-89-1


                                        UNCLASSIFIED
             Figure 1. (U) Generic Element Structure--A Collection of Attributes

(U)     There are two constraints that need to be imposed on generic elements. These
constraints are designed to assist in the standardization process and help maintain data
integrity. These two constraints are:
        (1) A generic element is unique to a single concept.
        (2) A generic element's set of values will not be a subset of the values that have been
            enumerated by another generic element.

         4.2 Data Element
(U)      A data element, as previously defined, represents what an object is and determines
the organizational context of a generic element. In other words, the structure specified in
the generic element is formulated into a data element that identifies what that data element
is in relation to the real world. This identification process is based on the "what it is"
aspect of the data and not on "how I am going to use it." To continue with the "country
code" example, if a data element were constructed to code the members of the ATCCIS
Working Group Nations, "FR" could be used as data value for an ATCCIS Working
Group Country Code-of-World. The generic element "Country Code-of-World" provides
a common structure for country codes, and this instance of the data element identifies the
particular members of a SHAPE body.
(U)      The data element, like the generic element, is specified by a collection of attributes
that convey technical information. When the data element is constructed, attributes are
added to those of the generic element to form a complete identification and description of
the data element. Data element attributes are also divided into three categories:

                                               21
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                     UNCLASSIFIED                                    June 1989
                                 Releasable for Internet transmission

administrative, relational, and representational. As before, the administrative attributes
address the descriptive type of information about the data element, and the most important
attribute is the name of the data element that is unique and structured for identification
purposes. (A full discussion of the naming conventions for both the data element and
generic element is provided in Chapter 6.)
(U)     Figure 2 illustrates the structure of a data element. The figure shows that the data
element includes all the attributes of the generic element to which it is associated. A
proposed set of attributes for data elements has been compiled from various national and
international documents. These attributes are discussed in Chapter 7.



                                            Data
                                          Element




                                                                                        Additional
                                                                                        Attributes




                                                                                         Generic
                                                                                         Element
                                                                                        Attributes

        Administrative                     Relational              Representational


    RW-1/27/89-2




                                              UNCLASSIFIED
                                Figure 2. (U) Data Element
(U)     There are a few constraints that need to be imposed on data elements. These
constraints are designed to assist in the standardization process and help maintain data
integrity. The constraints are:
        •          A data element's values will not be a subset of the values that have been enumerated
                   by another data element.
        •          A data element's values will either be the same set or a subset of the generic
                   element's values used to structure the data element.
        •          Data elements that are derived through chaining, computation, or calculation should
                   be treated as any other data element.
        •          Multiple uses or "ordinal representations" of a data element will not be approved as
                   separate standards. As an example, personnel data elements often capture the
                   successive dates of the first, second, third, etc., occasion that the same award is
                   presented to a soldier. These would be designated a single data element, which could
                   be used several times, as opposed to creating three or more different data elements.


                                                        22
                                       NATO UNCLASSIFIED
                                 Releasable for Internet transmission
WP 7L                                  UNCLASSIFIED                                 June 1989
                              Releasable for Internet transmission

        4.3 Data Element Alias
(U)     A data element alias is used to identify data elements in use in a specific
information system at a specific location. Data elements that are aliases differ from
standard data elements in one or more of the attributes that have been specified for the
standardized data element. Often, the differences will be in the name, the description, the
set of data values, or other representational attributes. This mechanism is used to bridge
current national data elements in fielded information systems to the proposed or actual
CCIS data element standards, when and if differences exist. As information systems are
redesigned, the use of the data element alias should be eliminated in order to facilitate cost
reduction and facilitate communications in a coalition warfare environment.
(U)     Figure 3 illustrates the structure of a data element alias. It shows that some of the
attributes of the data element alias can differ from its associated data element. As an
example of an alias, assume the US "UNIT IDENTIFICATION CODE" had a slightly
different structure from the one specified in STANAG 5621; in this case,23 the US data
element "UNIT IDENTIFICATION CODE" would be made an alias to the NATO
standard. In the alias specification the differences would be explicitly identified.
(U)     A proposed set of attributes for the data element alias has been compiled from
various national and international documents. These attributes are discussed in Chapter 7.



     Data Element                                                            Data Element
                                                                                 Alias
                                              Differences
                                              Permitted in:

                                              Administrative
                                                Attributes




                                              Relational
                                              Attributes




                                           Representational
                                              Attributes



     RPW-2-1-89-3




                                           UNCLASSIFIED
                                 Figure 3. (U) Data Element Alias


23           (U)    This example was taken from STANAG 5621, Appendix 3 to Annex A, UNCLASSIFIED.
                                                 23
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                     June 1989
                           Releasable for Internet transmission


5. DATA MANAGEMENT GLOSSARY
(U)    A glossary is needed to ensure a consistent definition is provided for all terms used
in IERs, as well as in the specification of generic elements and data elements. This
chapter provides background, purpose, and recommendations for a NATO data
management glossary.

       5.1 Background
(U)    This chapter discusses NATO initiatives toward a glossary. An early concept, the
Common Information Exchange Language (CIEL), originally developed by ADSIA [Ref.
27] and specified in an early draft of the NIPD [Ref. 28], was disapproved by the 15th
ADSIA Plenary in 1986 [Ref. 29]. An overview of the now abandoned CIEL is provided
as background; it is followed by a discussion of the NATO Common Information
Exchange Glossary (CIEG), now known as the Glossary of Operational Terms (GLOT),
which could be incorporated into AAP-6 or published separately as AAP-25.

        5.2 Common Information Exchange Language (CIEL)
(U)     The CIEL24 was originally specified in an early draft of the NIMP to be that portion
of the NATO Common Interface Standards (NCIS) that is procedural in nature. The three
parts of the CIEL were a dictionary, a character-oriented message notation, and a bit-
oriented message notation.
        •    The data element dictionary of CIEL was the one defined for NATO in          ADatP-1
             [Ref. 14] (no longer in effect; see Section 2.2.2).
        •    The character-oriented message notation already established for NATO and included
             in the CIEL is FORMETS as defined in ADatP-3 (STANAG 5500). FORMETS
             provides a formal notation for specifying both an abstract syntax (notations used in
             applications for information transfer that does not actually determine the
             representation to be used for data element values) and a concrete syntax (the transfer
             syntax derived from the abstract syntax in a particular application using encoding
             rules).
        •    The bit-oriented message notation for CIEL was the tactical data link language of
             ADatP-5, NATO Data Link Message Standards (DALIMS) [Ref. 30, now
             abandoned]. The function of this language was to provide a means to compile
             pictures and transmit command and control orders, weapons assignment, and control
             orders in real time or near real time. DALIMS used data link message formats with
             bit encoding techniques. The goal of DALIMS was to provide a language that uses
             only standard bit fields common to all tactical data systems.
(U)      There was no formal notation or language definition for DALIMS. Separate
STANAGs25 describe the generic message structure for each of the NATO digital data
links, and this syntax differs among the various types of data links. ADatP-5 specified
rules for the definition of bit fields; it also specified some standard bit fields, bit-field
fillers, and required indices and cross-references for the fields that were used in DALIMS.




24        (U) The discussion of CIEL is taken from "CIEL Discussion Paper" [Ref. 24].
25        (U) For example, STANAGs 5501 (Link-1), 5503 (Link-3), 5504 (Link-4), 5507 (Link-7),
5510 (Link-10), 5511 (Link-11), 5514 (Link-14), and 5516 (Link 16).
                                               24
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                 UNCLASSIFIED                                         June 1989
                             Releasable for Internet transmission

Not all data links use the standard bit fields that were provided in ADatP-5, even for new
development (e.g., Link-11).26
(U)     The CIEL ideal concept was for one uniform data element dictionary, one abstract
syntax for both character and bit-oriented message structures, and three or more different
sets of encoding rules--one for character-oriented systems, one for Link-11 systems, and
one for Link-16 systems. The data element dictionary was to be converted from its current
form to a more structured form to facilitate (automatic) verification of its completeness
and integrity. Alternates considered for the single abstract syntax were FORMETS, a
modified version of FORMETS, ASN.127 (the preferred choice), or a subset of ASN.1.
More than one set of encoding rules was envisioned because the single standard set of
encoding rules for ASN.1 available today28 dictates the inclusion of type and length
information for each field and subfield each time a message is passed, whereas messages
for current NATO data links contain very little information regarding data types and field
lengths (most of the type and length data are fixed by the standard for the data link) to
improve transmission efficiency.
(U)     ASN.1 was the preferred choice of abstract syntax for ADatP-3 because ASN.1:
        •     Supports graphics and digitized voice, as well as the teletex characters that are
              supported by FORMETS.
        •     A full ASN.1 implementation would facilitate the use of commercially available
              products [since ASN.1 is the only approved ISO standard for open systems
              interconnection (OSI)].
        •     ASN.1 has all the power of data representation provided by FORMETS and greater
              flexibility in its structuring mechanism.
        •     The encoding rules are explicit and separately defined in ISO standards [the X.409
              standard of the International Telegraph and Telephone Consultative Committee
              (CCITT) for abstract syntax is the same as ASN.1, but the encoding rules are
              included in the same standard].
        •     ASN.1 does not have input/output device-dependent limitations of FORMETS (e.g.,
              separate lines may not exceed 69 characters, a field may not span a line, the group of
              fields in a columnar set may not exceed 69 characters); where such limitations are
              desired, they can be defined and enforced using data types.
The primary operational objection to ASN.1 encoding rules was that encoded ASN.1
messages are not human-readable. A review of this concern may soon take place.

         5.3 Common Information Exchange Glossary (CIEG)
(U)      The Common Information Exchange Glossary (CIEG) has been an ADSIA
initiative to harmonize the definitions of terms used in the data element dictionaries of
character- and bit-oriented (data link) messages. The need for such a common operational
vocabulary was agreed to early in 1986 [Ref. 33], and the initial CIEG was produced six
months later, based on STANAG 5511 (Link-11), STANAG 5516 (Link-16), and ADatP-3
(FORMETS). It included 1,176 items, one third without a definition and 44 with more
than one definition [Ref. 34]. The CIEG is envisioned to contain terms and definitions
applicable to both bit- and character-oriented systems [Ref. 35]. At one time, the CIEG
was envisioned to be published and released by NATO's Military Agency for

26        (U) In some cases, the number of bits per field had been decreased in order to optimize
bandwidth utilization [Ref. 27].
27        (U) Abstract Syntax Notation One, ISO 8824 [Ref. 31].
28        (U) Basic Encoding Rules for Abstract Syntax Notation One, ISO 8825 [Ref. 32].
                                                   25
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                    June 1989
                          Releasable for Internet transmission

Standardization (MAS) as a separate document, namely AAP-25 (STANAG 5650)
[Ref. 36]. Alternatively, it is possible that the work on the CIEG could be released as part
of AAP-6.
(U)     At a minimum, each entry in the Glossary will have a term, the agreed definition,
and a reference to the context in which it is used. In addition, provision is made in the
database for the GLOT to record source, reference number, broader term, narrower term,
related term, synonym, non-peer synonym, status, and rationale.
(U)     The Glossary will consist only of "operational" terms that "describe one or more
parts of a function, or the subject(s) of that function in an operational activity."
Harmonization will be performed to ensure that each term relates (uniquely) to one
definition, in the same context, irrespective of the community in which it is used. Multiple
terms for the same object or activity will be harmonized. Units of measurement will be
used only when necessary for an unambiguous definition, and acronyms will not be used,
in principle, in the definitions.
(U)     The Glossary should serve a number of purposes:
        •   Newcomers to the operational community who are supported by information systems
            will find the meaning and relationships of operational terms used in the information
            exchange to be common and preserved.
        •   Trained personnel will be able to check the meaning of an uncommon term or the
            meaning of a common term in an unusual context.
        •   ADSIA Working Groups will use the GLOT as a basis for procedural interoperability
            standardization.
        •   Common bit fields, representational terms, and conversion of terms based on the
            GLOT will be investigated for use in development of future data links and for
            consideration in the upgrade of existing systems [Ref. 36].




                                              26
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                     June 1989
                          Releasable for Internet transmission


6. NAMING CONVENTION
(U)     This section proposes a convention that can be used as a basis for naming generic
elements and data elements in a structured manner. Such a convention is needed to ensure
that those data elements that are standardized are not duplicates of other data elements and
accurately reflect the intended data representation. The convention consists of syntax and
a set of rules, both based on four types of words to be used in the names.

        6.1 Introduction
(U)     The purpose for using a naming convention is to provide a structured method by
which standard names for generic elements and data elements can be developed. In this
way, names developed in separate locations stand a good probability of having the same
name or at least one that is very similar. This is necessary to eliminate the creation of
duplicate data element standards (based on name) that have been developed for a single
data concept. A naming convention or structured approach is needed to support the
development of names to achieve this goal. Historically, the use of free-text name
development has lead to multiple data element standards for a single concept. Without the
control exercised through a naming convention, this trend will continue. The naming
convention should, in addition to being a structured approach, result in a name that is
pseudo-readable to the user. This means that even though the name conforms to a
convention and may suffer some awkwardness in word flow, it must be readable to the
user. The user must be able to derive the basic meaning of the data element by looking at
the name. This type of feature is necessary to facilitate the use of data element standards
for their intended purpose--the support of communication and interoperability.
(U)     The proposed convention is based on standards emerging from the National
Institute of Standards and Technology (NIST) [Ref. 19] that are expected to be offered to
ISO in the near future. These conventions differ in many respects with the "OF-
Language" convention recommended by SHAPE for data management and for use in ACE
ACCIS [Ref. 5, 6]. The conventions recommended here are richer and are not based on a
proprietary standard. The "OF-Language" alternative is discussed at the end of this
Chapter and in Appendix D.
(U)     Some of the guiding principles to be followed when naming conventions are
developed and evaluated for adoption are [Ref. 19]:
        •   Clarity. Names are as clear and readable as possible. Ideally, they are immediately
            obvious to the casual user.
        •   Brevity within uniqueness. Names are as short as possible while still retaining
            meaning and uniqueness within the CCIS data structures (e.g., database). Conflicts
            between brevity and clarity are resolved in favor of clarity.
        •   Conformance to rules of syntax. Each name is in the proper format. Waivers, if
            granted, are used sparingly. The degree of specificity of format rules will drive the
            frequency of waiver requests.
        •   Context-freedom. Each entity is considered discretely from all others. The name
            references the logical structure, but is as independent as possible from the physical
            structure of the data and from other data entities. For example, the name of a data
            element derived from a report does not contain the name of or reference to the report.
            Relationships and other information documented in the data dictionary for an entry
            are not part of the name.



                                              27
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                    June 1989
                           Releasable for Internet transmission

        6.2 Definitions
(U)     The are four types of words used in the structured naming of generic elements and
data elements. These are defined below:
        •    Class Word (CW). A word used to specify the type of information contained in a set
             of data values.
        •    Modifier (M). A word that helps to refine, describe, or render a name unique for a
             data element, which is not designated a prime or class word. An architectural
             modifier (AM) is a special type of modifier for data elements that provides the
             logical connection between the data element and an organization's data architecture
             or data model.
        •    Prime Word (PW). A word used in a data element name that represents the data
             grouping to which the data element belongs.
        •    Qualifier (Q). A word used with a class word to further describe a characteristic of
             the information within a common set of data values.

       6.3 Syntax for Naming Convention
(U)    Structured names are needed for both generic elements and data elements. The
syntax recommended in this Working Paper and described in this chapter is based on the
U. S. National Institute of Standards and Technology (NIST) Special Publication 500-149
[Ref. 19]. The general syntax of the data element name is as follows:
                                     M:PW:M:CW:Q
where M represents a modifier, PW represents a prime word, CW represents a class word,
and Q represents a qualifier. Section 6.6 explains this naming convention in more detail,
including the restrictions and numbers of each type of word that is permitted.
(U)    The next two sections show how this syntax can be used to support the structure of
generic elements and data elements with names that conform to the needs of an effective
data management and standardization program.

         6.4 Generic Element Name
(U)      Each data element consists of the following: a structured name; information about
administrative aspects of the element; a set of data values and structural information; and
information about the element's relationships to other objects. A data element name is
assigned organizational context through the use of a prime word and some modification
words. The grouping of words is called a prime term and is discussed in Section 6.5.
(U)      A structured name is given to a generic element based on a class word that
represents a logical grouping of data values. The generic element name should accurately
reflect the intent of a data value set and its associated structure. The generic element name
further identifies the set of values that can be attached to a data element as in the case of a
specific set (i.e., as in the country code example). Its name consists of an optional
modifier, a class word, and up to two optional qualifiers. The general format is:

   GENERIC ELEMENT NAME               = (Modifier) + Class Word + (2) Qualifier(s)
                                      = M : CW : Q
(U)   Figure 4 illustrates the structure of the generic element name. The following are
examples of generic element names: DATE; DATE-TIME-GROUP; NAME.




                                               28
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                  UNCLASSIFIED                                 June 1989
                              Releasable for Internet transmission

                                    Generic Element
                                        Name
                                       (M)       : CW : (Q)
                                      Optional            Optional



                                       Class Word


                     Modifier                               Qualifier(s)

               RPW-2-1-89-4

                                         UNCLASSIFIED
                              Figure 4. (U) Generic Element Name


        6.5 Data Element Name
(U)     The structured name of a data element is composed of two components: a prime
term and a generic element name. The prime term is composed of a prime word that may
be further modified to construct a name that is representative of "what" the data element is
purported to represent. Composition of the name takes the general format:

               DATA ELEMENT NAME = AM : M : PW : M : CW : Q, where
                        PRIME TERM = AM : M : PW : M
                        GENERIC ELEMENT NAME = M : CW : Q

           AM =       Architectural Modifier--one required
            M =       Optional Modifier(s)- maximum of four in the Prime Term and one
                      in the Generic Element Name
          PW =        Prime Word--one required
          CW =        Class Word--one required
           Q =        Optional Class Word Qualifier(s)--maximum of two.
(U)   Figure 5 illustrates the structure of a data element name. An example of a data
element name conforming to these conventions is:29




29          (U) This example was taken from STANAG 5621, Appendix 3 to Annex A; however, most of
the data element names cited in STANAG 5621 do not follow the conventions cited in this section.
                                                 29
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 7L                                     UNCLASSIFIED                                    June 1989
                                 Releasable for Internet transmission

                                    DATA ELEMENT NAME

            Prime Term                                                  Generic Element
      (Organizational Context)                        plus                   Name

      AM*        : (M) : PW        : (M)
                  Optional         Optional
                                                                           (M) : CW : (Q)
                                                                          Optional   Optional

                                              *                           Class Word
        Architectural Modifier


                             Modifier(s)                     Modifier                Qualifier(s)

 A Prime Word (PW)
 is designated in
 one of the modifier
 positions.

 * The Architecture Modifier may also be the Prime Word.
  RPW-2-1-89-5

                                   Figure 5. (U) Data Element Name



                                                  UNCLASSIFIED

         ALLIED COMMAND EUROPE UNIT IDENTIFICATION CODE

(U)     A prime term (e.g., ALLIED COMMAND EUROPE UNIT IDENTIFICATION)
identifies and represents the object or relationship between objects about which a
organization wishes to maintain information. It has the form: AM:M:PW:M. Here,
"ALLIED" is the architectural modifier, "COMMAND" and "EUROPE" are modifiers,
"UNIT is the prime word, and "Identification" is a modifier. In general, an object is
represented by a prime word, preceded by one architectural modifier and optional
modifiers, and followed by additional optional modifiers that further define what the
object is in relation to the organization. In the prime term:
         •       The prime word (e.g., UNIT) should be positioned in front of the class word (i.e., in
                 front of the generic element name) and within the prime term.
         •       The architectural modifier (e.g., ALLIED) provides the logical connection between
                 the data element and an organization's data architecture or data model. The
                 architectural modifier should be the first word in the data element name and may also
                 serve as the prime word for the data element name if so desired. Architectural
                 modifiers should appear on the prime word list; however, not all prime words are
                 architectural modifiers.
(U)     The generic element name (e.g., CODE) identifies a grouping of similar data
values, which has been classified for use with a data element.

        6.6 Rules for Naming Convention
(U)     The naming rules apply to the construction of standard element (generic element or
data element) names for CCIS information exchange requirements. The rules should also
be applied to reconstruction of names of existing data elements for registration in an
                                                       30
                                       NATO UNCLASSIFIED
                                 Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                    June 1989
                          Releasable for Internet transmission

appropriate repository or encyclopedia. A restructured existing data element name not
registered as an approved CCIS data element should be carried as an alias. Thus, when
information sharing and compatibility are required across two or more CCISs, data
element names will adhere to the same principles and structural rules. In this way,
common data elements can be identified. There should be no alteration to the principles
and structural rules that are adopted, so that a high degree of standardization can be
achieved and data redundancy can be eliminated.
(U)     The following rules apply to the naming and formulation of generic element or
data element names:
        •   Rule 1: Each generic element name will contain one and only one class word.
                  Comment: By restricting the generic element name to one class word, the
                  standard element is formulated to describe only one type of information
                  collected about an object.
        •   Rule 2: Class words will be reserved (i.e., they will not be used as modifiers,
            qualifiers, or prime terms).
        •   Rule 3: Each data element name will contain one prime word and describe only one
            concept.
                  Comment: By requiring a data element name to have one prime word, the
                  data element is formulated to explicitly describe only one concept.
        •   Rule 4: The sequence of words in a data element name will be in the following
            format: Modifier(s) (if required), Prime Word, Modifier(s) (if required), Class Word,
            Qualifier(s) (if required).
                  Comment: Optionally, a class of modifiers, called architectural modifiers,
                  may be defined to provide a logical connection between a data element and a
                  data or information model. When used, these must be the first modifier in the
                  prime term.
        •   Rule 5: Each data element name will include its related generic element name.
        •   Rule 6: Plurals of class words or prime words are not permitted.
                  Comment: Removing plurals from data element names encourages the
                  designer to think in terms of primitive concepts and increases the possibility
                  that two people will develop the same name to describe identical concepts.
        •   Rule 7: Modifiers and qualifiers will be used to fully describe a standard element
            (five modifiers per prime word and one modifier plus two qualifiers per class word).
                  Comment: An architectural modifier is counted as one of the modifiers for the
                  prime term.
        •   Rule 8: Word order of commonly used terms will be preserved in data element alias
            names (e.g., Port of Debarkation, Ministry of Defence).
        •   Rule 9: A unit of measure suffix will be applied to the names of all elements that
            describe a numeric quantity (e.g., Volume-in-Litres).
        •   Rule 10: No abbreviations or acronyms are permitted in a standard element name.
                  Comment: Abbreviations and acronyms detract from the clarity of a standard
                  element name.
        •   Rule 11: Only alphabetic characters (A-Z, a-z) are permitted in a standard element
            name with two exceptions.
            (1)   A hyphen may be used to connect the words in a prime term or generic
                  element name.

                                              31
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                                    UNCLASSIFIED                                    June 1989
                                Releasable for Internet transmission
              (2)       A number may be used when it is part of a descriptive name (e.g., M109A3
                        Howitzer).
                        Comment: By permitting only alphabetic characters, standard element
                        developers are encouraged to describe standard element names in terms of
                        what the data is and not how it is stored or used. This rule also improves the
                        probability that different people will develop the same name for identical
                        standard elements.
        •         Rule 12: Names of organization, computer, or information systems, directives,
                  forms, screens, or reports are not permitted in standard element names.
        •         Rule 13: Titles of blocks, rows, or columns of screens, reports, or listings are not
                  permitted in standard element names unless those titles satisfy Rules 1-11.

        6.7 Relation of Recommended Naming Convention to Other Standards
(U)     The Information Resource Dictionary System (IRDS) [Ref. 37] is an emerging
standard for formally describing data. The structure for assigning names in IRDS provides
for three different kinds of names for data entities, and the convention recommended for
ATCCIS is consistent with IRDS. The IRDS structure supports:
        •         A single Access-Name, serving as the primary, unique identifier of the data entity. A
                  data dictionary entity has only one Access-Name. The convention recommended in
                  this Working Paper for ATCCIS provides for the Access-Name as an attribute of
                  each data element, "INFORMATION DATA ELEMENT MNEMONIC
                  ABBREVIATION" (see Appendix E, Section 2.1).
        •         An optional Descriptive-Name, normally longer and serving the same function as the
                  Access-Name. The Descriptive-Name corresponds to the data element name defined
                  in this Chapter for ATCCIS.
        •         Optional Alternate-Names, providing functional attributes of the entity; they are not
                  unique and serve as aliases. The concept of data element alias provides this function
                  in the convention recommended for ATCCIS.
(U)    Several options are defined in the NIST recommendation [Ref. 19, Section 5.1] for
naming conventions. Two of these options are included in the convention described in this
chapter and recommended for ATCCIS. The remaining option was omitted, since it puts
both the class word and prime word as the the leading terms for a data element and is
therefore the least readable of the three options. Note that NIST convention applies to the
term "Access-Name"; this convention has been extended and applied to both generic
elements and data elements.
(U)    In its discussion of data terminology,30 AM 96-1-4 discusses only one naming
convention, the so-called "OF-Language," and recommends it for adaption, as appropriate,
in ACE. Appendix D contains a short description and some examples for the use of the
"OF-Language" naming convention.
(U)    The use of the "OF-Language" naming conventions to support the naming of data
elements has three major faults. These restrictions render its use undesirable. These faults
are:
        •         First, the "OF-Language" is based on the premise that standardization is to be
                  accomplished on the use of data elements vice the structure of the data element. In
                  previous discussions it has been shown that standardization based on use is
                  counterproductive to the aim of interoperability. The synonymic and homonymic


30          (U)     "Data Terminology," Annex A, AM 96-1-4 [Ref. 6], Section 1.L.
                                                    32
                                      NATO UNCLASSIFIED
                                Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                    June 1989
                          Releasable for Internet transmission
            issues that arise based on data usage, create a potential redundancy and
            incompatibility of data that will not support the relatively free flow of information
            implied in the NIPD definition of Degree 5 or 6 interoperability.
        •   Second, the "OF-Language" is a psuedo-symbolic representation for a data element
            name. This makes the syntax difficult for the average user to read and comprehend.
            The more text oriented the name development, the greater is the potential for
            successful implementation. Data standardization for interoperability, or any purpose
            for that matter, must be functionally based. This means the functional experts must
            decide on the material content and naming of the data elements. Only in this way
            will the required meaning be placed in the correct context to support efficient and
            effective use of Information Exchange Requirements.
        •   Lastly, the "OF-Language" is perceived as a proprietary-based convention due to its
            conceptualization and development by the IBM Corporation to support IBM
            hardware. This proprietary aspect of the language makes it highly suspect in an
            ATCCIS environment that is seeking to identify and develop non-proprietary
            standards to answer near-term and future command and control issues.




                                              33
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                 June 1989
                          Releasable for Internet transmission


7. ATTRIBUTE LIST
(U)      As discussed earlier in the paper, within the concept of data, each of the three
elements identified to support data management--generic element, data element, and data
element alias--is a collection of attributes. These attributes qualify or characterize the
distinct features of each element. In order to achieve data management in the
environment, a set of attributes will have to be selected as a minimum set, on which to
base such activities. This selected set will enable the operators of ATCCIS conformant
systems to collectively identify, store, communicate, and manipulate data from a common
point of reference. This does not imply that the physical storage in national systems will
have to change based on these attributes; rather, to facilitate the communication of IERs
(from the data element perspective), a common point of reference must be established.
(U)      The attribute list provided in Appendix E has been prepared as a suggested starting
set. Each attribute has been named in accordance with the naming conventions proposed
earlier in the paper and is accompanied by a definition. To achieve data management,
such a list will have to be compiled, along with definitions and more technical details of
what the physical manifestation of each attribute will look like for storage purposes.
(U)      The attributes have been broken down by element and, within each element, by
those that are administrative, relational, and representational. See Appendix E for the
listing.




                                             34
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                    June 1989
                           Releasable for Internet transmission


8. DATA MANAGEMENT POLICY AND PROCEDURES
(U)     This is a proposal for addressing the requirements in CCIS data management in the
area of policy and procedures.

        8.1 Introduction
(U)     This chapter contains an approach for the procedural standards for CCIS data
management, including development, documentation, review, approval, implementation,
and archiving for generic elements, data elements, and data element aliases. The term
"standard element" is used when more of these three types of elements is being referenced
and to simplify discussion.
(U)     ACE Manual 96-1-4 describes in some detail the responsibilities of CCIS data
administrators and database administrators. The other personnel referenced below are:
information class proponent, data encyclopedia administrator, standard element developer,
and ACE (ATCCIS) data manager. The roles of these personnel are described in the
sections that follow.

        8.2 Standardization Procedures for Data Elements and Other Standard
               Elements

                8.2.1    Identifying Data Element Requirements
(U)     Data elements and other standard elements required to support CCIS applications
are identified during the life cycle phases of an information system. The identification of
standard elements should be done in the early phases of a system's life cycle. The system
developer or the system's functional proponent should compare these standard elements to
existing standard elements in a CCIS data encyclopedia to determine if existing standard
elements can satisfy the data requirement of the application. When standard elements are
found that meet the requirement, documentation from the encyclopedia should be
incorporated into systems design documentation (e.g., data requirements document). If no
standard element is found or a change is required to an existing standard element, the
standardization process must be initiated.

                8.2.2    Data Standards Considerations for Information Systems
(U)    The following considerations apply throughout the life cycle of any information
system:
        (1) Data Documentation. A CCIS data encyclopedia should be used as a source for
            producing data documentation for information system design documents. Using a
            CCIS data encyclopedia ensures that data documentation remains consistent CCIS-
            wide in whatever information system it may be used.
        (2) Reviews. Organizational data administrators should participate in design reviews,
            technical walkthroughs, and CCIS design tests to ensure that standard elements are
            actually being incorporated into the technical design.           Organizational data
            administrators and database administrators will participate in software qualifications
            tests to ensure that data standards are being used as intended.
        (3) Application Program Development Support. Organizational data administrators and
            database administrators should provide documentation and advisory services that
            assist with software development efforts to ensure that data are independent of the
            application programs being developed. Specifically, organizational level data
            administrators and organizational level database administrators should:
                                               35
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                  UNCLASSIFIED                                           June 1989
                              Releasable for Internet transmission
              (a)    Support the development effort by using a CCIS data encyclopedia to locate or
                     generate standard elements for use in command and control information
                     systems.
              (b) Encourage system developers to use data starvation techniques to delay binding
                  time31 between application program and databases. Data starvation is the
                  avoidance of explicitly declaring data structure definitions within the application
                  program. The program is coded to rely on dictionary look-ups at execution
                  time. The longer the binding time is delayed, the more predisposed the software
                  will be to adapt to changes in the data.
              (c)    Assist standard element developers in installing standard elements, element
                     changes, and version updates.
              (d) Use a CCIS data encyclopedia to manage change and version updates, as well as
                  make new data representations available to users, in support of application
                  program testing.

                    8.2.3   Status of Standard Elements
(U)     Each standard element will have a standardization status: candidate element,
approved element, installed element, or archived element. Each status marks the progress
of the element through the data standardization process. The possible standardization
status states for a standard element are:
        (1) Candidate Element. This is the status assigned to a data requirement that has been
            identified, defined, and submitted to the appropriate organizational data administrator
            for review. A candidate element can include a generic element, a data element, a
            data element alias, or a change to an existing standard element.
        (2) Approved Element. Candidate elements that have passed functional and technical
            reviews are upgraded to approved elements. Data values based on approved
            elements may be used for development. The Information Class Proponent must
            assign and coordinate organizations authorized to supply data values, define access
            requirements, and specify a CCIS-wide installation date for each approved element.
            Once data elements have an installation date, there can be no further changes to the
            element.
        (3) Installed Element. On the assigned installation date, an approved element is
            upgraded to an installed element.          Databases will have been modified to
            accommodate the actual data values based on the newly installed element, and
            affected information systems must then operate using updated versions of the
            databases. Organizations authorized to supply data values will commence their
            responsibilities for entering and maintaining the data in the databases required to run
            in accordance with the installed element. After the installation date is assigned, the
            standard element will be used.
        (4) Archived Element. Installed elements become archived elements when they no
            longer support a data requirement. The archived element and its associated attributes
            will be retained in the CCIS data encyclopedia for a period of time required by
            NATO policy or as established by the CCIS data encyclopedia administrator. These


31          (U) In this context, binding time refers to the time in the system development process that the
system designers are provided detailed information about the databases to be incorporated into the system.
Until the binding time is reached, the developer must retain a high degree of independence between the
application software and the attributes of the data to be used.
                                                    36
                                    NATO UNCLASSIFIED
                              Releasable for Internet transmission
WP 7L                                UNCLASSIFIED                                    June 1989
                            Releasable for Internet transmission
             retained standard elements will be used to assist with compiling or recovering
             information that spans several versions of the CCIS data encyclopedia.
        (5) Non-Standard Element. Those information systems and application programs not
            using standard elements will bear the cost of data conversion for any necessary
            transmittal to standard information systems and databases. Systems using non-
            standard elements must be modified or bridged to the standard. The non-standard
            element will be registered in the CCIS data encyclopedia as an alias to the
            appropriate current standard element.

        8.3 Life Cycle for Standard Elements
(U)     To control standard elements, organizational data administrators must actively
incorporate the disciplines of life cycle management. The standard element life cycle
reflects four phases necessary to define, approve, implement, assess, and review standard
elements.

                  8.3.1   Phase 1--Element Requirements Definition
(U)     Detailed data requirements definition occurs during the definition and design
phases for information systems development life cycle. The following are the major
activities for Phase 1:
        (1) Standard Element Development. If a standard element does not exist, the required
            set of attributes for the new element must be documented and submitted for
            standardization to the information class proponent. The organizational data
            administrator assists the requirements developer in reviewing the current inventory of
            CCIS standard elements to determine whether or not a standard element exists that
            suits a specific information requirement. In order to determine the specific set of
            attributes to document, standard element developers must consider the following
            possibilities:
            (a)    For a candidate generic element: When the data requirement cannot be satisfied
                   by an existing generic element, the Standard Element Developer must develop a
                   candidate generic element that will satisfy the requirement. A candidate generic
                   element may represent a change to an existing generic element or an entirely
                   new generic element.
            (b) For a candidate data element. After searching the current inventory of CCIS
                standard elements and no data element is found that meets a particular
                information requirement, the requirements developer must submit
                documentation for a candidate data element. This documentation will contain
                the information necessary to satisfy the attributes for the element.
        (2) System Control Data. Data elements will not be standardized if they are designed
            only to make system inputs or outputs more appealing, are primarily syntax or
            semantics related, or if they have no particular significance to CCIS missions and
            goals. Standard element developers will not categorize data elements as system
            control data in order to avoid standardization requirements.
        (3) Candidate Element Documentation Submission
            (a)    Organizational data administrators will review standard element documentation
                   from requirements developers in their area of responsibility and in accordance
                   with guidance from their chain of command. These developers will submit
                   elements for coordination and review in order to begin the review and approval
                   phase (Phase 2). At this time the status of the element changes from proposed to
                                                37
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 7L                                UNCLASSIFIED                                        June 1989
                            Releasable for Internet transmission
                   candidate. The elements are submitted through the standard element approval
                   channel. Review is facilitated by use of a CCIS data encyclopedia.
            (b) To ensure expeditious and timely approval of data elements for use, candidate
                elements will adhere to guidance provided ADSIA.

                  8.3.2   Phase 2--Review and Approval for Candidate Elements
(U)     The following are the major activities for Phase 2:
        (1) Organizational Data Administrator Review. The organizational data administrators
            will review the documentation submitted on candidate elements to ensure that the
            documentation meets documentation standards prescribed in ADSIA guidance. As
            part of the review and validation process, organizational data administrators will:
            (a)    Facilitate the coordination of candidate elements at their level of command to
                   ensure proper staffing with the functional and technical personnel in their area
                   of responsibility. The CCIS data encyclopedia administrator will provide advice
                   to the organizational data administrator on technical considerations as
                   appropriate.
            (b) Facilitate the coordination of candidate elements with subject matter experts
                who will validate the functionality of the candidate standard element.
            (c)    Coordinate with the likely users of the candidate standard element.
            (d) Compare a candidate standard element to existing standard elements to ensure it
                does not already exist.
            (e)    Review the collection of attributes completed by the requirements developer to
                   confirm the completeness of the information submitted.
            (f)    Verify that the candidate element is assigned to the appropriate information
                   class.
            (g) Forward recommended candidate element to the NATO Information Class
                Proponent.
        (2) NATO Information Class Proponent Functional Review:
            (a)    The NATO Information Class Proponent should ensure consistency of elements
                   among related development projects and with existing standard elements. This
                   includes resolving differences in documentation for the same candidate element
                   and staffing with interested users the positions taken.
            (b) When reviewing candidate standard elements, NATO Information Class
                Proponents will consider STANAGs, directives, and associated regulations,
                along with security classification and operational security.
            (c)    To effectively eliminate the possibility of redundancy or inconsistency, the
                   NATO information class proponent will ensure that naming conventions as
                   prescribed in Chapter 6 are properly applied. Each data definition describes
                   what the data element is, represents only one concept, and supports both the
                   element name and the set of data values. The NATO information class
                   proponent will coordinate with the CCIS data encyclopedia administrator to
                   receive and resolve the results of the technical review.
            (d) To ensure that candidate standard elements support the CCIS missions and goals
                and that they are more generally applicable across the CCISs, the NATO
                information class proponent will review the candidate to:

                                                38
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                        June 1989
                           Releasable for Internet transmission
                  -    Verify that the candidate element does not duplicate an existing standard
                       element.
                  -    Verify the regulation, publication, bulletin, or other document that
                       authorizes use of the candidate standard element, when applicable.
                  -    Verify that the candidate standard element supports information
                       requirements from a CCIS-wide perspective.
                  -    Determine the criteria for accessing the data. Access ranges from
                       "available to all" to "private." Access is determined by NATO or other
                       policy, functional need, and security requirements.
                  -    Designate the office(s) or person(s) who are authorized to enter data values
                       into a data element within a database or information system.
                  -    Designate the office or person who will be the functional expert for
                       defining, reviewing, and updating the candidate standard element and its
                       attributes.
                  -    Determine whether the requested access privilege conflicts with previously
                       established access privileges.
                  -    Resolve conflicts in usage and responsibility where necessary.
        (3) CCIS Data Encyclopedia Administrator Technical Review. The CCIS data
            encyclopedia administrator will conduct a concurrent technical review of the
            candidate element for its adherence to CCIS policy and guidance. This includes such
            considerations as reviewing field types and sizes; the CCIS-wide impact of adopting
            the candidate standard element; the proper use of naming conventions; and whether
            the candidate standard element name is a proper reflection of the definition. If a
            candidate standard element fails the technical review, the encyclopedia administrator
            will make the necessary recommendations to the NATO information class proponent
            to bring the candidate standard element into technical compliance. As a minimum
            the technical review will look at the following aspects of the candidate element:
            (a)   Conformance to appropriate provisions of NATO and other applicable
                  international standards
            (b) Proper application of naming conventions, as prescribed in Chapter 6
            (c)   Cohesive data definitions (i.e., the data definition does not represent more than
                  one concept and supports both the standard element name and the set of data
                  values).
        (4) NATO Information Class Proponent Approval. The NATO information class
            proponent will approve or disapprove a candidate standard element pending the final
            technical review by the CCIS encyclopedia administrator. If the candidate element
            passes the reviews, the NATO information class proponent will approve it as an
            approved standard element.
        (5) Adjudication. The ACE (ATCCIS) Data Manager resolves disputes among NATO
            information class proponents for ATCCIS and the CCIS data encyclopedia
            administrator concerning candidate standard element approval, installation, and
            archiving. When other resolution efforts fail during the review and approval phase,
            the ACE (ATCCIS) Data Manager performs the role of arbitrator. The ACE
            (ATCCIS) Data Manager will review recommendations, consider any grievances,
            and render final decisions.


                                               39
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                UNCLASSIFIED                                     June 1989
                            Releasable for Internet transmission
                8.3.3    Phase 3--Implementation of Approved Elements
(U)     Once candidate standard elements become approved elements, the CCIS data
encyclopedia administrator will identify maintenance that needs to be performed on
existing data structures and specify how updated values for the approved standard element
are to be distributed.
(U)     In those CCIS databases and information systems that require a direct data
exchange, an installation date will be specified for each approved standard element. This
is the date after which the approved standard element becomes installed and use of a
standard element is mandatory in partitioned and replicated databases, applications, and
reports. It is also the date by which implemented ATCCIS conformant databases must
have been changed or the required aliases have been entered into the encyclopedia. Where
the change applies to a manual portion of a CCIS with no automated interface, the new
standard element will be phased in as the current shelf stock of forms is depleted. Forms
will be redesigned to use the installed standard element.

                8.3.4    Phase 4--Assessment and Review of Standard Elements
(U)    During assessment, organizational data administrators will conduct audits of data
being maintained in databases and information systems to ensure data quality and track the
usage of the data to determine whether collection and maintenance of the data is
considered to be worth the cost. Assessment results will be made available to NATO
information class proponents and users for use in performing data management
responsibilities. The following are the major activities for Phase 4:
        (1) Verification. After the installation date of an approved standard element, the CCIS
            data encyclopedia administrator will verify that the standard element has been
            physically added to the databases and information systems that are new or have been
            modified, and which are required to run CCIS. The results of the installation review
            will be provided to the system development team involved. Problems encountered
            will be addressed based on the criticality and priority of each problem.
        (2) Monitoring. Organizational data administrators will maintain an ongoing effort to
            measure and evaluate the use of data by databases and ATCCIS Applications, and to
            monitor the environmental changes affecting performance.                  Measurements
            established for those standard elements of the databases required to run the CCIS that
            are deemed critical (e.g., response time, line traffic, mean time-to-failure, mean time-
            to-recover, adherence to procedures) will be monitored and evaluated regularly, and
            historical information kept so that trends can be observed and, whenever possible,
            problems can be avoided or minimized.
        (3) Evaluation. Organizational data administrators will determine if data is being
            exchanged across databases, ATCCIS Applications, and functional lines. Projected
            activity in databases and information systems will be compared to actual activity.
            All recovery, security, and synchronization procedures and processes will be
            monitored to ensure that they actually function as designed.
        (4) Standard Element Archiving.        The CCIS data encyclopedia administrator
            recommends to the ACE (ATCCIS) Data Manager the archiving of any standard
            element that is no longer needed and whose maintenance and management cost may
            exceed its utility. Consideration must be given to use of the standard element in
            manual systems, forms, reports, messages, and supporting publications. Standard
            elements nominated and approved for archiving will be maintained as archived
            standard elements in the CCIS data encyclopedia for a period of time as prescribed

                                                40
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                     June 1989
                           Releasable for Internet transmission
             by NATO. Recommendations for archiving will follow the information management
             approval channel as specified in the candidate standard element approval phase.

        8.4 Enforcement of Standard Elements
(U)     Standard element enforcement procedures should be worked out by agreement
within the NATO nations. The exact specification of these procedures, as well as the
policy they support, are the responsibility of the NATO nations that participate within
ATCCIS. However, to be effective, a data management and standardization effort must
have the responsibility and authority to accomplish the task. The enforcement of
standards is critical to the success of the standardization effort. Due to the sensitive nature
of these types of rule-penalty relationships and their importance, none will be proposed
here and their determination will be left to the appropriate NATO body.

        8.5 Exemptions and Waivers
(U)     Exemptions and waivers will be granted only in exceptional situations. The overall
success of the data management program depends on how effectively these exemptions
and waivers are handled. Neither exemptions nor waivers will be granted for new
databases or information systems merely because nonstandard data are currently being
used in databases and information systems with which the new database or information
system must interface. Neither exemptions nor waivers are permanent. Procedures for
exemptions and waivers are as follows:
        (1) Exemptions are approved where compliance with a standard element is either
            impossible or extremely impractical. Exemptions are re-evaluated by the ACE
            (ATCCIS) Data Manager at least biannually.
        (2) Waivers are approved for a specific period of time and are automatically revoked at
            the end of that time period. The maximum time period that can be specified for a
            waiver is 90 days (or some other period agreed to). Waivers may be granted in areas
            where previously established priorities preclude compliance with a standard element
            within the time frame specified.
        (3) Requests for exemptions and waivers will be submitted in writing through data
            management channels to the CCIS data encyclopedia administrator and must contain
            complete supporting information that will assist in evaluating requests. The CCIS
            data encyclopedia administrator will evaluate the request, recommend to the ACE
            (ATCCIS) Data Manager approval or denial of exemptions and waivers, and advise
            the requester of exemption and waiver decisions. Requests for back-to-back waivers
            will be forwarded for decision. The written request must contain the following
            information:
            (a)   Type of request (i.e., exemption or waiver)
            (b) Name of the CCIS database or application for which the request is written
            (c)   Names of the standard elements for which the waiver is requested
            (d) Names of the nonstandard elements currently being used
            (e)   Reasons for not implementing the standard elements.
        (4) The CCIS data encyclopedia administrator will maintain records to identify all
            exemption and waiver requests as a suspense control for re-evaluating exemptions
            and assuring that compliance with standard elements is achieved.
        (5) Organizational data administrators will receive a copy of each exemption and waiver
            granted.

                                               41
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                  June 1989
                          Releasable for Internet transmission


9.    CONCLUSIONS AND RECOMMENDATIONS

        9.1 Conclusions
(U)     The conclusions of this Working Paper are as follows:
        (1) To achieve interoperability, data standardization and management must be
            accomplished through an integrated approach.
        (2) Discussions of data management issues have not led to a NATO-wide policy. A data
            management policy is needed, and this need has been recognized by ADSIA and
            other NATO bodies.       The ISWG has been asked by ADSIA to provide
            recommendations on data management.
        (3) A NATO glossary of military/operational terms is needed for information exchange;
            it must go beyond the current approach being used in the development of AAP-25.
        (4) Development of standards by ISO/IEC and other standards bodies for data
            representation, syntax, encoding, and exchange needs to be monitored by NATO
            agencies. Appropriate bodies of TSGCEE, ADSIA, and NACISA need to assess how
            well the civil standards meet military requirements for data management and agree
            on a policy. Further analysis and a decision on message syntax requirements and
            standardization options (e.g., ASN.1, FORMETS) is needed.
        (5) A NATO Data Element Naming Convention is needed.
        (6) A NATO Data Element Attribute List is needed to characterize the distinct features
            of data elements and other data concepts.
        (7) The NATO data management policy needs to be applied to the specification of data
            elements to be used for developing and validating IERs.

     9.2 Recommendations
(U)  The following recommendations are provided for consideration by the appropriate
NATO - SHAPE bodies:
        (1) A consistent and integrated NATO-wide data management policy should be
            developed, approved, and promulgated by the NACISC.
        (2) The nations, NATO, and SHAPE should monitor ISO/IEC development of standards
            for data representation, syntax, encoding, and exchange. Appropriate bodies of
            TSGCEE, ADSIA, and NACISA should assess how well the civil standards meet
            military requirements for data management and make recommendations.
        (3) A NATO-wide glossary of military/operational terms should be developed. ACE, the
            other Major NATO Commands (MNCs), and the nations should press urgently for an
            authoritative statement by NATO.
        (4) A NATO-wide Data Element Naming Convention should be developed. The naming
            convention provided in Chapter 6 of this Working Paper should be adopted as a
            starting point for use with data elements and other data concepts. It should be
            modified as necessary and used in ACE and NATO.
        (5) A NATO-wide Data Element Attribute List should be developed. The list provided
            in Appendix E should be used as a starting point.
        (6) The recommended actions should commence as soon as possible for the specification
            of data elements to be used for developing and validating IERs.


                                             42
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                      June 1989
                           Releasable for Internet transmission

                                         APPENDIX A
                           Categorization of Data Concepts
(U)      Each of the three data concepts (data element, data value, and data field) can be
categorized in two ways. The first is to distinguish qualitative data from quantitative data;
this is known in ISO as data classification. The second categorization is by data type, in
which there are traditionally six types: character string, bit string, float (or floating point),
fixed-point, integer, and boolean (logical).
(U)      The purpose of these two categories is to provide a common framework for
discussing data concepts and to ensure data are consistently treated and processed in
software.

I. Classification of Data
(U)     Each data concept may be classified as quantitative or qualitative (descriptive).
Quantitative data concepts have sets of assigned values that answer the question "How
much?"
(U)     Data values can be divided into two types (see Figure 1): qualitative data
(sometimes referred to as data items) and quantitative data. A data value, either
qualitative data or quantitative data, represents the content of a data element--a piece of
data that has been defined within the context of an organization.
(U)     Qualitative data are a non-quantitative combination of characters or binary string
that represent a qualitative aspect of a person, place, thing, activity, or concept. For
example, a person's last name can be a data item. Operations such as compare,
concatenate, and logical AND/OR can be performed on qualitative data, where
appropriate. Qualitative data are of three types: literal data, data code, and image data.
        •    Literal Data. Literal data is a narrative or human-readable representation of a data
             element. The occurrence of the data element--a data value--requires no translation
             before use. An example would be the words of text as they appear in this paragraph.
        •    Data Code. A data code is a number, letter, character, symbol, or combination of
             them that is used to represent literal data. An example is the two-character alphabetic
             combination that NATO uses to identify the NATO nations: FR--France, GE--
             Germany, UK--United Kingdom, etc.
        •    Image Data. Image data is normally a bit-string representing the results of video,
             graphic, or photographic processing, transfer, or storage.
(U)   Quantitative data are numerical expressions such as: 4, -3.1, and 5.3*10**-3.
Arithmetic operations are performed on quantitative data.

II. Data Types
(U)    Six data types are identified below. The first three definitions are primitive types
recognized by ASN.1; all but the integer type are recognized by the Information Resource
Dictionary System (IRDS) [Ref. 37].
        •    Integer. The positive and negative whole numbers, including zero; the range is
             unbounded.
        •    Boolean. A true or false value.
        •    Bit-string. An ordered set of zero or more bits (i.e., 0 or 1) of unbounded length; the
             range is effectively unbounded.



                                                43
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                 UNCLASSIFIED                                        June 1989
                             Releasable for Internet transmission
        •     Character-string. An ordered set of zero or more characters.32
        •     Float. A number representation system in which each number, as represented by a
              pair of numerals, equals one of those numerals times a power of an implicit fixed
              positive integer base where the power is equal to the implicit base raised to the
              exponent represented by the other number (e.g., in BASE10, 545 is 5.45*10**2 in
              common notation or 545+02 in standard floating point representation).33
        •     Fixed-point. A radix (point) numeration representation in which the radix point is
              implicitly fixed in the series of digit places by some convention upon which
              agreement has been reached (i.e., the appearance of the radix or "decimal" point can
              be implicit or explicitly shown). For example, a five-significant-place decimal
              representation of pi is 3.1416 or 31416, where the decimal place of the latter is fixed
              by agreement.

III. Domains
(U)    The concepts of generic element and data element, discussed in Section 3.3 of the
main body of this Working Paper, are both constrained by needing an agreed set of
acceptable values. This limitation is called a domain or, more precisely, a domain set.34
When the domain set of a data element is specified, the domain set can be divided into two
types: specific and general. These types are discussed below.

        A. Specific Domain
(U)     A specific domain has a definition together with a discrete, finite set of acceptable
values. For a specific domain, one can always explicitly compile a complete list of these
acceptable values. As an example, the specific domain set for the data element "NATO
country code-of-world" is {BE, CA, DA, FR, GE, GR, IC, IT, LU, NL, NO, PO, SP, TU,
UK, US}. Codes or identifiers are usually specified by such a domain. Once an agreed to
domain has been established, at the generic element level, data elements standardized on
that domain must use the whole domain set or a subset of that domain. As in this example,
the 16 codes in the data element are a subset of the domain set specified in the generic
element "country code-of-world."

        B. General Domain
(U)     A general domain (set) specifies its limitations in terms of a general definition or a
range of acceptable values. In DP 7826 [Ref. 11] the following example is given by ISO
for the domain of the generic element "code":
                Coded representations shall consist of up to 35 characters that uniquely
                represent a complete name of a data (value), selected from a data (value)
                set of a data element, within a coding scheme. Unless otherwise specified,
                the coded representation shall use the following subset of ISO 646
                International Reference Version (IRV): (a) the letters A to Z single case
                only; (b) the digits 0 to 9; (c) space; (d) hyphen; (e) point; (f) solidus,35
                [and] (g) colon.
This is a an example of a general domain.

32      (U)      The ISO definition of "character": a member of a set of elements upon which agreement
has been reached and that is used for the organization, control, or representation of data [Ref. 11].
33      (U)      Vocabulary for Information Processing, X3.12-1970, ANSI, December 1970.
34         (U) The use of the term "domain" here differs from its use in WP 24.
35         (U) Solidus is sometimes called "backslash" and represented as "\".
                                                  44
                                   NATO UNCLASSIFIED
                             Releasable for Internet transmission
WP 7L                             UNCLASSIFIED                               June 1989
                         Releasable for Internet transmission

                                     APPENDIX B

LIST OF CLASS WORDS AND DEFINITIONS BY CATEGORY

(U)    The following is a list of class words that can be used to support the naming of
Generic Elements. The class word is used to specify the type of information contained in
a domain. Through the naming conventions, the domain specified by the class word (plus
a modifier and qualifiers) is associated with a data element. Listed below are the class
words segregated by category:

A.      QUALITATIVE
        1.  IDENTIFICATION CLASS WORDS
            (a)     NAME--A designation for an object expressed in a word or words.
            (b)     ABBREVIATION--A shortened form of a word, phrase, or name
            used to represent the complete form. Mnemonics are considered
            abbreviations.
            (c)     CODE--A group of alphabetic letters and/or digits that represent a
            specific name. Acronyms are considered codes.
            (d)     IDENTIFIER--A sequence of alphabetic characters that serve to
            indicate some object.
            (e)     NUMBER--A nonquantitative number associated with an object.
        2.  DESCRIPTIVE CLASS WORDS
            (a)     CATEGORY--A specifically defined division or subset in a system
            of classification in which all items share the same concept of taxonomy.
            (b)     TEXT--An unformatted character string descriptive field.

B.      QUANTITATIVE
        1.  TIME-RELATED CLASS WORDS
            (a)     AGE--The length of time a person or thing has lived or existed.
            (b)     DATE--A calendar date, commonly expressed by month, day, and
            year.
            (c)     DATE-TIME-GROUP--Time (day, hour, and minute) and date
            (month and year) in the format DDHHMMZMMMYY.
            (d)     TIME--A specific point in the day expressed within the 2400 hours
            clock.
            (e)     YEAR--The period of time as measured by the Gregorian calendar,
            consisting of approximately 365 days beginning on January 1 and ending
            on December 31.
        2.  POSITION-RELATED CLASS WORDS
            (a)     LOCATION--A position or site on the earth's surface represented
            by Mercator Projection grid coordinates.
            (b)     LATITUDE--Angular distance north or south from the earth's
            equator measured through 90 degrees. The format is degrees, minutes,
            seconds, hemisphere.
            (c)     LONGITUDE--The arc or portion of the earth's equator intersected
            between the meridian of a given place and the prime meridian (Greenwich,
            England) expressed in degrees. The format is degrees, minutes, seconds,
            hemisphere.
        3.  MEASUREMENT CLASS WORDS

                                           45
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                 June 1989
                          Releasable for Internet transmission

               (a)     ACCELERATION--The rate of change of velocity.
               (b)     ANGLE--The measurement of the space formed by two lines
               diverging from a common point.
               (c)     AREA--The number of unit squares equal in measure to the
               surface.
               (d)     DENSITY--The amount of particular items of interest per unit of
               measure.
               (e)     DEPTH--The linear measurement downward, backward, or inward.
               (f)     DISTANCE--The extent of advance away or along from a point
               considered primary or original.
               (g)     FLOW--The continuous movement, circulation, or throughput of a
               substance.
               (h)     FORCE--The intensity of strength, vigor, or power.
               (i)     HEIGHT--The distance from the base to the top of something
               standing upright.
               (j)     HUMIDITY--The amount of water vapor in the air.
               (k)     LENGTH--The longer or longest dimension of an object.
               (l)     MASS--The physical volume or bulk of a body.
               (m)     PRESSURE--A measure of applied force per unit area.
               (n)     RANGE--The extent covered by something.
               (o)     TENSION--A measure for tautness caused by pulling or stretching
               something.
               (p)     TEMPERATURE--A measure of the degree of hotness or coldness
               of something.
               (r)     TORQUE--A measure for a turning or twisting force.
               (s)     VELOCITY--The rate of motion.
               (t)     VISCOSITY--The degree to which a substance resists flowing.
               (u)     VOLUME--The amount of space occupied by a three-dimensional
               figure as measured in cubic units.
               (v)     WEIGHT--The force with which a body or object is attracted
               toward the earth by gravitation.
               (w)     WIDTH--The measurement taken at right angles to the length.
               (x)     SIZE--The physical dimensions or magnitude of something.
        4.     COMPUTATIONAL CLASS WORDS
               (a)     AMOUNT--The monetary value arrived at by counting.
               (b)     COST--The amount paid or required in payment for a purchase.
               (c)     QUANTITY--Non-monetary numeric value arrived at by counting.

C.      MEASUREMENT AND COMPUTATIONAL CLASS WORD QUALIFIERS
       1.       AVERAGE--The arithmetic mean of numbers.
       2.       MEDIAN--The middle value in a distribution, above and below which lie
                an equal number of values.
       3.       PERCENT--One part of a hundred.
       4.       RATIO--The calculated relation in degree or number between two similar
                things.
       5.       TOTAL--The final sum of amounts, costs, or quantity.
(U)    The above list is by no means exhaustive in nature, but rather represents a starting
point based on some ongoing efforts. It is envisioned that this list will grow as the need
for additional class words are identified. However, the class word list that is adopted must
be controlled and kept to a minimum.

                                            46
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                             UNCLASSIFIED                                June 1989
                         Releasable for Internet transmission


                                      AppendiX C

           ARCHITECTURAL MODIFIERS AND PRIME WORD LIST

(U)     The following is a list of the architectural modifiers and prime words that can be
used to support the naming of generic elements and data elements. The prime word
represents the objects to which an application data element belongs. The architectural
modifier is at a macro-organizational level, or in other words, the first major division of
information within a specific organization. The architectural modifier provides the logical
connection between the data element and an organization's data architecture or data model.
The architectural modifier should be the first word in the data element name and may also
serve as the prime word for the data element name if so desired. Architectural modifiers
should appear on the prime word list; however, not all prime words are architectural
modifiers.
(U)     An initial set of architectural modifiers and prime words has been listed below. As
time progresses and experience is gained, this list would change accordingly. Other prime
words would be recommended for inclusion to the prime word list.
(U)     The architectural modifiers have been mapped below to their information class and
Army Data Architecture Subject Area. The architectural modifier within each subject area
may be associated with any information class within that subject area. However, an
architectural modifier may not be associated with an information class outside of the
subject areas assigned below. "Associated" means appearing as the first word in a data
element name that supports a specific information class.
(U)     The architectural modifiers listed below, in accordance with the naming
conventions specified in Chapter 6, are used as modifiers of prime words.

A. ARCHITECTURAL MODIFIER MAPPING
1. DATA MODEL SUBJECT AREA: Acquisition
     INFORMATION CLASSES:
          Personnel Accessions
          Materiel Acquisition
          Facilities Acquisition
          Industrial Capability
          Materiel Improvement
          ARCHITECTURAL MODIFIERS:
                         Acquisition
                         Industrial

2.      DATA MODEL SUBJECT AREA: Budget
        INFORMATION CLASSES:
             Cash/Funds Authorizations
             Program/Budget Execution
             Accounting
             Budget
             ARCHITECTURAL MODIFIERS:
                          Accounting
                          Budget
                          Finance
                          Resource
                                            47
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                    June 1989
                      Releasable for Internet transmission

3.      DATA MODEL SUBJECT AREA: Commercial Activities
        INFORMATION CLASSES:
             Commercial Activities
             ARCHITECTURAL MODIFIERS:
                         Commercial
                         Contractor
                         Supplier
                         Vendor
4.      DATA MODEL SUBJECT AREA: Contracts
        INFORMATION CLASSES:
             Contracts
             ARCHITECTURAL MODIFIERS:
                         Contract
                         Agreement

5.      DATA MODEL SUBJECT AREA: Crisis Operations
        INFORMATION CLASSES:
             Crisis Operation
             ARCHITECTURAL MODIFIERS:
                            Catastrophic
                            Crisis
                            Disaster
                            Relief
                            Special
                            Unconventional

6.      DATA MODEL SUBJECT AREA: Facilities
        INFORMATION CLASSES:
             Installation
             Facilities Maintenance
             Facilities Disposal
             ARCHITECTURAL MODIFIERS:
                         Annex                   Maintenance
                         Base                    Office
                         Camp                    Post
                         Cemetery                Production
                         Construction            Range
                         Engineering             Reservation
                         Facility                Storage
                         Housing                 Terminal

7.      DATA MODEL SUBJECT AREA: Funds
        INFORMATION CLASSES:
             Funds
             Disbursement
             ARCHITECTURAL MODIFIERS:
                          Appropriated
                                      48
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                      June 1989
                      Releasable for Internet transmission

                         Compensation
                         Disbursement
                         Funds
                         Receipt

8.      DATA MODEL SUBJECT AREA: Government Liaison
        INFORMATION CLASSES:
             External Guidance
             Foreign Liaison
             Government Liaison
             ARCHITECTURAL MODIFIERS:
                        Executive         International
                        External          Interservice
                        Foreign           Liaison
                        Government        National
                        Interheadquarters

9.      DATA MODEL SUBJECT AREA: Guidance & Doctrine
        INFORMATION CLASSES:
             Strategic Direction
             Doctrine
             ARCHITECTURAL MODIFIERS:
                        Command            Priority
                        Direction          Regulation
                        Directive          Strategic
                        Policy             Strategy

10.     DATA MODEL SUBJECT AREA: Information Management
        INFORMATION CLASSES:
             Information Management
             ARCHITECTURAL MODIFIERS:
                       Audio                Printing
                       Automation           Publication
                       Communication        Record
                       Computer             Telecommunications
                       Information          Visual
                       Library

11.     DATA MODEL SUBJECT AREA: Intelligence
        INFORMATION CLASSES:
             Intelligence
             ARCHITECTURAL MODIFIERS:
                        Counterintelligence  Mapping
                        Deception            Nuclear Surety
                        Enemy                Reconnaissance
                        Geographic           Topology

                                      49
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                         June 1989
                      Releasable for Internet transmission

                      Intelligence               Weather

12.     DATA MODEL SUBJECT AREA: Materiel
        INFORMATION CLASSES:
             Materiel Distribution
             Materiel Inventory
             Materiel Maintenance
             Materiel Disposition
             ARCHITECTURAL MODIFIERS:
                        Developer                Major-Item
                        Equipment                Materiel
                        Inventory                Supply
                        Logistic

13.     DATA MODEL SUBJECT AREA: Operational Testing (OT)
        INFORMATION CLASSES:
             Testing (OT)
             ARCHITECTURAL MODIFIERS:
                          Evaluation
                          Test

14.     DATA MODEL SUBJECT AREA: Operations Plans
        INFORMATION CLASSES:
             Plans (Operation)
             Deployment
             ARCHITECTURAL MODIFIERS:
                    Air-Defence Chemical       Long-range         Operation
                    Air-Ground  Defence        Manoeuver          Operational
                    Assessment  Deployment     Mobilization       Plan
                    Biological  Exercise       Movement           Psychological
                    Battlefield Fire-Support   Nuclear            Transport
                    Barrier     Intertheatre   Obstacles          Warfare
                    Capability  Intratheatre   Offense

15.     DATA MODEL SUBJECT AREA: Personnel
        INFORMATION CLASSES:
             Personnel Distribution
             Personnel Strength
             Casualties
             Personnel Sustainment
             Personnel Transitions
             ARCHITECTURAL MODIFIERS:
                        Civilian                      Member
                        Dependent                     Military
                        Equal-Opportunity             Personnel
                        Family                        Union
                        Local

                                      50
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                          June 1989
                      Releasable for Internet transmission

16.     DATA MODEL SUBJECT AREA: Public Affairs
        INFORMATION CLASSES:
             Public Affairs
             ARCHITECTURAL MODIFIERS:
                            Affair
                            Public

17.     DATA MODEL SUBJECT AREA: Readiness
        INFORMATION CLASSES:
             Force Readiness
             ARCHITECTURAL MODIFIERS:
                          Force
                          Readiness

18.     DATA MODEL SUBJECT AREA: Research and Development
        INFORMATION CLASSES:
             RDTE
             ARCHITECTURAL MODIFIERS:
                    Electronic                  Research
                    Experiment                  Sample
                    Development                 Science
                    Laboratory                  Subject
                    Life-Science                Technology
                    Protocol

19.     DATA MODEL SUBJECT AREA: Security
        INFORMATION CLASSES:
             Security
             Law Enforcement
             ARCHITECTURAL MODIFIERS:
                      Discipline                      Physical
                      Law-and-Order                   Security
                      Prisoner                        Surveillance

20.     DATA MODEL SUBJECT AREA: Security Assistance
        INFORMATION CLASSES:
             Security Assistance
             ARCHITECTURAL MODIFIERS:
                            Security
                            Assistance

21.     DATA MODEL SUBJECT AREA: Structure
        INFORMATION CLASSES:
             Structure
             Manpower Requirements
             Manpower Authorizations
             Materiel Requirements
             Materiel Authorizations
             Facilities Requirements
                                      51
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                      June 1989
                      Releasable for Internet transmission

              Facilities Authorizations
              ARCHITECTURAL MODIFIERS:
                             Authorization
                             Manpower
                             Structure

22.     DATA MODEL SUBJECT AREA: Studies Program
        INFORMATION CLASSES:
             Study Program
             ARCHITECTURAL MODIFIERS:
                          Study

23.     DATA MODEL SUBJECT AREA: Support Activities
        INFORMATION CLASSES:
             Inspection Results
             Audit Findings
             Legal Support
             Community Support
             Health Support
             Safety
             Individual Entitlement
             Claims
             ARCHITECTURAL MODIFIERS:
                         Administration          Installation
                         Audit                   Investigation
                         Clinic                  Legal
                         Community               Religious
                         Health                  Safety
                         Hospital                Soldier
                         Inspection              Support
24.     DATA MODEL SUBJECT AREA: Training
        INFORMATION CLASSES:
             Institutional Training
             Individual and Unit Proficiency
             ARCHITECTURAL MODIFIERS:
                             Institutional
                             Training

25.     DATA MODEL SUBJECT AREA: Transportation (non-Army)
        INFORMATION CLASSES:
             Transportation (non-Army)
             ARCHITECTURAL MODIFIERS:
                           Air
                           Land
                           Rail
                           Sea
                           Transportation

                                      52
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                          UNCLASSIFIED                    June 1989
                      Releasable for Internet transmission

26.     DATA MODEL SUBJECT AREA: Unit(s) and Organization(s)
        INFORMATION CLASSES:
             Review and Analysis Results
             Internal Management
             ARCHITECTURAL MODIFIERS:
                        Army                     Report
                        Documentation            Reserve
                        Goal                     Standard
                        Management               Tactical
                        Organization             Unit
                        Procedure




                                      53
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                         UNCLASSIFIED                           June 1989
                     Releasable for Internet transmission



B. PRIME WORD LIST

Accounting       Berth                 Crane                Fire-Support
Acquisition      Biological            Crisis               Force
Administration   Budget                Deception            Foreign
Affair           Bunker                Defence              Fuel
Agency           Camp                  Departure            Funds
Agreement        Capability            Dependent            Geographic
Air              Cargo                 Deployment           Goal
Air-Defence      Carrier               Description          Government
Air-Ground       Catastrophic          Developer            Harbour
Aircraft         Cemetery              Development          Health
Airfield         Channel               Direction            Hospital
Airlift          Chart                 Directive            Hostilities
Airport          Chemical              Disaster             Housing
Ammunition       Civilian              Disbursement         Ice
Anchorage        Clinic                Discipline           Industrial
Annex            Combat                Diseased             Information
Appropriated     Command               Document             Inspection
Apron            Commercial            Electricity          Installation
Arctic           Communication         Electronic           Institutional
Army             Community             Encyclopedia         Intelligence
Arresting-Gear   Compensation          Enemy                Interheadquarter
Arrival          Complex               Engineering          International
Assessment       Component             Equipment            Interservice
Asset            Computer              Evacuee              Intertheatre
Assistance       Construction          Evaluation           Intratheatre
Audio            Container             Executive            Inventory
Authorization    Contract              Exercise             Investigation
Automation       Contractor            Experiment           Item
Barrier          Conversion            External             Laboratory
Base             Counterintelligence   Facility             Land
Battlefield      Country               Family               Language
Bed              Craft                 Finance              Law-and-Order
Legal            Operation             Record               Subject
Liaison          Operational           Regulation           Supplier
Library          Organization          Relief               Supply
Life-Science     Outpatient            Religious            Support
Lighter          Patient               Report               Surveillance
Local            Personnel             Requirement          Tactical
Location         Petroleum             Research             Technology
Logistic         Physical              Reservation          Telecommunications
Long-range       Pipeline              Reserve              Terminal
Maintenance      Plan                  Resource             Test
Major-Item       Policy                Road                 Theatre
Management       Port                  Runway               Tidal
Manoeuvre        Post                  Safety               Topology
Manpower         Printing              Sample               Training

                                        54
                           NATO UNCLASSIFIED
                     Releasable for Internet transmission
WP 7L                        UNCLASSIFIED                           June 1989
                    Releasable for Internet transmission

Mapping          Priority          Science                 Transport
Materiel         Prisoner          Sea                     Transportation
Medical          Procedure         Seaport                 Tugboat
Member           Production        Security                Unconventional
Message          Program           Sequence                Union
Military         Project           Service                 Unit
Mission          Protocol          Ship                    Vendor
Mobilization     Psychological     Soldier                 Visual
Movement         Public            Special                 War
Nation           Publication       Standard                Warfare
National         Rail              State                   Water
Non-Evacuee      Railroad          Stock                   Weather
Nuclear          Ramp              Storage                 Wharf
Nuclear Surety   Range             Strategic               Work
Obstacles        Readiness         Strategy                Zone
Offense          Receipt           Structure
Office           Reconnaissance    Study




                                    55
                          NATO UNCLASSIFIED
                    Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                  June 1989
                           Releasable for Internet transmission

                                        APPENDIX D

                "OF-LANGUAGE" NAMING CONVENTION


(U)     In its discussion of data terminology,36 AM 96-1-4 discusses only one naming
convention, the so-called "OF-Language" (based on a proprietary concept developed by
IBM), and recommends it for adaption, as appropriate, in ACE.
(U)     The general format for a name in the "OF-Language" convention is:
P . QQQ [R SSS][R SSS] [R SSS]
where:
P                indicates type of name (from a list of valid types given below)
.                means "OF"
QQQ              is a global noun (e.g., listed in a data dictionary)
R                is a connector for descriptions (from a list of valid connectors given below)
SSS              is a descriptor (adjective).
Connector/descriptor pairs, denoted [R SSS], are used optionally and may be repeated as
appropriate.
(U)     Valid type-of-name ["P"] values are: Amount (A), Code (C), Date (D), Flag (F),
Constant (K), Name (N), Number (O), Percent (P), Quantity (Q), Text (T), and Control
(X). Valid values of the connector ["R"] are:
/                meaning "which is"
-                meaning "Compound" [the symbol is hyphen]
$                meaning "OR"
#                meaning "AND"
@                meaning "by," "per", "for", or "with"
–                meaning "initiator" [the symbol is underscore].
(U)     The following are valid examples of names in the "OF-Language," taken from AM
96-1-4:
A.SALARY/BASE#COMMISSION                          Amount of salary that is Base and
                                                  Commission
Q.AIRCRAFT/STANDBY                                Quantity of Aircraft that are on standby
N.COUNTRY/NATO                                    Name of Country that is in NATO
C.COUNTRY/NATO                                    Code of Country that is in NATO
P.MINES/REMAINING/ACOUSTIC                        Percentage of mines remaining that are
                                                  acoustic.




36      (U)    "Data Terminology," Annex A, AM 96-1-4 [Ref. 6], Section 1.L.
                                               56
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                     June 1989
                          Releasable for Internet transmission

                                       APPENDIX E

                                  ATTRIBUTE LIST

1.   Generic Element

              1.1 Administrative Attributes

              (U) Administrative attributes for generic elements are:
        •   INFORMATION GENERIC ELEMENT NAME - A character string given to a
            generic element based on a class word that identifies a domain.
        •   INFORMATION ELEMENT APPROVAL DATE - The date a standard element is
            approved as an ATCCIS standard.
        •   INFORMATION ELEMENT CLASS WORD NAME - A character string (word)
            from a reserved list that identifies the generic element.
        •   INFORMATION ELEMENT MODIFIER NAME - A character string that further
            describes a characteristic of an object, a relationship between objects, or the object
            itself.
        •   INFORMATION GENERIC ELEMENT QUALIFIER NAME - A character string
            that modifies a class word. It is normally associated with quantities.
        •   INFORMATION GENERIC ELEMENT DEFINITION TEXT - narrative describing
            the general intent of a generic element.

              1.2 Relational Attributes

              (U) Relational attributes for generic elements are:
        •   INFORMATION ELEMENT STANDARDIZATION AUTHORITY ATTRIBUTE
            IDENTIFIER - The NATO, SHAPE, or Command organization that approved the
            element.
        •   INFORMATION ELEMENT AUTHORIZATION DOCUMENT NAME - A
            character string given to the document (directive, regulation, publication, or other)
            that authorizes the generic element.

              1.3 Representational Attributes

              (U) Representational attributes for generic elements are:
        •   INFORMATION ELEMENT DATA TYPE CATEGORY - The editing type of the
            data value associated with an element.
        •   INFORMATION ELEMENT MAXIMUM DATA VALUE LENGTH - The
            maximum number of characters for an attribute.
        •   INFORMATION GENERIC ELEMENT DOMAIN DEFINITION TEXT - Narrative
            describing the acceptable set of data values for a generic element.
        •   INFORMATION DATA VALUE TYPE IDENTIFIER - An indicator specifying the
            data value type of an information element.
        •   INFORMATION ELEMENT JUSTIFICATION CATEGORY - The positional
            justification of an element within a data field.

                                              57
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                   June 1989
                           Releasable for Internet transmission
        •    INFORMATION DATA VALUE SOURCE LIST TEXT - The source in which
             lengthy codes are enumerated for the user. The source can be either manual or
             automated medium.
                1.3.1   Relating to Qualitative Data
                (U)     Representational attributes relating to qualitative data for generic
elements are:
        •    INFORMATION DATA VALUE NAME - An occurrence of a character string given
             to an acceptable set of data values.
        •    INFORMATION DATA VALUE DEFINITION TEXT - Narrative describing a data
             value name or number specified in a domain set.
                1.3.2   Related to Quantitative Data
                (U)     Representational attributes relating to quantitative data for generic
elements are:
        •    INFORMATION QUANTITATIVE DATA HIGH RANGE NUMBER - The largest
             value for quantitative data, when a domain set is expressed as a possible range of
             values.
        •    INFORMATION QUANTITATIVE DATA LOW RANGE NUMBER - The
             smallest value for quantitative data, when a domain set is expressed as a possible
             range of values.
        •    INFORMATION QUANTITATIVE DATA SCALE NUMBER - The integer that
             determines the decimal point placement in an element for fixed point or floating
             point data types.
        •    INFORMATION QUANTITATIVE DATA VALUE NUMBER - The set of values
             for quantitative data, when mathematical operations must be performed on "codes."
        •    INFORMATION QUANTITATIVE DATA VALUE DEFINITION TEXT -
             Narrative describing a data value name or number specified in a domain set.

        2.      DATA ELEMENT

                2.1 Administrative Attributes

                (U) Administrative attributes for data elements are:
        •    INFORMATION DATA ELEMENT NAME - A character string given to a data
             element based on a prime term and a generic element name.
        •    INFORMATION PRIME WORD NAME - A character string in a data element name
             that represents the data grouping to which the data element belongs.
        •    INFORMATION DATA ELEMENT ARCHITECTURAL MODIFIER NAME - A
             data element character string directly related to a subject area in the ATCCIS data
             architecture.
        •    INFORMATION DATA ELEMENT DESCRIPTION TEXT - Narrative describing a
             data element.
        •    INFORMATION DATA ELEMENT MNEMONIC ABBREVIATION - A short
             form of a data element character string.
        •    INFORMATION DATA ELEMENT SECURITY CATEGORY - The level of
             security that the value set of this data element requires.


                                              58
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                                UNCLASSIFIED                                     June 1989
                            Releasable for Internet transmission
        •     INFORMATION DATA ELEMENT STATUS IDENTIFIER - An indicator of the
              current status of a data element in relation to the standardization process.
        •     INFORMATION DATA ELEMENT COMMENT TEXT - Administrative comment
              concerning a data element.
                2.1.1     Defined at the Generic Element Level
        •     INFORMATION ELEMENT APPROVAL DATE
        •     INFORMATION DATA ELEMENT QUALIFIER NAME
        •     INFORMATION ELEMENT MODIFIER NAME

                2.2 Relational Attributes

                (U) Relational attributes for data elements are:
        •     INFORMATION DATA ARCHITECTURE SUBJECT AREA NAME - A character
              string given to a data architecture entity subject area.
        •     INFORMATION CLASS NAME - A character string given to the class of
              information to which a data element is assigned in accordance with the Information
              Model.
        •     INFORMATION PROCESS NAME - A character string given to a process that
              creates an information class in accordance with the current Information Model.
        •     INFORMATION CLASS PROPONENT NAME - A character string given to an
              organization that has been assigned responsibility for an information class.
        •     INFORMATION DATA ELEMENT RESPONSIBLE OFFICE NAME - A character
              string given to the office and/or person designated by the information class proponent
              as the functional expert for defining, reviewing, and updating a data element and its
              attributes.

        2.3     Representational Attributes

                    (U) Representational attributes for data elements are:
        •     INFORMATION DATA ELEMENT DOMAIN DEFINITION TEXT - Narrative
              describing the data values acceptable for a data element. The specification for the
              element must be the set or subset of a generic element definition. It may not contain
              data values outside the set. This definition includes the range of acceptable values.
        •     INFORMATION DATA ELEMENT TIMELINESS IDENTIFIER - An indicator of
              how often data values must be updated.
        •     INFORMATION DATA ELEMENT LENGTH - The maximum number of
              characters in a standard data element.
                2.3.1     Defined at the Generic Element Level
        •     INFORMATION DATA VALUE TYPE IDENTIFIER
        •     INFORMATION ELEMENT JUSTIFICATION CATEGORY
        •     INFORMATION ELEMENT CODE LOCATION
                2.3.2     Related to Qualitative Data
                (U)       Representational attributes relating to qualitative data for data
elements are:


                                                59
                                  NATO UNCLASSIFIED
                            Releasable for Internet transmission
WP 7L                               UNCLASSIFIED                                     June 1989
                           Releasable for Internet transmission
        •   INFORMATION QUALITATIVE DATA VALUE ACCURACY NUMBER
            PERCENT - An indicator of how accurate a qualitative data value must be.
             2.3.3 Related to Qualitative Data Defined at the Generic
            Element Level
        •   INFORMATION DATA VALUE NAME
        •   INFORMATION DATA VALUE DEFINITION TEXT
                2.3.4   Related to Quantitative Data
                (U)     Representational attributes relating to quantitative data for data
elements are:
        •   INFORMATION QUANTITATIVE DATA ACCURACY IDENTIFIER - An
            indicator of how precise a quantitative data value must be.
        •   INFORMATION DATA ELEMENT CALCULATION FORMULA TEXT -
            Narrative expressing the algorithmic formula for a data element that is derived.
             2.3.5 Related to Quantitative Data Defined at the Generic
            Element Level
        •   INFORMATION QUANTITATIVE DATA HIGH RANGE NUMBER
        •   INFORMATION QUANTITATIVE DATA LOW RANGE NUMBER
        •   INFORMATION QUANTITATIVE DATA SCALE IDENTIFIER
        •   INFORMATION DATA VALUE DEFINITION TEXT
        •   INFORMATION QUANTITATIVE DATA VALUE NUMBER

3.   Data Element Alias

                3.1 Administrative Attributes

                (U) Administrative attributes for data element aliases are:
        •   INFORMATION DATA ELEMENT ALIAS NAME - A character string given to a
            nonstandard data element.
        •   INFORMATION DATA ELEMENT ALIAS HOST APPLICATION NAME - A
            character string given to an application or program that contains a data element alias.
        •   INFORMATION DATA ELEMENT ALIAS HOST SYSTEM NAME - A character
            string given to an information system that contains a data element alias.

                3.2 Relational Attributes

                (U) Relational attributes for data element aliases are:
        •   INFORMATION DATA ELEMENT ALIAS RESPONSIBLE OFFICE NAME - A
            character string given to the office and/or person designated by the information class
            proponent as the functional expert for defining, reviewing, and updating a data
            element alias and its attributes.

                3.2.1    Defined at the Data Element Level
        •   INFORMATION DATA ELEMENT NAME




                                               60
                                 NATO UNCLASSIFIED
                           Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                 June 1989
                          Releasable for Internet transmission

                3.3 Representational Attributes
                (U)     The representational attributes at the data element alias level are
identical to the Data Element Level, except they are used only to report exceptions where
that alias deviates from the established standard.

4.   Relation of Attributes to Other Standards
     (U)        The attributes listed in this section were identified in ISO/IEC DP 10027,
1 April 1988, from the Element Entity level of the IRDS. Other attributes have been
added to the attribute set associated with the development of a data model to support the
standardization process.




                                             61
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




          (This page intentionally left blank)




                          62
              NATO UNCLASSIFIED
        Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                  June 1989
                          Releasable for Internet transmission

                                       APPENDIX F

            NATIONAL INITIATIVES ON DATA MANAGEMENT


(U)     This Appendix briefly describes some of the national initiatives being conducted to
define a policy for data management and standardization.

I. Data Management policy for the u.s. army
(U)     The U.S. Army has recently published an Army Regulation (AR 25-9) [Ref. 35] to
prescribe policies, responsibilities, and concept of operation for the management of data
used in manual and automated information systems throughout the U.S. Army. This
document was coordinated with ISO, ANSI, and the U.S. National Bureau of Standards, as
well as with the U.S. Joint Chiefs of Staff, to ensure alignment in the area of a data
element naming convention. The Army plans to maintain a Service-wide data
encyclopedia of information about all data elements that have gone through a
standardization process and are designated as Army standard elements. AR 25-9
addresses six activities that form the Army Data Management and Standards Program:
        •    Strategic Data Planning. The development and maintenance of data-related
             initiatives in integrated organizational multiyear long-range plans.
        •    Data Element Standards. The standardization and management of data elements and
             their attributes.
        •    Information Management Control. The interface between data management and
             control of the collection and reporting of management information requirements.
        •    Data Security. The policies and procedures required to protect and safeguard data
             and information, including operational security.
        •    Data Synchronization. The policies and procedures that govern the consistency,
             accuracy, reliability, and timeliness of data used and generated by the Army.
        •    Database Development and Maintenance. The policies and standards that guide
             design, development, documentation, and integration of data bases.
(U)     AR 25-9 provides for three types of standard elements: reference element, data
element, and data element alias. A reference element is a structure used to specify the
domain or the range of acceptable values. A data element consists of a data element name,
together with attributes describing what it is, its representation, and relationships to other
objects. The data element name includes the name of the reference element that has the
appropriate range of acceptable values. Note that it is the structure of a data element that
is standardized, not the use of a data element. Data element aliases identify data elements
in use in specific systems and locations, and they are used, temporarily, to bridge the gap
between standard elements and nonstandard names being used in fielded systems.




                                             63
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




          (This page intentionally left blank)




                          64
              NATO UNCLASSIFIED
        Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                                  June 1989
                          Releasable for Internet transmission

                                     APPENDIX G

                    BACKGROUND, OBJECTIVE, AND
                        ADDITIONAL GUIDANCE

(U)     This IDA Memorandum Report was written in response to Task Order T-J1-246
and Amendment No. 6. Those portions of the task order that pertain to the background
and objectives of the task, and the additional guidance provided therein by the sponsoring
office, are reprinted here.


        2.   BACKGROUND:

              The tactical ADP portion of the NATO Long Term Defense Program (LTDP)
        proposed that command and control systems be built to common specifications.
        The Deputy SACEUR initiated a study to determine the feasibility of the nations in
        the Central Region commonly developing an Automated Army Tactical Command
        and Control Information System (ATCCIS) for deployment in the post-1995
        timeframe. Commitments for supporting this effort were obtained from US, UK,
        and FRG Army Chiefs of Staff. These nations provided information on their
        operational doctrine, procedures, functions, and information exchange
        requirements for their maneuver forces, as well as their operational requirements
        for an automated CCIS and information on the ADP systems that they are currently
        developing to support their maneuver forces. This information was used in the
        initial phase of the study to determine the extent to which similarities and
        differences in national requirements for automated CCISs would indicate that a
        commonly developed system is potentially feasible. The results of ths initial phase
        were positive. SHAPE has requested that their nations complete the study and has
        received US, UK and FRG Army Chiefs of Staff commitments.

        3.   OBJECTIVE:

             The objective of this phase II effort of the study is to assist SHAPE in defining
        the military objectives and basic operational requirements for a common ATCCIS
        that achieves interoperability to ADP systems. The capabilities of ADP systems
        are to be compared to the concept of operations of each of the nations to determine
        the extent to which such a common ATCCIS could accommodate the requirements
        of each nation and to identify issues remaining to be resolved before such a system
        could be employed in the Central Region in post-1995 time period.

        4.   ADDITIONAL GUIDANCE:


                                             65
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                             UNCLASSIFIED                                June 1989
                         Releasable for Internet transmission
            The FY 1988 task includes:

            a. Continue tasks to support the establishment of the organizational and
        operational concept, operational requirements, and technical concept for the
        ATCCIS.

             b. Continue review of the U.S. operational doctrine, procedures, functions,
        and information exchange requirements for the maneuver forces and operational
        requirements for automated CCIS and the ADP systems currently being developed
        with a view towards post-1995 as necessary to conduct the study. This specifically
        includes efforts underway to develop and support dispersed command posts.




                                            66
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                            June 1989
                          Releasable for Internet transmission


                                        Appendix H

                            DISTRIBUTION LIST
                                                                 No. of Copies
Office of the Assistant Secretary of Defense (C3I)                    10
ATTN: Mr. V. Russell
The Pentagon, Room 3D174
Washington, DC 20301

Office of the Assistant Secretary of Defense (C3I)                    1
ATTN: LTC T. Parrish
The Pentagon, Room 3D174
Washington, DC 20301

HQDA ODISC4                                                           35
ATTN: SAIS-ADO (LTC J. Johnson)
The Pentagon, Room 1C670
Washington, DC 20301

HQDA ODISC4                                                           1
Interoperability and Standards Office
ATTN: SAIS-ADO (LTC R. Farmer)
The Pentagon, Room 1C670
Washington, DC 20301

HQDA ODISC4                                                           40
ATTN: SAIS-ADA (Maj M. Napoliello)
The Pentagon, Room 1C670
Washington, DC 20301

Office of the Joint Chiefs of Staff                                   2
ATTN: J6U (M. Billings)
The Pentagon, Room 1D770
Washington, DC 20301

Office of the Joint Chiefs of Staff                                   13
ATTN: JMCEB (Cdr A. Mitchell)
The Pentagon, Room 1B707
Washington, DC 20301

Director, JTC3A (C3A-ARM)                                             2
ATTN: C3-WA(ASD(C3I)ASC)
Washington, DC 20301-3160


Director, JTC3A (C3A-AR)                                              2
ATTN: MAJ Jakoboswki

                                            67
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                              UNCLASSIFIED                       June 1989
                          Releasable for Internet transmission
Russell Hall
Fort Monmouth, NJ 07703-5513

Director, JTC3A (C3A-AR)                                         3
Technical Standards Office
ATTN: C3A-ADW-S (O. Schultz, Gary Koener)
DCA/JTC3A
11440 INS-N
Reston, VA 22090-5006

Director, Defense Communications Agency                          3
Defense Communications Engineering Center (DCEC)
ATTN: Code R640 (S. Lloyd)
1860 Wiehle Avenue
Reston, VA 22090-5500

CINCUSAREUR                                                      6
ATTN: AEAIM-AA (Maj J. Fleming)
APO New York 09403

Chief, Rationalization, Standardization, and Interoperability    3
U.S. Army Signal Center
Directorate of Combat Development
ATTN: ATZH-CDQ
Fort Gordon, GA 30905

Commander, CECOM                                                 10
PEO Army Command and Control Systems
ATTN: AMSEL-ACCS (R. Giordano, T. Collins)
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                                 2
PEO Communications
ATTN: AMSEL-Comm
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                                 2
Avanced Systems Concepts Organization
ATTN: AMSEL-RD-ASCO-RA (E. Tawil)
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                                 3
Information Systems Division
Protocol and Standards Team,
ATTN: AMSEL-ISD-SD (J. Savin, J. Onufer, A. Talerico)
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                                 1
Systems Division
ATTN: RD-C3-D (J. Plant)

                                            68
                                NATO UNCLASSIFIED
                          Releasable for Internet transmission
WP 7L                           UNCLASSIFIED                       June 1989
                       Releasable for Internet transmission
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                              2
ATTN: SPIS-CC-TF (LTC G. Banks, S. Levine)
Fort Monmouth, NJ 07703-5000

Commander, CECOM                                              2
ATTN: SPIS-CC-OTDS (Col J. Doyle, J. D'Oria)
Fort Monmouth, NJ 07703-5000

Commander, U.S. Army CACDA                                    2
ATTN: ATZL-CAC-CR (CPT (P) B. Bray)
Fort Leavenworth, KS 66027-5300

Commander, U.S. Army Information Systems Command (USISC)      10
Information Systems Software Development Center
ATTN: ASBF-SMS (C. Venditto)
Fort Huachuca, AZ 85613-5450

U.S. Army Development and Employment Agency (ADEA)            1
ATTN: Direction, ATCCS Experimental Site
Fort Lewis, WA 98433

U.S. Army Development and Employment Agency (ADEA)            1
ATTN: UKSPO (LTC R.B. Hawken)
ATCCS Experimental Site
Fort Lewis, WA 98433

U.S. Army Development and Employment Agency (ADEA)            1
ATTN: MARLNO (Maj D. Rape)
ATCCS Experimental Site
Fort Lewis, WA 98433

Chief of Naval Operations                                     1
Director, Naval Communciations Division
ATTN: OP-941C (Maj B.T. Diekema)
The Pentagon, Room 5A686
Washington, DC 20350

Chief of Naval Operations                                     1
Tactical C2 Systems Branch
ATTN: OP-942G
The Pentagon, Room 5E523
Washington, DC 20350




                                          69
                             NATO UNCLASSIFIED
                       Releasable for Internet transmission
WP 7L                           UNCLASSIFIED                         June 1989
                       Releasable for Internet transmission


Chief of Naval Operations                                        1
Director, Information Management Support Division
ATTN: OP-945D (P. McKenna)
The Pentagon, Room 5E573
Washington, DC 20350

HQ Department of the Navy, Information Resources Management      2
ATTN: Technology Assessment Division (M.R. Potter, T. Senator)
The Pentagon, Room 4C434
Washington, DC 20350

Commander, Space and Naval Warfare Systems Command               2
(SPAWAR), Warfare Systems Engineering
ATTN: Interoperability Branch, Code 3213 (M. Zich, P. Darby)
NC-1, Room 11E47
2511 Jefferson Davis Highway
Arlington, VA 22202

Commander, Space and Naval Warfare Systems Command               2
(SPAWAR), Warfare Systems Engineering
ATTN: Interoperability Branch, Code 3213 (M. Zich, P. Darby)
NC-1, Room 11S10
2511 Jefferson Davis Highway
Arlington, VA 22202

Commander, Naval Data Automation Command                         1
ATTN: Code 32 (D. Vaughn)
Building 166
Washington Navy Yard
Washington, DC 20374-1662

Director, C4 Division                                            2
U.S. Marine Corps
Code CCA (Col Aginbroad)
Navy Annex, Room 3020
Washington, DC 20380

Commander, Marine Corps Research, Development, and               2
 Acquisition Command (MCRDAC)
ATTN: TACSIIP (A. Harris, Capt C. Howes)
Navy Annex, Room 3020
Washington, DC 20380

Commander, Marine Corps Tactical Systems Support Activity        2
 (MCTSSA)
ATTN: Col D. Gardner, J. Steenwerth
Camp Pendleton, CA 92055-5080



                                         70
                             NATO UNCLASSIFIED
                       Releasable for Internet transmission
WP 7L                             UNCLASSIFIED                         June 1989
                         Releasable for Internet transmission


HQ USAF, Tactical Command and Control Division                   1
ATTN: XOORC
The Pentagon, Room BF881
Washington, DC 20330

HQ USAF                                                           1
ATTN: AF/SCTI (Col K. Kubiak)
The Pentagon, Room 5C1080
Washington, DC 20330

HQ Tactical Air Forces                                           1
ATTN: TAFIG/IISQ
Langley, VA

National Institute for Science and Technology                     4
ATTN: ICST (J. Mulvennay, R. Martin, D. Jefferson, C. Royster)
Technology Building, Room B266
Gaithersburg, MD 20899

Defense Technical Information Center                             2
Cameron Station
Alexandria, VA 22314

Institute for Defense Analyses                                   20
1801 N. Beauregard Street
Alexandria, VA 22311-1772

TOTAL:                                                           203




                                         71
                               NATO UNCLASSIFIED
                         Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




          (This page intentionally left blank)




                          72
              NATO UNCLASSIFIED
        Releasable for Internet transmission
WP 7L                         UNCLASSIFIED                               June 1989
                     Releasable for Internet transmission


                              GLOSSARY
        AAP       Allied Administrative Publication (MAS)
        ACCIS     Automated Command and Control Information System (NATO)
        ACE       Allied Command Europe (NATO)
        ACP       Allied Communications Publication (NATO)
        ADSIA     Allied Data Systems Interoperability Agency
        ADatP     Allied Data Publication
        ADP       Automatic Data Processing
        AM        ACE Manual
        ANDIP     American National Directory for Information Processing
        ANSI      American National Standards Institute
        ASCE      Association Service Control Elements (OSI)
        ASN       Abstract Syntax Notation (OSI)
        ATCCIS    Army Tactical Command and Control Information System
                  (SHAPE)
        ATP       Allied Tactical Publication

        C2        Command and Control
        CCIS      Command and Control Information System
        CCITT     Comite Consultatif International de Telegraphique et Telephonique
                  (International Telegraph and Telephone Consultative Committee)
        CIEG      Common Information Exchange Glossary
        CIEL      Common Information Exchange Language

        DAFTG     Database Architecture Framework Task Group (ANSI)
        DALIMS    NATO Data Link Message Standards
        DMF       Data Management Facility (ATCCIS)
        DMRM      Data Management Reference Model
        DMS       Data Management Subsystem (ACE CCIS)
        DP        Draft Proposal (ISO)

        FORMETS   NATO Message Text Formatting System

        GLOT      Glossary of Operational Terms

        ICSI      International Coding System Identifier (ISO DP 7826)
        IEC       International Electrotechnical Commission
        IER       Information Exchange Requirement
        IRDS      Information Resource Dictionary System
        ISO       International Organization for Standardization

                                       73
                           NATO UNCLASSIFIED
                     Releasable for Internet transmission
WP 7L                         UNCLASSIFIED                              June 1989
                     Releasable for Internet transmission
        ISWG      Information Systems Working Group (NACISO)

        JTC       Joint Technical Committee

        LTDP      Long-Term Defense Plan (NATO)

        M         Modifier
        MAS       Military Agency for Standardization (NATO)
        MTF       Message Text Format

        NACISA    NATO Communications and Information Systems Agency
        NACISC    NATO Communications and Information Systems Committee
        NACISO    NATO Communications and Information Systems Organization
        NCCIS     NATO Command and Control Information System
        NCIS      NATO Common Interoperability Standards
        NIAG      NATO Industrial Advisory Group
        NIMP      NATO Interoperability Management Plan
        NIPD      NATO Interoperability Planning Document
        NIST      U.S. National Institute of Science and Technology
        NISTIR    NBS Interim Report

        OSI       Open Systems Interconnection

        PW        Prime Word
        PWG       Permanent Working Group

        Q         Qualifier

        SC        Sub-committee (ISO); Study Committee
        SCF       Service Control Facility (ATCCIS)
        SG        Sub-group
        SHAPE     Supreme Headquarters Allied Powers Europe (NATO)
        SMF       System Management Facility (ATCCIS)
        STANAG    NATO Standardization Agreement
        STC       SHAPE Technical Centre
        STRADIS   Structured Analysis, Design, and Implementation of Information
                  Systems

        TADIL     Tactical Data Link
        TCIS      Technical Common Interface Standards (TSGCEE SG9)
        TF        Transfer Facility (ATCCIS)
        TM        Technical Manual
                                      74
                           NATO UNCLASSIFIED
                     Releasable for Internet transmission
WP 7L                       UNCLASSIFIED                            June 1989
                   Releasable for Internet transmission
        TSGCEE   Tri-Service Group for Communications Electronic Equipment

        WG       Working Group
        WP       Working Paper (ATCCIS)




                                    75
                         NATO UNCLASSIFIED
                   Releasable for Internet transmission
WP 7L            UNCLASSIFIED                    June 1989
        Releasable for Internet transmission




         (This page intentionally left blank.)




                          76
              NATO UNCLASSIFIED
        Releasable for Internet transmission
                               UNCLASSIFIED
                      Releasable for Internet transmission



                             REFERENCES
1.    "Develop ADP and Communications Support Concepts," ATCCIS Phase II Work
      Plan, Edition 2, 15 September 1986, NATO UNCLASSIFIED.
2.    ATCCIS Working Paper 25, "Technical Standards for the ATCCIS Architecture,"
      Edition 1, September 1988, NATO UNCLASSIFIED.
3.    The Need for Standardisation of Data Management and Data Base Information
      Exchange in the NATO CCIS, Enclosure 2 to ADSIA-RCA-WP/44(Revised),
      ADSIA, September 1987, NATO UNCLASSIFIED.
4.    ACE Manual 96-1-4, Data Management, SHAPE, 30 October 1988, NATO
      UNCLASSIFIED.
5.    Data Management Standardisation for ACE ACCIS, TM-776, SHAPE Technical
      Center, July 1985, NATO UNCLASSIFIED.
6.    "Policy for Data Management in NATO CCIS," Memorandum for the Chairman of
      the ISWG, ADSIA-RCA-C-14-88, Capt E. Happach (GENA), 25 January 1988,
      NATO UNCLASSIFIED.
7.    NATO Interoperability Management Plan (NIMP), Second Edition (1988),
      AC/259-D/1274 (Revised) and AC/317-D/33, Conference of National Armaments
      Directors and NATO Communications and Information Systems Committee, 20
      February 1989, NATO UNCLASSIFIED.
8.    NATO Interoperability Planning Document (NIPD), Volume 2, Draft Edition,
      ADSIA-REC-WP/59, Allied Data Systems Interoperability Agency, 29 January
      1989, NATO UNCLASSIFIED.
9.    "Sequence and Schedule for the Development of the NIPD Volumes," ADSIA-
      RCA-WP-49(2nd Revise), Chairman ADSIA, 27 April 1988, NATO
      UNCLASSIFIED.
10.   "Data Base Information Exchange and Data Management Standards," Annex AA
      to ADSIA-RCX-DS/22, G. van Domselaar, 22nd ADSIA Plenary, 17-21 October
      1988, NATO UNCLASSIFIED.
11.   DP 7826, Representation of Data Elements, 2nd Draft, JTC1/SC14, International
      Standards Organization, 28 April 1988, UNCLASSIFIED.
12.   Discussions with William Kenworthy, Chair, ISO JTC1/SC14, and Chair, ANSI
      X3L8, 28 December 1988, UNCLASSIFIED.
13.   AAP-6, NATO Glossary of Terms and Definitions, Change 2, April 1984, NATO
      UNCLASSIFIED.
14.   ADatP-1 (STANAG 5550), NATO Standards Data Elements, Data Items, and
      Codes, NATO UNCLASSIFIED. [HISTORICAL REFERENCE]
15.   ADatP-2(D), NATO Glossary of Automatic Data Processing (ADP) Terms and
      Definitions, December 1985, NATO UNCLASSIFIED.
16.   ADatP-3 (STANAG 5500), NATO Message Text Formatting Systems, Part IV,
      Catalog of Standard Field Formats, December 1986, NATO UNCLASSIFIED.
17.   ACP 167(F), Glossary of Communications-Electronics Terms, NATO, August
      1981, UNCLASSIFIED.
18.   "NATO Technical Interoperability Standards (NTIS) Transition Strategy,"
      AC/302-D/347(3rd Revise), TSGCEE SG9, 20 June 1988, NATO
      UNCLASSIFIED.
19.   Guide on Data Entity Naming Conventions, NIST Special Publication 500-149,
      National Institute of Standards and Technology, October 1987, UNCLASSIFIED.

                                       77
                            NATO UNCLASSIFIED
                      Releasable for Internet transmission
WP 7L                            UNCLASSIFIED                             June 1989
                        Releasable for Internet transmission

20.     ACE Manual 96-1-2, STRADIS Introduction and Implementation, NATO
        UNCLASSIFIED.
21.     ACE Manual 96-1-3, STRADIS Reference Manual, NATO UNCLASSIFIED.
22.     Structured Design, Edward Yourdon and Larry L. Constantine, 2nd Edition,
        Prentice-Hall, Englewood Cliffs, New Jersey, 1979.
23.     Structured Analysis and System Specification, Tom DeMarco, Yourdon Press, New
        York, 1978.
24.     Structured Systems Analysis: Tools, and Techniques, Chris Gane and Trish
        Sarson, Improved Systems Technologies, Inc., New York, 1979.
25.     Structured Walkthroughs, Edward Yourdon, Third Edition, Yourdon Press, New
        York, 1985.
26.     Computer Data-Base Organization, James Martin, Prentice-Hall, Englewood
        Cliffs, New Jersey, 1975.
27.     "CIEL Discussion Paper," Prepared by H. Jansson for TSGCEE SG9, Protocoles
        Standards de Communication, Inc., January 1986, UNCLASSIFIED.
        [HISTORICAL REFERENCE]
28.     Common Information Exchange Language (CIEL), Annex D, NATO
        Interoperability Planning Document (NIPD), ADSIA-D/3 (early draft, now
        abandoned), UNCLASSIFIED. [HISTORICAL REFERENCE]
29.     "Representation Form--Common Information Structure," ADSIA-RCA-C-132-87
        (Correspondence on ADSIA-RCA-WP/53), 3 September 1987, ADSIA Chairman,
        NATO UNCLASSIFIED.
30.     ADatP-5, NATO Data Link Message Standards (DALIMS), NATO
        UNCLASSIFIED. [HISTORICAL REFERENCE]
31.     ISO 8824, Abstract Syntax Notation One, UNCLASSIFIED.
32.     ISO 8825, Basic Encoding Rules for Abstract Syntax Notation One,
        UNCLASSIFIED.
33.     15th ADSIA Plenary, ADSIA-RCA/RDX-DS/15, 24 January 1986.
34.     "Common Information Exchange Glossary," ADSIA-RCA-C-59-86, Cover
        Memorandum, 23 July 1986, NATO UNCLASSIFIED.
35.     "Representational Form--Common Information Structure," Working Paper,
        ADSIA-RCA-WP/53, ADSIA, 8 April 1987, NATO UNCLASSIFIED.
        [HISTORICAL REFERENCE]
36.     "Way Ahead on AAP-25," ADSIA-RCA-C-143-87, 5 October 1987, NATO
        UNCLASSIFIED.
37.     A Technical Overview of the Information Resource Dictionary System (IRDS),
        Second Edition, NIST-IR-88-3700, Alan Goldfine and Patricia Konig, National
        Institute of Standards and Technology, January 1988, UNCLASSIFIED.




                                         78
                              NATO UNCLASSIFIED
                        Releasable for Internet transmission

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:45
posted:3/21/2011
language:English
pages:130