Go to index.

Section 9: The Master Data Dictionary Transfer

9. The DLG-E Master Data Dictionary Transfer

One of the guiding philosophies of the SDTS is that a transfer should be self-contained, i.e. contain data as well as its meaning. To satisfy the requirements of the SDTS, a data dictionary must accompany a transfer. The data dictionary can be included as part of a transfer or it can be packaged as a separate transfer. For DLG-E, the data dictionary will be separate because it will apply to a series of transfers. The TVP describes the method by which a Master Data Dictionary can be accomplished.

9.1 Module Set for Data Dictionary Transfer

The module set is defined by the TVP. A Master Data Dictionary transfer shall consist of one each of the following modules:

• Identification
• Catalog/Directory
• Lineage
• Completeness
• Data Dictionary/Definition
• Data Dictionary/Domain

The Identification (IDEN) module will identify the transfer as a master data dictionary transfer. It will include the producing organization and the version of the data dictionary. The version number is used when determining which data dictionary applies to which dataset transfer.

The Catalog/Directory (CATD) module will list the modules in the transfer, their version numbers, and the files in which they are located.

The Lineage (DQHL) module will describe the origin of the data dictionary information. As new versions of the Data Dictionary are released a change log summarizing the differences between versions shall be included here.

The Completeness (DQCG) module will describe the overall contents of the data dictionary and to which series of transfers it applies.

The Data Dictionary/Definition (DDDF) module will contain the definitions and/or descriptions of entity and attribute terms, and the authority for the definitions.

The Data Dictionary/Domain (DDOM) module describe the domains for the attributes. It will also define and/or describe attribute values that may need further explanation.

9.2 Module Records for Data Dictionary Transfer

The SDTS contains module specifications for each of the module types needed for the master data dictionary (see Part 1, Section 5 of the SDTS.) A module specification describes a generic record layout with fields and subfields and rules for inclusion and repetition. The specifications for the modules were used to design specific module record layouts for the DLG-E model. This section describes the different types of logical records for each module type.

Each module record layout is described by listing its subfields, describing the information needed for the subfield, and explaining the source of the information. The subfields are defined by the SDTS and are referenced here by their mnemonics. The sources of information are provided in the tables via the use of the following codes:

DSDB     Value extracted from the DLG-E Content Standards 
         Database
TVPA     value or limited range is specified within SDTS 
         as implemented by the Topological Vector Profile
<gen>    Generated value there is a simple generation 
         or counting involved which is normally done within a 
         computer program
Const    Agency has specified a constant value
Ext      Value must be obtained from a source requiring 
         human intervention  (These are typically satisfied by 
         producing auxiliary files of information to be included 
         when a transfer is created.)

9.2.1 Identification Module

There will only be one record in the Identification module.

9.2.2 Catalog/Directory Module

There will be one record for every file of the Master Data Dictionary transfer. If no module is large enough to be split into multiple files, there will be 6 records. (The TVP requires one module per file, allowing file splits only if constrained by file size.)

9.2.3 Data Quality Modules

Only the lineage and completeness portions of the Data Quality Report are permitted for a Master Data Dictionary Transfer.

Lineage Module

Completeness Module

9.2.4 Data Dictionary/Definition Module

Although there is only one DD/Definition module, it contains many distinct groups of records. To describe the contents of this module, its "groups" are discussed individually. Each group has a purpose preceding its module record table. (There is an example Definition Module in Appendix D.)

9.2.4.1 Authority Descriptions

The purpose of Authority Description records is to define the authorities for attribute and entity terms and definitions. (The SDTS term entity refers to DLG-E objects of dataset, theme, surface, feature and relationship.) There is only one authority used in the DLG-E Master Data Dictionary. There are two records in this group, one for the entity authority and one for the attribute authority.

9.2.4.2 Object Type Definitions

The purpose of Object Type Definition records is to define the DLG-E model objects that will be modeled as SDTS entities because they carry attributes and/or participate in relationships. This includes the DLG-E objects of dataset, theme, surface, and feature. There will be four records in this group, one defining each object type.

9.2.4.3 Feature Types

The purpose of Feature Type records is to define all DLG-E feature types as SDTS entities. (Note: The Data Dictionary reflects the set of possible terms. Therefore, all DLG-E feature types will be defined regardless of actual occurrences in any specific dataset.) There will be one record for each feature type as listed in the version 0.12 of the DLG-E Standards Database. (Appendix A which lists the attribute table design for each feature type happens to include a list of the feature types.)

9.2.4.4 Relationship Type Definitions

Certain DLG-E relationship instances will be encoded in SDTS attribute tables (as determined in Section 7.) The relationship types will be treated as SDTS entities. The purpose of Relationship Type Definition records is to define the relationship types from DLG-E that will be modeled as Attribute tables. There will be one record defining each relationship type as listed in Section 7.3.2.2.

9.2.4.5 DSDB Attribute Definitions

The DLG-E Content Standards Database (DSDB) contains the definitions of the attribute terms that are used by feature types, dataset, theme, and surface objects. Not all of the attributes are to be included in the SDTS data dictionary as some map to standard subfields and others are not encoded. Only the attribute terms that will be used as SDTS attributes will be included in this group. The purpose of DSDB Attribute Definition records is to define the attribute terms that are used in an SDTS encoding of DLG-E objects.

The decision to include/exclude an attribute has been made as part of the mapping work described in Section 5 and 6. Appendix B contains the list of attributes that are to be included in the Data Dictionary. There will be one record for every attribute code as listed in Appendix Ba.

9.2.4.6 Relationship Table Column Definitions

Certain DLG-E relationships will be encoded as SDTS attribute tables, as described in Section 7. The purpose of Relationship Table Column Definition records is to define the attribute labels of the attribute tables used to encode relationship instances. There will be one record for every relationship attribute label as listed in the table in Section 7.3.2.1.

9.2.4.7 DPDF Attribute Definitions

There are attribute labels used to encode DLG-E constructs which are not depicted in the DLG-E Standards Database. These attributes represent elements from the DPDF file (i.e. internal structures of the DLG-E implementation) that are to be preserved in transfers. The purpose of DPDF Attribute Definition records is to define these attribute labels. There will be one record for each attribute term as listed in Appendix C.

9.2.5 Data Dictionary/Domain Module

Only the attributes with enumerated domains, numeric ranges, and/or special null values have domain records. For every attribute that uses a FIPS code set for its domain, there shall be one record with the name of the codeset in the DVAL field. For every attribute that has a numeric range domain, there shall be two records--one with minimum and other with maximum. For every attribute with enumerated values, there shall be a record for every value. For every attribute, there shall be a record identifying a specific value for each of its allowable null values (not applicable, unknown, unspecified).

Go back to index.