Appendix I (Informative): Compatibility of the Address Standard with the FGDC Geographic Information Framework Data Content Standard for the NDSI

This appendix assesses the compatibility of the Address Standard with the FGDC's Geographic Information Framework Data Content Standard (hereinafter called the "Framework Standard"). This appendix is presented in three sections:

1. Section 1 states why and how the assessment was done, and summarizes the results.
2. Section 2 provides a brief statement of the scope of each part of the framework standard, how the Address Standard is related to that part, and whether the two are consistent.
3. Section 3 shows in detail whether and to what extent the Address Standard meets the conformance tests set forth in Part Zero (Base Part) of the framework standard.

The Framework Standard provides interrelated thematic standards in seven data areas: cadastral, digital orthoimagery, elevation, geodetic control, governmental unit boundaries and other geographic area boundaries, hydrography, and transportation. are considered framework data of critical importance to the spatial data infrastructure of the Nation... The standard is divided into eight parts, one for each of the seven data themes and a base document containing information common to two or more themes.

Address data are used in conjunction with several of the framework themes, most notably cadastral data and transportation data. Addresses and transportation features (especially road networks) are so closely related that their standards are interdependent. Street names form an integral part of thoroughfare addresses, and street segments and their network geometry form the basis for Address Reference Systems and their components. In addition, addresses are used by the public to identify cadastral parcels and specify their locations. Finally, addressed features have elevations; and place names within addresses are often determined by governmental boundaries.

Because address data are closely tied to several framework data themes, the Address Standard should be compatible with the Framework Standard. Compatibility assessment requires two types of tests:

1. Consistency tests, to find whether the Address Standard is consistent with the standards for the seven data themes, and
2. Conformity tests, to determine whether the Address Standard conforms to the requirements set forth in the Base Part of the Framework Standard, which govern the seven thematic parts of the Framework Standard.

The consistency tests evaluate, for each thematic part, whether the part shares any classes, elements, or defined terms with the Address Standard, and if so, whether the shared classes, elements, or terms are defined and used consistently. Three outcomes are possible:

• Unrelated - The Framework part shares no classes, elements, or defined terms with the Address Standard.
• Consistent - The Framework part shares classes, elements, or defined terms with the Address Standard; and they are defined and used consistently; and the two standards are complementary and mutually exclusive in scope.
• Inconsistent - The Framework part shares classes, elements, or defined terms with the Address Standard, but they are not defined and used consistently, and/or the two standards overlap in scope.

The Address Standard relates to the data theme parts as follows:

• Unrelated - Digital Orthoimagery, Geodetic Control, and Hydrography.
• Consistent - Cadastral, Elevation, and Governmental Unit Boundaries and Other Geographic Area Boundaries.
• Inconsistent - Transportation (see I.8.2 below).

Section 3 sets forth the conformance requirements given in the Framework Standard Base Part, section by section, and analyzes whether and how the Address Standard conforms to the requirements. It shows that the Address Standard conforms to all of the requirements.

1. To best serve geographic data users, the Address Standard should provide explicitly for relationships with other standards.
2. This is best done by defining a minimum set of attributes needed to relate features across different themes (e.g. an address to a parcel, or an address to a transportation feature), that is, to provide for the foreign key needed to relate address records to cadastral features or transportation features; and
3. Those key attributes should be defined by reference to the other standard.

The Content Part of the address standard includes two elements, Address Parcel Identifier Source and Address Parcel Identifier, that were created to relate addresses with parcels.

The Content Part of the Address Standard includes five attributes by which an address feature can be related to a transportation event and a transportation segment or path: Address Transportation System Name, Address Transportation System Authority, Address Transportation Feature Type, Address Transportation Feature ID, and Related Transportation Feature ID. In addition, the Content Part includes five address range attributes, so that address ranges can be properly related to the transportation segments or paths they describe: Address Range Type, Address Range Parity, Address Range Side, Address Range Directionality, and Address Range Span.

Within this appendix, quotations from the Framework Standard are italicized and set in quotation marks.

This appendix refers to the May 2008 versions of the Geographic Information Framework Data Content Standard as posted on the FDGC website at: http://www.fgdc.gov/standards/standards_publications/ . Complete citations are given in Part 6 of the Standard.

2.1.1 Scope of Part 0: Base.

The Base Part provides A high-level view of the seven framework data themes[,] [a]n overall integrating Unified Modeling Language (UML) model that is supplemented by detail in the part for each data theme, [and] [t]erminology and other information common to two or more themes (Part 0, Sec 1.2).

A high-level view of the seven framework data themes[,] [a]n overall integrating Unified Modeling Language (UML) model that is supplemented by detail in the part for each data theme, [and] [t]erminology and other information common to two or more themes

