[Top] [Prev] [Next] [Bottom]

Annex A

(normative)

The Data Dictionary Transfer

A.1 Introduction

This annex describes the method by which master data dictionary transfer will be accomplished. The first section addresses the requirements of the dictionary transfer itself, the next section addresses the requirements of a spatial transfer that will use a dictionary transfer.

A.2 Requirements for Master Data Dictionary Transfer

A.2.1 Required Modules

One each of the following modules is required:

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

No other types of modules shall be included.

A.2.2 Required Contents Per Module

These are requirements in addition to those specified by Parts 1, 2, and 3. This information aids in precisely identifying transfer contents.

Identification Module:

• Title - this subfield shall include text to the effect of "Master Data Dictionary for ..."
• Data Id - this subfield shall include the version number of this release of the master data dictionary
• Data Structure - this subfield shall include "MASTER DATA DICTIONARY"
• Data Set Creation Date - this subfield shall include the date of the last modify to the contents of the data dictionary
• Comment - this subfield shall contain a statement to the effect of "This transfer is intended to be used in conjunction with a spatial data transfer to form a conforming SDTS transfer"
• Composites - this subfield shall contain "N"
• Vector Geometry - this subfield shall contain "N"
• Vector Topology - this subfield shall contain "N"
• Raster - this subfield shall contain "N"
• External Spatial Reference - this subfield shall have a null value meaning "undefined, not relevant;" it is acceptable to specify this by omitting this subfield
• Features Level - this subfield shall contain the feature conformance level ("1", "2", "3", or "4") for transfers which use this master data dictionary.

Catalog/Directory:

• Module Version - this subfield shall include the version number of this release of the master data dictionary.

Lineage:

• Comment - this subfield shall include a change log summarizing the differences between all versions. It should also recommend which old versions would best be replaced by this version.

Completeness:

• Comment - this subfield shall describe the product (transfer) series to which this dictionary applies. If applicable, it shall also note what subset of definitions this transfer contains.

A.2.3 Version Numbering

Version numbers shall have the following form:

• d.nn

where d = a positive integer, with no leading zeroes, and nn = two-digit positive integer. Valid version numbers are 1.01, 1.12, and 2.13. Invalid version numbers are 01.1 and 2.1.

Version numbers shall be incremented according to the following rules. The first released version of a master data dictionary transfer shall be 1.00.

The number "nn" shall be incremented when

a) typographical errors are corrected

b) definitions are enhanced, without meaning being changed

c) a domain is increased

d) unintentionally omitted entities/attributes are added

The number "d" shall be incremented when

a) additional entities/attributes are added

b) meaning of a domain value is changed

Note: When "d" is incremented, "nn" shall restart from "00". A valid sequence of version numbers would be: 1.00, 1.01, 1.02, 2.00, 2.01, 2.02, 2.03, 3.00. Invalid sequence would be 1.0, 1.10, 1.20. Another invalid sequence would be 1.00, 1.01, 1.02, 2.03.

The numbering scheme is intended to help the receiver of a transfer decide which version of a data dictionary is required. The changes in "nn" indicate that changes of a corrective nature have been made, whereas the changes in "d" indicate that something new and different has been added.

A.2.4 Module Naming Conventions

The modules must be named in such a way as to not cause module name conflicts with any module in a Topological Vector Profile transfer. The modules shall be named in the following manner:

		MIDE			Identification
		MDIR			Catalog/Directory
		MQHL			Lineage
		MQCG			Completeness
		MDEF			Data Dictionary/Definition
		MDOM			Data Dictionary/Domain

A.2.5 File Restrictions and Naming Conventions

Each file (ISO 8211 DDF) shall contain information from a single module. Files shall be named using the following convention:

		xxxxMIDE			Identification
		xxxxMDIR			Catalog/Directory
		xxxxMQHL			Lineage
		xxxxMQCG			Completeness
		xxxxMDEF			Data Dictionary/Definition
		xxxxMDOM			Data Dictionary/Domain

 
where xxxx = 4 characters which uniquely identify the data dictionary.  Examples are an agency abbreviation or a data model abbreviation.

When allowed, the extension should be ".DDF" to indicate the type of file transferred; but the last character of this extension or an optional ninth character on the base name may be used in the case of modules that span files. Thus the extension could become ".DDG", ".DDH", ".DDI", ... for multi-volume modules. Such file extenders are optional. Any file that is not ISO 8211 compliant (e.g. adjunct files) shall not have the ".DDx" extension.

A.2.6 Requirements for Transfer Using a Master Data Dictionary

The following restrictions apply to any spatial data transfer that requires the use of a master data dictionary.

a) No Data Dictionary/Definition or Data Dictionary/Domain modules shall be present in this transfer, prior to a merge with a Data Dictionary only transfer.

b) This transfer shall make no references via foreign identifier to module records of the master data dictionary.

c) No module names or file names reserved for a data dictionary transfer shall be used in the spatial data transfer.

To indicate that this transfer requires a master data dictionary, the following modules shall include the following information.

Identification:

• Comment - this subfield shall include a statement to the effect "This transfer requires an external data dictionary from <agency>, with 4-character code of ..., Version number d.nn".

Catalog/Directory:

• There shall be a module record in a Catalog/Directory module for each Data Dictionary module that is required by this transfer.
• External - this subfield shall contain a "Y".
• Module Version - this subfield shall contain the version number of the module referenced in the Name subfield (of this module record).
• Volume - this subfield must not contain a value.

A.2.7 Creating a Complete Transfer

When external transfer modules are merged with a spatial transfer, the appropriate fields in the Catalog/Directory module must be updated - External set to "N", and Volume, file, and record filled if information is present. It is recommended that the Module Version subfield remain as is, so version information is not lost.