The Base Part defines the abstract model that underlies and unifies the seven data themes. It sets forth, for the data themes, specific conformance requirements as to definitions of terms and abbreviations, UML model notation, data dictionary content and formatting, element and attribute naming, incorporation of metadata and record identifiers, and conformance to ISO reference standards and the abstract framework data model.

2.1.2. Relation of Part 0 to Address Standard.

To be compatible with the Framework Standard, the Address Standard must meet the conformance requirements given in the Base Part, or at least not contradict them. As shown in the detailed analysis in Section 3, the Address Standard conforms to all of the requirements.

2.1.3. Conclusion

The Address Standard conforms to the Base Part.

2.2.1. Scope of Part 1: Cadastral.

Part 1 "provides the information necessary to identify the existence of parcel-level cadastral information and the source of that information." (Part 1, Sec. 1).

provides the information necessary to identify the existence of parcel-level cadastral information and the source of that information.

Part 1 is a profile of the FGDC's Cadastral Data Content Standard (FGDC-STD-003). The Cadastral Data Content Standard "contains the standardization of the definition of entities and objects related to cadastral information including survey measurements, transactions related to interests in land, general property descriptions, and boundary and corner evidence data." (Part 1, Introduction).

2.2.2. Relation of Part 1 and the Cadastral Data Content Standard to the Address Standard.

The Address Standard is consistent with both the Cadastral Part of Framework Standard and the Cadastral Data Content Standard. The Address Standard includes two address attributes, Address Parcel Identifier and Address Parcel Identifier Source, both defined by reference to the Cadastral Data Content Standard. They correspond to the Parcel ID and Source Identifier (or Parcel ID Assigner) elements, respectively, in the Cadastral Part and the Cadastral Data Content Standard.

Because addresses and parcels are created and altered independently of each other, no specific address-parcel relationship can be assumed. They should be treated as independent entities, and the relationship between them should be considered, in relational database terms, as a many-to-many relationship--that is, an address can relate to any number of parcels, and a parcel can relate to any number of addresses.

The Address Parcel Identifier and the Address Parcel Identifier Source are both defined by reference to the Cadastral Standard, and they are the only parcel elements included or needed within the Address Standard. Except for those two attributes, the Address and Cadastral Standards do not share any defined terms, data elements, or data classes. All other parcel elements are defined within the Cadastral Standard and need not be repeated in the Address Standard. All address elements and classes are defined in the Address Standard and need not be repeated in the Cadastral Standard. Thus the two standards are consistent in their shared elements, and mutually exclusive and complementary in their scopes.

2.2.3. Conclusion

The Address Standard is consistent with the Framework Standard Cadastral Part

2.3.1 Scope of Part 2: Digital Orthoimagery.

Part 2 "specifies data content and logical structure for the description and interchange of framework digital orthoimagery. To a certain extent, it also provides guidelines for the acquisition and processing of imagery (leading toward the generation of digital orthoimagery), and specifies the documentation of those acquisition and processing steps." (Part 2, Sec 1.1)

2.3.2 Relation of Part 2 to Address Standard.

The Address Standard does not refer to digital orthoimagery, and it does not share any defined terms, data elements, or data classes with Part 2.

2.3.3. Conclusion

The Address Standard is unrelated to the Digital Orthoimagery Part.

2.4.1. Scope of Part 3: Elevation.

Part 3 "defines the geospatial data model entities and attributes that permit the exchange of digital elevation data consistent with the National Spatial Data Infrastructures (NSDI) framework for elevation data." (Part 3, Sec. 1)

2.4.2 Relation of Part 3 to Address Standard.

The Address Standard includes address attributes that define horizontal and vertical coordinates for address points, and the coordinate reference system to which the coordinates are referenced. The attributes are:

Horizontal: Address XCoordinate, Address YCoordinate, Address Longitude, Address Latitude, USNational Grid Coordinate

Vertical: Address Elevation

Coordinate Reference System: Address Coordinate Reference System ID, Address Coordinate Reference System Authority; Complex Element: Address Coordinate Reference System

The address attributes listed above are consistent with Part 3, and otherwise the two standards are independent and unrelated.

2.4.3 Conclusion

The Address Standard is consistent with the Elevation Part.

2.5.1. Scope of Part 4: Geodetic Control.

Part 4 "provides a common methodology for creating datasets of horizontal coordinate values and vertical coordinate values for geodetic control points represented by survey monuments, such as brass disks and rod marks. It provides a single data structure for relating coordinate values obtained by one geodetic survey method (for example, a classical line-of-sight traverse) with coordinate values obtained by another geodetic survey method (for example, a Global Positioning System geodetic control survey)." (Part 4, Sec .1.2)

2.5.2 Relation of Part 4 to Address Standard.

The Address Standard does not refer to control points, and it does not share any defined terms, data elements, or data classes with Part 4.

2.5.3. Conclusion

The Address Standard is unrelated to the Geodetic Control Part.

2.6.1. Scope of Part 5: Governmental Units and Other Geographic Area Boundaries.

"The purpose of ...Part 5...is to establish the content requirements for the collection and interchange of governmental units and other geographic area boundary data and to facilitate the maintenance and use of that information." (Part 5, Sec 1).

The part recognizes four types of areas (definitions are quoted from Part 5, Sec.5.5):

• governmental unit - "geographic area with legally defined boundaries established under Federal, Tribal, State, or local law, and with the authority to elect or appoint officials and raise revenues through taxes" (Sec. 5.5.12)
• administrative unit - "area established by rule, treaty, or regulation of a legislative, executive, or judicial governmental authority, a non-profit organization, or private industry for the execution of some function" (Sec. 5.5.1)
• statistical unit - "geographic area defined for the collection, tabulation, and/or publication of demographic, and/or other statistical data" (sec. 5.5.20)
• other unit - "geographic area that is not a governmental unit, administrative unit, or statistical unit, as defined herein, and that is not an area defined or described in other framework parts" (Sec. 5.5.17)

2.6.2. Relation of Part 5 to Address Standard.

The Address Standard is related to the Governmental Units and other Geographic Area Boundaries Part in two ways:

1. Government unit names and other geographic area names often also serve as address Place Names, State Names, or Country Names.
2. Part 5 defines boundaries and spatial relationships. The Data Quality Part of the address standard uses spatial relationships to test whether the address is within the polygon that represents the address Place Name(s), State Name, or Country Name.

To provide for consistency of terminology:

1. The Address Standard definition of Place Name is based in part on the Framework Standard Part 5.
2. Tables 11, 13, and 15 of Part 5, which provide an extensive list of terms and definitions for various types of communities and local governments, are cited in the Address Standard Place Name notes.
3. Relevant terms from tables 11, 13, and 15 are listed in the Address Standard under Place Name as Other Common Names for the Element.
4. The Address Standard notes for State Name cite the definition of state given in Framework Standard part 5, Table 13.
5. The Address Standard definition of Country Name incorporates the definition of country given in Framework Standard part 5, Table 13.

The data quality tests use boundary polygons and spatial relationships in a manner consistent with the definitions of Part 5.

2.6.3. Conclusion

The Address Standard is consistent with the Governmental Units and other Geographic Area Boundaries Part.

2.7.1. Scope of Part 6: Hydrography.

"The purpose of ... Part 6 ... is to establish the content requirements for the collection and interchange of hydrography features and to facilitate the maintenance and use of that information by all users of geographic information. The Hydrography part identifies and defines terminology, encoding schema, and the data components required for describing hydrographic features, along with the metadata needed for the hydrography data exchange.... The scope of this part is limited to the information regarding surface water features and hydrographic networks for the purpose of cartography and network analysis." (Part 6, Sec. 1.1)

2.7.2. Relation of Part 6 to Address Standard.

The Address Standard does not refer to hydrography or hydrographic features, and it does not share any defined terms, data elements, or data classes with Part 6.

2.7.3. Conclusion

The Address Standard is unrelated to the Hydrography Part.

2.8.1 Scope of Part 7: Transportation.

Part 7 "defines the data model for describing transportation systems components of transportation systems for five [sic] modes that compose the Transportation theme of the NSDI." (Part 7, Sec. 1).

Part 7 is comprised of five sub-parts: the Transportation Base Part (Part 7), and Rail, Roads, Transit, and Inland Waterways (Parts 7b through 7e). (Part 7a, Transportation - Air, was drafted but not endorsed.) The Base, Roads, and Transit subparts are especially germane to the Address Standard.

2.8.2 Relation of Part 7 to Address Standard.

Addresses and transportation networks--and the standards that define them--are so closely related as to be interdependent. In particular, the thoroughfare address classes locate addresses by reference to a thoroughfare; thoroughfare networks are defined and described in the Transportation Part of the Framework Standard. Appendix H (informative) describes the interdependence and complementarity of the two standards in detail.

The Address Standard includes five elements by which an address feature can be related to a transportation event and a transportation segment or path: Address Transportation System Name, Address Transportation System Authority, Address Transportation Feature Type, Address Transportation Feature ID, and Related Transportation Feature ID.

The Address Standard includes five address range attributes, so that address ranges can be properly related to the transportation segments they describe: Address Range Type, Address Range Parity, Address Range Side, Address Range Directionality, and Address Range Span.

These elements are defined to incorporate by reference the transportation model defined in the Transportation Part, without overlapping it.

Because the Transportation Part was completed before the Address Standard was started, it overlaps with the Address Standard in certain respects. Within the Transit subpart, Annex D (Informative) describes an address extension to the transit model. The model is inconsistent with the Address Standard. In addition, the following classes, attributes, and code list values overlap and in some respects are inconsistent with elements in the Address Standard:

1. Transit, Table 1 (Data Dictionary for TransitStop) attributes: address, street side
2. Transit, Table 10(Data Dictionary for Landmark) class and attributes: Landmark, landmarkName, landmarkType, address
3. Transit, Table 11 (Data Dictionary for Facility) attributes: address
4. Roads, Table 3 (Code List for RoadLinearEventType) code list values: directionalPrefix, directionalSuffix, addressInformation, alternateNameBody, alternateNameText, alternateStreetName, alternateStreetNameBody, alternateStreetNameText, firstHouseNumber, houseNumberRange, houseNumberStructure, intermediateHouseNumber, lastHouseNumber, postalCode

2.8.3 Conclusion

The Address Standard and the Transportation Part are inconsistent. They can be made consistent by replacing or redefining Annex D and the class, attributes and values listed above with reference to the Address Standard.

Framework Base Part Section 1 states the scope of the Framework Standard, the Base Part and the seven data theme parts. It is descriptive; it imposes no conformance requirements that would apply to the Address Standard.

Framework Base Part Section 2 states in full: "2. Conformance. Each thematic part of the Framework Data Content Standard includes a data dictionary based on the conceptual schema presented in that part. To conform to the standard, a thematic dataset shall satisfy the requirements of the data dictionary for that theme. It shall include a value for each mandatory element, and a value for each conditional element for which the condition is true. It may contain values for any optional element. The data type of each value shall be that specified for the element in the data dictionary and the value shall lie within the domain specified for the element."

Address Standard Conformance to Section 2: The Address Standard includes a data dictionary (the Content Part) and a conceptual schema (the XSD in the Exchange Part). The Content Part provides data types and (if applicable) domains for each elements and attribute. The Classification Part shows which elements are mandatory for each class. The Address Standard thus includes all information needed to determine whether a given dataset conforms to the standard.

Framework Base Part Section 3 refers to Annex A, which lists normative references to standards that affect two or more parts of the Framework Data Content Standard. This section imposes no conformance requirements that apply to the Address Standard.

Framework Base Part Section 4 states that the FGDC is the maintenance authority for the Base Part, and it provides a contact point for questions. This section imposes no conformance requirements that would apply to the Address Standard.

Framework Base Part Section 5 defines terms used in the Base Part part or common to two or more parts of the standard. Two of the terms are pertinent to the Address Standard:

"5.12 data content standard standard that specifies what information is contained within a geospatial dataset and provides an application schema"

Address Standard Conformance to 5.12: The Address Standard specifies what information is contained within an address dataset and provides an address schema. Thus the Address Standard fits the definition of a data content standard.

"5.22 feature type category of real world phenomena with common properties [ISO 19126]"

Address Standard Conformance to 5.22: Addresses are real world phenomena with common properties. The Classification Part of the Address Standard specifies the common properties of the various classes of addresses. Addresses therefore meet the definition of "feature type."

Framework Base Part Section 6 lists abbreviations used in the Base Part or common to two or more parts of the Framework Standard. Abbreviations used in the Address Standard are consistent with the abbreviations listed in the Base Part.

3.7.1 Conformance to Base Part Subsection 7.1: Unified Modeling Language (UML) model

Framework Base Part Section 7.1 reads in full: "7.1 Unified Modeling Language (UML) model. A data model expressed in UML is provided in each theme part in one of the following ways:

• Incorporated in the body text in each section that needs it
• Incorporated in the body text in a UML model-only section
• Incorporated in a normative annex and referenced in the body text
• Incorporated in the body text, but only at a high level or in a general way with detailed data components of the model presented in a normative annex

"The use of UML class diagrams in the Framework Data Content Standard is an application-neutral approach to depict the inherent description of and relationships among data entities. These diagrams should neither be interpreted as requiring object-oriented implementation methods or interfaces are not typically shown on these data classes nor should they be interpreted as representing tables in relational databases. Instead, the UML classes should be used as the basis for translation to and from internal organization data stores and applications. UML modeling environments typically support conversion of logical UML models into implementations in various programming environments through rule-based transforms."

Address Standard Conformance to Base Part 7.1: The Data Exchange Part provides a UML model of the standard, and a complete XSD.

3.7.2 Conformance to Base Part Subsection 7.2: Dependence on ISO 19100 series of geographic information standards

Framework Base Part Section 7.2 reads in full: "7.2 Dependence on ISO 19100 series of geographic information standards. The Framework Data Content Standard is dependent on structures and concepts from several standards in the ISO 19100 series of geographic information standards, as shown in Figure 1. Full titles for these standards are found in Annex A. The digital orthoimagery and elevation data parts also are dependent on ISO 19123. Data standards for certain transportation modes are dependent on ISO 19133. All parts have dependencies on ISO 19107, ISO 19108, ISO 19109, ISO 19111, and ISO 19115."

Address Standard Conformance to Base Part 7.2. The Address Standard is not directly dependent on any of the ISO 19100 series of geographic information standards, because there is no ISO 19100 standard for addresses. To the extent that the Address Standard is indirectly dependent on other ISO standards that govern the Framework Standard, conformance to this section (7.2) is shown by the conformance of the Address Standard to the Base Part of the Framework Standard.

3.7.3 Conformance to Base Part Subsection 7.3: Application schema

Framework Base Part Section 7.3 reads in full: "7.3 Application schema. Each of the thematic Framework Data Content Standard parts includes an integrated application schema expressed in the Unified Modeling Language (UML) according to ISO 19109, Geographic information Rules for application schema, and its normative references. The application schema specifies, as appropriate, the feature types, attribute types, attribute domain, feature relationships, spatial representation, data organization, and metadata that define the information content of a dataset.

"The UML models included in the parts of the standard describe the common content and structures that can be exchanged between members of the geospatial community. The use of UML and abstract modeling concepts allows the standard to be technology independent but permits current and future implementation cases to be derived from the UML model.

"Whenever possible, the standard references abstract UML object types from the ISO 19100 series of standards and OGC specifications. Specialization of these classes of objects allows each theme to inherit properties and behaviors and ensure their propagation when transformed into an encoding such as XML.

"UML concepts and notation are described in Annex B." (Base Part subsection 7.3, quoted in full)

Address Standard Conformance to Base Part 7.3. The UML model and XSD provided in the Data Exchange Part express an integrated application schema that define the information content of the standard.

Address Standard Conformance to Base Part 7.3.

3.7.4 Conformance to Base Part Subsection 7.4: Data dictionary

3.7.4.1 Conformance to Base Part Subsection 7.4.1: General requirements

Framework Base Part Section 7.4.1 reads in full: "7.4.1 General requirements. Each of the thematic Framework Data Content Standard parts contains, as appropriate, documentation of all features, attributes, and relationships and their definitions. A data dictionary table describes the characteristics of the UML model diagrams.

"The data dictionary (see Table 1) is structured as follows:

• Each UML model class equates to a data dictionary entity
• Each UML model class attribute equates to a data dictionary element
• Each UML model role name equates to a data dictionary element
• The shaded rows define entities
• The entities and elements within the data dictionary are defined by six attributes based on those specified in ISO/IEC 11179-3 for the description of data element concepts, that is, data elements without representation."

Address Standard Conformance to Base Part 7.4.1. The Address Standard Content Part provides a data dictionary of all the elements and attributes specified in the address standard . The dictionary provides the required information about each element and attribute, and extends the base standard by including additional items.

In the Address Standard each address data element is described by giving its:

1. Element name: The name of the element.
2. Other common names for this element: Common words or phrases having the same or similar meaning as the element name.
3. Definition: The meaning of the element.
4. Definition Source: The source of the definition. ("New" indicates that the definition is original.)
5. Data Type: Whether the element is a characterString, integer, datetime, etc.
6. Existing Standards for this Element: Other standards that govern this element (if any).
7. Domain of Values for this Element: The range or set of values (if any) to which the element is restricted.
8. Source of Values: The source (if any) for the domain of values.
9. How Defined: How the domain of values is defined.
10. Example: Illustrative examples of the element.
11. Notes/Comments: Notes and comments giving further explanation about the element.
12. XML Tag: The XML tag for the element.
13. XML Model: XML model of the element.
14. XML Example: The XML model applied to a specific example of the element.
15. XML Notes: Explanatory notes about the XML model.
16. Quality Measures: Quality tests applied to the class.
17. Quality Notes: Explanatory notes about the quality measures applied to this element.

The list above includes all the information required by the Base Part 7.4.1. Specifically:

• Name/Role Name is provided under Element Name
• Definition is provided under Definition
• Obligation/Condition is provided in the XML model
• Maximum Occurrence is provided in the XML model
• Data Type is provided under Data Type
• Domain is provided under Domain of Values for this Element

The Address Standard data dictionary includes additional information to encourage widespread and consistent use of the standard by providing clear and complete explanatory information, notes, and examples about each element and attribute. The documentation for address data elements in the Address Standard meets the requirements used by the Framework Data Standard, and provides for additional attributes.

3.7.4.2 Conformance to Base Part Subsection 7.4.2: Name/Role name

Framework Base Part Section 7.4.2 reads in full: "7.4.2: Name/Role name. The name/role name is a label assigned to a data dictionary entity or to a data dictionary element.

The class name begins with an upper case letter. Spaces do not appear in an entity name: instead, multiple words are concatenated, with each word starting with a capital letter (example: XnnnYmmm). Entity names are unique within a data theme.

Element names start with a lower case letter. Spaces do not appear in an element name: instead, multiple words are concatenated, with subsequent words starting with a capital letter (example: xnnnYmmm). Element names are unique within an entity. Combinations of the entity and element names (example: Dataset.name) are therefore unique within a data theme.

Role names are used to identify the roles of the classes at the ends of a model association and are preceded by the term "Role name" followed by a colon to distinguish them from other types of data dictionary elements."

Address Standard Conformance to Base Part 7.4.2. The Address Standard conforms to this section in substance, but not in form:

1. The Address Standard (specifically the content and class parts) provides unique names for every element, attribute, and class.
2. Consistent naming conventions are used for for class, element, and attribute names and XML tags.
3. The Address Standard does not define any roles nor specify any role names.

3.7.4.3 Conformance to Base Part Subsection 7.4.3: Definition

Framework Base Part Section 7.4.3 reads in full: "7.4.3: Definition. The definition is the entity or element description."

Address Standard Conformance to Base Part 7.4.3. The Address Standard (specifically the content and class parts) includes a formal definition for every element, attribute, and class in the standard.

3.7.4.4 Conformance to Base Part Subsection 7.4.4: Obligation/Condition

Framework Base Part Section 7.4.4 reads in full:

"7.4.4.1 General

"Used only in rows that contain elements, Obligation/Condition is a descriptor indicating whether the element shall always be populated (that is, contain a value or values) or sometimes will be populated for every instance of its owning entity. If the element is a role name, then the obligation/condition shall apply to the element indicated by the Data Type. This descriptor may have the following values: M (mandatory), C (conditional), or O (optional).

"7.4.4.2 Mandatory (M)

"Mandatory (M) indicates that the entity or element shall be populated.

"7.4.4.3 Conditional (C) Conditional (C) specifies an electronically manageable condition under which at least one entity or element is mandatory. Conditional is used for one of the three following possibilities:

• Expressing a choice between two or more options. At least one option is mandatory and must be populated
• Populating an entity or element if another element has been populated
• Populating an element if a specific value for another element has been populated.

"To facilitate reading by humans, the specific value is used in plain text (for example, C/not defined by encoding?). However, the code shall be used to verify the condition in electronic user interface,

"If the answer to the condition is positive, then the entity or the element shall be populated.

"7.4.4.4 Optional (O)

"The entity or the element may be populated. Optional (O) entities and optional elements have been defined to provide a guide to those looking to fully document their data. (Use of this common set of defined elements will help promote interoperability among framework data users and producers.) Optional entities may have mandatory elements. If the optional entity is used, the mandatory elements shall be used. If an optional entity is not used, the elements contained within that entity (including mandatory elements) will also not be used."

Address Standard Conformance to Base Part 7.4.4. Obligation/conditionality is indicated in the XML model of each element and attribute, and in syntax descriptions and XML model of each address class.

3.7.4.5 Conformance to Base Part Subsection 7.4.5: Maximum occurrence

Framework Base Part Section 7.4.5 reads in full: "7.4.5: Maximum occurrence Used only in rows that contain elements, maximum occurrence specifies the maximum number of instances the element may have. Single occurrences are shown by 1; unconstrained number of instances are represented by an asterisk *. Fixed number occurrences, other than one, are allowed and will be represented by the corresponding number (that is, 2, 3 and so on). If the element is a role name, then the maximum occurrence shall apply to the element indicated by the Data Type."

Address Standard Conformance to Base Part 7.4.5. The XML model for each class and complex element shows the maximum occurrence for each of the elements and attributes that may comprise it.

3.7.4.6 Conformance to Base Part Subsection 7.4.6: Data type

Framework Base Part Section 7.4.6 reads in full: "7.4.6: Data type. Specifies a set of distinct values for representing the elements (example: integer, real, CharacterString, DateTime, and Boolean). The data type attribute is also used to define stereotypes for entities and entity names for elements which are role names. These data types are generic types that do not infer an implementation." (Base Part 7.4.6, quoted in full)

Address Standard Conformance to Base Part 7.4.6. The data type for each element and attribute is specified in its description in the Content Part. Data types are named and defined in accordance with the Code List for Data Type (see Base Part section 7.8.2.2, Table 4), except for certain address reference system elements, which are geometric. All geometric data types are defined in the Open Geospatial Consortium's "OpenGIS(R) Geography Markup Language (GML) Encoding Standard" version: 3.2.1 (see Part 6 for a complete citation).

3.7.4.7 Conformance to Subsection Base Part 7.4.7: Domain

Framework Base Part Section 7.4.7 reads in full: "7.4.7: Domain. For an entity, the domain indicates line numbers covered by the elements of that entity in the table.

"For an element, the domain specifies the values allowed. Unrestricted indicates that no restrictions are placed on the data type of the element. Code lists provide a list of potential values, although additional values can be used. Enumerations provide a non-extensible list of potential values." (Base Part 7.4.7, quoted in full)

Address Standard Conformance to Base Part 7.4.7. Domain information for each element and attribute is provided in its description in the Content Part. For address classes, no domain information is provided, because no address class has any domains.

3.7.5 Conformance to Subsection Base Part 7.5: Metadata

Framework Base Part Section 7.5 reads in full:

"7.5.1 Requirement for metadata

"All datasets shall have metadata that conforms to at least the minimal set of mandatory elements of either ISO 19115, Geographic Information Metadata, or FGDC-STD-001-1998, Content Standard for Digital Geospatial Metadata (revised June 1988). However, more extensive metadata should be provided.

"7.5.2 Associating metadata entry with data transfer

"The mechanism used to associate a structured metadata entry with a data transfer is not explicitly declared in the Framework Data Content Standard due to possible complex dependencies on either the structure of FGDC or ISO metadata being used. It is the intention of the standard to logically insert the appropriately structured metadata from either standard wherever the class attribute metadata occurs. The implementation of this capability may be specified in the implementation annexes as referenced to external metadata schemas in the appropriate implementation or programming environment."

Address Standard Conformance to Base Part 7.5. The Address Standard incorporates by reference, for address data files, the FGDC"s Content Standard for Digital Geospatial Metadata (CSDGM)(FGDC 1998). The Address Standard extends the CSDGM by providing attributes for record-level address metadata.

3.7.6 Conformance to Subsection Base Part 7.6: Model integration

Framework Base Part Section 7.6 reads in full: "7.6: Model integration. The dependencies among the models specified in the thematic parts of the standard are shown in Figure 2. In Figure 2, the parenthetical text (from Transportation) means that there is a UML package called Transportation in which all transportation constructs reside, including Transportation Base."

Address Standard Conformance to Base Part 7.6. If the Address Standard were to be incorporated into the Framework Data Standard, it would be instantiated by and dependent on the Base Part. Relations between the Address Standard and the Framework data themes (especially Transportation and Cadastral themes) are described in Section 2 of this Appendix.

3.7.7 Conformance to Subsection Base Part 7.7: Establishment of identifiers

Framework Base Part Section 7.7 reads in full (omitting the footnote): "7.7: Establishment of identifiers. Every UML class that represents a feature type includes attributes for identifier and an optional identifier authority. This construct can be used to distinguish between similar values in different datasets. Policies may be developed within a community for assigning namespaces and permanent identifiers to features and expressing equivalencies among features that have been assigned different namespaces and, therefore, different identifiers, which may be permanent. If there is no standard way to create and manage identifiers, users may develop their own schema and include its description in the dataset metadata."

Address Standard Conformance to Base Part 7.7. The Address Standard defines an address attributes, Address ID, to serve as an address identifier, and another attribute, Address Authority, to serve as an authority identifier. Address ID may be implemented as a local ID or as a UUID.

3.7.8 Conformance to Base Part Subsection 7.8: Framework feature model and common classes

3.7.8.1 Conformance to Subsection Base Part 7.8.1: Introduction

Framework Base Part Section 7.8.1 reads in full: "7.8.1: Introduction. The Framework Data Content Standard organizes information using the ISO General Feature Model [ISO 19109]. Features are abstractions of real-world phenomena or man-made constructs that typically have a persistent or assigned identity, such as a name or code, a location represented by a formalized geometry, and a set of other properties and relationships.

"Each framework theme, represented by a part in the standard, documents one or more formal feature types using a logical information model (attributes, associations, conditionality) represented as class diagrams in UML. All feature types (see darker shaded classes in Figure 3) are denoted in UML using the stereotype <>. All features in every part of the standard are subclasses of this common framework Feature and thus inherit its properties as shown in the diagram. Except for identifier, all properties are optional and most of them are repeatable.

"All classes stereotyped as <> implement the Abstract class named "Feature" in the Base and inherit all of its properties. Likewise, any class stereotyped as <> implements the Abstract class of the same name in the Base and inherits its property of "metadata". Inheritance is also shown through an italicized parent classname in the upper right corner of the child class.

"The Framework Data Content Standard supports the transfer of geographic data from one party to another. A group of features, known as a feature collection, would define a transfer. Metadata may be associated with the contents of the transfer, as is done now with FGDC "dataset-level" metadata. This feature collection may include features from one or more thematic parts of the standard, depending on the application and its requirements.

"Table 2 represents the information from Figure 3 in data dictionary format.

"Table 2 represents the information from Figure 3 in data dictionary format.

Table 2 Description of common UML classes

"The extensibility mechanism shown in Figure 3 (ExtendedAttribute) allows for the description and transfer of additional ad hoc data content without requiring changes or extensions to the data schema. This repeatable structure may carry one or more additional attributes and their values for use in peer-to-peer transfer of unofficial feature properties. Any feature class may incorporate this reference to the ExtendedAttribute class. The link property of ExtendedAttribute expands to a triplet of elements associated with a Uniform Resource Locator (URL) for external documentation. Some ResourceTypes are shown as a code list to characterize the information content found at the referenced URL. For Transportation parts of this standard, events provide an alternative method of extending attributes when their values are not necessarily constant for the entire length of a feature."

Address Standard Conformance to Base Part 7.8.1. The Address Standard meets this requirement. Addresses meet the definition of feature. The Classification Part defines an abstract Address class and defines subclasses of the feature addresses, using a logical information model. The model is presented as both a UML model and an XSD. The Standard supports both record-level and file-level metadata, and the Exchange Part provides a template for both monolithic and transactional exchanges. The data model is extensible.

3.7.8.2 Conformance to Base Part Subsection 7.8.2: Code lists

Framework Base Part Section 7.8.2 reads in full:

"7.8.2.1 ResourceType code list

"ResourceType is a CodeList of values for the attribute urlType.

"Table 3 CodeList for ResourceType

Name	Definition
database	Collection of records where each record has the same structure of data elements
documentation	Resource file that describes usage of referenced URL
dtd	Schema expressed via a set of declarations written in Document Type Definition (DTD) language*
metadata 19115_19139	Metadata records formatted using structure from ISO 19115, Geographic information Metadata, and ISO 19139, Geographic information Metadata - XML schema implementation
metadataFGDC	Metadata records formatted using structure from a version of the FGDC Content Standard for Digital Geospatial Metadata
webPage	Resource on the World Wide Web usually in Hypertext Markup Language (HTML) format
webSite	Collection of Web pages that common to a particular domain name or subdomain on the World Wide Web
xmlSchema	Schema expressed using a version of the XML Schema World Wide Web Consortium (W3C) Recommendation

"7.8.2.2 DataType code list

"DataType is a CodeList of values for the attribute dataType.

"Table 4 CodeList for DataType

Name	Definition
boolean	True or False
characterString	A CharacterString is an arbitrary-length sequence of characters including accents and special characters from repertoire of one of the adopted character sets
date	Values for year, month, and day
dateTime	A combination of year, month, and day and hour, minute, and second
integer	Any member of the set of positive whole numbers, negative whole numbers and zero
number	One of a series of symbols of unique meaning in a fixed order which may be derived by counting
real	Real numbers are all numbers that can be written as a possibly never repeating decimal fraction
url	Network accessible resource in the form of a Uniform Resource Identifier (URI)

Address Standard Conformance to Base Part 7.8.2. All data types in the data dictionary conform to the code list in Table 4, except for certain address reference system elements, which are geometric features. The Address Standard includes no resource types, so Table 3 does not apply to the Address Standard.

Framework Base Part Section 8 reads in full: "8: Encoding of framework data content. To support data exchange, the parts of the Framework Data Content Standard may include informative annexes that provide guidance to implementers on the transformation of the UML information content into a specific encoding environment. These annexes not only document the context and environment of implementation and validation schema for the information content unique to a part of the standard, but also may include encoding or schema representation of heterogeneous collections of features from multiple themes. Because the standard includes a single UML model of all themes that are exposed progressively through a series of limited diagrams in the context of a theme, it represents an integrated set of classes for all framework data."

Address Standard Conformance to Base Part 8. The Address Standard provides both a UML model and an XSD. The XSD provides guidance on the transformation of address information into a specific encoding environment. The Content and Classification Parts of the Address Standard provide XML models for each class, element, and attribute defined in the standard. The Exchange Part of the standard integrates the XML element, attribute, and class models into a single XSD. The XSD provides complete, open, standard XML data exchange templates for both monolithic and transactional data exchanges. For validation tests, similar guidance is provided by inclusion of complete SQL pseudocode in each test defined in the Data Quality Part of the Address Standard.