SDSFIE Metadata (SDSFIE-M): Conceptual Schema · 28/8/2014 · M) is a standard which defines the...

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE)

SDSFIE Metadata (SDSFIE-M):

Conceptual Schema

Version 1.0.2

(28 AUGUST 2014)

Prepared By:

The Defense Installation Spatial Data Infrastructure (DISDI) Group

Chair:

Office of the Deputy Under Secretary of Defense (Installations & Environment), Business Enterprise Integration Directorate

© 2014

SDSFIE Metadata: Conceptual Schema v1.0.2

i

THIS PAGE IS INTENTIONALLY BLANK


i

Executive Summary

Metadata, data about data, is important and valuable because it enables discovery of information. It I also an aid to data and system interoperability. Metadata describes the source, methods, content and the appropriate use of a data or service. As archived data and imagery grow to enormous volumes, metadata is becoming even more critical. Without good metadata, a consumer cannot search and retrieve data containing the characteristics and content necessary to support their mission. Metadata instills data accountability and limits data liability. The timely capture of metadata is also fundamental to the quality of the data resource as a whole.

For geospatial datasets, accurate, complete and descriptive geospatial metadata is a key component of that dataset and is needed by a rapidly growing geospatial data market to locate available geospatial data and services and assess their quality and lineage, allowing the appropriate understanding, use and exploitation of that geospatial data. Certain geospatial metadata is also used in the DoD Installations and Environment (I&E) community to specify the structure and characteristics of I&E data.

In general, geospatial metadata describes the geospatial data elements used to specify information about features, events, coverages (including, images and elevation surfaces), datasets (collections of such information) and services (capabilities to create, access, display, and/or manipulate such information). Geospatial metadata also specifies characteristics of the values of data items (e.g., the accuracy of a measured height value or the analytic confidence that a type-assignment is correct) and characteristics of datasets (the producer, release date, content summary and the like). In order for a geospatial data resource to be discovered, assessed for its fitness of use, retrieved, and then exchanged, it must comply with certain DoD and international standards that mandate the structure and content of metadata for geospatial information. All the diverse metadata requirements within these various standards that are appropriate for compliance in I&E systems have been brought together under a single umbrella reference standard for ease of use in the I&E community. Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) Metadata (SDSFIE-M) is a standard which defines the conceptual schema profile for specifying geospatial metadata in and for the I&E community. It is the policy of the Deputy Under Secretary of Defense for Installations and Environment that all I&E geospatial data have accompanying metadata, conforming to DoD standards. SDSFIE-M is that standard for the I&E community. This document defines the mandatory and common elements of the SDSFIE-M conceptual schema. This document does not contain the implementation schema for SDSFIE-M. The XML schema implementation of SDSFIE-M, called the SDSFIE Metadata Implementation Schema (SMIS), is defined and provided separately. This document does not contain implementation guidance. Implementation guidance is defined in a separate SDSFIE-M Implementation Guidance document.


ii

Revision History

Description Date Version

Initial DISDIG Approved Version June 12, 2013 1.0

Revision to include modifications as follows:

Changed the name from SMF to SDSFIE-M.

Fixed one typographical error.

Add PresentationFormCode code list that was inadvertently left out of 1.0 specification

Remove ResourceAssociationType code list that was duplicative of the AssociationType code list and unused in the remainder of the specification

Remove the UnclassHandlingCode code list as it duplicates many of the entries in the IC ISM.

Add a free text handlingDescription element to allow for additional information about the restrictions on handling the resource or metadata

Updated the SMF_Feature data type to allow for alias name, model name, description, and note from SDSFIE.

Reintroduced BrowseGraphic element after discussions with the Metadata Working Group.

May 16, 2014 1.0.1

Revision to include modifications as follows:

Aligned code lists (Table 3) to SMIS 1.0.1 document.

Set hierarchyLevel and heirarchyName to multiplicity N to align with NMF 2.2 (Table 7).

changed SMF_RoleCode reference to RoleCode (Table 7).

removed the default value on metadataStandardVersion (Table 7).

Changed the reference to the MetadataStandardNameCode value from sdsfieMetadataFoundation to sdsfieMetadata and the URL from http://metadata.ces.mil/dse/ns/GSIP/codelist/MetadataStandardNameCode/sdsfieMetadataFoundation to http://metadata.ces.mil/dse/ns/DISDI/codelist/MetadataStandardNameCode/sdsfieMetadata (Table 7 and footnote).

Changed MD_Keywords/Type element to MD_Keywords/type (Table 11).

August 28, 2014 1.0.2


iii

Table of Contents

Executive Summary ...................................................................................................... i

Forward ........................................................................................................................ xi

Introduction ................................................................................................................ xiii

1 Scope ................................................................................................................. 15

1.1 General ................................................................................................................................................ 15

1.2 Relation to other Standards .................................................................................................................. 15

2 References ......................................................................................................... 17

2.1 Normative References .......................................................................................................................... 17

2.2 Informative References ........................................................................................................................ 18

3 Definitions ........................................................................................................... 20

4 Abbreviations ...................................................................................................... 27

5 Conformance and Compliance ........................................................................... 28

5.1 Introduction .......................................................................................................................................... 28

5.2 Profiles and Conformance .................................................................................................................... 28

5.3 Conformance ........................................................................................................................................ 29

5.3.1 Core Conformance .......................................................................................................................... 29

5.3.2 Profile Conformance Requirements ................................................................................................. 29

5.3.3 Implementation Specification Conformance Requirements ............................................................. 29

5.4 Compliance .......................................................................................................................................... 29

6 Requirements ..................................................................................................... 32

6.1 General Resource Model ..................................................................................................................... 32

6.2 Metadata Requirement for Geographic Data ........................................................................................ 33

7 SDSFIE-M Conceptual Schema Profile .............................................................. 36

7.1 Introduction .......................................................................................................................................... 36

7.2 Value Domains ..................................................................................................................................... 37

7.2.1 Datatypes ........................................................................................................................................ 37

7.2.2 Codelists .......................................................................................................................................... 38

7.2.3 Enumerations .................................................................................................................................. 44

7.3 Element Table Structure ....................................................................................................................... 48

7.3.1 Introduction ...................................................................................................................................... 48

7.3.2 Name ............................................................................................................................................... 48

7.3.3 Definition ......................................................................................................................................... 48

7.3.4 Obligation/Condition ........................................................................................................................ 48

7.3.5 Maximum occurrence ...................................................................................................................... 49

7.3.6 Datatype / Domain ........................................................................................................................... 50

7.3.7 Business Rule .................................................................................................................................. 50


iv

7.4 Resource Metadata Sections ............................................................................................................... 52

7.4.1 Metadata Entity Set ......................................................................................................................... 52

7.4.2 Identification .................................................................................................................................... 57

7.4.3 Constraints ...................................................................................................................................... 69

7.4.4 Data Quality ..................................................................................................................................... 78

7.4.5 Maintenance Information ............................................................................................................... 102

7.4.6 Spatial Representation Information ............................................................................................... 105

7.4.7 Reference System ......................................................................................................................... 112

7.4.8 Identifier ......................................................................................................................................... 114

7.4.9 Content Information ....................................................................................................................... 118

7.4.10 Application Schema .................................................................................................................. 125

7.4.11 Acquisition Information ............................................................................................................. 127

7.4.12 Extent ....................................................................................................................................... 136

7.4.13 Citation...................................................................................................................................... 141

Annex A – Profiles (Normative) ................................................................................ 150

A.1 Extending the SDSFIE-M Conceptual Schema Profile ....................................................................... 150

A.1.1 Introduction .................................................................................................................................... 150

A.1.2 Extension Methodology ................................................................................................................. 150

A.1.3 Existing Element ............................................................................................................................ 150

A.1.4 New Element or Entity ................................................................................................................... 152

A.2 Profiling the SDSFIE-M Conceptual Schema Profile .......................................................................... 153

A.2.1 Introduction .................................................................................................................................... 153

A.2.2 Profile Structure ............................................................................................................................. 153

A.2.3 Business Rules .............................................................................................................................. 154

Annex B – Data Types (Normative) .......................................................................... 158

Annex C – Abstract Test Suite (ATS) (Normative) ................................................... 162

C.1 Abstract test suite ............................................................................................................................... 162

C.2 Introduction ........................................................................................................................................ 162

C.3 Test Purpose ...................................................................................................................................... 163

C.4 Test Methods...................................................................................................................................... 163

C.5 Test case – SDSFIE-M -derived Profiles ............................................................................................ 164

C.5.1 Test Purpose ................................................................................................................................. 164

C.5.2 Test Method................................................................................................................................... 164

C.5.3 Test Criteria ................................................................................................................................... 164

C.6 Test Case – Extensions to the SDSFIE-M Conceptual Schema Profile ............................................. 165

C.6.1 Test Purpose ................................................................................................................................. 165

C.6.2 Test Method................................................................................................................................... 165

C.6.3 Test Criteria ................................................................................................................................... 165

C.7 Test Case – Conformance with Established SDSFIE-M -Based Profiles ........................................... 166


v

C.7.1 Test Purpose ................................................................................................................................. 166

C.7.2 Test Method................................................................................................................................... 166

C.7.3 Test Criteria ................................................................................................................................... 166

Annex D – UML Primer (Informative) ....................................................................... 168

D.1 UML notations .................................................................................................................................... 168

D.2 UML model relationships .................................................................................................................... 168

D.2.1 Associations .................................................................................................................................. 168

D.2.2 Generalization ............................................................................................................................... 169

D.2.3 Instantiation / Dependency ............................................................................................................ 169

D.2.4 Roles ............................................................................................................................................. 169

D.3 UML model stereotypes ..................................................................................................................... 170

D.4 Package abbreviations ....................................................................................................................... 171

Bibliography ............................................................................................................. 172


vi

Table of Figures

Figure 1 : General Resource Model ............................................................................................................................. 32

Figure 2 : SDSFIE-M Metadata Packages ................................................................................................................... 33

Figure 3 : Metadata Entity Set ...................................................................................................................................... 52

Figure 4 : Metadata Entity Set, Extended for Imagery and Gridded Data .................................................................... 55

Figure 5 : Identification ................................................................................................................................................. 57

Figure 6 : Service Identification Context ....................................................................................................................... 58

Figure 7 : Constraints ................................................................................................................................................... 70

Figure 8 : Data Quality ................................................................................................................................................. 78

Figure 9 : LI_Lineage Metadata ................................................................................................................................... 82

Figure 10 : LE_Lineage Metadata ................................................................................................................................ 86

Figure 11 : Quality Element Context ............................................................................................................................ 92

Figure 12 : Data Quality Result .................................................................................................................................... 97

Figure 13 : Data quality result with coverage quality extension .................................................................................... 99

Figure 14 : Transfer Files ........................................................................................................................................... 101

Figure 15 : Maintenance Information .......................................................................................................................... 103

Figure 16 : Spatial Representation ............................................................................................................................. 106

Figure 17 : Spatial representation extension for imagery ........................................................................................... 107

Figure 18 : Reference System.................................................................................................................................... 113

Figure 19 : Identifier ................................................................................................................................................... 114

Figure 20 : Content Information.................................................................................................................................. 118

Figure 21 : Content Information with imagery extensions .......................................................................................... 119

Figure 22 : Application Schema ................................................................................................................................. 126

Figure 23 : Acquisition Overview ................................................................................................................................ 128

Figure 24 : Acquisition Detail ..................................................................................................................................... 129

Figure 25 : Extent ....................................................................................................................................................... 137

Figure 26 : Citation and Responsible Party ................................................................................................................ 142

Figure 27 : UML Notation ........................................................................................................................................... 168

Figure 28 : UML Roles ............................................................................................................................................... 170


vii

Table of Tables

Table 1 : SDSFIE-M metadata packages and their corresponding obligations. ........................................................... 34

Table 2 : SDSFIE-M Conceptual Schema Profile Datatypes ........................................................................................ 38

Table 3 : SDSFIE-M Conceptual Schema Codelists .................................................................................................... 44

Table 4 : Enumeration MD_TopicCategory Domain Values ......................................................................................... 46

Table 5 : Enumeration MD_PixelOrientationCode Domain Values .............................................................................. 47

Table 6 : Multiplicity and Implied Obligation ................................................................................................................. 50

Table 7 : Metadata Entity Set ....................................................................................................................................... 54

Table 8 : Metadata Entity Set, Extension for Imagery and Gridded Data ..................................................................... 55

Table 9 : Locale............................................................................................................................................................ 56

Table 10 : Identification ................................................................................................................................................ 62

Table 11 : Keywords .................................................................................................................................................... 63

Table 12 : Format ......................................................................................................................................................... 63

Table 13 : Resolution ................................................................................................................................................... 64

Table 14 : Representative Fraction .............................................................................................................................. 64

Table 15 : Aggregate Information ................................................................................................................................. 65

Table 16 : Operation Information .................................................................................................................................. 66

Table 17 : Operation Chain Information ....................................................................................................................... 66

Table 18 : Parameter Information ................................................................................................................................. 67

Table 19 : Coupled Resource Information .................................................................................................................... 68

Table 20 : Standard Order Process Information ........................................................................................................... 68

Table 21 : Constraints .................................................................................................................................................. 72

Table 22 : SDSFIE-M Security Constraints .................................................................................................................. 73

Table 23 : ISM Security Attributes Group ..................................................................................................................... 76

Table 24 : Need To Know ............................................................................................................................................ 77

Table 25 : ISM Notices ................................................................................................................................................. 78

Table 26 : Data Quality ................................................................................................................................................ 79

Table 27 : Data Quality Scope ..................................................................................................................................... 80

Table 28 : Using LI_Lineage ........................................................................................................................................ 81

Table 29 : LI_Lineage .................................................................................................................................................. 83

Table 30 : LI_ProcessStep ........................................................................................................................................... 84

Table 31 : LI_Source .................................................................................................................................................... 84

Table 32 : LE_Source .................................................................................................................................................. 88

Table 33 : LE_ NominalResolution ............................................................................................................................... 88

Table 34 : LE_ ProcessStep ........................................................................................................................................ 89

Table 35 : LE_ ProcessStepReport .............................................................................................................................. 89

Table 36 : LE_Processing ............................................................................................................................................ 90

Table 37 : LE_Algorithm ............................................................................................................................................... 91

Table 38 : DQ_Element ................................................................................................................................................ 97


viii

Table 39 : DQ_Result ................................................................................................................................................... 98

Table 40 : MX_File, MX_DataFile, and MX_SupportFile ........................................................................................... 102

Table 41 : Maintenance Information ........................................................................................................................... 104

Table 42 : Scope Description ..................................................................................................................................... 105

Table 43 : Spatial Representation Information ........................................................................................................... 110

Table 44 : MD_Dimension .......................................................................................................................................... 110

Table 45 : MI_Georectified ......................................................................................................................................... 110

Table 46 : MI_Georeferenceable................................................................................................................................ 111

Table 47 : MI_GeolocationInformation ....................................................................................................................... 111

Table 48 : MI_GCP .................................................................................................................................................... 112

Table 49 : Geometric Objects..................................................................................................................................... 112

Table 50 : Reference System ..................................................................................................................................... 113

Table 51 : Identifier .................................................................................................................................................... 114

Table 52 : Resolvable Resource Identifiers ................................................................................................................ 115

Table 53 : Non-Resolvable Resource Identifiers ........................................................................................................ 116

Table 54 : General Purpose Identifiers for Imagery and Gridded Data ...................................................................... 116

Table 55 : Imagery and Gridded Data Identifiers........................................................................................................ 117

Table 56 : RS_Identifier ............................................................................................................................................. 117

Table 57 : Content Information ................................................................................................................................... 121

Table 58 : SMF_FeatureTypes................................................................................................................................... 122

Table 59 : SMF_Features .......................................................................................................................................... 122

Table 60 : MD_RangeDimension ............................................................................................................................... 124

Table 61 : MI_Band .................................................................................................................................................... 124

Table 62 : MI_CoverageDescription ........................................................................................................................... 125

Table 63 : MI_ImageDescription ................................................................................................................................ 125

Table 64 : MI_RangeElementDescription ................................................................................................................... 125

Table 65 : Application Schema Information ................................................................................................................ 127

Table 66 : MI_AcquisitionInformation ......................................................................................................................... 130

Table 67 : MI_EnvironmentalRecord .......................................................................................................................... 130

Table 68 : MI_Plan ..................................................................................................................................................... 131

Table 69 : MI_Requirement ........................................................................................................................................ 132

Table 70 : MI_RequestedDate ................................................................................................................................... 132

Table 71 : MI_Instrument ........................................................................................................................................... 133

Table 72 : MI_Objective ............................................................................................................................................. 133

Table 73 : MI_Operation ............................................................................................................................................ 134

Table 74 : MI_Platform ............................................................................................................................................... 135

Table 75 : MI_PlatformPass ....................................................................................................................................... 135

Table 76 : MI_Event ................................................................................................................................................... 136

Table 77 : Extent ........................................................................................................................................................ 138


ix

Table 78 : Geographic Extent .................................................................................................................................... 139

Table 79 : Temporal Extent ........................................................................................................................................ 140

Table 80 : Vertical Extent ........................................................................................................................................... 141

Table 81 : Citation ...................................................................................................................................................... 144

Table 82 : Responsible Party ..................................................................................................................................... 145

Table 83 : Address ..................................................................................................................................................... 145

Table 84 : Contact ...................................................................................................................................................... 146

Table 85 : Date........................................................................................................................................................... 146

Table 86 : Online Resource ....................................................................................................................................... 147

Table 87 : Series ........................................................................................................................................................ 148

Table 88 : Telephone ................................................................................................................................................. 148


x



xi

Forward

The Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) Metadata Foundation, or SMF is a community standard for geospatial metadata and is a profile of the National System for Geospatial-Intelligence (NSG) Metadata Foundation, or NMF. NMF is, in turn, a profile of ISO 19115:2003/Cor 1:2006 (Geographic Information – Metadata). SMF is specifically applicable to the Defense Installation Spatial Data Infrastructure Community of Interest (DISDI COI) as listed in the United States Department of Defense (DoD) Metadata Registry, and having a corresponding DISDI namespace. The SDSFIE supports the ability of the DISDI COI, also known as the Installation Geospatial Information and Services (IGI&S) user community, to describe its spatial data holdings (e.g. those structured according to the Spatial Data Standard for Facilities, Infrastructure, and Environment). Complete and current geospatial metadata is also essential to meet the goals of DoD Directive 8320.02 summarized as “making data and services more visible (discoverable), accessible, understandable, trusted, and interoperable.” The DISDI COI is led by the Defense Installation Spatial Data Infrastructure (DISDI) Group, or DISDIG. A subgroup of the DISDIG called the Metadata Working Group (DMWG) serves as the I&E community-wide forum to conduct and coordinate pertinent metadata standardization efforts like the SDSFIE-M.

The SDSFIE-M (previously known as the Defense Installation Spatial Data Infrastructure (DISDI) Geospatial Metadata Profile or DGMP) specification was established via consensus input of the DISDIG, the officially designated I&E governance body for spatial data standards, including metadata standards. In 2009 the DUSD(I&E), as the chair of the RPILM Investment Review Board, required the Components to implement the DGMP as the enterprise standard for IGI&S metadata that is primarily used to support RPILM core business missions (DUSD(I&E) memorandum, 14 April, 2009). The DISDI Group exercises tiered governance of the SDSFIE-M, ensuring implementation of the standard supports the Department’s business transformation goals, the Business Enterprise Architecture, and RPILM initiatives. The DISDI Group is also responsible for ensuring all concepts in SDSFIE-M are harmonized to the greatest extent practicable with the NMF, and integrated with the NMF where beneficial.

The DISDI COI has long known the value of metadata. Prior to developing DGMP 1.0, the community used the Federal Geographic Data Committee’s (FGDC) Content Standard for Digital Geospatial Metadata (CSDGM), established in 1998 and required under the provisions of Office of Management and Budget Circular A-16. Although the CSDGM is widely used, it has been implemented inconsistently due to inherent flaws in the standard itself as well as a general lack of detailed implementation guidance throughout the DISDI COI. Without a uniform implementation of the CSDGM standard, the goal of authoritative net-centric data sharing is defeated.

The growing challenges in implementing CSDGM have converged with the new policy-based requirements to implement International Organization for Standardization (ISO) 19115:2003 Geographic Information – Metadata. In 2010, the GEOINT Standards Working Group (GWG) developed a profile of ISO 19115 known as the National System for GEOINT (NSG) Metadata Foundation, or NMF. In accordance with DoDD 5105.6,


xii

the DISDI Community is required to implement this standard. Meanwhile, the FGDC recently developed a successor standard to CSDGM in conjunction with the Canadian Geospatial governance body. This North American Profile (NAP) is a profile of the ISO 19115 just as the SDSFIE-M 1.0 and NMF. The SDSFIE-M Version 1.0 is intended to serve as a “bridge standard” for the DISDI community, allowing easy translation of metadata to the NMF profile as well as the NAP, both of which are required by federal or DoD policy but which, on their own, do not meet all the needs of the I&E business mission area.


xiii

Introduction

The term Geospatial refers to either an implicit or explicit reference to a location relative to the earth.

Metadata is information which captures the underlying characteristics of an resource. It represents the who, what, when, where, why and how of the resource.

The term Geospatial Information & Services – or GI&S – encompasses the concept for collection, information extraction, storage, dissemination, and exploitation of geodetic, geomagnetic, imagery, gravimetric, aeronautical, topographic, hydrographic, littoral, cultural, and toponymic data accurately referenced to a precise location on the earth’s surface1. These data are used in the battlespace for military planning, training, and operations, including navigation, mission planning, mission rehearsal, modeling, simulation, and precise targeting, as well as in the basing space to provide situational awareness for force protection and management of the built and natural infrastructure.

For the purposes of this specification, Installation GI&S (IGI&S) refers to the subset of GI&S activities that enhance the DoD I&E business mission area and support I&E business enterprise priorities as defined in the DoD Business Enterprise Architecture. IGI&S are considered complimentary to but different from GEOINT, and are managed as DoD information resources and information technology as defined in EO 12906, DoD Directives 8000.1 and 8115.01.

Geospatial information provides the basic framework for IGI&S business mission support. It is information that can be produced by one or more sources to common interoperable data standards. It may be utilized in the form of printed maps, charts, and publications; in digital simulation and modeling databases; in photographic form; or in the form of digitized maps and charts or attributed centerline data. Geospatial services include tools that enable users to access and manipulate data and also include instruction, training, laboratory support, and guidance for its use.

SDSFIE-M defines an NMF Profile (and thus an ISO 19115:2003/Cor 1:2006 Profile) for specifying geospatial metadata in the I&E business mission area.

The purposes of the SDSFIE-M are to promote the following:

Common understanding of Geospatial metadata within and across I&E business mission area;

Conceptual specification standard for Geospatial metadata;

Foundation standard defining business rules for specifying Geospatial metadata;

Logical specification standard for Geospatial metadata;

Re-use and standardization of Geospatial metadata in the I&E business mission area;

1 Joint Publication (JP) 2-03, 31 Oct 2012.


xiv

Harmonization of Geospatial metadata creation within and across I&E business mission area, supporting varying business requirements and practices;

Physical specification(s) standard for Geospatial metadata with multiple COTS technologies, including standards-based exchange; and

Geospatial metadata publication standard using externally-specified specifications and mechanisms.

A note on terminology

SDSFIE-M uses the Unified Markup Language (UML) to model a conceptual schema. This mixture of techniques may lead to some confusion of terms. A conceptual schema consists of metadata entities composed of elements. A UML model is composed of classes containing attributes. An effort has been made to use the terminology appropriate for the context. However, it is best to remember that:

1) Entities are concepts modeled by classes

2) Classes are models representing concepts

3) Elements are concepts modeled by attributes

4) Attributes are models representing elements.


15

SDSFIE Metadata

1 Scope

1.1 General

Geospatial metadata is used in the IGI&S community to describe the characteristics and structure of IGI&S data and services. Geospatial metadata describes the geospatial data elements used to specify information about features, events, coverages (including images and elevation surfaces), datasets (collections of such information), measurements, observations and services (capabilities to create, access, display, and/or manipulate such information).

SDSFIE Metadata (SDSFIE-M) is a profile of the National System for Geospatial-Intelligence (NSG) Metadata Foundation, or NMF. NMF is, in turn, a profile of ISO 19115:2003/Cor 1:2006 (Geographic Information – Metadata) that specifies the minimum and recommended sets of metadata elements required for the discovery and exchange of geospatial datasets in the IGI&S community. This Conceptual Schema Profile shall be used to document geospatial datasets for cataloguing, discovery and retrieval. It may be used as a basis for populating DoD Discovery Metadata Standard (DDMS) conformant “metacards” for use in the Global Information Grid (GIG) Enterprise Discovery Service.

1.2 Relation to other Standards

SDSFIE-M is a profile of the conceptual schema for metadata defined by Geospatial-Intelligence Standards Working Group (GWG)2. This specification profiles NMF Parts 1, 2, and 3 and is thus also a profile of ISO 19115:2003/Cor 1:2006 and ISO 19115-2:2009 and is intended to specify the minimum and recommended set of metadata elements required for the discovery and exchange of geospatial datasets in the IGI&S community.

2 The GWG is an NSG forum that serves the Director, National Geospatial-Intelligence Agency and the NGA Chief Information Officer who is the delegated functional manager for GEOINT architecture and standards, in executing the functional management responsibilities authorized in NSG Directive ST 8100, 1 March 2007. The GWG provides the forum for the coordination of GEOINT standard activities. The GWG is led and chaired by the NGA's National Center for Geospatial Intelligence Standards (NCGIS).

In addition to its designation as an NSG Functional Management forum, the GWG is a Joint Technical Working Group that participates in both the DoD and IC standards governance processes. In the DoD, the GWG votes and manages GEOINT standards lifecycle recommendations reported to the Information Technology Standards Committee (ITSC), the governing group responsible for developing and promoting standards interoperability in support of net-centricity within the Department of Defense (DoD). GWG recommendations for mandating standards for the DoD are approved by the DoD Architecture and Standards Review Group (ASRG). Approved GEOINT standards are then cited in the DoD Information Technology (IT) Standards Registry (DISR).

In the Intelligence Community (IC), the GWG provides the same GEOINT standards lifecycle management recommendations brought into the DoD process and these voted upon recommendations are approved for the IC by the IC Enterprise Standards Committee (IC ESC) and the IC CIO’s Architecture, Standards and Engineering Committee (ASEC). Approved GEOINT standards are then cited in the IC Standards Registry (ICSR).


16

As a profile of GEOINT and ISO standards, SDSFIE-M is only normative in those areas where the GEOINT and ISO standards have been profiled to address IGI&S requirements. The originating ISO standards continue to provide the normative definition of all elements not restricted or extended by SDSFIE-M. Information from those standards has been included solely to provide context.

This standard is a specification of the SDSFIE-M conceptual schema. A conceptual schema is agnostic to implementing technology. Implementation specifications address how this conceptual schema should be realized for a specific technology. The SDSFIE Metadata Implementation Specification (SMIS) provides that guidance for XML schema. Additional implementation specifications may be developed as requirements for those specifications are identified. One near-term example of this is the SDSFIE-M Feature Level Metadata (SDSFIE-M-FLM) profile (a strict subset of SDSFIE-M intended to be used at define metadata at the feature level). The SDSFIE-M-FLM implementation specification will most likely be expressed as Structured Query Language (SQL) Data Definition Language (DDL).


17

2 References

2.1 Normative References

The following referenced documents provide the basis for SDSFIE-M. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including amendments) applies.

Department of Defense Discovery Metadata Specification (DDMS), August 10, 2007, Deputy Assistant Secretary of Defense/Deputy Chief Information Officer.

ISO 639-2:1998, Codes for the representation of names of languages – Part 2: Alpha-3 code

ISO 3166 (all parts), Codes for the representation of names of countries and their subdivisions

ISO 8859 (parts 1 to 16), Information technology ― 8-bit single-byte coded graphic character sets

ISO 8879, Information processing ― Text and office systems ― Standard Generalized Markup Language (SGML)

ISO/IEC 10646-1, Information technology ― Universal Multiple-Octet Coded Character Set (UCS) ― Part 1: Architecture and Basic Multilingual Plane

ISO/IEC 11179 (all parts), Information technology ― Specification and standardization of data elements

ISO 19106:―1, Geographic information ― Profiles

ISO 19107:2003, Geographic information ― Spatial schema

ISO 19108:2002, Geographic information ― Temporal schema

ISO 19109:―1, Geographic information ― Rules for application schema

ISO 19110:―1, Geographic information ― Methodology for feature cataloguing

ISO 19111:2003, Geographic information ― Spatial referencing by coordinates

ISO 19112:―1, Geographic information ― Spatial referencing by geographic identifiers

ISO 19115:2003:―1, Geographic information ― Metadata

ISO 19115:2006:―1, Geographic information ― Metadata, Technical Corrigendum 1

ISO/DIS 19115-1, Geographic information — Metadata — Part 1: Fundamentals, Nov 2011 (NOTE: This is a DRAFT International Standard)

ISO 19115-2:2009, Geographic information - Metadata - Part 2: Extensions for imagery and gridded data

ISO 19118:―1, Geographic information ― Encoding


18

ISO 19139:2007―1, Geographic information ― Metadata ― XML schema implementation

NGA.STND.0012_2.1, National System for Geospatial-Intelligence (NSG) Metadata Framework (NMF) – Part 1: Conceptual Schema Profile, Version 2.1

NGA.STND.0012-2_1.0.0, National System for Geospatial-Intelligence (NSG) Metadata Framework (NMF) – Part 2: Quality Metadata, Version 1.0

NGA.STND.0012-3_1.0.0, National System for Geospatial-Intelligence (NSG) Metadata Framework (NMF) – Part 3: Metadata for Imagery and Gridded Data, Version 1.0

2.2 Informative References

The following publications were referenced to support the development of this Profile.

Content Standard for Digital Geospatial Metadata Workbook, Version 2.0, May 1, 2000, Federal Geographic Data Committee

Defence Imagery and Geospatial Organisation, Data Management Profile of ISO 19115:2003 Geographic Information – Metadata, Draft Version 1.15, Australian Government Department of Defence, Intelligence & Security.

Department of Defense Manual 5200.01 Vol. 1, DoD Information Security Program: Overview, Classification, and Declassification, February 24, 2012, Under Secretary for Intelligence.

Department of Defense Manual 5200.01 Vol. 2, DoD Information Security Program: Marking of Classified Information, February 24, 2012, Under Secretary for Intelligence.

Department of Defense Manual 5200.01 Vol. 4, DoD Information Security Program: Controlled Unclassified Information (CUI), February 24, 2012, Under Secretary for Intelligence.

Department of Defense Instruction 8320.02 Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense, August 5, 2013, Department of Defense Chief Information Officer.

Department of Defense Information Technology Standards Registry (DISR) Baseline, Release 06-3.0, October 25, 2006, Deputy Chief Information Officer.

Department of Defense Installation Visualization Tool Quality Assurance Plan (IVT QAP), Version 1.1, December 31, 2003, IVT Program Office, Headquarters Air Force Geo Integration Office.

Content Standard for Digital Geospatial Metadata(CSDGM), Version 2.0, 1998, Federal Geographic Digital Committee (FGDC).

Federal Geographic Digital Committee (FGDC) – International Standardization Organization (ISO) Crosswalk, Version 4.0, April 17, 2003, Intergraph Corporation.


19

National System for Geospatial-Intelligence (NSG) Metadata Framework (NMF) – Part 1: Conceptual Schema Profile, Version 2.1, February 2012, National Geospatial-Intelligence Agency (NGA).

White Paper: A Common DoD Business Mission Area Metadata Profile, October 12, 2006, Defense Installation Spatial Data Infrastructure (DISDI).


20

3 Definitions

This section provides definitions for terms used in this document. The standard or specification indicated in brackets is the authoritative source of the definition.

abstract test case (ATS)

generalized test for a particular requirement [ISO 19105]

NOTE An abstract test case is a formal basis for deriving executable test cases. One or more test purposes are encapsulated in the abstract test case. An abstract test case is independent of both the implementation and the values. It should be complete in the sense that it is sufficient to enable a test verdict to be assigned unambiguously to each potentially observable test outcome (i.e. sequence of test events).

abstract test method

method for testing implementation independent of any particular test procedure [ISO 19105]

abstract test module

a set of related abstract test cases [ISO 19105]

NOTE Abstract test modules may be nested in a hierarchical way.

abstract test suite

an abstract test module specifying all the requirements to be satisfied for conformance [ISO 19105]

application schema

conceptual schema for data required by one or more applications [ISO 19101]

attribute

see feature attribute

base standard

ISO geographic information standard or other information technology standard that is used as a source from which a profile may be constructed [ISO 19106]

basic test

initial capability test intended to identify clear cases of non-conformance [ISO 19105]

business rule

guidance and documentation to describe and standardize the use of metadata elements that best support a community’s’ needs [DCMI]

business mission area

A defined area of responsibility with function and processes contributing to mission accomplishment.

capability test


21

test designed to determine whether an IUT conforms to a particular characteristic of an International Standard as described in the test purpose [ISO 19105]

class

description of a set of objects that share the same attributes, operations, methods, relationships, and semantics [adapted from ISO/IEC 19501]

codelist

a code list is a list of coded values that can be used to describe an open enumeration and shall be used if only the likely or an initial set of allowed values are known. This means that it may need to be represented and implemented in such a way that it can be extended during system runtime. [adapted from 19103]

component

The Office of the Secretary of Defense, the Military Departments, the Chairman of the Joint Chiefs of Staff, the Combatant Commands, and the Defense Agencies.

conceptual model

model that defines the concepts of a universe of discourse [ISO 19101]

conceptual schema

formal description of a conceptual model [ISO 19101]

conformance

fulfillment of specified requirements [ISO 19105]

NOTE For the NMF, the concept of conformance pertains to the conformance of specifications, including any profile or functional standard, with the series of ISO geographic information standards as a whole, plus NMF-authorized extensions to those geographic information standards.

content metadata

schema that defines data (including metadata) structures, including the types of elements, sub-elements, and values they can contain [Getty Library - Introduction to Metadata]

coordinate reference system

coordinate system that is related to an object by a datum [ISO 19111]

NOTE 1 A coordinate system is a set of mathematical rules for specifying how coordinates are to be assigned to points. [ISO 19111]

NOTE 2 A datum is a parameter or set of parameters that define the position of the origin, the scale, and the orientation of a coordinate system. [ISO 19111]


22

NOTE 3 A coordinate is one of a sequence of n numbers designating the position of a point in n-dimensional space.3 [ISO 19111]

coverage

feature that acts as a function to return values from its range for any direct position within its spatiotemporal domain [ISO 19123]

EXAMPLES A raster image, a polygon overlay, and a digital elevation matrix. [ISO 19123, 5.1.1]

NOTE In other words, a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type; it associates positions within a bounded space (its domain) to feature attribute values (its range). It is both a feature and a function. [ISO 19123, 5.1.1]

dataset

identifiable collection of data [ISO 19115]

data type

specification of a value domain with operations allowed on values in this domain [ISO 19103]

EXAMPLES An Integer, a Real, a Boolean, a CharacterString, and a Date.

NOTE Data types include primitive predefined types and user-definable types.

entity

set of metadata elements describing the same aspect of data [ISO 19115]

event

action which occurs at an instant [ISO 19108]

extension

the addition of information not included in the content being extended [adapted from 19106]

externally-specified specification

a specification referenced by the NSG Metadata Foundation (NMF) document

feature

abstraction of real world phenomena [ISO 19101]

feature attribute

characteristic of a feature [ISO 19101]

3 In a coordinate reference system, the n numbers shall be qualified by units.


23

geospatial

refers to either an implicit or explicit reference to a location relative to the earth.

geographic dataset

a dataset that represents physical geospatial features. Not to be confused with vendor- specific implementations (for example, ESRI dataset).

geospatial information

information that identifies the geographic location and characteristics of natural or constructed features and boundaries on the earth, including statistical data; information derived from, among other things, remote sensing, mapping, and surveying technologies; and mapping, charting, and geodetic data, including “geodetic products.” [Title 10 US Code §467]

geospatial information & services

The concept for collection, information extraction, storage, dissemination, and exploitation of geodetic, geomagnetic, imagery, gravimetric, aeronautical, topographic, hydrographic, littoral, cultural, and toponymic data accurately referenced to a precise location on the earth’s surface. These data are used in the battlespace for military planning, training, and operations, including navigation, mission planning, mission rehearsal, modeling, simulation, and precise targeting, as well as in the basing space to provide situational awareness for force protection and management of the built and natural infrastructure. For the purposes of this specification, Installation GI&S (IGI&S) refers to the subset of GI&S activities that enhance the DoD I&E business mission area and support I&E business enterprise priorities as defined in the DoD Business Enterprise Architecture. IGI&S are considered complimentary to but different from GEOINT, and are managed as DoD information resources and information technology as defined in EO 12906, DoD Directives 8000.1 and 8115.01. Geospatial information provides the basic framework for IGI&S. It is information produced by multiple sources to common interoperable data standards. It may be presented in the form of printed maps, charts, and publications; in digital simulation and modeling databases; in photographic form; or in the form of digitized maps and charts or attributed centerline data. Geospatial services include tools that enable users to access and manipulate data and also include instruction, training, laboratory support, and guidance for the use of geospatial data.

geospatial intelligence

(GEOINT) the exploitation and analysis of imagery and geospatial information to describe, assess, and visually depict physical features and geographically referenced activities on the Earth. [Title 10 U.S. Code §467]

NOTE Consists of imagery, imagery intelligence, and geospatial information

geospatial intelligence standard

documented agreement containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics to ensure that


24

materials, products, processes, or services are fit for the analysis and visual representation of physical features and geographically referenced activities.

geospatial metadata

information which captures the basic characteristics of a data resource; represents the who, what, when, where, why and how of the resource.

image

gridded coverage whose attribute values are a numerical representation of a physical parameter [ISO 19115-2]

NOTE The physical parameters are the result of measurement by a sensor or a prediction from a model.

imagery

representation of phenomena as images produced by electronic and/or optical techniques [ISO/TS 19101-2]

NOTE1 It is assumed that the objects and phenomena have been sensed or detected by camera, infrared and multispectral scanners, radar and photometers, or similar devices.

NOTE2 A likeness or presentation of any natural or manmade feature or related object of activity and the positional data acquired at the same time that the likeness or representation was acquired.

implementation

realization of a specification. In the context of the ISO geographic information standards, this includes specifications of geographic information services and datasets [ISO 19105]

information

knowledge concerning objects, such as facts, events, things, processes, or ideas, including concepts, that within a certain context has a particular meaning [ISO 19118]

measure

value described using a numeric amount with a scale or using a scalar reference system [ISO 19136]

NOTE 1 When used as a noun, measure is a synonym for physical quantity.

NOTE 2 A physical quantity is a quantity used for the quantitative description of physical phenomena.4

metadata

data about data [ISO 19115]

4 In GML a physical quantity is always a value described using a numeric amount with a scale or using a scalar reference system.


25

metadata element

discrete unit of metadata [ISO 19115]

NOTE 1 Metadata elements are unique within a metadata entity.

NOTE 2 Equivalent to an attribute in UML terminology.

metadata entity

set of metadata elements describing the same aspect of data [ISO 19115]

NOTE 1 May contain one or more metadata entities.

NOTE 2 Equivalent to a class in UML terminology.

metadata mapping

table that maps the relationships and equivalencies between two or more metadata schemes. Crosswalks or metadata mapping support the ability of search engines to search effectively across heterogeneous databases. [DCMI]

metadata package

metadata is presented in UML packages, called metadata packages. Each package contains one or more entities (UML Classes), which can be specified (subclassed) or generalized (superclassed). [ISO 19115]

metadata section

subset of metadata which consists of a collection of related metadata entities and metadata elements [ISO 19115]

NOTE Equivalent to a package in UML terminology.

model

abstraction of some aspects of reality [ISO 19109]

national system for geospatial intelligence

the combination of technology, policies, capabilities, doctrine, activities, people, data, and communities necessary to produce geospatial intelligence in an integrated multi-intelligence, multi-security domain environment

profile

set of one or more base standards or subsets of base standards, and, where applicable, the identification of chosen clauses, classes, options and parameters of those base standards, that are necessary for accomplishing a particular function [ISO/IEC TR 10000-1]

NOTE A profile is derived from base standards so that by definition, conformance to a profile is conformance to the base standards from which it is derived.

quality

totality of characteristics of a product that bear on its ability to satisfy stated and implied needs [ISO 19101]


26

raster

usually rectangular pattern of parallel scanning lines forming or corresponding to the display on a cathode ray tube [ISO 19123]

registry

information system on which a register is maintained [adapted from 11179-3:1994]

remote sensing

collection and interpretation of information about an object without being in physical contact with the object [ISO/TS 19101-2]

resource

asset or means that fulfills a requirement [ISO 19115]

specification

declarative description of what something is or does [adapted from ISO/IEC 19501]

unit of measure

reference quantity adopted as a standard of measurement for other quantities of the same kind. [adapted from ISO 19103]

EXAMPLE The unit of measure “metre” from the category “length”.

value domain

set of accepted values [ISO/IEC 19103:2005]

EXAMPLE The range 3-28, all integers, any ASCII character, enumeration of all accepted values (green, blue, white).


27

4 Abbreviations

CRS – Coordinate Reference System

CSDGM – Content Standard for Digital Geospatial Metadata

DDMS – Department of Defense Discovery Metadata Specification

DISDI – Defense Installation Spatial Data Infrastructure

DISDIG – DISDI Group

DISR – Department of Defense Information Technology Standards Registry

DMWG – DISDI Metadata Working Group

DoD – Department of Defense

DSN – Defense Switched Network

FGDC – Federal Geographic Data Committee

IGI&S – Installation Geospatial Information & Services

GI&S – Geospatial Information & Services

I&E – Installations & Environment

ISO – International Organization for Standardization

NSG – National System for Geospatial-Intelligence

POC – Point of Contact

SDSFIE – Spatial Data Standards for Facilities, Infrastructure, and Environment

SME – Subject Matter Expert

UML – Unified Modeling Language

XML – Extensible Markup Language


28

5 Conformance and Compliance

5.1 Introduction

SDSFIE-M is a conceptual schema. The purpose of a conceptual schema is to capture the concepts and relationships of a domain model in a form which is agnostic to the eventual choice of an implementing technology. Due to this level of abstraction, compliance with SDSFIE-M cannot be tested directly. Therefore, developers seeking to implement an SDSFIE-M compliant system shall first locate or develop a conformant implementation specification5.

SDSFIE-M-conformant implementation specifications provide a validated specification for implementing the SDSFIE-M when employing a specific technology. The implementation specification then serves as a requirements specification that guides system development.

Demonstration of compliance of the system with the implementation specification and then conformance of the implementation specification with SDSFIE-M shall constitute demonstration of compliance of the system with SDSFIE-M.

SDSFIE-M is a profile of NMF and several International Standards. Except where modified in SDSFIE-M, those International Standards are the normative authority for SDSFIE-M elements and entities.

5.2 Profiles and Conformance

ISO 19106:2004 Geographic information - Profiles details two classes of conformance, which may be generally thought of as profile types. Conformant Class 1 profiles are a pure subset of the ISO geographic information standards. Conformance class 2 allows profiles to include extensions within the context permitted in the base standard and permits the profiling of non-ISO geographic information standards as parts of profiles. When such a profile adds any information that is not covered in a base ISO geographic information standard or other ISO standard, then the profile will not be processed as an ISO geographic information standard but may be established under the authority of the standards organization, member body or liaison organization making the profile. Specifications that profile the SDSFIE-M Conceptual Schema may extend the SDSFIE-M Conceptual Schema to meet the metadata requirements of individual organizations and systems. These include, e.g., I&E datasets, products, systems and services, profiles of the SDSFIE-M Conceptual Schema, application schemas, implementation specifications and any other documentation that is required to conform to this standard.

Demonstration of the compliance of a specification with SDSFIE-M requires both the determination that metadata elements and entities that are included in the SDSFIE-M Conceptual Schema (Class 1 profile conformance) are correctly implemented, and the

5 The DISDI Program Office will provide both an XML Schema-based SDSFIE Metadata Implementation Specification (SMIS) and “template” instance documents for vector datasets, imagery, and services that conform to SMIS. The DISDI Program Office will also issue an SMF Implementation Guidance document that provides implementation guidance details.


29

determination that metadata elements and entities that are valid extensions to the SDSFIE-M Conceptual Schema (Class 2 profile conformance) are correctly implemented. The validity of metadata extensions shall be tested using the 19115:2003/Cor 1:2006 rules for metadata extensions.

5.3 Conformance

5.3.1 Core Conformance

Conformance with this standard shall be a requirement for any specification claiming to be an SDSFIE-M profile (conformance class 1 or 2).

The minimum and recommended sets of metadata elements, their content, rules, relationships and representations, as described conceptually in this standard can be tested through the use of a defined set of conformance criteria. Any implementation claiming conformance to SDSFIE-M shall satisfy the criteria found in the Abstract Test Suite (ATS) in Annex C of this standard. That test suite includes criteria for conformance with the content, rules, and encoding requirements of the SDSFIE-M Conceptual Schema, its profiles, and all normatively-cited ISO, IC, and DoD documentation.

5.3.2 Profile Conformance Requirements

Conformance with the provisions of the SDSFIE-M Conceptual Schema is addressed in two related, yet distinct, categories of SDSFIE-M profile conformance.

Conforming profiles: SDSFIE-M allows for the documentation of application-specific profiles of the SDSFIE-M Conceptual Schema. Profiles of the SDSFIE-M Conceptual Schema shall conform to the requirements and provisions of Section B.2, Profiling the SDSFIE-M Conceptual Schema.

Approved profiles: SDSFIE-M has provisions for establishing additional profiles of the SDSFIE-M Conceptual Schema. Application or implementation of approved SDSFIE-M profiles shall conform to the obligations and business rule constraints established by that specific profile.

5.3.3 Implementation Specification Conformance Requirements

An implementation specification realizes a conceptual schema in a form that can be directly implemented using a specific technology. Development of an implementation specification shall follow the rules for an ISO Class 2 profile where the community requirements are the rules, structures and conventions of the implementation environment. As a profile of the SDSFIE-M Conceptual Schema, any Implementation Specification of the SDSFIE-M Conceptual Schema shall demonstrate conformance with SDSFIE-M as described in Section 5.1.

5.4 Compliance

Compliance with the SDSFIE-M Conceptual Schema is defined in terms of conformance of derivative specifications (implementation specifications and profiles) to the conceptual schema. Ultimately SDSFIE-M must be implemented in software, data


30

structures and logic; the compliance of an implementation with SDSFIE-M must be testable. Therefore, developers seeking to implement SDSFIE-M shall perform the following actions to demonstrate compliance:

Locate or develop an SDSFIE-M implementation specification for the target implementation environment.

Demonstrate conformance of the implementation specification to the SDSFIE-M Conceptual Schema.

Use that implementation specification as a requirements specification to guide system development.

Demonstrate compliance of the system with that implementation specification.

These steps form a chain of verification that the system has correctly implemented the SDSFIE-M Conceptual Schema.

Compliance with the conceptual schema is not enough to guarantee interoperability. To that end, the following requirements shall apply to any system that implements an SDSFIE-M -based implementation specification, profile, or the conceptual schema itself. These requirements help to assure that SDSFIE-M implementations successfully interoperate.

Any specification claiming compliance with this standard shall meet the following requirements:

A compliant implementation shall populate all mandatory elements with valid values.

A compliant implementation when populating conditional or optional elements must do so with valid values.

A compliant implementation shall ingest and properly process all mandatory elements from any compliant metadata set.

A compliant implementation shall ingest any compliant metadata set containing valid conditional or optional elements but is not required to process them in any meaningful manner (e.g., their values may be ignored).


31



32

6 Requirements

6.1 General Resource Model

The SDSFIE-M Conceptual Schema Profile is intended to be applied in many I&E community resource contexts. An important use case for the SDSFIE-M Conceptual Schema Profile is the publication of metadata documenting the content of geospatial intelligence resources.

Figure 1 presents a general-case model of a geospatial intelligence resource whose content shall be documented using metadata intended to support its discovery and content exchange.

Figure 1 : General Resource Model

The fundamental building-block of the resource content is the abstract Entity class, which has identity and whose subclasses are used to model different types of geospatial phenomena (e.g., events, features, coverages and other types of geospatial information).

Entities may be organized into sets (the Dataset class) according to some rationale (e.g., common production or publication process). Entities may simultaneously be members of multiple datasets, e.g., a lighthouse may participate in an “air obstruction” product, a “maritime navigation” product, and a “map” product.

Furthermore, datasets may be grouped (by the Series class) according to some strategy (e.g., a repeated process that is sequentially applied to different spatial and/or temporal extents). A series might consist of an atlas of the primary and secondary highways of each of the 48 contiguous states of the US, where each state-specific highway dataset is prepared and/or updated as local data sources become available, but all adhere to a common specification (feature catalog, application schema, and production processes).

Series Dataset

Entity

{abstract}

Resource Metadata

Event

(e.g., pirate attack)

Feature

(e.g., building, road)

Coverage

(e.g., image, grid)

Information

(e.g., place-name, sensor)

Subclasses

Metadata


33

Metadata is used to describe the abstract Entity class; therefore, metadata can be used to describe any of the subclasses of the abstract Entity class.

6.2 Metadata Requirement for Geographic Data

This section focuses on the metadata packages specified in SDSFIE-M (section 7.4). These metadata packages are used to describe DoD Installation and Environment (I&E) geospatial assets to support their discovery and end use. The requirement to have these metadata applies to all I&E geospatial feature types and their aggregations. Figure 2 depicts all the SDSFIE-M metadata packages (the boxes in the figure) and the hierarchical relationships between the packages (the arrows).

Figure 2 : SDSFIE-M Metadata Packages

SDSFIE-M metadata packages are also listed in Table 1. This table provides a description of the metadata package and an indication as to whether it is mandatory for all data sets (Mandatory) or its inclusion in a metadata set is elective (Optional). Any Optional SDSFIE-M metadata package can be mandated as required by policy at the Component or installation level for some or all geospatial data resources in their jurisdiction.


34

Section Name Obligation Description

7.4.1 Metadata Entity Set Information (MD_Metadata)

Mandatory The Metadata Entity Set Information provides the overview descriptions necessary to establish understanding and use of the metadata entity.

7.4.2 Identification Information (MD_Identification)

Mandatory Identification information is used to specifically identify the data being described by the metadata.

7.4.3 Constraints Information (MD_Constraint)

Mandatory Constraint information is used to describe legal and security constraints placed on the resource to support access and use requirements.

7.4.4 Data Quality Information (DQ_DataQuality)

Optional Data quality information.

7.4.5 Maintenance Information (MD_Maintenance)

Mandatory Maintenance information provides a clear understanding of how the resource is managed.

7.4.6 Spatial Representation Information (MD_SpatialRepresentation)

Optional Spatial representation information reports the spatial mechanisms of vector and gridded resources.

7.4.7 Reference System Information (MD_ReferenceSystem)

Mandatory Reference system information provides the necessary data to identify how a spatial resource is positioned relative to the earth.

7.4.9 Content Information (MD_ContentInformation)

Optional Content information captures details relevant to a feature catalog and the description of the coverage.

7.4.10 Application Schema Information (MD_ApplicationSchema)

Optional Application schema information provides the means to report details regarding an application’s use of the metadata.

7.4.11 Imagery Acquisition Information (MI_Imagery)

Conditional Designations for the measuring instruments, the platform carrying them, and the mission to which the data contributes.

7.4.12 Extent (EX_Extent) Mandatory Extent provides for various descriptions of the geographic, temporal, and vertical extent of the resource

7.4.13 Citation (CI_Citation) Mandatory Citation provides for description of authoritative reference information, including responsible party and contact information.

Table 1 : SDSFIE-M metadata packages and their corresponding obligations.


35



36

7 SDSFIE-M Conceptual Schema Profile

7.1 Introduction

The SDSFIE-M Conceptual Schema Profile defines “what we all must understand” (as a set of metadata concepts) in the I&E community regarding geospatial metadata in support of (e.g.) data discovery, determining data fitness for use, data access, data transfer, and mission-specific use of IGI&S information.

The SDSFIE-M Conceptual Schema Profile draws abstract metadata concepts from a broad community of International, National, DoD, and IC standards. These are used as the basis for establishing a coherent set of metadata concepts that meet I&E community requirements for geospatial metadata.

ISO 19115:2003/Cor 1:2006 serves as the primary source, specifically the “core metadata for geographic datasets” that is defined in that International Standard. The Dublin Core Metadata Set, DDMS and IC.ADD are then used to expand upon that Core, by adding other concepts that are defined in 19115:2003/Cor 1:2006. The IC.ADD also defines additional security fields that are not present in the International Standard, so those concepts are presented as extensions to the 19115:2003/Cor 1:2006 Security package.

The ISO 19115:2003/Cor 1:2006 standard is defined using Unified Modeling Language (UML) diagrams6. As the SDSFIE-M Conceptual Schema Profiles is a profile of NMF and, therefore, 19115:2003/Cor 1:2006, it is also defined using UML diagrams. For an introduction on understanding UML notation, see Annex D of this document.

The SDSFIE-M Conceptual Schema Profile is specified as follows:

Section 7.2 specifies the basic value domains (data types, code lists, and enumerations) used by the Conceptual Schema Profile;

Section 7.3 specifies the structure of the tables used to specify the Conceptual Schema data dictionary;

Section 7.4 specifies the resource metadata sections

Section 7.4.1 specifies the metadata entity set metadata elements;

Section 7.4.2 specifies the identification metadata elements;

Section 7.4.3 specifies the constraints metadata elements;

Section 7.4.4 specifies the data quality metadata elements;

Section 7.4.5 specifies the maintenance metadata elements;

Section 7.4.6 specifies the spatial representation system metadata elements;

Section 7.4.7 specifies the reference system metadata elements;

Section 7.4.8 specifies the identifier metadata elements;

6 In fact, all ISO standards in the 1900 series are defined using UML.


37

Section 7.4.9 specifies the content information metadata elements;

Section 7.4.10 specifies the application schema metadata elements;

Section 7.4.11 specifies the acquisition information metadata elements;

Section 7.4.12 specifies the extent metadata elements;

Section 7.4.13 specifies the citation and responsible party metadata elements;

7.2 Value Domains

In this SDSFIE-M Conceptual Schema Profile the specification of value domains provides a normalization of metadata values in order to ensure that two community members exchanging information “speak the same conceptual encoding language”.

The SDSFIE-M Conceptual Schema Profile draws on ISO/TS 19103 for its abstract types when specifying value domains; Section Annex B specifies the definitions for these datatypes. The SDSFIE-M Conceptual Schema Profile, however, requires additional types in order to unambiguously specify value domains. These fall into four categories:

Datatypes expressing complex content directly or indirectly in a CharacterString – these are specified in Table 2;

Codelists expressing a resource-managed value in a CharacterString – these are specified in Table 3;

Enumerations expressing fixed values in a CharacterString – these are specified in Table 4; and

Complex datatypes consisting of multiple elements whose value domains are either abstract types, datatypes, Codelist, or Enumeration values.

7.2.1 Datatypes

The SDSFIE-M Conceptual Schema Profile specifies unique datatypes; each expresses complex content as a CharacterString who’s allowed values are constrained to follow specific semantics (and syntax). These datatypes are specified in Table 2.

Name/Definition Example(s)

TelephoneNumber

An “internationalized” telephone number as specified in ITU-T Recommendation E.123 Clause 2.

NOTE1: The international prefix symbol is a ‘+’ (plus) and should precede the country code in the international number. It serves to remind the subscriber to dial the international prefix which differs from country to country and also serves to identify the number following as the international telephone number.

NOTE2: Spacing symbols are symbols that are used solely to separate parts of a telephone number from each other. They cannot be dial-able, procedural or information symbols. Grouping of digits in a telephone number should be accomplished only through the use of spaces in an international number. In the international number, spacing shall occur between the country code and the trunk code and between the trunk code and the subscriber number.

NOTE3: A slash (/) may not be used to indicate alternate numbers; instead separate element(s) shall be populated.

“+1 703 555 1234”

or

“+22 607 123 4567”


38

Name/Definition Example(s)

CrsIdentifier

An identification of a spatial (coordinate) reference system.

NOTE1: Represented as a single URL with two distinguishable components separated by a forward-slash (“/”) character.

NOTE2: The first component is a well-formed RestrictedURI expressing an authoritative namespace within which coordinate reference systems are designated; it may be treated as optional if its value can be determined from the context of use.

NOTE3: The second component is an unambiguous identifier of a coordinate reference system in the authoritative namespace; it consists of a character string of length at least one, and restricted such that it must not contain any of the following characters: “:” (colon), “ ” (space) , “/” (forward slash), (new line), (carriage return), and (tab).7

NOTE4: Using the fully-qualified CharacterString as a URL it shall be possible to unambiguously identify and access (e.g., via a catalog or register) the parametric specification of the coordinate reference system being referenced.

“http://metadata.dod.mil/ dse/ns/GSIP/crs/ WGS84E_2D” where the final substring designates the coordinate reference system.

or

“WGS84E_2D” where the authoritative namespace URL can be determined in context.

Table 2 : SDSFIE-M Conceptual Schema Profile Datatypes

7.2.2 Codelists

7.2.2.1 Data Agility

The SDSFIE-M Conceptual Schema Profile uses the Codelist type (literally, a “list of codes”) to specify the value domains for many metadata elements. The use of Codelists instead of “free text” or a fixed enumeration has three principal advantages:

They ensure that the lexical content of a metadata element is encoded in a consistent manner for a given concept. Even though the code may be a human-readable word or phrase, code lists eliminate variations in spelling, character case, spacing and other presentation factors to reduce the concept to a single unambiguous representation.

They are independent of the conceptual schema and the metadata content. This allows Codelists to be profiled to meet evolving user needs without requiring changes to the conceptual schema.

They provide a mechanism for encoding data for use in a multilingual environment. Because the codes provide a consistent representation for a given concept, supporting dictionaries containing definitions and human-readable labels in one or more languages can be developed for presentation of Codelist information in multiple languages.

Within a metadata instance document, the content of a metadata element that is specified as a Codelist value requires two pieces of information. In addition to the value itself, identification of the Codelist (value domain) is required in order for consumers of the metadata to interpret the value. One means to identify a value domain is publication and access of the values through a named register on common-access registry such as the DoD Metadata Registry (MDR).

The Codelists used to specify value domains in the SDSFIE-M Conceptual Schema shall be specified in the MDR; accordingly their domains are not specified in this document, although example values are provided.

7 This restriction is efficiently specified by the XML Schema pattern "[^: /\n\r\t]+".


39

Codelist Value

A Codelist value is an unambiguous identifier of a concept within a set of related concepts (e.g., country codes or geometry types). A Codelist value may be designated through the use of a URL, allowing for the identification of the Codelist value to be tied to a resource where the semantic of the value may be maintained.

For each Codelist the following rules apply:

A domain value is represented as a CharacterString with two distinguishable components separated by a forward-slash (“/”) character.

The first component is a RestrictedURI expressing an authoritative namespace within which the Codelist value is designated; this first component may be treated as optional if its value can be determined from the context of use.

The second component is an unambiguous identifier of a value in the authoritative Codelist namespace; it follows the XML schema pattern "[^: /\n\r\t]+" – which ensures that the Codelist value excludes specific characters and is at least one character in length.

Using the fully-qualified CharacterString as a URL it shall be possible to unambiguously identify and access (e.g., via a catalog or register) the full specification of the Codelist value being referenced.

7.2.2.2 Conceptual Schema Profile Codelists

The Codelists used by the SDSFIE-M Conceptual Schema Profile are specified in Table 3. The examples provided in Table 3 are not all-inclusive. All URLs containing “DISDI” may not be in-place at the time this document is published. Initial codelist values will be posted with SMIS when it is released.

Name / Authoritative Namespace(s) Example(s) (not all-inclusive)

AssociationTypeCode

justification for the correlation of two datasets

NOTE: The allowed authoritative namespaces are:

ISO 19115:2003/Cor. 1:2006 (as extended by the North American Profile):

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist//AssociationTypeCode”

"crossReference"

or

"largerWorkCitation"

or

"partOfSeamlessDatabase"

etc.

BandDefinitionCode

designation of criterion for defining maximum and minimum wavelengths for a spectral band

NOTE: The allowed authoritative namespaces are :

ISO 19115-2:2009 (profiled):

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/BandDefinitionCode”

“3dB” or “halfMaximum” or “fiftyPercent” or “oneOverE“ or “equivalentWidth“

CellGeometryCode

code indicating whether grid data is point, area, or volume



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist//CellGeometryCode”

“point”

or

“area”

or

“voxel”


40


CharacterSetCode

character coding standard used by the text of a resource


ISO 19115:2003/Cor. 1:2006 (profiled):

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/CharacterSetCode”

“utf8”

etc.

ClassifiedCode

a code indicating whether a resource is classified or not.


DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ClassifiedCode”

“unclassified”

or

“classified”

ClassificationCode

level of classification applicable to a resource, or portion of a resource.


DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ClassificationCode”

“U” (Unclassified)

or

“C” (Confidential)

or

“S” (Secret)

or

“TS” (Top Secret)

or

“R” (Restricted)

ContextCode

designation of criterion for defining the context of the scanning process event


ISO 19115-2:2009:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ContextCode”

“acquisition”

or

“pass”

or

“wayPoint”

CountryCode

recognized geographic identifier that is a member of the list of countries maintained in the GENC standard.

NOTE: The allowed authoritative namespace is:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/GENC-digraph” “http://metadata.ces.mil/dse/ns/DISDI/codelist/GENC-trigraph”

”US” or “USA”

or

“GB” or “GBR

etc.

CouplingTypeCode

type of coupling between service and associated data.


ISO/DIS 19115-1:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/CouplingTypeCode”

“loose”

or

“mixed”

or

“tight”

CoverageContentTypeCode

specific type of information represented in the cell.


ISO 19115:2003/Cor. 1:2006:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/CoverageContentTypeCode”

"image"

or

"thematicClassification"

or

"physicalMeasurement"


41


DateTypeCode

context with respect to which a date is specified.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/DateTypeCode”

“creation”

or

“publication”

or

“revision”

etc.

DCPList

type of distributed computing platform or environment.


ISO/DIS 19115-1:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/DCPList”

“XML”

or

“CORBA”

or

“JAVA””

etc.

DimensionNameTypeCode

name of the dimension.


ISO 19115-2:2009:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/DimensionNameTypeCode”

"row"

or

"column"

or

"vertical"

etc.

EvaluationMethodTypeCode

type of method for evaluating an identified data quality measure.


ISO 19115:2003/Cor. 1:2006 (as extended by the North American Profile)

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/EvaluationMethodTypeCode”

“directInternal”

or

“directExternal”

or

“indirect”

GeometricObjectTypeCode

name of point or vector objects used to locate zero-, one-, two-, or three-dimensional spatial locations in the dataset.


ISO 19115:2003/Cor. 1:2006:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/GeometricObjectTypeCode”

"complex"

or

"composite"

or

"curve"

etc.

GeometryTypeCode

geometric description of the collection


• ISO 19115-2:2009:

DISDI “http://metadata.ces.mil/dse/ns/DISDI/codelist/GeometryTypeCode”

“point”

or

“linear”

or

“areal”

etc.

ImagingConditionCode

code which indicates conditions which may affect the image.


ISO 19115:2003/Cor. 1:2006:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ImagingConditionCode”

"blurredImage"

or

"cloud"

or

"degradingObliquity"

etc.


42


KeywordTypeCode

method used to group a set of similar keywords.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/KeywordTypeCode”

“discipline”

or

“place”

or

“stratum”

etc.

MaintenanceFrequencyCode

frequency with which modifications and deletions are made to the data after it is first produced.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/MaintenanceFrequencyCode”

“continual”

or

“daily”

or

“weekly”

etc.

MetadataStandardNameCode

name of the metadata standard used.


DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/MetadataStandardNameCode”

“sdsfieMetadata”

NoticeTypeCode

set of currently authorized Notice values

NOTE: The allowed authoritative namespacs are::

ISM: “urn:us:gov:ic:ism-cvenum”

Found in the schema file: ./ic/ism/version/CVEGenerated/CVEnumISMNotice.xml

Where version is the version of IC-ISM used (currently this is “9.0.0”).

DISDI (for the currently mandated version of ISM): “http://metadata.ces.mil/dse/ns/DISDI/codelist/NoticeTypeCode

“RD”

or

“IMCON”

or

“FRD”

etc.

ObjectiveTypeCode

temporal persistence of collection objective


ISO 19115-2:2009:

DISDI:

“http://metadata.ces.mil/dse/ns/DISDI/codelist/ObjectiveTypeCode”

“instantaneousCollection”

or

“persistentView”

or

“survey”

OnlineFunctionCode

function performed by the resource.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/OnlineFunctionCode”

"download"

or

"information"

or

"offlineAccess"

etc.

ParameterDirection

indication if the parameter is an input to the service, an output or both.


ISO/DIS 19115-1:

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ParameterDirection”

“in”

or

“out”

or

“inOut”


43


PolarisationOrientationCode

polarisation of the antenna relative to the waveform


ISO 19115-2:2009 (profiled):

DISDI

“http://metadata.ces.mil/dse/ns/DISDI/codelist/PolarisationOrientationCode”

“horizontal”

or

“vertical”

or

“leftCircular”

etc.

PriorityCode

ordered list of priorities


• ISO 19115-2:2009 (profiled):

DISDI:

“http://metadata.ces.mil/dse/ns/DISDI/codelist/PriorityCode”

“critical”

or

“highImportance”

or

“mediumImportance”

etc.

PresentationFormCode

mode in which the data is represented



DISDI:

“http://metadata.ces.mil/dse/ns/DISDI/codelist/PresentationFormCode”

“documentDigital"

or

"documentHardcopy"

or

"imageDigital"

etc.

ProgressCode

status of the dataset or progress of a review



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ProgressCode”

"completed"

or

"historicalArchive"

or

"obsolete"

etc.

RestrictionCode

limitation placed upon the access to, or use of, a resource.


ISO 19115:2003/Cor. 1:2006 (profiled)

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/RestrictionCode”

“copyright”

or

“intellectualPropertyRights”

or

“restricted”

etc.

RoleCode

function performed by a responsible party for a resource.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/RoleCode”

“resourceProvider”

or

“custodian”

or

“owner”

etc.

ScopeCode

class of information to which the referencing entity applies.


ISO 19115:2003/Cor. 1:2006 (profiled):

DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ScopeCode”

“dataset”

or

“series”

or

“feature”

etc.


44


ScopeAmplificationCode

A set of scope amplifications individually identifying an augmentation of an identified grouping of information within a resource.


DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/ScopeAmplificationCode”

“cell”

or

“theme”

or

“notApplicable”

etc.

SequenceCode

temporal relation of activation


ISO 19115-2:2009:

DISDI

“http://metadata.ces.mil/dse/ns/DISDI/codelist/SequenceCode”

“start”

or

“end”

or

“instantaneous”

SpatialRepresentationTypeCode

method used to represent geospatial information in a resource.



DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/SpatialRepresentationTypeCode”

“vector”

or

“grid”

or

“textTable”

etc.

TopologyLevelCode

code which identifies the degree of complexity of the spatial relationships


DISDI: “http://metadata.ces.mil/dse/ns/DISDI/codelist/TopologyLevelCode”

“geometryOnly”

or

“topology1D”

or

“planarGraph”

etc.

TransferFunctionTypeCode

transform function to be used when scaling a physical value for a given element


ISO 19115-2:2009:

DISDI

“http://metadata.ces.mil/dse/ns//DISDI/codelist/TransferFunctionTypeCode”

“linear”

or

“logarithmic”

or

“exponential”

TriggerCode

Mechanism of activation


ISO 19115-2:2009:

DISDI

“http://metadata.ces.mil/dse/ns/DISDI/codelist/TriggerCode”

“automatic”

or

“manual”

or

“preProgrammed”

Table 3 : SDSFIE-M Conceptual Schema Codelists

7.2.3 Enumerations

An Enumeration value is an unambiguous identifier of a concept within a fixed, finite set of related concepts. Unlike a Codelist this set may not be extended without a schema modification. The following subsections specify the Enumerations used in the SDSFIE-M Conceptual Schema Profile.

7.2.3.1 TopicCategory

The Enumeration TopicCategory is defined as follows:


45

TopicCategory

A high-level geographic data thematic classification that assists in the grouping and search of available geospatial data sets.

NOTE1 May be used to group keywords as well. The listed example topic members are not exhaustive.

NOTE2 It is understood there are overlaps between general categories and the user is encouraged to select the one most appropriate.

Its domain members (enumerants) are specified in Table 4; for each the following information is specified:

domain Code – a 3-digit numeric code that may be used where compactness in denotation is desirable;

concept Topic – a human-interpretable camel-case designation for the topic;

concept Definition; and

Example Topic Members – concepts that fall within the scope of the topic category.

Code Topic Definition Example Topic Members

001 farming The rearing of animals and/or the

cultivation of plants.

Agriculture, irrigation, aquaculture, plantations, herding,

pests and diseases affecting crops and livestock.

002 biota Flora and/or fauna in the natural

environment.

Wildlife, vegetation, biological sciences, ecology,

wilderness, sea life, wetlands, and habitat.

003 boundaries Legal land descriptions. Political and administrative boundaries.

004 climatologyMeteorology

Atmosphere8

Processes and phenomena of the

atmosphere.

Cloud cover, weather, climate, atmospheric conditions,

climate change, and precipitation.

005 economy Economic activities, conditions

and employment.

Production, labor, revenue, commerce, industry,

tourism and ecotourism, forestry, fisheries, commercial

or subsistence hunting, exploration and exploitation of

resources such as minerals, oil and gas.

006 elevation Height above or below sea level. Altitude, bathymetry, digital elevation models, slope,

and derived products.

007 environment environmental resources,

protection and conservation

Environmental pollution, waste storage and treatment,

environmental impact assessment, monitoring

environmental risk, nature reserves, and landscapes.

008 geoscientificInformation Information pertaining to earth

sciences.

Geophysical features and processes, geology,

minerals, sciences dealing with the composition,

structure and origin of the earth’s rocks, risks of

earthquakes, volcanic activity, landslides, gravity

information, soils, permafrost, hydrogeology, and

erosion.

009 health Health, health services, human

ecology, and safety.

Disease and illness, factors affecting health, hygiene,

substance abuse, mental and physical health, and

health services.

010 imageryBaseMaps

EarthCover8

Base maps. Land cover, topographic maps, imagery, unclassified

images, and annotations.

011 intelligenceMilitary Military bases, structures, and

activities.

Barracks, training grounds, military transportation, and

information collection.

8 Although split over two lines for presentation purposes this is a single string with no breaks.


46

Code Topic Definition Example Topic Members

012 inlandWaters Inland water features, drainage

systems and their characteristics.

Rivers and glaciers, salt lakes, water utilization plans,

dams, currents, floods, water quality, and hydrographic

charts.

013 location Positional information and

services.

Addresses, geodetic networks, control points, postal

zones and services, and place names.

014 oceans Features and characteristics of

salt water bodies (excluding inland

waters).

Tides, tidal waves, coastal information, and reefs.

015 planningCadastre Information used for appropriate

actions for future use of the land.

Land use maps, zoning maps, cadastral surveys, and

land ownership.

016 society Characteristics of society and

cultures.

Settlements, anthropology, archaeology, education,

traditional beliefs, manners and customs, demographic

data, recreational areas and activities, social impact

assessments, crime and justice, and census

information.

017 structure Man-made constructions. Buildings, museums, churches, factories, housing,

monuments, shops, and towers.

018 transportation Means and aids for conveying

persons and/or goods.

Roads, airports/airstrips, shipping routes, tunnels,

nautical charts, vehicle or vessel location, aeronautical

charts, and railways.

019 utilitiesCommunication Energy, water and waste systems

and communications infrastructure

and services.

Hydroelectricity, geothermal, solar and nuclear sources

of energy, water purification and distribution, sewage

collection and disposal, electricity and gas distribution,

data communication, telecommunication, radio, and

communication networks.

Table 4 : Enumeration MD_TopicCategory Domain Values

7.2.3.2 PixelOrientationCode

The Enumeration PixelOrientation is defined as follows:

PixelOrientationCode

Point in a pixel corresponding to the Earth location of the pixel

Its domain members (enumerants) are specified in Table 5; for each the following information is specified:

domain Code – a 3-digit numeric code indicating the maturity rating;

concept Maturity – a human-interpretable camel-case designation for the rating;

concept Description - a description of the criteria for each rating; and

Code Orientation Description

000 center point halfway between the lower left and the upper right of the pixel

001 lowerLeft the corner in the pixel closest to the origin of the SRS; if two are at the same distance from the

origin, the one with the smallest x-value

002 lowerRight next corner counterclockwise from the lower left

003 upperRight next corner counterclockwise from the lower right

004 upperLeft next corner counterclockwise from the upper right

005 center point halfway between the lower left and the upper right of the pixel


47

Table 5 : Enumeration MD_PixelOrientationCode Domain Values


48

7.3 Element Table Structure

7.3.1 Introduction

Each subsection in Section 7.4 contains a UML diagram and a data dictionary table. The data dictionary tables provide definitions and explanations to go along with the UML diagram in order to fully define the metadata. The dictionary is specified in a hierarchy to establish relationships and an organization for the information.

The UML diagrams contained in Section 7.4 are profiled versions of the UML diagrams contained in ISO 19115:2003/Cor 1:2006, ISO 19115-2:2009, ISO/DIS 19115-1, or NMF Parts 1-3. Some classes, attributes and association roles have been hidden and some have been extended because they do not apply to SDSFIE-M. For the full diagrams, consult the relevant ISO document.

For the data dictionary tables in Section 7.4, each UML model class equates to a data dictionary entity. Each UML model class attribute equates to a data dictionary element. The shaded rows define entities. The entities and elements within the data dictionary are defined by six attributes (as listed below). The term “dataset”, when used as part of a definition, is synonymous with all the types of aggregated geographic data attributes (all members from the NMF_ScopeCode codelist).

7.3.2 Name

A label assigned to a metadata entity or to a metadata element. Metadata entity names start with an upper case letter. Spaces do not appear in a metadata entity name. Instead, multiple words are concatenated, with each new subword starting with a capital letter (example: XnnnYmmm). Metadata entity names are unique within the entire data dictionary of this document. Metadata element names are unique within a metadata entity, not the entire data dictionary of this document. Metadata element names are made unique, within an application, by the combination of the metadata entity and metadata element names (example: MD_Metadata.characterSet). Role names are used to identify metadata abstract model associations and are preceded by “Role name:” to distinguish them from other metadata elements.

7.3.3 Definition

The metadata entity/element description.

7.3.4 Obligation/Condition

7.3.4.1 General

This is a descriptor indicating whether a metadata entity or metadata element shall always be documented in the metadata or sometimes be documented (i.e. contains value(s)). This descriptor may have the following values: M (mandatory), C (conditional), or O (optional).

7.3.4.2 Mandatory

The metadata entity or metadata element shall be documented.


49

7.3.4.3 Conditional

Specifies an electronically manageable condition under which at least one metadata entity or a metadata 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 documented.

Documenting a metadata entity or a metadata element if another element has been documented.

Documenting a metadata element if a specific value for another metadata element has been documented. To facilitate reading by humans, the specific value is used in plain text (ex. "C/not defined by encoding?”).

If the answer to the condition is positive, then the metadata entity or the metadata element shall be mandatory. The conditions are typically supplied as footnotes to make the table more legible.

7.3.4.4 Optional

A metadata record may or may not include a metadata entity from the SDSFIE-M, and may or may not specify a value of a metadata element in SDSFIE-M. Optional metadata entities and optional metadata elements provide a guide to those looking to fully document their data when preparing a metadata record. (Use of this common set of defined elements will help promote interoperability among geographic data users and producers in the I&E community.)

If an optional metadata entity is not included in a metadata record, then the metadata elements contained within that entity (including mandatory elements) shall have no specified values.

If an optional metadata entity is included in a metadata record, then the mandatory metadata elements contained within that entity shall have specified values.

If a metadata entity (optional or otherwise) is included in a metadata record and there are no mandatory metadata elements contained within that entity, then at least one conditional or optional element contained within that entity shall have a specified value. The choice of which metadata element shall become mandatory is determined by a conditional expression in the context in which the metadata entity is referenced (the UML class whose association role references the metadata entity UML class).

7.3.5 Maximum occurrence

Specifies the maximum number of instances the metadata entity or the metadata element may have. Single occurrences are shown by “1”; repeating occurrences are represented by “N”. Fixed number occurrences other than one are allowed, and will be represented by the corresponding number (i.e. “2”, “3”…etc.).


50

Multiplicity should always be understood to apply to the specified metadata element “as a whole” – regardless of the nature (e.g., complex) of its value domain. Conversely, multiplicity should always be understood to be only applicable (meaningful) within the scope of the table within which the element is specified.

For example, while a point of contact shall have exactly one postal address, that postal address may have multiple delivery point element values (e.g., a street address as well as a suite number).

The multiplicity of the Contact (in whatever table it appears) would then be exactly one with a value domain of ContactPostalAddress, however the table specifying the Contact Postal Address would contain a line (element) specifying a Delivery Point with a multiplicity of one or more (with a value domain perhaps of CharacterString).

The types of possible multiplicity statements are listed in Table 6.

Multiplicity Definition Implied Obligation

Exactly one Example: 1

Exactly one value occurrence is permitted. Minimum

At least one Example: 1..*

At least one value occurrence is required, and multiple value occurrences are permitted.

Minimum

Exact number Example: 3

Exactly the specified number of value occurrences must be present.

Minimum

Exact range Example: 2..4

At least the number of value occurrences specified in the lower range limit must be present; no more value occurrences than the specified upper range limit may be present.

Minimum

Zero or one Example: 0..1

Possibly one; zero or one value occurrence is permitted. Additional

Zero or more Example: 0..*

A possibly empty range; zero or more value occurrences are permitted.

Additional

Exact range (possibly empty) Example: 0..3

No occurrences are permitted; no more occurrences than the specified upper range limit may be present.

Additional

Table 6 : Multiplicity and Implied Obligation

7.3.6 Datatype / Domain

Specifies a set of distinct values for representing the metadata elements; for example, integer, real, string, DateTime, and Boolean. The data type attribute is also used to define metadata entities, stereotypes, and metadata associations.

In cases where the value domain is complex, a reference is provided to the section that specifies its complex content requirement. When this occurs no example is specified, that table cell grey-filled, and the example is instead specified in the referenced section.

The domain specifies the values allowed or the use of free text. “Free text” indicates that no restrictions are placed on the content of the field. Integer-based codes shall be used to represent values for domains containing codelists.

7.3.7 Business Rule

Business rules describe the operation of an enterprise and can relate to something as high-level as privacy or security, or as low-level as the derivation of a particular


51

metadata element value. It is generally not appropriate to build such constraints routinely into implementation database structures or even interfaces. However, such rules are still important and must be discerned, documented and accommodated in such a way that implementers will not overlook their importance, requirements builders will fully understand their impact, and acquisition personnel will recognize their necessity.

Details on business rules can be found in Section A.2.3.


52

7.4 Resource Metadata Sections

7.4.1 Metadata Entity Set

7.4.1.1 Metadata Entity Set UML

This UML diagram presented in this section is a SDSFIE-M -specific version of the corresponding Metadata Entity Set Package UML diagrams found in ISO 19115:2003/Cor 1:2006 (Figure A.1) and NMF Part 1 (Figure 2). The diagram has been profiled, so some classes, attributes and association roles have been hidden. For the full diagram, consult ISO 19115:2003/Cor 1:2006.

This diagram shows containment relationships with the other metadata classes which, in aggregate, define metadata for geographic data.

Figure 3 : Metadata Entity Set

7.4.1.2 Metadata Entity Set

The data dictionary (Table 9) presented in this section is an SDSFIE-M -specific version of the corresponding Metadata Entity Set data dictionary table found in NMF Part 1 (Table 7). The table has been extended, so some classes, attributes and association roles have been added and some domains have been modified.

Name / role name Definition Obligation / Condition

Max

Occur

Data type Domain

Business Rule


53

MD_Metadata root entity which defines metadata about a resource or resources

M 1 Class

fileIdentifier unique identifier for this metadata file

M 1 CharacterString / Free text

language language used for documenting metadata

M 1 CharacterString / ISO 639-2, other parts may be used

Default value: “en”

characterSet full name of the character coding standard used for the metadata set

M 1 Class / CharacterSetCode <<CodeList>> (7.2.2.2)

See Table 3 (CharacterSetCode)

Default value: “utf8”

parentIdentifier file identifier of the metadata to which this metadata is a subset (child)

C 1 CharacterString / Free text

Obligation: Required if there is an upper hierarchy level.

hierarchyLevel scope to which the metadata applies (see ISO 19115, Annex H for more information about metadata hierarchy levels)

M N Class / ScopeCode <<CodeList>> (7.2.2.2)

See Table 3 (ScopeCode)

Note: this element is optional in 19115

hierarchyLevelName name of the hierarchy levels for which the metadata is provided

M N CharacterString / ScopeAmplification Code <<CodeList>> (7.2.2.2)

See Table 3 (ScopeAmplification)


contact party responsible for the metadata information

M N Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)

In the case of more than a single contact element then the first of the set shall use the RoleCode “pointOfContact”.

dateStamp date that the metadata was created

M 1 Class / Date (Annex B)

metadataStandardName name of the metadata standard (including profile name) used

M 1 CharacterString / MetadataStandardName <<CodeList>> (7.2.2.2)

See Table 3 (Metadata StandardNameCode)

Default Value: SDSFIE-M Identifier9

Note: This element is optional in 19115

metadataStandardVersion version of the metadata standard (version of the profile) used


It is recommended Best Practice that the version number follow the 0.0.0 format.

Note: This element is optional in 19115

dataSetURI Uniformed Resource Identifier (URI) of the dataset to which the metadata applies

O 1 CharacterString / Free text

9 http://metadata.ces.mil/dse/ns/DISDI/codelist/MetadataStandardNameCode/sdsfieMetadata


54

locale provides information about an alternatively used localized character string for linguistic extension

O 1 Class / PT_Locale (7.4.1.3)

Obligation: Required when not defined by encoding.

Note: This element has a maximum occurrence of “N” in 19115.

role name: spatialRepresentationInfo

digital representation of spatial information in the dataset

O N Association / MD_SpatialRepresentation <<Abstract>> (7.4.6.2)

role name: referenceSystemInfo

description of the spatial and temporal reference systems used in the dataset

C N Association / MD_ReferenceSystem (7.4.7.2)

Obligation: Required if the resource includes coordinates. 10

role name: identificationInfo

basic information about the resource(s) to which the metadata applies

M N Association / MD_Identification <<Abstract>> (7.4.2.2)

role name: contentInfo provides information about the feature catalogue and describes the coverage and image data characteristics

O N Association / MD_ContentInformation <<Abstract>> (7.4.9.2)

role name: dataQualityInfo

provides overall assessment of quality of a resource(s)

O N Association / DQ_DataQuality (7.4.4.2)

role name: metadataConstraints

provides restrictions on the access and use of metadata

M 2..N Association / MD_Constraints (7.4.3.2)

It is a Recommended Best Practice that there shall be two instances of MD_Constraints, one for MD_SecurityConstraints and at least one for MD_LegalConstraints.

role name: applicationSchemaInfo

provides information about the conceptual schema of a dataset

O N Association / MD_ApplicationSchemaInformation (7.4.10.2)

role name: metadataMaintenance

provides information about the frequency of metadata updates, and the scope of those updates

O 1 Association / MD_MaintenanceInformation (7.4.5)

Table 7 : Metadata Entity Set

The MI_Metadata class is a specialization of MD_Metadata defined in ISO 19115-2 (Figure A.1) and retained in NMF Part 3 (Section 7.4.1.1, Figure 1). This class is used when documenting imagery or gridded data. No additional profiling of this class has been performed to address I&E community requirements.

10 if spatialRepresentationType in MD_DataIdentification is "vector", "grid", or "tin"


55

Figure 4 : Metadata Entity Set, Extended for Imagery and Gridded Data

The data dictionary table in this section is from NMF Part 3 (Section 7.4.1.2, Table 6). No additional profiling of this table has been performed to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

MI_Metadata

root entity that defines information about imagery or gridded data (MD_Metadata extended)

Use obligation/ condition

from referencing

object

Use maximum occurrence

from referencing

object

Specified Class (MD_Metadata)

role name: acquisitionInformation

provides information about the acquisition of the data

C11 N

Association / MI_AcquisitionInformation (7.4.11.2)

Obligation: Required when documenting imagery or gridded data

Table 8 : Metadata Entity Set, Extension for Imagery and Gridded Data

7.4.1.3 Locale

The data dictionary table presented in this section is an profile of the corresponding NMF Part 1 PT_Locale datatype (Section 7.4.1.3, Table 8).


Max

Occur

Data type Domain

Business Rule

11 if spatialRepresentationType in MD_DataIdentification is "grid"


56

PT_Locale

identification of the human language(s), language country(ies), and character set(s) used in the resource


from referencing

object


from referencing

object

Class <<DataType>>

language

identification of the human language that is used in the text

M 1

Class / LanguageCode <<CodeList>>

See Table 3 (LanguageCode)

Default value: “en”

country

national localization of the language that is used in the text

M 1

Class / CountryCode <<CodeList>>

See Table 3 (CountryCode)

Default value: “US”

characterEncoding

identification of the character set that is used in the text

M 1

Class / CharacterSet <<CodeList>>


Default value: “utf8”

Table 9 : Locale


57

7.4.2 Identification

7.4.2.1 Identification UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Identification Package UML diagram (Figure A.2) found in ISO 19115:2003/Cor 1:2006 and NMF Part 1 (Figure 3). The diagram has been profiled from NMF Part 1. The NMF_DataIdentification class has been removed, some attributes and association roles from ISO 19115:2003/Cor 1:2006 have been restored.

This diagram defines the metadata classes required to identify a resource.

Figure 5 : Identification

This UML diagram in Figure 6 is provided to show the relationships between SV_ServiceIdentification and its associated classes.


58

Figure 6 : Service Identification Context

7.4.2.2 Identification

The data dictionary table presented in this section is a SDSFIE-M -specific version of the corresponding Identification data dictionary table (Section B.2.2) found in ISO 19115:2003/Cor 1:2006 and NMF Part 1 (Table 9). The SV_ServiceIdentification portion of the table is from ISO/DIS 19115-1 (Section B.2.14.1). The table has been profiled from that table, so some classes, attributes and association roles have been hidden. For the full table, consult ISO 19115:2003/Cor 1:2006 and NMF Part 1.


Max

Occur

Data type Domain

Business Rule

MD_Identification basic information required to uniquely identify a resource or resources

Use obligation/

condition from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata) <<Abstract>>

citation citation data for the resource(s)

M 1 Class / CI_Citation <<DataType>> (7.4.13.2)


59

abstract brief narrative summary of the content of the resource(s)


Abstract narrative should include information on general content, thematic features (e.g., geology; climatology; etc.), and features; dataset application: GIS, CAD, image, database; geographic coverage: county/city name; time period of content: begin and end date or single date; and special data characteristics or limitations

purpose summary of the intentions with which the resource(s) was developed.


status status of the resource(s) M N Class / ProgressCode <<CodeList>> (7.2.2.2)

See Table 3 (ProgressCode)

pointOfContact identification of, and means of communication with, person(s) and organization(s) associated with the resource(s)


In the case of more than a single pointOfContact element then the members of the set shall be ordered in descending priority of their recommended use, however not all implementations will necessarily honor the ordering.

Note: this element is optional in 19115.

role name: resourceMaintenance

provides information about the frequency of resource updates, and the scope of those updates

O N Association / MD_MaintenanceInformation (7.4.5)

role name: graphicOverview

provides a graphic that illustrates the resource(s) (should include a legend for the graphic)

O N Association / MD_BrowseGraphic

role name: resourceFormat

provides a description of the format of the resource(s)

O N Association / MD_Format (7.4.2.4)


60

role name: descriptiveKeywords

provides category keywords, their type, and reference source

M N Association / MD_Keywords (7.4.2.3)

role name: resourceConstraints

provides information about constraints which apply to the resource(s)

M 2..N Association / MD_Constraints (7.4.3)

It is a Recommended Best Practice that there shall be two or more instances of MD_Constraints, one for security constraints and at least one for legal constraints.

role name: aggregationInfo

provides aggregate dataset information

O N Association / MD_AggregateInformation (7.4.2.7)

MD_DataIdentification information required to identify a dataset

Use obligation/


object

Use maximum

occurrence from

referencing object

Specified Class (MD_Identification)

spatialRepresentationType method used to spatially represent geographic information

O N Class / SpatialRepresentation TypeCode <<CodeList>> (7.2.2.2)

See Table 3 (SpatialRepresentationTypeCode)

spatialResolution factor which provides a general understanding of the density of spatial data in the dataset

O N Class / MD_Resolution <<Union>> (7.4.2.5)

language language(s) used within the dataset

M N CharacterString / ISO 639-2, other parts may be used

Default: “en”

characterSet full name of the character coding standard used for the dataset

M N Class / CharacterSetCode <<CodeList>> (7.2.2.2)


Default: “utf8”

topicCategory main theme(s) of the dataset

C / if hierarchyLevel

equals “dataset”?

N Class / MD_TopicCategoryCode <<Enumeration>> (7.2.3.1)

environmentDescription description of the dataset in the producer’s processing environment, including items such as the software, the computer operating system, file name, and the dataset size



61

extent extent information including the bounding box, bounding polygon, vertical, and temporal extent of the dataset

C / if hierarchyLevel

equals “dataset” ?

either extent.geographicElement.EX_GeographicBoundingBox

or extent.geographicElement.EX_GeographicDescription is

required

N Class / EX_Extent <<DataType>> (7.4.12.2)

If the hierarchyLevel element value is “dataset” then at least either the bounding box or point shall be populated.

If the hierarchyLevel element value is “series” then at least either the bounding box or polygon shall be populated.

At least one of MinimumBoundingRectangle, BoundingPolygon, or BoundingPoint is required.

Note that this may not necessarily be the full extent of the content of the resource as multiple instances of this class may be specified.

supplementalInformation any other descriptive information about the dataset


SV_ServiceIdentification identification of capabilities which a service provider makes available to a service user through a set of interfaces that define a behaviour - See ISO 19119 – Services for further information

Use obligation/


object

Use maximum

occurrence from

referencing object

Specified Class (MD_Identification)

serviceType a service type name from a registry of services. For example, the values of the nameSpace and name attributes of GeneralName may be "OGC" and "catalogue".

M 1 GenericName (Annex B)

serviceTypeVersion provides for searching based on the version of serviceType. For example, we may only be interested in OGC Catalogue V1.1 services. If version is maintained as a separate attribute, users can easily search for all services of a type regardless of the version.

O N CharacterString


62

accessProperties

information about the availability of the service, including, - fees - planned available date and time - ordering instructions - turnaround

O 1

Class / MD_StandardOrderProcess (7.4.2.12)

couplingType

qualitative information on the tightness with which the service and the associated data are coupled

M 1 Class / CouplingType <<CodeList>> (7.2.2.2)

See Table 3 (CouplingType)

coupledResource

further description of the coupling between the service and the data when they are tightly coupled

O N Class / SV_CoupledResource (7.4.2.11)

operatedDataset provides a reference to the dataset on which the service operates

O N Class / CI_Citation <<DataType>> (7.4.13.2)

role name: containsOperations

provides information about the operations that comprise the service

M N Association / SV_OperationMetadata (7.4.2.8)

role name: operatesOn provides information on the datasets that the service operates on

O N Association / MD_DataIdentification (7.4.2.2)

role name: containsChain

provide information about the chain applied by the service

O N Class / SV_OperationChainMetadata (7.4.2.9)

Table 10 : Identification

7.4.2.3 Keywords

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Keywords data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.2.3) and NMF Part 1 (Table 10).


Max

Occur

Data type Domain

Business Rule

MD_Keywords keywords, their type and reference source

Use obligation/


object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Identification)

keyword commonly used word(s) or formalised word(s) or phrase(s) used to describe the subject

M N CharacterString /

Free text

type subject matter used to group similar keywords

O 1 Class /

KeywordTypeCode

<<CodeList>> (7.2.2.2)

See Table 3 (KeywordTypeCode)

See Table 3 (KeywordTypeCode)


63

thesaurusName name of the formally registered thesaurus or a similar authoritative source of keywords

M 1 Class /

CI_Citation

<<DataType>>

(7.4.13.2)


Table 11 : Keywords

7.4.2.4 BrowseGraphic

The data dictionary table presented in this section is an SDSFIE-M-specific version of the corresponding Browse Graphic data dictionary table found in ISO 19115:2003 (Section B.2.2.2).


Max

Occur

Data type Domain

Business Rule

MD_BrowseGraphic graphic that provides an illustration of the dataset (should include a legend for the graphic)

Use obligation/ condition from referencing object

Use maximum occurrence from referencing object


fileName name of the file that contains a graphic that provides an illustration of the dataset


fileDescription text description of the illustration O 1 CharacterString / Free text

fileType format in which the illustration is encoded Examples: CGM, EPS, GIF, JPEG, PBM, PS, TIFF, XWD


7.4.2.5 Format

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Keywords data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.10.4) and NMF Part 1 (Section 7.4.10.2, Table 31).


Max

Occur

Data type Domain

Business Rule

MD_Format description of the computer language construct that specifies the representation of data objects in a record, file, message, storage device or transmission channel




name name of the data transfer format(s) M 1 CharacterString / Free text

version version of the format (date, number, etc.)


Table 12 : Format


64

7.4.2.6 Resolution

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Resolution data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.2.5). The table has been profiled, so some classes, attributes and association roles have been hidden. For the full table, consult ISO 19115:2003/Cor 1:2006.


Max

Occur

Data type Domain

Business Rule

MD_Resolution level of detail expressed as a scale factor or a ground distance

Use obligation/ condition from

referencing object

Use maximum

occurrence from

referencing object

Class <<Union>> UNION – one and only one attribute should be populated

equivalentScale level of detail expressed as the scale of a comparable hardcopy map or chart

C / if distance not documented or if

spatialRepresentationType in

MD_DataIdentification is "vector" or "tin"?

1 Class / MD_RepresentativeFraction <<DataType>> (7.4.2.6)

distance ground sample distance C / if equivalentScale not documented or if

spatialRepresentationType in

MD_DataIdentification is "grid"?

1 Class / Distance (Annex B)

Distance is used as a type for returning the length between two points. (defined in ISO/TS 19103)

Table 13 : Resolution

7.4.2.7 Representative Fraction

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Representative Fraction data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.2.4). The table has been profiled, so some classes, attributes and association roles have been hidden. For the full table, consult ISO 19115:2003/Cor 1:2006.


Max

Occur

Data type Domain

Business Rule

MD_RepresentativeFraction derived from ISO 19103 Scale where MD_RepresentativeFraction.denominator = 1 / Scale.measure And Scale.targetUnits = Scale.sourceUnits


from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

denominator the number below the line in a vulgar fraction

M 1 Integer / Integer > 0

Table 14 : Representative Fraction


65

7.4.2.8 Aggregate Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Aggregate data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.2.7). The table has been profiled, so some classes, attributes and association roles have been hidden. For the full table, consult ISO 19115:2003/Cor 1:2006.


Max

Occur

Data type Domain

Business Rule

MD_AggregateInformation aggregate dataset information


referencing object

Use maximum

occurrence from

referencing object


aggregateDataSetName citation information about the aggregate dataset

C / if aggregateDataSetIdentifier not documented?

1 Class / CI_Citation <<DataType>> (7.4.13.2)

aggregateDataSetIdentifier identification information about aggregate dataset

C / if aggregateDataSetName not documented?

1 Class / MD_Identifier <<DataType>> (7.4.8.2)

associationType association type of the aggregate dataset

M 1

Class / AssociationTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (AssociationTypeCode)

Table 15 : Aggregate Information

7.4.2.9 Operation Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Operation Metadata data dictionary table found in ISO/DIS 19115-1 (Section B.2.14.2).


Max

Occur

Data type Domain

Business Rule

SV_OperationMetadata describes the signature of one and only one method provided by the service.


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (SV_ServiceIdentification)

operationName an identifier that uniquely designates the operation


distributedComputingPlatform distributed computing platforms on which the operation has been implemented

M N Class / DCPList <<CodeList>> (7.2.2.2)

See Table 3 (DCPList)

operationDescription free text description of the intent of the operation and the results of the operation



66

invocationName the name used to invoke this interface within the context of the DCP. The name is identical for all DCPs.


connectPoint handle for accessing the service interface

M N Class / CI_OnlineResource <<DataType>> (7.4.13.7)

role name: dependsOn list of operations that must be completed immediately before current operation is invoked, structured as a list for capturing alternate predecessor paths and sets for capturing parallel predecessor paths

O N Sequence / CharacterString set{sequence{operationName} | set(operationName}

role name: parameters the parameters that are required for this interface

M 1 Sequence (B.4.7) / SV_Parameter (7.4.2.10)

role name: theSV_ServiceIdentification

capabilities which a service provider makes available to a service

O N Association / SV_ServiceIdentification (7.4.2.2)

Table 16 : Operation Information

7.4.2.10 Operation Chain Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Operation Chain Information data dictionary table found in ISO/DIS 19115-1 (Section B.2.14.3).


Max

Occur

Data type Domain

Business Rule

SV_OperationChainMetadata Operation Chain Information


from referencing

object

Use maximum

occurrence from

referencing object


name the name, as used by the service for this chain

M 1 CharacterString / FreeText

description a narrative explanation of the services in the chain and resulting output

O 1 CharacterString / FreeText

role name: operation (ordered) information about the operations applied by the chain

M N Class / SV_OperationMetadata (7.4.2.8)

Table 17 : Operation Chain Information

7.4.2.11 Parameter Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Parameter Information data dictionary table found in ISO/DIS 19115-1 (Section B.2.14.4).


67


Max

Occur

Data type Domain

Business Rule

SV_Parameter describes a parameter of a service


referencing object

Use maximum

occurrence from

referencing object


name the name, as used by the service for this parameter

M 1 Class / MemberName (Annex B)

direction indication if the parameter is an input to the service, an output or both

O 1 Class / ParameterDirection <<CodeList>> (7.2.2.2)

See Table 3 (ParameterDirection)

description description a narrative explanation of the role of the parameter

O 1 CharacterString

optionality indication if the parameter is required

M 1 CharacterString

repeatability indication if more than one value of the parameter may be provided

M 1 Boolean

role name: valueType the class used for thevalue type

O N TypeName (Annex B)

Table 18 : Parameter Information

7.4.2.12 Coupled Resource Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Coupled Resource Information data dictionary table found in ISO/DIS 19115-1 (Section B.2.14.5).


Max

Occur

Data type Domain

Business Rule

SV_CoupledResource information describing the linkage between a service operation and a tightly coupled dataset


referencing object

Use maximum

occurrence from

referencing object


scopedName scoped identifier of the resource in the context of the given service instance NOTE: name of the resources (i.e. dataset) as it is used by a service instance (e.g. layer name or featureTypeName).

O 1 Class / ScopedName (Annex B)

resourceReference reference to the dataset on which the service operates



68

role name: resource the tightly coupled dataset. This attribute should be implemented by reference

O N Class / MD_DataIdentification (7.4.2.2)

role name: operation The service operation. This attribute should be implemented by reference

O 1 Class / SV_OperationMetadata (7.4.2.8)

Table 19 : Coupled Resource Information

7.4.2.13 Standard Order Process Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Standard Order Process Information data dictionary table found in ISO/DIS 19115-1 (Section B.2.11.6).

MD_StandardOrderProcess common ways in which the resource may be obtained or received, and related instructions and fee information


from referencing

object

Use maximum

occurrence from

referencing object


fees fees and terms for retrieving the resource. Include monetary units (as specified in ISO 4217)

C 1

CharacterString / Free text

Obligation: At least one of the conditional attributes in this class must be used

plannedAvailableDateTime date and time when the resource will be available

C 1

Class / DateTime (Annex B)


orderingInstructions general instructions, terms and services provided by the distributor

C 1



turnaround typical turnaround time for the filling of an order

C 1



orderOptionsType description of the order options record

O 1 Class / RecordType (Annex B)

orderOptions request/purchase choices

C 1

Class / Record (Annex B)


Table 20 : Standard Order Process Information


69

7.4.3 Constraints

7.4.3.1 Constraints UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Constraint Package UML diagram found in ISO 19115:2003/Cor 1:2006 (Figure A.3) and as extended by NMF Part 1 (Section 7.4.3.1, Figure 4). Classes, attributes and associations that have not been included in this SDSFIE-M profile have been hidden. Likewise, classes, attributes and associations which extend the base standard have been added. For the original diagram consult ISO 19115:2003/Cor 1:2006.

The NMF and SDSFIE-M modifies the ISO 19115 model of MD_SecurityConstraints as follows:

MD_SecurityConstraints has been subclassed by NMF (and thus SDSFIE-M) to create the NMF_SecurityConstraints class. This class serves as the root for U.S. Intelligence and Defense related security marking metadata.


70

Figure 7 : Constraints

7.4.3.2 Constraints

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Constraints data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.3) and NMF Part 1 (7.4.3.2, Table 15). For the original data dictionary consult ISO 19115:2003/Cor 1:2006.

The SDSFIE-M modifies the ISO 19115 and NMF data dictionary for Constraints as follows:

The elements accessConstraints, useConstraints, and classification have been restricted to SDSFIE-M /NMF CodeLists


71

Constraints are mandatory for MD_Metadata and MD_Identification instances. One instance of NMF_SecurityConstraints is required. One instance of MD_LegalConstraints is required with additional instances being optional.


Max

Occur

Data type Domain

Business Rule

MD_Constraints restrictions on the access and use of a resource or metadata


referencing object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata and MD_Identification)

useLimitation limitation affecting the fitness for use of the resource or metadata. Example, “not to be used for navigation”

O N CharacterString / Free text

MD_LegalConstraints restrictions and legal prerequisites for accessing and using the resource or metadata


referencing object

N Specified Class (MD_Constraints)

accessConstraints access constraints applied to assure the protection of privacy or intellectual property, and any special restrictions or limitations on obtaining the resource or metadata

O N Class / RestrictionCode <<CodeList>> (7.2.2.2)

See Table 3 (RestrictionCode)

See Table 3

useConstraints constraints applied to assure the protection of privacy or intellectual property, and any special restrictions or limitations or warnings on using the resource or metadata

O N Class / RestrictionCode <<CodeList>> (7.2.2.2)

See Table 3 (RestrictionCode)

See Table 3

SMF_LegalConstraints Extended class to hold additional legal information


referencing object

N Specified Class (MD_LegalConstraints)

furtherExplanation further explanation of the legal restrictions


MD_SecurityConstraints handling restrictions imposed on the resource or metadata for national security or similar security concerns


referencing object

1 Specified Class (MD_Constraints)

classification name of the handling restrictions on the resource or metadata

M 1 Class / ClassificationCode <<CodeList>> (7.2.2.2)

See Table 3 (ClassificationCode)

See Table 3

userNote explanation of the application of the legal constraints or other restrictions and legal prerequisites for obtaining and using the resource or metadata


classificationSystem name of the classification system

M 1 CharacterString Always has to be "US CAPCO"


72

handlingDescription additional information about the restrictions on handling the resource or metadata


Table 21 : Constraints

7.4.3.3 SDSFIE-M Security Constraints Extension

ISO 19115:2003/Cor 1:2006 contains a bare minimum of security-related metadata elements. That bare minimum is not sufficient for use in the NSG (or in the I&E community). The MD_SecurityConstraints class has been extended to accommodate the additional security requirements. The extension follows DoD/IC directives for the use of IC.ADD.V2 (Chapter 3, Information Security Marking) as defined in the table below.

The XML Data Encoding specification for Need-To-Know Metadata, version 5 (NTK.XML.V5) is an ODNI standard for encoding metadata necessary to facilitate automated systems making a “need-to-know” determination in order allow to address a resource. Support for this standard has been included in Table 24.

MD_SecurityConstraints entity has been extended by the SDSFIE-M to include an attribute describing handling restrictions for unclassified data.It is mandatory for all users of the SDSFIE-M to document security metadata using the SMF_SecurityConstraints class.


Max

Occur

Data type Domain

Business Rule

SMF_SecurityConstraints Extended class to hold additional security information.


from referencing

object

1 Specified Class (MD_SecurityConstraints) (Table 16)

capcoMarking provides Intelligence Community Information Security Markings (IC.ADD) security elements.

M 1 Class / ISM_SecurityAttributesGroup (Table 23)

needToKnow User, group or profile identifying information to be used to make a need-to-know access determination.

O 1 Class / NTK_Access (Table 24)

handlingDescription additional information about the restrictions on handling the resource or metadata

C / NMFSecurityConstraints.capcoMarking.classification = "U" and the

handling restriction defined in

the associated code list exists?

1 CharacterString / UnclassHandlingCode <<CodeList>> (7.2.2.2)

See Table 3 (UnclassHandlingCode)


73

role name: notices Information concerning “well-defined” security notices including those defined in the CAPCO register and the ISM.XML standard

O N Class / ISM_Notices (Table 25)

Table 22 : SDSFIE-M Security Constraints

7.4.3.3.1 Capco Marking

The Controlled Access Program Coordination Office (CAPCO) is responsible for establishing the uniform list of security control markings authorized for dissemination of classified information by components of the U.S. Intelligence Community and the authorized abbreviated forms of such markings. This list is maintained and disseminated through the Authorized Classification and Control Markings Register (known as the CAPCO Register). The authoritative list of CAPCO markings for use in the NSG are documented in IC.ADD.V2 (Chapter 3, Information Security Marking).XML encodings of the CAPCO markings is specified is the ISM.XML standard.

The data dictionary table presented in this section is not found in ISO 19115:2003/Cor 1:2006. This metadata represents the CAPCO markings as specified in IC.ADD version 2 and is specific to NSG implementations.


Max

Occur

Data type Domain

Business Rule

ISM_SecurityAttributesGroup


from referencing

object

Use maximum

occurrence from

referencing object

Class

atomicEnergyMarkings One or more indicators identifying information controlled under the Atomic Energy Act.

O 1 Character String / Free Text

classification A single indicator of the highest level of classification applicable to an information resource or portion within the domain of classified national security information.

M 1 Character String / Free Text

The Classification element is always used in conjunction with the Owner Producer element. Taken together, the two elements specify the classification category and the type of classification (US, non-US, or Joint).

classificationReason The basis for an original classification decision


This element is used only in conjunction with the classifiedBy element.

classifiedBy The identity, by name or personal identifier, and position title of the original classification authority for a resource


This element is used only when the value for the classification element is not unclassified and the derivedFrom element is not used.


74

dateOfExemptedSource A specific year, month, and day of publication or release of a source document, or the most recent source document, that was itself marked with a declassification constraint.

O 1 Date /YYYY-MM-DD Deprecated. Not valid in ISM Version 7

declassDate A specific year, month, and day upon which the information shall be automatically declassified if not properly exempted from automatic declassification

O 1 Date /YYYY-MM-DD

declassEvent A description of an event upon which the information shall be automatically declassified if not properly exempted from automatic declassification.


declassException A single indicator describing an exemption to the nominal 25-year point for automatic declassification.

O 1 CharacterString / FreeText (Code)

This element is used in conjunction with the Declassification Date or Declassification Event

derivativelyClassifiedBy The identity, by name or personal identifier, of the derivative classification authority


This element is used in conjunction with the derivedFrom element.

derivedFrom A citation of the authoritative source or reference to multiple sources of the classification markings used in a classified resource


This element is used only when the value for the classification element is not unclassified and the classifiedBy element is not used.

compilationReason The reason that a portion or resource is marked with a higher and/or more restrictive mark than its components would indicate. For example this would document why 3 Unclassified bullet items form a Secret List. Without this reason being noted the above-described document would be considered to be mismarked and over-classified.



75

displayOnlyTo One or more indicators identifying the country or countries and/or international organization(s) to which classified information may be displayed based on the determination of an originator in accordance with established foreign disclosure procedures. This element is used in conjunction with the Dissemination Controls element.


Country and organization names

disseminationControls One or more indicators identifying the expansion or limitation on the distribution of information

O N Character String / Free Text

This element is used only when the value for the classification element is not unclassified

fgiSourceOpen One or more indicators identifying information which qualifies as foreign government information for which the source(s) of the information is not concealed

O N CharacterString / FreeText (Code)

fgiSourceProtected A single indicator that information qualifies as foreign government information for which the source(s) of the information must be concealed

O 1 CharacterString / FreeText (Code)

Within protected internal organizational spaces this element may be used to maintain a record of the one or more indicators identifying information which qualifies as foreign government information for which the source(s) of the information must be concealed. Measures must be taken prior to dissemination of the information to conceal the source(s) of the foreign government information

nonICMarkings One or more indicators of the expansion or limitation on the distribution of an information resource or portion within the domain of information originating from non-intelligence components



nonUSControls One or more indicators of the expansion or limitation on the distribution of an information resource or portion within the domain of information originating from non-US components. Currently just includes a few NATO marks.



76

ownerProducer One or more indicators identifying the national government or international organization that have purview over the classification marking of an information resource or portion therein.

M 1 CharacterString / Free Text

This element is always used in conjunction with the Classification element. Taken together, the two elements specify the classification category and the type of classification (US, non-US, or Joint).

Within protected internal organizational spaces this element may include one or more indicators identifying information, which qualifies as foreign government information, for which the source(s) of the information must be concealed. Measures must be taken prior to dissemination of the information to conceal the source(s) of the foreign government information.

releasableTo One or more indicators identifying the country or countries and/or international organization(s) to which classified information may be released based on the determination of an originator in accordance with established foreign disclosure procedures.

C N Class / CountryCode <<CodeList>> (7.2.2.2)

See Table 3 (CountryCode)

This element is used in conjunction with the disseminationControls element.

sarIdentifier One or more indicators identifying the defense or intelligence programs for which special access is required



sciControls One or more indicators identifying sensitive compartmented information control system(s).



Table 23 : ISM Security Attributes Group

7.4.3.3.2 Need to Know

Information sharing within the U.S. national intelligence enterprise frequently relies on being able to determine an individual’s need-to-know as one component in determining whether to allow access to data. This need to know metadata are used to represent the system-specific properties assigned to an information resource that will be used, in conjunction with information about the user, and possibly other information, to determine the user’s access to the data.

The data dictionary table presented in this section is not found in ISO 19115:2003/Cor 1:2006. This metadata represents the Need to Know metadata defined in NTK.XML version 5 and is specific to NSG implementations.


77


Max

Occur

Data type Domain

Business Rule

NTK_Access A statement or description of a group of people who should be granted access to an information resource.


from referencing

object


from referencing

object

Class

individual A statement, as defined by an access system, of a mechanism that identifies an individual who has access to the resource.

O N Class / MD_Identifier <<DataType>> (7.4.8.2)

group A statement, as defined by an access system, of a group that should refer ultimately to one or more individuals.


profile A statement of the traits that an access system will use in determining if a particular individual making a request for access to an information resource is granted access.


Table 24 : Need To Know

7.4.3.3.3 Notices

In some cases restrictions on the distribution and use of a resource cannot be adequately captured in the CAPCO markings. Notices provide that additional security related information in a textual format. Most notices are standardized through registration in the CAPCO register. Registered notices can be identified by their notice type. Use of the notice type avoids the need to distribute the full text of the notice.

The data dictionary table presented in this section is not found in ISO 19115:2003/Cor 1:2006. This metadata represents the Notices metadata defined in ISM.XML version 7 and is specific to NSG implementations.


Max

Occur

Data type Domain

Business Rule

ISM_Notices Information concerning “well-defined” security notices including those defined in the CAPCO register and the ISM.XML standard.


from referencing

object

Use maximum

occurrence from

referencing object

Class

noticeText The actual text of a notice M N CharacterString / Free Text

noticeType Specifies which category of notice is included in this entity.

O 1 Class / NoticeTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (NoticeTypeCode)

noticeDate Specifies the date the notice was issued

O 1 Class / Date (Annex B)

noticeReason Specifies the reason the notice was issued

O 1 CharacterString / Free Text


78

unregisteredNoticeType Used to represent notices that are not registered in the CAPCO register and are not defined in the ISM.


Table 25 : ISM Notices

7.4.4 Data Quality

The DQ_DataQuality class is the root of the SDSFIE-M Quality metadata. This class defines the scope of the quality assessment and aggregates the history (LI_Lineage) and quality measurements (DQ_Element) for the referenced resource.

7.4.4.1 Data Quality UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Data Quality Package UML diagram found in 19115:2003/Cor 1:2006 (Figure A.4) and NMF Part 2 (7.4.1.1, Figure 1). No profiling of this diagram was needed to address I&E Community requirements.

This diagram defines the metadata required to give a general assessment of the quality of a resource.

Figure 8 : Data Quality

7.4.4.2 Data Quality

The data dictionary table presented in this section is the same corresponding Data Quality data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.1). No


79

profiling was required to address I&E community requirements. Additional text to clarify business rules has been added to assist users in the use of these elements.


Max

Occur

Data type Domain

Business Rule

DQ_DataQuality quality information for the data specified by a data quality scope


referencing object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata)

scope the specific data to which the data quality information applies

M 1 Class / DQ_Scope <<DataType>> (7.4.4.3)

"report" or "lineage" role is mandatory if scope. DQ_Scope. level = 'dataset' or ‘series’

role name: report quantitative quality information for the data specified by the scope

C / “lineage” not provided

and (DQ_DataQuality.

scope. DQ_Scope.level =

“dataset” or “series”)?

N Association / DQ_CompletenessCommission and/or DQ_CompletenessOmission and/or DQ_ConceptualConsistency and/or DQ_DomainConsistency and/or DQ_FormatConsistency and/or DQ_TopologicalConsistency and/or DQ_AbsoluteExternalPositionalAccuracy and/or DQ_GriddedDataPositionalAccuracy and/or DQ_RelativeInternalPositionalAccuracy and/or DQ_ThematicClassificationCorrectness and/or DQ_NonQuantitativeAttributeAccuracy and/or DQ_QuantitativeAttributeAccuracy and/or DQ_AccuracyOfATimeMeasurement and/or DQ_TemporalValidity and/or DQ_TemporalConsistency (7.4.4.5.2)

role name: lineage non-quantitative quality information about the lineage of the data specified by the scope

C / “report” not provided

and (DQ_DataQuality.

scope. DQ_Scope.level =

“dataset” or “series”)?

1 Association / LI_Lineage (B 2.4.1)

Table 26 : Data Quality


80

7.4.4.3 Scope

DQ_Scope specifies the extent of the resources that are described by the reported quality metadata. Extent can be described in terms of spatial, temporal, hierarchy level and resource type properties.

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Scope data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.5). The table has been profiled, as follows:

The levelDescription attribute has been restricted from a Union of references (MD_ScopeDescription) to a code list.


Max

Occur

Data type Domain

Business Rule

DQ_Scope extent of characteristic(s) of the data for which quality information is reported



Class <<DataType>>

level hierarchical level of the data specified by the scope

M 1 Class / ScopeCode <<CodeList>> (7.2.2.2)

See Table 3 (ScopeCode)

See Table 3 (NMF_ScopeCode)

extent information about the horizontal, vertical and temporal extent of the data specified by the scope

O 1 Class / EX_Extent <<DataType>> (7.4.12.2)

levelDescription detailed description about the level of the data specified by the scope

M 1 Class / ScopeAmplificationCode <<CodeList>> (7.2.2.2)

See Table 3 (ScopeAmplificationCode)

See Table 3 (NMF_ScopeAmplificationCode )

Note: this element is optional in 19115, and the domain class has been constrained to a code list

Table 27 : Data Quality Scope

7.4.4.4 Lineage

When assessing the quality of a data resource, it is important to know how that resource was created; what source material was used, and what processing was applied to that source. Lineage metadata entities provide that information.

Lineage is described in terms of Sources and Process Steps. Sources and Process Steps, in turn are associated with each other. This structure allows discovery of the lineage of a resource from both the processing and source perspective. Examples of how this structure can be used are provided in Table 28.

User Question Class Path

What sources were used to create this resource? LI_LineageLI_Source


81

What processing was applied to those sources to create this resource?

LI_LineageLI_SourceLI_ProcessStep

Were all of the required process steps executed in the production of this resource?

LI_LineageLI_ProcessStep

Was appropriate source used in each process step?

LI_LineageLI_ProcessStepLI_Source

Is the lineage metadata complete? LI_LineageLI_ProcessStepLI_Source == LI_Lineage-LI_Source and LI_LineageLI_SourceLI_ProcessStep == LI_LineageLI_ProcessStep

Table 28 : Using LI_Lineage

The examples above reflect a rather simple lineage, where sources are processed directly (or at least without persistent intermediate products) into a product. That model is supported by the LI_Lineage entity. The LE_Lineage model extends LI_Lineage to address more complex cases. In these cases, sources may go through several stages of processing before being used on the final product. Capturing this lineage requires more robust metadata, including details about intermediate sources (process step outputs), processing parameters and algorithms.

In short; LI_Lineage provides a flat lineage model, typical of cartographic production and LE_Lineage provides a deep lineage model, typical of image processing workflows. LI_Lineage and LE_Lineage are profiled from ISO 19115 and 19115-2 respectively.

7.4.4.4.1 LI_Lineage

LI_Lineage is the base lineage class defined in ISO 19115. It associates the sources used to produce a data resource with the process steps performed on those sources. This model assumes a compilation environment typical of cartographic production. Under this model a number of sources are compiled into the final product (the data resource). Each source may be processed in some manner prior to being applied to the product. Any intermediate data created by this processing was discarded. As such, output from that processing is considered the data resource itself.

7.4.4.4.1.1 LI_Lineage UML

This UML diagram is based on the Lineage Package UML diagram (Figure A.5) found in ISO 19115:2003/Cor 1:2006. The diagram has not been profiled for SDSFIE-M.


82

Figure 9 : LI_Lineage Metadata

7.4.4.4.1.2 LI_Lineage Data Dictionary

LI_Lineage provides information on the sources and processing that was performed to create the described resource.

The data dictionary in table 31is based on the corresponding data dictionary found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.2.1). No profiling of this table was required to address I&E community requirements.

LI_Lineage is included in SDSFIE-M from NMF Part 1 and is extended by NMF Part 2 as follows:

The “source” association has been restored from ISO 19115

The “processStep” association has been restored from ISO 19115


Max

Occur

Data type Domain

Business Rule

LI_Lineage information about the events or source data used in constructing the data specified by the scope or lack of knowledge about lineage


referencing object

Use maximum

occurrence from

referencing object

Aggregated Class (DQ_DataQuality)


83

statement general explanation of the data producer’s knowledge about the lineage of a dataset

C / If(count(source)

+ count(processSt

ep) =0) and

(DQ_DataQuality.scope.level =

'dataset' or 'series') then statement is mandatory

1 CharacterString / Free text

The “statement” element of LI_Lineage is mandatory if DQ_DataQuality.scope. DQ_Scope.level has a value of “dataset” or “series” and the LI_Lineage roles of “source” and “processStep” are not documented.

role name: processStep information about events in the life of a dataset specified by the scope

C / mandatory if LI_Lineage.state

ment and "source" role are not documented

N Association / LI_ProcessStep (7.4.4.4.1.3)

The “processStep” role of LI_Lineage is mandatory if the

“statement” element and the “source” role of LI_Lineage are not documented.

role name: source information about the source data used in creating the data specified by the scope

C / mandatory if LI_Lineage.state

ment and "processStep"

role are not documented

N Association / LI_Source (7.4.4.4.1.4)

The “source” role of LI_Lineage is mandatory if the “statement” element and the “processStep” role of LI_Lineage

Table 29 : LI_Lineage

7.4.4.4.1.3 LI_ProcessStep Data Dictionary

LI_ProcessStep describes an instance of the processing that was performed on a source or sources to create the described resource. Sources and process steps that worked together are linked by the metadata to provide a history of how the resource was created.

The data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.2.2). No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

LI_ProcessStep information about an event or transformation in the life of a dataset including the process used to maintain the dataset


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LI_Lineage and LI_Source)

description description of the event, including related parameters or tolerances


rationale requirement or purpose for the process step


dateTime date and time or range of date and time on or over which the process step occurred

O 1 Class / DateTime (Annex B)

processor

identification of, and means of communication with, person(s) and organization(s) associated with the process step

O N

Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)


84


O N Association / LI_Source (7.4.4.4.1.4)

Table 30 : LI_ProcessStep

7.4.4.4.1.4 LI_Source Data Dictionary

LI_Source describes a source that was used to create the described resource. Sources and process steps that worked together are linked by the metadata to provide a history of how the resource was created.

The data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.2.3). No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

LI_Source information about the source data used in creating the data specified by the scope


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LI_Lineage and LI_ProcessStep)

description detailed description of the level of the source data

C / sourceExtent

not provided?

1 CharacterString / Free Text

Either the “description” or “sourceExtent” element of LI_Source must be documented.

scaleDenominator denominator of the representative fraction on a source map

O 1 Class / MD_RepresentativeFraction <<DataType>> (7.4.2.6)

sourceReferenceSystem spatial reference system used by the source data

O 1 Class / MD_ReferenceSystem (7.4.7.2)

sourceCitation recommended reference to be used for the source data

O 1 Class / CI_Citation <<DataType>> (7.4.13.2)

sourceExtent information about the spatial, vertical and temporal extent of the source data

C / description

not provided?



role name: sourceStep information about an event in the creation process for the source data

O N Association / LI_ProcessStep (7.4.4.1.3)

Table 31 : LI_Source

7.4.4.4.2 LE_Lineage

The lineage entities defined in Section 7.4.4.4.1 model a history which is wide but shallow. Many data resources, however, are the result of a long chain of processing applied to a small number of raw sources. ISO 19115-2 addresses this case by extending the lineage entities defined in ISO 19115. A key change is the addition of an “output” association to the process step class. Distinguishing between input (source)


85

and output data allows process steps to be assembled into long processing chains. These chains describe the original source, every processing step applied and all intermediate products. Since these process chains are by necessity automated, this model expands the process step class to describe the automated resources used and to capture reports on the work done at each process step.

7.4.4.4.2.1 LE_Lineage UML

Figure 10 defines the extended metadata classes required to specify the lineage of imagery and gridded data. This diagram is based on Figure A.3 in ISO 19115-2:2009. No profiling of this diagram was required to address I&E community requirements.


86

Figure 10 : LE_Lineage Metadata


87

7.4.4.4.2.2 LE_Source Data Dictionary

The LE_Source data dictionary table presented in this section is an extension of the LI_Source dictionary found in Table 31 of this document. The extensions are described in ISO 19115-2:2009 section B.2.2.7.

This data dictionary includes additional SDSFIE-M -specific profiling of the parent LI_Source class:

Obligation of “scaleDemoninator” element has been changed to conditional.


Max

Occur

Data type Domain

Business Rule

LE_Source information on data sets input to or output by the processing step (LI_Source extended)


referencing object

Use maximum

occurrence from

referencing object

SpecifiedClass (LI_Source)

Inherited from LI_Source

description detailed description of the level of the source data

C / sourceExtent not provided?

1 CharacterString / Free Text


scaleDenominator denominator of the representative fraction on a source map

C / if LE_Source. resolution.

scanningResolution is specified, then

LE_Source. scaleDenominator

(inherited from LI_Source) is

required.

1 Class / MD_RepresentativeFraction <<DataType>> (7.4.2.6)

sourceReferenceSystem spatial reference system used by the source data

O 1 Class / MD_ReferenceSystem (7.4.7.2)

sourceCitation recommended reference to be used for the source data


sourceExtent information about the spatial, vertical and temporal extent of the source data

C / description not provided?



role name: sourceStep information about an event in the creation process for the source data

O N Association / LI_ProcessStep (7.4.4.1.3)

LE_Source-specific attributes

processedLevel processing level of the source data

O 1 Class / MD_Identifier <<DataType>> (7.4.8.2)


88

resolution distance between consistent parts (centre, left side, right side) of two adjacent pixels

O 1 Class / LE_NominalResolution <<Union>> (7.4.4.2.3)

Table 32 : LE_Source

7.4.4.4.2.3 LE_NominalResolution Data Dictionary

LE_NominalResolution provides a means to capture the resolution of an image. Since resolution can be in terms of ground resolution or scanning resolution, this class serves to combine those two mutually exclusive measures into a single element.

The LE_NominalResolution data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115-2:2009 section B.2.2.3. No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

LE_NominalResolution distance between consistent parts of (centre, left side, right side) adjacent pixels


from referencing

object

Use maximum

occurrence from

referencing object


scanningResolution distance between consistent parts of (centre, left side, right side) adjacent pixels in the scan plane

M 1 Class / <<Type>> Distance

Defined in ISO 19103

groundResolution distance between consistent parts of (centre, left side, right side) adjacent pixels in the object space

M 1 Class / <<Type>> Distance

Defined in ISO 19103

Table 33 : LE_ NominalResolution

7.4.4.4.2.4 LE_ProcessStep Data Dictionary

The LE_ProcessStep data dictionary table presented in this section is an extension of the LI_ProcessStep dictionary found in Table 30 of this document. The extensions are described in ISO 19115-2:2009 section B.2.2.5.


Max

Occur

Data type Domain

Business Rule

LE_ProcessStep

information about an event or transformation in the life of the dataset including details of the algorithm and software used for processing (LI_ProcessStep extended)


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LI_Lineage)

Inherited from LI_ProcessStep

description description of the event, including related parameters or tolerances


rationale requirement or purpose for the process step



89

dateTime date and time or range of date and time on or over which the process step occurred

O 1 Class / DateTime (Annex B)

processor

identification of, and means of communication with, person(s) and organization(s) associated with the process step

O N

Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)


O N Association / LI_Source (7.4.4.4.1.4)

LE_ProcessStep-specific attributes

role name: output description of the product generated as a result of the process step

O N Association / LE_Source (7.4.4.4.2.2)

role name: processingInformation

comprehensive information about the procedure by which the algorithm was applied to derive geographic data from the raw instrument measurements, such as datasets, software used, and the processing environment

O 1 Association / LE_Processing (7.4.4.4.2.6)

role name: report report generated by the process step

O N Association / LE_ProcessStepReport (7.4.4.4.2.5)

Table 34 : LE_ ProcessStep

7.4.4.4.2.5 Image Process Step Report

Processing systems often generate a report on what was done, issues encountered and the level of quality achieved. LE_ProcessStepReport provides a way to capture that report for latter reference.

The LE_ProcessStepReport data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115-2:2009 section B.2.2.6. No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

LE_ProcessStepReport report of what occurred during the process step


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LE_ProcessStep)

name name of the processing report M 1 Character String / Free Text

description textual description of what occurred during the process step


fileType type of file that contains the processing report


Table 35 : LE_ ProcessStepReport

7.4.4.4.2.6 LE_Processing


90

LE_Processing provides information about how an output product was derived from source data. This entity is useful to describe automated processing where established algorithms, software and procedures are used.

The LE_Processing data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115-2:2009 section B.2.2.4. No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

LE_Processing comprehensive information about the procedure(s), process(es) and algorithm(s) applied in the process step


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LE_ProcessStep)

identifier information to identify the processing package that produced the data

M 1 Class / MD_Identifier <<DataType>> (7.4.8.2)

softwareReference reference to document describing processing software


procedureDescription additional details about the processing procedures


documentation reference to documentation describing the processing


runTimeParameters parameters to control the processing operations, entered at run time


role name: algorithm details of the methodology by which geographic information was derived from the instrument readings

O N Association / LE_Algorithm (7.4.4.4.2.7)

Table 36 : LE_Processing

7.4.4.4.2.7 LE_Algorithm

LE_Algorithm describes an algorithm used for automated processing of source data.

The LE_Algorithm data dictionary presented in this table is based on the corresponding data dictionary found in ISO 19115-2:2009 section B.2.2.2.1. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

LE_Algorithm

details of the methodology by which geographic information was derived from the instrument readings


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (LE_Processing)


91

citation information identifying the algorithm and version or date

M 1

Class / CI_Citation <<DataType>> (7.4.13.2)

description information describing the algorithm used to generate the data


Table 37 : LE_Algorithm

7.4.4.5 Quality Element

DQ_Element is the root class for all quantifiable measures of quality. When a quality measurement is performed, this class captures the quality measurement technique used and the resulting measurement values. ISO 19115 and 19115-2 define the semantics of this information by subclassing the DQ_Element class. In effect, the inheritance tree from DQ_Element forms a taxonomy of quality measurement types.

A register of quality measurement techniques has been established on the NSG Standards Registry to help capture this information in a standard repeatable form. Detailed descriptions of a measurement technique can be retrieved from the register using the “measureIdentification” element of DQ_Element.

7.4.4.5.1 Quality Element UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Data Quality Classes and Subclasses UML diagram (Figure A.6) found in ISO 19115:2003/Cor 1:2006. The diagram has been extended to include additional classes beyond those defined in ISO 19115. The NMF Part 2 Quality Extension modifies the ISO 19115 of DQ_Element as follows:

Added QE_Usability subclass from ISO 19115-2. This entity provides an expression of how suitable this resource would be for its’ intended use.

Added the NMF_QualityMeasure subclass. This subclass extends the quality measure taxonomy to include measures related to coordinate transformations, statistical measures and signal quality.


92

Figure 11 : Quality Element Context

7.4.4.5.2 Quality Element Data Dictionary

DQ_Element is the root class for all measurements of quantifiable quality. When a quality measurement is performed, this class identifies the quality measurement process used and the resulting measurement values. ISO 19115 and 19115-2 have constructed a taxonomy of quality measurement types by subclassing DQ_Element. Since it is unlikely that this taxonomy will support all possible quality measures, the NMF_QualityMeasure sub-class has been added to provide an alternate to the taxonomy.


93

The data dictionary presented in this table includes SDSFIE-M-specific extensions to the Quality Element Data Dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.2.4.3). Modifications to the DQ_Element class in ISO 19115 are:

Added QE_Usability subclass from ISO 19115-2. This entity provides an expression of how suitable this resource would be for its’ intended use.

Added the NMF_QualityMeasure subclass. This subclass extends the quality measure taxonomy to include measurements related to coordinate transformations, statistical measures and signal quality.

Added business logic identifying the “measureIdentification” element of DQ_Element as being the preferred way to reference the quality measurement technique used.

DQ_Element provides six elements that describe the measurement and how it was performed. A register of quality measurement techniques has been established on the NSG Standards Registry to capture this information in a standard repeatable form. Implementations of the NMF Part 2 shall reference the appropriate register entry for a measurement technique using the measureIdentification element. Use of the other five elements should be avoided except as allowed under the business rules.


Max

Occur

Data type Domain

Business Rule

DQ_Element aspect of quantitative quality information


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (DQ_DataQuality) <<Abstract>>

nameOfMeasure name of the test applied to the data


Use should be avoided

measureIdentification code identifying a registered standard procedure


I&E community preferred method to identify the measure

measureDescription description of the measure



evaluationMethodType type of method used to evaluate quality of the dataset

O 1 Class / EvaluationMethodTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (EvaluationMethodTypeCode)



94


Max

Occur

Data type Domain

Business Rule

evaluationMethodDescription description of the evaluation method


Shall only be used to convey essential information not supplied by measureIdentification or evaluationProcedure

evaluationProcedure reference to the procedure information


Shall only be used when there are alternative procedures for calculating a measure

dateTime date or range of dates on which a data quality measure was applied

O N Class / DateTime (Annex B)

result value (or set of values) obtained from applying a data quality measure or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level

M 2 Class / DQ_Result <<Abstract>> (7.4.4.5.3)

No more than one instance of each DQ_Result subclass shall be provided

Generalization of DQ_Element for completeness with no additional attributes or operations

DQ_Completeness presence and absence of features, their attributes and their relationships


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_Element) <<Abstract>>

Generalization: DQ_CompletenessCommission

excess data present in the dataset, as described by the scope


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_Completeness)

Generalization: DQ_CompletenessOmission

data absent from the dataset, as described by the scope


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_Completeness)

Generalization of DQ_Element for consistency with no additional attributes or operations


95


Max

Occur

Data type Domain

Business Rule

DQ_LogicalConsistency degree of adherence to logical rules of data structure, attribution and relationships (data structure can be conceptual, logical or physical)


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_ConceptualConsistency

adherence to rules of the conceptual schema


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_LogicalConsistency)

Generalization: DQ_DomainConsistency

adherence of values to the value domains


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_FormatConsistency

degree to which data is stored in accordance with the physical structure of the dataset, as described by the scope


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_TopologicalConsistency

correctness of the explicitly encoded topological characteristics of the dataset as described by the scope


from referencing

object

Use maximum

occurrence from

referencing object


Generalization of DQ_Element positional quality with no additional attributes or operations

DQ_PositionalAccuracy accuracy of the position of features


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_AbsoluteExternalPositionalAccuracy

closeness of reported coordinate values to values accepted as or being true


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_PositionalAccuracy)

Generalization: DQ_GriddedDataPositionalAccuracy

closeness of gridded data position values to values accepted as or being true


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_RelativeInternalPositionalAccuracy

closeness of the relative positions of features in the scope to their respective relative positions accepted as or being true


from referencing

object

Use maximum

occurrence from

referencing object


Generalization of DQ_Element for temporal quality with no additional attributes or operations


96


Max

Occur

Data type Domain

Business Rule

DQ_TemporalAccuracy accuracy of the temporal attributes and temporal relationships of features


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_AccuracyOfATimeMeasurement

correctness of the temporal references of an item (reporting of error in time measurement)


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_TemporalAccuracy)

Generalization: DQ_TemporalConsistency

correctness of ordered events or sequences, if reported


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_TemporalValidity

validity of data specified by the scope with respect to time


from referencing

object

Use maximum

occurrence from

referencing object


Generalization of DQ_Element thematic quality with no additional attributes or operations

DQ_ThematicAccuracy accuracy of quantitative attributes and the correctness of non-quantitative attributes and of the classifications of features and their relationships


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_ThematicClassificationCorrectness

comparison of the classes assigned to features or their attributes to a universe of discourse


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_ThematicAccuracy)

Generalization: DQ_NonQuantitativeAttributeAccuracy

accuracy of non-quantitative attributes


from referencing

object

Use maximum

occurrence from

referencing object


Generalization: DQ_QuantitativeAttributeAccuracy

accuracy of quantitative attributes


from referencing

object

Use maximum

occurrence from

referencing object


Generalization of DQ_Element for usability with no additional attributes or operations

QE_Usability degree of adherence of a dataset to a specific set of user requirements (DQ_Element extended)


from referencing

object

Use maximum

occurrence from

referencing object

Specified class (DQ_Element)

From 19115-2


97


Max

Occur

Data type Domain

Business Rule

Generalization of DQ_Element for unclassified measures with one additional attribute to address the case of multi-part results

NMF_QualityMeasure Quality measures that do not fall under the other categories including coordinate transformations, statistics and signal quality.


from referencing

object

Use maximum

occurrence from

referencing object

Specialized Class (DQ_Element)

role name: derivedElement In the case of aggregation or derivation, indicates the original element

O N Association / DQ_Element

Table 38 : DQ_Element

7.4.4.5.3 DQ_Result

Figure 12 defines the metadata classes required to capture the value (or set of values) obtained from applying a quality measure technique. This diagram is based on Figure A.4 in ISO 19115:2003/Cor 1:2006. This diagram has not been profiled to address I&E community requirements.

Figure 12 : Data Quality Result

7.4.4.5.4 DQ_Result Data Dictionary

DQ_Result is used by DQ_Element to capture the value (or set of values) obtained from applying a quality measure technique or the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level.

The data dictionary table presented in this section is based on the corresponding Quality Result data dictionary table (Section B.2.4.4) found in ISO 19115:2003/Cor 1:2006. Modifications to the DQ_Element class in ISO 19115 are:

Added business logic discouraging use of the errorStatistic element.


98


Max

Occur

Data type Domain

Business Rule

DQ_Result generalization of more specific result classes


from referencing

object

Use maximum

occurrence from

referencing object

Class <<Abstract>>

DQ_ConformanceResult Information about the outcome of evaluating the obtained value (or set of values) against a specified acceptable conformance quality level


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_Result)

specification citation of product specification or user requirement against which data is being evaluated


explanation explanation of the meaning of conformance for this result


pass indication of the conformance result where 0 = fail and 1 = pass

M 1 Boolean / 1 = yes, 0 = no

DQ_QuantitativeResult the values or information about the value(s) (or set of values) obtained from applying a data quality measure


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (DQ_Result)

valueType value type for reporting a data quality result

O 1 Class / RecordType <<Metaclass>> (Annex B)

valueUnit value unit for reporting a data quality result

M 1 Class / UnitOfMeasure (Annex B)

Defined in ISO/TS 19103:2005

value quantitative value or values, content determined by the evaluation procedure used

M N Class / Record (Annex B)

Table 39 : DQ_Result

7.4.4.5.5 Extension to data quality result to support coverage quality

Figure 13 defines an extension required to specify the reported quality for coverage data. The additional elements provide information about the representation of the quality result documenting the data in the dataset.


99

Figure 13 : Data quality result with coverage quality extension

The specification of QE_CoverageResult is simply based on existing concepts from ISO 19115 and ISO/TS 19139:

the coverage result has a spatial representation which, in some cases, can be exactly the same as the resource spatial representation or may differ (e.g., coverage result computed on a vector database or coverage result using a sample of the resource). The construct used to describe the spatial representation of the coverage result is the MD_SpatialRepresentation class. The resultSpatialRepresentation property is mandatory but can be implemented as a reference to the instance of MD_SpatialRepresentation related to the resource.

the coverage result has a content description. The construct used to describe the content of the result coverage is MD_CoverageDescription. The resulting coverage will often be defined by the distribution of a single attribute over the result coverage domain, but it is anticipated that the range type of the result coverage can comprise many attributes.

the coverage result has a format which is expressed through the MD_Format class.

the coverage result is associated to a data file containing the coverage result data. The construct used to describe the result coverage data file is MX_DataFile (from ISO/TS 19139).


100

The data dictionary presented in this table includes SDSFIE-M -specific extensions to the QE_CoverageResult Data Dictionary table found in ISO 19115-2:2009 (Section B.2.2.1). No profiling of this table was required to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

QE_CoverageResult

result of a data quality measure organising the measured values as a coverage (DQ_Result extended)


from referencing

object

Use maximum

occurrence from

referencing object

Specified class (DQ_Result)

spatialRepresentationType

method used to spatially represent the coverage result M 1

Class / SpatialRepresentationTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (SpatialRepresentationTypeCode)

Role name: resultSpatialRepresentation

provides the digital representation of data quality measures composing the coverage result

M 1 Association / MD_SpatialRepresentation <<Abstract>> (7.4.6.2)

Role name: resultContentDescription

provides the description of the content of the result coverage, i.e. semantic definition of the data quality measures

M 1 Association / MD_CoverageDescription (7.4.9.2)

Role name: resultFormat

provides information about the format of the result coverage data

M 1 Association / MD_Format (7.4.2.4)

Role name: resultFile

provides information about the data file containing the result coverage data

M 1 Association / MX_DataFile (7.4.4.5.6)

7.4.4.5.6 Transfer files

Figure 14 describes the support and data files concept and is based on the corresponding figure from ISO/TS 19139:2005 (Figure 9). The data files are potentially related to one or many feature types. Each data file has its own format which is generally described within the metadata of the dataset.


101

Figure 14 : Transfer Files

The MX_File data dictionary presented in this table is based on the corresponding data dictionary found in ISO/TS 19139:2005 section B.2.3.3. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MX_File Description of a transfer file Use obligation/ condition

from referencing

object

Use maximum

occurrence from

referencing object

Class

<<Abstract>>

fileName Name of the transfer data file. This name is associated with a path to the physical file

M 1 FileName (Annex B)

fileDescription General description of the transfer data file


fileType Type of the transfer data file. The textual description of the file type is associated with an indication of the MIME Type.

M 1 MimeFileType (Annex B)

MX_DataFile Description of a transfer data file Use obligation/ condition

from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MX_File)


102

featureType Provides the list of Feature Types concerned by the transfer data file. Depending on the transfer choices, a data file may contain data related to one or many feature types. This attribute may be omitted when the dataset is composed of a single file and/or the data does not relate to a feature catalogue

O N GenericName (Annex B)

Role name: fileFormat Defines the format of the transfer data file

M 1 Class / MD_Format (7.4.2.4)

MX_SupportFile Description of a transfer support file Use obligation/ condition

from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MX_File)

Table 40 : MX_File, MX_DataFile, and MX_SupportFile

7.4.5 Maintenance Information

Maintenance information is used to describe the maintenance and update practices (scope and frequency) for the documented resource.

7.4.5.1 Maintenance Information UML

Figure 15 is based on the corresponding Maintenance Information Package UML diagram (Figure A.7) found in 19115:2003/Cor 1:2006. No profiling of this diagram was required to address I&E requirements.


103

Figure 15 : Maintenance Information

7.4.5.2 Maintenance Information

The data dictionary table presented in this section is based on the corresponding Maintenance Information data dictionary table (Section B.2.5.1) found in ISO 19115:2003/Cor 1:2006. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MD_MaintenanceInformation information about the scope and frequency of updating


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_Metadata and MD_Identification)


104

maintenanceAndUpdateFrequency frequency with which changes and additions are made to the resource after the initial resource is completed

M 1 Class / MaintenanceFrequencyCode <<CodeList>> (7.2.2.2)

See Table 3 (MaintenanceFrequencyCode)

dateOfNextUpdate scheduled revision date for resource

O 1 Class / Date (Annex B)

userDefinedMaintenanceFrequency maintenance period other than those defined

O 1 Class / TM_PeriodDuration (Annex B)

updateScope scope of data to which maintenance is applied

O N Class / NMF_ScopeCode <<CodeList>> (7.2.2.2)

updateScopeDescription additional information about the range or extent of the resource

O N Class / MD_ScopeDescription <<Union>> (7.4.5.3)

maintenanceNote information regarding specific requirements for maintaining the resource


Contact identification of, and means of communicating with, person(s) and organization(s) with responsibility for maintaining the metadata

O N Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)

Table 41 : Maintenance Information

7.4.5.3 Scope Description

The data dictionary table presented in this section is based on the corresponding Scope Description data dictionary table (Section B.2.5.2) found in ISO 19115:2003/Cor 1:2006. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MD_ScopeDescription description of the class of information covered by the information


referencing object

Use maximum occurrence from

referencing object


attributes instances of attribute types to which the information applies

C / features, featureInstances, attributeInstances, dataset and other not documented?

1 Set (B.4.7) / GF_AttributeType (Annex B)

features instances of feature types to which the information applies

C / attributes, featureInstances, attributeInstances, dataset and other not documented?

1 Set (B.4.7) / GF_FeatureType (Annex B)

featureInstances feature instances to which the information applies

C / attributes, features,

attributeInstances, dataset and other not documented?

1 Set (B.4.7) / GF_FeatureType (Annex B)


105

attributeInstances attribute instances to which the information applies


featureInstances, dataset and other not documented?

1 Set (B.4.7) / GF_AttributeType (Annex B)

dataset dataset to which the information applies


featureInstances, attributeInstances,

and other not documented?


other class of information that does not fall into the other categories to which the information applies


featureInstances, attributeInstances,

and dataset not documented?


Table 42 : Scope Description

7.4.6 Spatial Representation Information

The MD_SpatialRepresentation entity captures information about the mechanisms used to represent spatial information in a data set.

7.4.6.1 Spatial Representation UML

The data dictionary table presented in this section is based on the corresponding Scope Description data dictionary table (Section B.2.5.2) found in ISO 19115:2003/Cor 1:2006 and ISO 19115-2:2009. No profiling of this diagram was required to address I&E requirements.


106

Figure 16 : Spatial Representation

Figure 17 depicts extensions made by ISO 19115-2:2009 for imagery.


107

Figure 17 : Spatial representation extension for imagery

7.4.6.2 Spatial Representation Information

The data dictionary table presented in this section is based on the corresponding Spatial Representation Information data dictionary table (Section B.2.6.1) found in ISO 19115:2003/Cor 1:2006. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule


108

MD_SpatialRepresentation digital mechanism used to represent spatial information


from referencing

object

Use maximum

occurrence from

referencing object


MD_GridSpatial Representation

information about grid spatial objects in the dataset


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_SpatialRepresentation)

numberOfDimensions number of independent spatial-temporal axes

M 1 Integer

axisDimensionsProperties information about spatial-temporal axis properties

M 1 Sequence (Annex B) / MD_Dimension <<DataType>> (7.4.6.3)

cellGeometry identification of grid data as point or cell

M 1 Class / CellGeometryCode <<CodeList>> (7.2.2.2)

See Table 3 (CellGeometryCode)

transformationParameter Availability

indication of whether or not parameters for transformation between image coordinates and geographic or map coordinates exist (are available)


MD_Georectified grid whose cells are regularly spaced in a geographic (i.e., lat / long) or map coordinate system defined in the Spatial Referencing System (SRS) so that any cell in the grid can be geolocated given its grid coordinate and the grid origin, cell spacing, and orientation


from referencing

object

Use maximum

occurrence from

referencing object

Specified (MD_GridSpatialRepresentation)

checkPointAvailability indication of whether or not geographic position points are available to test the accuracy of the georeferenced grid data


checkPointDescription description of geographic position points used to test the accuracy of the georeferenced grid data

C / checkpoint Availability

equals “yes”?



109

cornerPoints earth location in the coordinate system defined by the Spatial Reference System and the grid coordinate of the cells at opposite ends of grid coverage along two diagonals in the grid spatial dimensions. There are four corner points in a georectified grid; at least two corner points along one diagonal are required. The first corner point corresponds to the origin of the grid.

M 1 Sequence (Annex B) GM_Point <<Type>> (Annex B)

centerPoint earth location in the coordinate system defined by the Spatial Reference System and the grid coordinate of the cell halfway between opposite ends of the grid in the spatial dimensions

O 1 Class / GM_Point <<Type>> (Annex B)

pointInPixel point in a pixel corresponding to the Earth location of the pixel

M 1 Class / MD_PixelOrientationCode <<Enumeration>> (7.2.3.2)

transformationDimension Description

general description of the transformation


transformationDimension Mapping

information about which grid axes are the spatial (map) axes


MD_Georeferenceable grid with cells irregularly spaced in any given geographic/map projection coordinate system, whose individual cells can be geolocated using geolocation information supplied with the data but cannot be geolocated from the grid properties alone


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_GridSpatialRepresentation)

controlPointAvailability indication of whether or not control point(s) exists


orientationParameter Availability

indication of whether or not orientation parameters are available


orientationParameter Description

description of parameters used to describe sensor orientation


georeferencedParameters terms which support grid data georeferencing

M 1 Class / Record (Annex B)

parameterCitation reference providing description of the parameters


MD_VectorSpatial Representation

information about the vector spatial objects in the dataset


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_SpatialRepresentation)


110

topologyLevel code which identifies the degree of complexity of the spatial relationships

O 1 Class / TopologyLevelCode <<CodeList>> (7.2.2.2)

See Table 3 (TopologyLevelCode)

geometricObjects information about the geometric objects used in the dataset

O N Class / MD_GeometricObjects <<DataType>> (7.4.6.8)

Table 43 : Spatial Representation Information

7.4.6.3 Dimension

The data dictionary table presented in this section is based on the corresponding MD_DImension data dictionary table (Section B.2.6.2) found in ISO 19115:2003/Cor 1:2006. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MD_Dimension axis properties Use obligation/ condition from

referencing object


from referencing

object

Class <<DataType>>

dimensionName name of the axis M 1 Class / DimensionNameTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (DimensionNameTypeCode)

dimensionSize number of elements along the axis

M 1 Integer / Integer

resolution degree of detail in the grid dataset

O 1 Class / Measure (Annex B)

Table 44 : MD_Dimension

7.4.6.4 Georectified - Extensions

The data dictionary table presented in this section is based on the corresponding Georectified - Extensions data dictionary table (Section B.2.3.2) found in ISO 19115-2:2009. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MI_Georectified extends georectified grid description to include associated checkpoints (MD_Georectified extended)


referencing object


referencing object

Specified Class (MD_Georectified)

role name: checkPoint geographic references used to validate georectification of the data

O N Association / MI_GCP (7.4.6.7)

Table 45 : MI_Georectified


111

7.4.6.5 Georeferenceable- Extensions

The data dictionary table presented in this section is based on the corresponding Georeferenceable- Extensions data dictionary table (Section B.2.3.3) found in ISO 19115-2:2009. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MI_Georeferenceable description of information provided in metadata that allows the geographic or map location of the raster points to be located (MD_Georeferencable extended)


referencing object


from referencing

object

Specified Class (MD_Georeferenceable)

role name: geolocationInformation

information that can be used to geolocate the data

M N Association / MI_GeolocationInformation (7.4.6.7)

Table 46 : MI_Georeferenceable

7.4.6.6 Ground Control Point Collection

The data dictionary table presented in this section is based on the corresponding Ground Control Point Collection data dictionary table (Section B.2.3.4) found in ISO 19115-2:2009. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MI_GeolocationInformation information used to determine geographic location corresponding to image location

Use obligation/


object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Georeferenceable)

role name: qualityInfo provides an overall assessment of quality of geolocation information

O * Association / DQ_DataQuality (7.4.4.2)

MI_GCPCollection information on ground control point collections used for geolocation

Use obligation/


object

Use maximum

occurrence from

referencing object

Specified Class (MI_GeolocationInformation)

collectionIdentification identifier of the GCP collection

M 1 Integer / Integer

collectionName name of the GCP collection M 1 CharacterString / Free text

coordinateReferenceSystem coordinate system in which the ground control points are defined

M 1 Class / MD_ReferenceSystem (7.4.7.2)

role name: gcp ground control point(s) used in the collection

M * Association / MI_GCP (7.4.6.7)

Table 47 : MI_GeolocationInformation


112

7.4.6.7 Ground Control Points

The data dictionary table presented in this section is based on the corresponding Ground Control Points data dictionary table (Section B.2.3.5) found in ISO 19115-2:2009. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MI_GCP information on ground control points used for geolocation


referencing object


referencing object

Aggregated Class (MI_GCPCollection)

geographicCoordinates geographic or map position of the control point, in either two or three dimensions

M 1 Class / Direct Position (ISO/TS 19103)

role name: accuracyReport

accuracy of a ground control point

O * Class / DQ_Element (7.4.4.5.2)

Table 48 : MI_GCP

7.4.6.8 Geometric Objects

The data dictionary table presented in this section is based on the corresponding Geometric Objects data dictionary table (Section B.2.6.3) found in ISO 19115:2003/Cor 1:2006. No profiling of this table was required to address I&E requirements.


Max

Occur

Data type Domain

Business Rule

MD_GeometricObjects number of objects, listed by geometric object type, used in the dataset

Use obligation/


object

Use maximum

occurrence from

referencing object

Class <<DataType>>

geometricObjectType name of point or vector objects used to locate zero-, one-, two-, or three-dimensional spatial locations in the dataset

M 1 Class / GeometricObjectTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (GeometricObjectTypeCode)

geometricObjectCount total number of the point or vector object type occurring in the dataset

O 1 Integer / > 0

Table 49 : Geometric Objects

7.4.7 Reference System

7.4.7.1 Reference System UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Reference System Package UML diagram (Figure A.9) found in ISO 19115:2003/Cor 1:2006. The diagram has been profiled, so some classes, attributes and association roles have been hidden. For the full diagram, consult ISO 19115:2003/Cor 1:2006.

This diagram defines metadata required to describe the spatial reference system used in the resource.


113

Figure 18 : Reference System

7.4.7.2 Reference System

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Reference System data dictionary table (Section B.2.7.1) found in ISO 19115:2003/Cor 1:2006. The table has been profiled, so some classes, attributes and association roles have been hidden. For the full table, consult ISO 19115:2003/Cor 1:2006.


Max Occur Data type / Domain

Business Rule

MD_ReferenceSystem information about the reference system


from referencing

object

Use maximum

occurrence from

referencing object


referenceSystemIdentifier name of reference system

M 1 Class / RS_Identifier (7.4.8.3)

See Table 2 (CrsIdentifier)

CrsIdentifier is a realization of the abstract functionality described by RS_Identifier, and is the preferred realization.

It is a Recommended Best Practice that when a Geodetic 2D CRS is used that it be in accordance with World Geodetic System 1984 - Geographic, 2- Dimensional, as specified in NIMA TR8350.2 (3rd Edition, Amendment 1) and identified by the URI:

http://metadata.ces.mil/dse/ns/GSIP/crs/WGS84E_2D

Note: this element is optional in ISO 19115:2003/Cor. 1:2006.

Table 50 : Reference System




114

7.4.8 Identifier

7.4.8.1 Identifier UML

This UML diagram is an SDSFIE-M -specific diagram that is not found in ISO 19115:2003/Cor 1:2006. The classes defined here are present in ISO 19115:2003/Cor 1:2006, but they have been moved to a separate diagram for ease of understanding.

This diagram defines the metadata required to unambiguously identify a resource.

Figure 19 : Identifier

7.4.8.2 Identifier

The MD_Identifier entity serves to unambiguously identify a resource. The structure of this entity consists of a namespace or authority and a code value. The code value uniquely identifies a resource within the specified namespace.

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Identifier Information data dictionary table (Section B.2.7.3) found in ISO 19115:2003/Cor 1:2006. It differs from the ISO version in that the obligation on “authority” is mandatory in this profile and that the RS_Identifier subclass is documented in a separate table.

Name / role name

Definition Obligation / Condition Max

Occur

Data type Domain

Business Rule

MD_Identifier value uniquely identifying an object within a namespace


Use maximum

occurrence from

referencing object

Class <<DataType>>

authority person or party responsible for maintenance of the namespace


code alphanumeric value identifying an instance in the namespace


Table 51 : Identifier


115

MD_Identifier is flexible construct supporting many different forms of identification. Flexibility, however, is often the enemy of interoperability. This standard addresses that issue by specifying the content of the MD_Identifier elements for each metadata element in this standard which is of type MD_Identifier.

Table 52 addresses the case where the identifier can be resolved to the referenced entity through automated means.

Element Authority (CI_Citation) Code (CharacterString)

NMF_RevisionRecall.

revisionLink

Title: “ITU-T REC. X.667”

Date: 08/2008

or

Title: “IETF RFC 3986”

Date: 2005

Hexadecimal UUID value per ITU-T REC. X.667

or

URI per IETF RFC 3986

MD_AggregateInformation.

aggregateDataSetIdentifier


Date: 08/2008

or


Date: 2005


or


NTK_Access.

Individual

and

NMF_UserInput.user

Title: URN for the LDAP server

Date: date and time when the identification was last validated

LDAP Distinguished Name for the user per IETF RFC 4514

NTK_Access.

group



LDAP Distinguished Name for the group per IETF RFC 4514

NTK_Access.

profile


Date: date and time when the definition was last validated

LDAP Distinguished Name for the profile per IETF RFC 4514

EX_GeographicDescription.

geographicIdentifier


Date: 08/2008

or


Date: 2005


or


CI_Citation.

identifier


Date: 08/2008

or


Date: 2005


or


NOTE: Implementation Specifications may specify another X.667 compliant encoding of the UUID as long as it conveys equivalent information to the specified hexadecimal encoding.

Table 52 : Resolvable Resource Identifiers

Not all identifiers will be suitable for automated resolution. In those cases, it may be sufficient that the authority / code pair is unique, or human intervention may be required to perform the resolution. Table 53 addresses these case where the identifier cannot be resolved through automated means.



116

NMF_RevisionRecall.

revisionLink

NA – notice content should be provided in revisionDetails

NA

MD_AggregateInformation.

aggregateDataSetIdentifier

NA – aggregateDataSetName provides dataset name

NA

NTK_Access.

Individual

and

NMF_UserInput.user

Title: name of the system


User name

NTK_Access.

group



Group name

NTK_Access.

profile


Date: date and time when the definition was last validated

Profile name

EX_GeographicDescription.

geographicIdentifier

Title: title of the document where the identifier is described

Date: date of the describing document

Textual identification of the geographic extent

CI_Citation.

identifier

Title: title of the governing specification

Date: date of the governing specification

Identifier (ex. card catalog number)

Table 53 : Non-Resolvable Resource Identifiers

For imagery and gridded data, many of the identifier metadata elements may be captured using one of the general purpose identifiers described in Table 31.


UUID Title: “ITU-T REC. X.667”

Date: 08/2008


UUID URN encoding Title: “IETF RFC 4122”

Date: 2005

URN per IETF RFC 4122

URI Title: “IETF RFC 3986”

Date: 2005


NOTE: Implementation Specifications may specify another X.667 compliant encoding of the UUID as long as it conveys equivalent

Table 54 : General Purpose Identifiers for Imagery and Gridded Data

For imagery and gridded data, many of the identifier metadata elements may be captured using one of the general purpose identifiers described in Table 55.


MD_ImageDescription. imageQualityCode

Title: Name of the quality measurement specification

Date: Date of the version used

Image quality code value

MD_ImageDescription. processingLevelCode

Title: Name of the processing specification


Processing level value

MI_Requirement.identifier Title: Name of community standard


or

A general purpose identifier

Community identifier value


117

MI_Instrument.identifier Title: Name of community standard


or



MI_Objective.identifier Title: Name of community standard


or



MI_Operation.identifier Title: Name of community standard


or



MI_Platform.identifier Title: Name of community standard


or



MI_PlatformPass.identifier Title: Name of community standard


or



MI_Event.identifier Title: Name of community standard


or



Table 55 : Imagery and Gridded Data Identifiers

7.4.8.3 Reference System Identifier

The RS_Identifier entity extends MD_Identifier to identify a reference system. The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Identifier Information data dictionary table (Section B.2.7.3) found in ISO 19115:2003/Cor 1:2006. It differs from the ISO version in its obligations and in that the MD_Identifier and RS_Identifier classes are documented in separate tables.


Max

Occur

Data type Domain

Business Rule

RS_Identifier

identifier used for reference systems


referencing object

Use maximum

occurrence from

referencing object

Specified Class (MD_Identifier)

codeSpace name or identifier of the person or organization responsible for namespace


version version identifier for the namespace


Table 56 : RS_Identifier


118

7.4.9 Content Information

7.4.9.1 Content Information UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Content Information Package UML diagram (Figure A.10) found in ISO 19115:2003/Cor 1:2006. The diagram has been profiled, so some classes, attributes and association roles have been hidden. For the full diagram, consult ISO 19115:2003/Cor 1:2006

Figure 20 : Content Information

class Content information

MD_ImageDescription

+ il luminationElevationAngle :Real [0..1]

+ il luminationAzimuthAngle :Real [0..1]

+ imagingCondition :MD_ImagingConditionCode [0..1]

+ imageQualityCode :MD_Identifier [0..1]

+ cloudCoverPercentage :Real [0..1]

+ processingLevelCode :MD_Identifier [0..1]

+ compressionGenerationQuantity :Integer [0..1]

+ triangulationIndicator :Boolean [0..1]

+ radiometricCalibrationDataAvailabil ity :Boolean [0..1]

+ cameraCalibrationInformationAvailabil ity :Boolean [0..1]

+ fi lmDistortionInformationAvailabil ity :Boolean [0..1]

+ lensDistortionInformationAvailabil ity :Boolean [0..1]

MD_RangeDimension

+ sequenceIdentifier :MemberName [0..1]

+ descriptor :CharacterString [0..1]

MD_Cov erageDescription

+ attributeDescription :RecordType

+ contentType :MD_CoverageContentTypeCode

"units" is mandatory if "maxValue" or

"minValue" are provided

MD_Band

+ maxValue :Real [0..1]

+ minValue :Real [0..1]

+ units :UomLength [0..1]

+ peakResponse :Real [0..1]

+ bitsPerValue :Integer [0..1]

+ toneGradation :Integer [0..1]

+ scaleFactor :Real [0..1]

+ offset :Real [0..1]

«CodeList»

MD_ImagingConditionCode

{root,leaf}

+ blurredImage

+ cloud

+ degradingObliquity

+ fog

+ heavySmokeOrDust

+ night

+ rain

+ semiDarkness

+ shadow

+ snow

+ terrainMasking

«CodeList»

MD_Cov erageContentTypeCode

{root,leaf}

+ image

+ thematicClassification

+ physicalMeasurement

MD_ContentInformation

MD_Metadata

MD_FeatureCatalogueDescription

+ complianceCode :Boolean [0..1]

+ language :CharacterString [0..*]

+ includedWithDataset :Boolean

+ featureTypes :SMF_FeatureTypes [1..*]

+ featureCatalogueCitation :CI_Citation [1..*]

«union»

SMF_FeatureTypes

+ featureTypes :GenericName

+ sdsfieFeatureTypes :SMF_Feature

«<<DataType>>»

SMF_Feature

+ name :CharacterString

+ aliasName :CharacterString

+ modelName :CharacterString

+ definition :CharacterString

+ description :CharacterString

+ note :CharacterString

+ justification :CharacterString

+dimension 0..*0..*

+contentInfo 0..*


119

This UML diagram is the corresponding Content Information Package UML diagram (Figure A.7) found in ISO 19115-2:2009. No profiling of this diagram has been performed to address I&E community requirements.

Figure 21 : Content Information with imagery extensions

7.4.9.2 Content Information

The data dictionary table presented in this section is an SDSFIE-M -specific version of the corresponding Content Information data dictionary table (Section B.2.8) found in ISO 19115:2003/Cor 1:2006. The table has been modified by updating the featureTypes DataType to allow for a more detailed description of SDSFIE feature types while still leaving the possibility for the description of non-SDSFIE feature types. For the full table, consult ISO 19115:2003/Cor 1:2006.



Business Rule


120

MD_ContentInformation description of the content of a dataset


from referencing

object

Use maximum

occurrence from

referencing object


MD_FeatureCatalogueDescription information identifying the feature catalogue or the conceptual schema


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_ContentInformation)

includedWithDataset indication of whether or not the feature catalogue is included with the dataset

M 1 Boolean / 0=no, 1=yes

featureTypes subset of feature types from cited feature catalogue occurring in dataset

M N Class / SMF_FeatureTypes <<Union>> (7.4.9.3)

featureCatalogueCitation complete bibliographic reference to one or more external feature catalogues

M N Class / CI_Citation <<DataType>> (7.4.13.2)

MD_CoverageDescription information about the content of a grid data cell


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_ContentInformation)

attributeDescription description of the attribute described by the measurement value

M 1 Class / RecordType <<Metaclass>> (Annex B)

contentType type of information represented by the cell value

M 1 Class / CoverageContentTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (CoverageContentTypeCode)

role name: dimension information on the dimensions of the cell measurement value

O N Class / MD_RangeDimension (7.4.9.5)

MD_ImageDescription information about an image’s suitability for use


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_CoverageDescription)

illuminationElevationAngle illumination elevation measured in degrees clockwise from the target plane at intersection of the optical line of sight with the Earth’s surface. For images from a scanning device, refer to the centre pixel of the image

O 1 Real / -90.0 – 90.0


121

illuminationAzimuthAngle illumination azimuth measured in degrees clockwise from true north at the time the image is taken. For images from a scanning device, refer to the centre pixel of the image

O 1 Real / 0.00 – 360.0

imagingCondition conditions affected the image

O 1 Class / ImagingConditionCode <<CodeList>> (7.2.2.2)

See Table 3 (ImagingConditionCode)

imageQualityCode specifies the image quality


cloudCoverPercentage area of the dataset obscured by clouds, expressed as a percentage of the spatial extent

O 1 Real / 0.0 – 100.0

processingLevelCode image distributor’s code that identifies the level of radiometric and geometric processing that has been applied


compressionGenerationQuantity count of the number of lossy compression cycles performed on the image

O 1 Integer

triangulationIndicator indication of whether or not triangulation has been performed upon the image

O 1 Boolean / 0=no, 1=yes

radiometricCalibrationData Availability

indication of whether or not the radiometric calibration information for generating the radiometrically calibrated standard data product is available


cameraCalibrationInformation Availability

indication of whether or not constants are available which allow for camera calibration corrections


filmDistortionInformation Availability

indication of whether or not Calibration Reseau information is available


lensDistortionInformation Availability

indication of whether or not lens aberration correction information is available


Table 57 : Content Information


122

7.4.9.3 FeatureTypes

SMF_FeaturesTypes is an entirely new element meant to provide for documentation of the feature types contained within a dataset, either by name (using the featureTypes element) or, for SDSIFE-based feature types by name, alias name, model name, definition, description, note, and justification (using the sdsfieFeatureTypes element).



Business Rule

SMF_FeatureTypes description of feature types Use obligation/


object

Use maximum

occurrence from

referencing object


featureTypes feature types contained within the dataset

C / sdsfieFeatureTypes is not

set?

N Class / GenericName (Annex B)

sdsfieFeatureTypes SDSFIE (Gold or Adaptation) feature types contained with the dataset

C / featureTypes

is not set?

N Class / SMF_Feature <<DataType>> (7.4.9.4)

Table 58 : SMF_FeatureTypes

7.4.9.4 Features

The SMF_Features DataType is an entirely new element intended to group the elements of an SDSFIE-based feature type description in to a single entity.



Business Rule

SMF_Feature

SDSFIE-M specific information required to describe feature classes that are defined by some Adaptation of SDSFIE


from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

name the name of the SDSFIE feature class


aliasName the alias name of the SDSFIE feature class


modelName the model name of the SDSFIE feature class


definition the definition of the SDSFIE feature class


description the description of the SDSFIE feature class


note the note for the SDSFIE feature class


justification

information regarding the business justification and/or purpose for collection of this feature class


Table 59 : SMF_Features


123

7.4.9.5 Range Dimension

The data dictionary table presented in this section is based on the corresponding Range Dimension data dictionary table found in ISO 19115:2003/Cor. 1:2006 (Section B.2.8.2).

No profiling of this table has been performed to address I&E community requirements.


Max

Occur

Data type Domain

Business Rule

MD_RangeDimension information on the range of each dimension of a cell measurement value


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MD_CoverageDescription)

sequenceIdentifier number that uniquely identifies instances of bands of wavelengths on which a sensor operates

O 1 Class / MemberName (Annex B)

descriptor description of the range of a cell measurement value


MD_Band range of wavelengths in the electromagnetic spectrum


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_RangeDimension)

maxValue longest wavelength that the sensor is capable of collecting within a designated band

O 1 Real

minValue shortest wavelength that the sensor is capable of collecting within a designated band

O 1 Real

units units in which sensor wavelengths are expressed

C / minValue or maxValue

provided?

1 Class / UomLength (Annex B)

peakResponse wavelength at which the response is the highest

O 1 Real

bitsPerValue maximum number of significant bits in the uncompressed representation for the value in each band of each pixel

O 1 Integer

toneGradation number of discrete numerical values in the grid data

O 1 Integer

scaleFactor scale factor which has been applied to the cell value

O 1 Real

offset the physical value corresponding to a cell value of zero

O 1 Real


124

Table 60 : MD_RangeDimension

7.4.9.6 Wavelength Band Information

The data dictionary table presented in this section is based on the corresponding Wavelength Band data dictionary table found in ISO 19115-2:2009 (Section B.2.4.2).



Max

Occur

Data type Domain

Business Rule

MI_Band extensions to electromagnetic spectrum wavelength description (MD_Band extended)

Use obligation/


object


from referencing

object

Specified Class (MD_Band)

bandBoundaryDefinition designation of criterion for defining maximum and minimum wavelengths for a spectral band

O 1 Class / BandDefinition <<CodeList>> (7.2.2.2)

See Table 3 (BandDefinition)

nominalSpatialResolution smallest distance between which separate points can be distinguished, as specified in instrument design

O 1 Class / Distance <<DataType>>

transferFunctionType type of transform function to be used when scaling a physical value for a given element

O 1 Class / TransferFunctionTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (TransferFunctionTypeCode)

transmittedPolarisation polarisation of the radiation transmitted

O 1 Class / PolarisationOrientationCode <<CodeList>> (7.2.2.2)

See Table 3 (PolarisationOrientationCode)

detectedPolarisation polarisation of the radiation detected

O 1 Class / PolarisationOrientationCode <<CodeList>> (7.2.2.2)

See Table 3 (PolarisationOrientationCode)

Table 61 : MI_Band

7.4.9.7 Coverage and Image Description – Extensions

The data dictionary table presented in this section is based on the corresponding section of the Coverage and Image Description – Extensions data dictionary table found in ISO 19115-2:2009 (Section B.2.4.3).



Max

Occur

Data type Domain

Business Rule

MI_CoverageDescription information about the content of a coverage, including the description of specific range elements (MD_CoverageDescription extended)


referencing object

Use maximum

occurrence from

referencing object

Specified class (MD_CoverageDescription)


125

role name: rangeElementDescription

provides the description of the specific range elements of a coverage

O N Association / MI_RangeElementDescription (7.4.9.7)

Table 62 : MI_CoverageDescription




Max

Occur

Data type Domain

Business Rule

MI_ImageDescription information about the content of an image, including the description of specific range elements (MD_ImageDescription extended)


referencing object

Use maximum

occurrence from

referencing object

Specified class (MD_ImageDescription)

role name: rangeElementDescription

provides the description of the specific range elements of an image

O N Association / MI_RangeElementDescription (7.4.9.7)

Table 63 : MI_ImageDescription




Max

Occur

Data type Domain

Business Rule

MI_RangeElementDescription description of specific range elements


referencing object


referencing object

Class

name designation associated with a set of range elements


definition description of a set of specific range elements


rangeElement specific range elements, i.e. range elements associated with a name and their definition

M N Class / Record (Annex B)

Table 64 : MI_RangeElementDescription

7.4.10 Application Schema

7.4.10.1 Application Schema UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Application Schema Package UML diagram (Figure A.14) found in ISO 19115:2003/Cor 1:2006. The MD_ApplicationSchema class was specialized to provide a place for the version of


126

the application schema to be included. For the full diagram, consult ISO 19115:2003/Cor 1:2006

This diagram defines the application schema used.

Figure 22 : Application Schema

7.4.10.2 Application Schema

The data dictionary table presented in this section is based on the corresponding section of the Application Schema data dictionary table (Section B.2.12) found in ISO 19115:2003/Cor 1:2006.

The definition of the name element to indicate that the name of the application schema is equivalent to the SDSFIE Adaptation name if that is the application schema used.



Business Rule

MD_ApplicationSchema Information

information about the application schema used to build the dataset


from referencing

object

Use maximum

occurrence from

referencing object


name The name of the application schema used. If the resource being documented is SDSFIE data, then this element is the name of the applicable SDSFIE Adaptation.


schemaLanguage identification of the schema language used


constraintLanguage formal language used in Application Schema


schemaAscii full application schema given as an ASCII file



127

graphicsFile full application schema given as a graphics file

O 1 Binary

softwareDevelopmentFile full application schema given as a software development file

O 1 Binary

softwareDevelopmentFile Format

software dependent format used for the application schema software dependent file


SMF_ApplicationSchema Information

SDSFIE-M specific information required to describe an application schema for feature classes that are defined by some Adaptation of SDSFIE


from referencing

object

Use maximum

occurrence from

referencing object

Specified Class (MD_ApplicationSchema Information)

sdsfieAdaptationVersion the version of the SDSFIE Adaptation that contains this feature class

C / is an SDSFIE (Gold or

adaptation) feature class?


Table 65 : Application Schema Information

7.4.11 Acquisition Information

The MI_AcquisitionIformation entity captures information about the measuring instruments and their bands, the platform carrying them, and the mission to which the data contributes. This information is added to SDSFIE-M through this entity.

7.4.11.1 Acquisition Information UML

Two UML diagrams have been presented in this section. The first diagram (Figure 23) is based on the Acquisition Overview UML diagram (Figure A.7) found in ISO 19115-2:2009. The second diagram (Figure 24) provides a detailed view of the Acquisition Information classes. It is based on the Acquisition Details UML diagram (Figure A.8) also found in ISO 19115-2:2009. Neither diagram has been modified for SDSFIE-M.


128

Figure 23 : Acquisition Overview


129

Figure 24 : Acquisition Detail

7.4.11.2 Acquisition Information Data Dictionary

The data dictionary table presented in this section is based on the corresponding Acquisition Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.1).




Business Rule

MI_AcquisitionInformation designations for the measuring instruments, the platform carrying them, and the mission to which the data contributes


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Metadata)

role name: acquisitionPlan Identifies the plan as implemented by the acquisition

O N Association / MI_Plan (7.4.11.4)


130

role name: acquisitionRequirement

Identifies the requirement the data acquisition intends to satisfy

O N Association / MI_Requirement (7.4.11.5)

role name: instrument general information about the instrument used in data acquisition

O N Association / MI_Instrument (7.4,11.7)

role name: objective identification of the area or object to be sensed

O N Association / MI_Objective (7.4.11.8)

role name: operation general information about an identifiable activity which provided the data

O N Association / MI_Operation (7.4.11.9)

role name: platform general information about the platform from which the data were taken

O N Association / MI_Platform (7.4.11.10)

Table 66 : MI_AcquisitionInformation

7.4.11.3 Environmental Information

The data dictionary table presented in this section is based on the corresponding Environmental Record data dictionary table found in ISO 19115-2:2009 (Section B.2.5.2).




Business Rule

MI_EnvironmentalRecord Information about the environmental conditions during the acquisition


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Operation)

averageAirTemperature average air temperature along the flight pass during the photo flight

M 1 Real

maxRelativeHumidity maximum relative humidity along the flight pass during the photo flight

M 1 Real

maxAltitude maximum altitude during the photo flight

M 1 Real

meteorologicalConditions meteorological conditions in the photo flight area, in particular clouds, snow and wind


Table 67 : MI_EnvironmentalRecord

7.4.11.4 Plan Information

The data dictionary table presented in this section is based on the corresponding Plan Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.7).



131



Business Rule

MI_Plan designations for the planning information related to meeting the data acquisition requirements


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Acquisition Information)

type manner of sampling geometry that the planner expects for collection of objective data

O 1 Class / GeometryTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (GeometryTypeCode)

status current status of the plan (pending, completed, etc.)

M 1 Class / ProgressCode <<CodeList>> (7.2.2.2)


citation identification of authority requesting target collection


role name: operation identification of the activity or activities that satisfy a plan


role name: satisfiedRequirement

requirement satisfied by the plan

O N Association / MI_Requirement (7.4.11.5)

Table 68 : MI_Plan

7.4.11.5 Requirement Information

The data dictionary table presented in this section is based on the corresponding Requirement Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.11).




Business Rule

MI_Requirement requirement to be satisfied by the planned data acquisition


from referencing

object

Use maximum

occurrence from

referencing object


citation identification of reference or guidance material for the requirement


identifier unique name, or code, for the requirement


requestor origin of requirement M N Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)

recipient person(s), or body(ies), to receive results of requirement



132

priority relative ordered importance, or urgency, of the requirement

M 1 Class / PriorityCode <<CodeList>> (7.2.2.2)

See Table 3 (PriorityCode)

requestedDate required or preferred acquisition date and time

M 1 Class / MI_RequestedDate <<DataType>> (7.4.11.6)

expiryDate date and time after which collection is no longer valid

M 1 Class / DateTime (Annex B)

role name: satisfiedPlan plan that identifies solution to satisfy the requirement

O N Association / MI_Plan (7.4.11.4)

Table 69 : MI_Requirement

7.4.11.6 Request Date Range

The data dictionary table presented in this section is based on the corresponding Request Date Range data dictionary table found in ISO 19115-2:2009 (Section B.2.5.10).




Business Rule

MI_RequestedDate range of date validity Use obligation/ condition

from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

requestedDateOf Collection

preferred date and time of collection


latestAcceptableDate latest date and time collection must be completed


Table 70 : MI_RequestedDate

7.4.11.7 Instrument Identification

The data dictionary table presented in this section is based on the corresponding Instrument Identification data dictionary table found in ISO 19115-2:2009 (Section B.2.5.4).




Business Rule

MI_Instrument designations for the measuring instruments


from referencing

object

Use maximum

occurrence from

referencing object


citation complete citation of the instrument

O * Class / CI_Citation <<DataType>> (7.4.13.2)


133

identifier unique identification of the instrument


type name of the type of instrument


description textual description of the instrument


role name: mountedOn platform the instrument is mounted on

O 1 Association / MI_Platform (7.4.11.10)

Table 71 : MI_Instrument

7.4.11.8 Objective Identification

The data dictionary table presented in this section is based on the corresponding Objective Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.5).




Business Rule

MI_Objective describes the characteristics, spatial and temporal extent of the intended object to be observed


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Acquisition Information, MI_Operation)

identifier code used to identify the objective

M * Class / MD_Identifier <<DataType>> (7.4.8.2)

priority priority applied to the target O 1 CharacterString / Free text

type collection technique for the objective

O N Class / ObjectiveTypeCode <<CodeList>> (7.2.2.2)

See Table 3 (ObjectiveTypeCode)

function role or purpose performed by or activity performed at the objective


extent extent information including the bounding box, bounding polygon, vertical and temporal extent of the objective

O N Class / EX_Extent <<DataType>> (7.4.12.2)

role name: objectiveOccurence

event or events associated with objective completion.

M N Association / MI_Event (7.4.11.12)

role name: pass pass of the platform over the objective

O N Association / MI_PlatformPass (7.4.11.11)

role name: sensingInstrument

instrument which sensed the objective data


Table 72 : MI_Objective


134

7.4.11.9 Operation Information

The data dictionary table presented in this section is based on the corresponding Operation Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.6).




Business Rule

MI_Operation designations for the operation used to acquire the dataset


from referencing

object

Use maximum

occurrence from

referencing object


description description of the mission on which the platform observations are made and the objectives of that mission


citation identification of the mission O 1 Class / CI_Citation <<DataType>> (7.4.13.2)

identifier unique identification of the operation


status status of the data acquisition M 1 Class / ProgressCode <<CodeList>> (7.2.2.2)


role name: childOperation sub-missions that make up part of a larger mission


role name: objective object(s) or area(s) of interest to be sensed


role name: parentOperation heritage of the operation M 1 Association / MI_Operation (7.4.11.9)

role name: plan plan satisfied by the operation

O 1 Association / MI_Plan (7.4.11.4)

role name: platform platform (or platforms) used in the operation

O N Association / MI_Platform (7.4.11.10)

role name: significantEvent record of an event occurring during an operation

O N Association / MI_Event (7.4.11.12)

Table 73 : MI_Operation

7.4.11.10 Platform Information

The data dictionary table presented in this section is based on the corresponding Platform Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.8).




Business Rule


135

MI_Platform designation of the platform used to acquire the dataset


from referencing

object

Use maximum

occurrence from

referencing object


citation source where information about the platform is described


identifier unique identification of the platform.


description narrative description of the platform supporting the instrument


sponsor organization responsible for building, launch, or operation of the platform

O N Class / CI_ResponsibleParty <<DataType>> (7.4.13.3)

role name: instrument instrument(s) mounted on a platform

M N Association / MI_Instrument (7.4,11.7)

Table 74 : MI_Platform

7.4.11.11 Platform Pass Identification

The data dictionary table presented in this section is based on the corresponding Platform Pass Information data dictionary table found in ISO 19115-2:2009 (Section B.2.5.9).




Business Rule

MI_PlatformPass identification of collection coverage


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Objective)

identifier unique name of the pass M 1 Class / MD_Identifier <<DataType>> (7.4.8.2)

extent area covered by the pass O 1 Class / GM_Object (ISO 19107) <<Type>>

role name: relatedEvent occurrence of one or more events for a pass

O N Association / MI_Event (7.4.11.12)

Table 75 : MI_PlatformPass

7.4.11.12 Event Identification

The data dictionary table presented in this section is based on the corresponding Event Identification data dictionary table found in ISO 19115-2:2009 (Section B.2.5.3).




Business Rule


136

MI_Event identification of a significant collection point within an operation


from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (MI_Operation)

identifier event name or number M 1 Class / MD_Identifier <<DataType>> (7.4.8.2)

trigger initiator of the event M 1 Class / TriggerCode <<CodeList>> (7.2.2.2)

See Table 3 (TriggerCode)

context meaning of the event M 1 Class / ContextCode <<CodeList>> (7.2.2.2)

See Table 3 (ContextCode)

sequence relative time ordering of the event

M 1 Class / SequenceCode <<CodeList>> (7.2.2.2)

See Table 3 (SequenceCode)

time time the event occurred M 1 Class / DateTime (Annex B)

role name: expectedObjective

objective or objectives satisfied by an event


role name: relatedPass pass during which an event occurs

O 1 Association / MI_PlatformPass (7.4.11.11)

role name: relatedSensor instrument or instruments for which the event is meaningful


Table 76 : MI_Event

7.4.12 Extent

7.4.12.1 Extent UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Extent Package UML diagram (Figure A.15) found in ISO 19115:2003/Cor 1:2006. Classes, attributes and associations which extend the base standard have been added. For the original diagram consult ISO 19115:2003/Cor 1:2006.

SDSFIE-M modifies the ISO 19115 model of EX_Extent as follows:

Extended EX_GeographicExtent through the NMF_BoundingPoint subclass. This addresses the I&E community requirement for zero-dimension extents.


137

Figure 25 : Extent

7.4.12.2 Extent

The data dictionary table presented in this section is based on the corresponding Extent data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.1.1).




Business Rule

EX_Extent information about horizontal, vertical, and temporal extent

Use obligation/condition

from referencing object

Use maximum

occurrence from

referencing object

Class <<DataType>>

description spatial and temporal extent for the referring object

C / geographicElement

and temporalElement

and verticalElement not documented?



138

role name: geographicElement

provides geographic component of the extent of the referring object

C / description and temporalElement

and verticalElement not documented?

N Association / EX_GeographicExtent <<Abstract>> (7.4.12.3)

role name: temporalElement

provides temporal component of the extent of the referring object

C / description and geographicElement and verticalElement not documented?

N Association / EX_TemporalExtent (7.4.12.4)

role name: verticalElement

provides vertical component of the extent of the referring object

C / description and geographicElement

and temporalElement not

documented?

N Association / EX_VerticalExtent (7.4.12.5)

Table 77 : Extent

7.4.12.3 Geographic Extent

The data dictionary table presented in this section corresponds to the Geographic Extent data dictionary table (Section B.3.1.2) found in ISO 19115:2003/Cor 1:2006. The SDSFIE-M modifies the ISO 19115 data dictionary for EX_GeographicExtent by extending EX_GeographicExtent through the NMF_BoundingPoint subclass. This addresses the I&E community requirement for zero-dimension extents.



Business Rule

EX_GeographicExtent geographic area of the dataset

Use obligation/


object

Use maximum

occurrence from

referencing object

Aggregated Class (EX_Extent and EX_SpatialTemporalExtent) <<Abstract>>

extentTypeCode indication of whether the bounding polygon encompasses an area covered by the data or an area where data is not present

O 1 Boolean / 0 – exclusion, 1 – inclusion

EX_BoundingPolygon boundary enclosing the dataset, expressed as the closed set of (x,y) coordinates of the polygon (last point replicates first point)

Use obligation/


object

Use maximum

occurrence from

referencing object

Specified Class (EX_GeographicExtent)

polygon sets of points defining the bounding polygon

M N Class / GM_Object (Annex B)

EX_GeographicBoundingBox geographic position of the dataset. NOTE This is only an approximate reference so specifying the coordinate reference system is unnecessary

Use obligation/


object

Use maximum

occurrence from

referencing object



139

westBoundLongitude western-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east)

M 1 Decimal / -180,0 <= West Bounding Longitude Value <= 180,0

eastBoundLongitude eastern-most coordinate of the limit of the dataset extent, expressed in longitude in decimal degrees (positive east)

M 1 Decimal / -180,0 <= East Bounding Longitude Value <= 180,0

southBoundLatitude southern-most coordinate of the limit of the dataset extent, expressed in latitude in decimal degrees (positive north)

M 1 Decimal / -90,0 <= South Bounding Latitude Value <= 90,0; South Bounding Latitude Value <= North bounding Latitude Value

northBoundLatitude northern-most, coordinate of the limit of the dataset extent expressed in latitude in decimal degrees (positive north)

M 1 Decimal / -90,0 <= North Bounding Latitude Value <= 90,0; North Bounding Latitude Value >= South Bounding Latitude Value

EX_GeographicDescription description of the geographic area using identifiers

Use obligation/


object

Use maximum

occurrence from

referencing object


geographicIdentifier identifier used to represent a geographic area


NMF_BoundingPoint point position of the resource

Use obligation/


object

Use maximum

occurrence from

referencing object


point point defining the location of the resource

M N Class / GM_Point (Annex B)

Table 78 : Geographic Extent

7.4.12.4 Temporal Extent

The data dictionary table presented in this section is based on the corresponding Temporal Extent data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.1.3).



140



Business Rule

EX_TemporalExtent time period covered by the content of the dataset

Use obligation/con

dition from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (EX_Extent)

extent date and time for the content of the dataset

M 1 Class / TM_Primitive (Annex B)

EX_SpatialTemporalExtent extent with respect to date/time and spatial boundaries

Use obligation/con


object

Use maximum

occurrence from

referencing object

Specified Class (EX_TemporalExtent)

role name: spatialExtent spatial extent component of composite spatial and temporal extent

M N Association / EX_GeographicExtent <<Abstract>> (7.4.12.3)

Table 79 : Temporal Extent

7.4.12.5 Vertical Extent

The data dictionary table presented in this section is based on the corresponding Vertical Extent data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.1.4).




Business Rule

EX_VerticalExtent vertical domain of dataset Use obligation/ condition

from referencing

object

Use maximum

occurrence from

referencing object

Aggregated Class (EX_Extent)

minimumValue lowest vertical extent contained in the dataset

M 1 Real

maximumValue highest vertical extent contained in the dataset

M 1 Real


141

role name: verticalCRS provides information about the vertical coordinate reference system to which the maximum and minimum elevation values are measured. The CRS identification includes unit of measure.

M 1 Association / SC_CRS (ISO 19111)

See Table 2 (CrsIdentifier)

CrsIdentifier is a realization of the abstract functionality described by SC_CRS, and is the preferred realization. It is a Recommended Best Practice that when a Vertical CRS is used that it be in accordance with the Earth Gravity Model 1996 (EGM96), as specified in NIMA TR8350.2 (3rd Edition, Amendment 1).

This Vertical CRS is identified by one of two URIs depending on whether the coordinate is a height or depth value:

http://metadata.ces.mil/dse/ns/GSIP/crs/EGM96_H

http://metadata.ces.mil/dse/ns/GSIP/crs/EGM96_D

Table 80 : Vertical Extent

7.4.13 Citation

7.4.13.1 Citation UML

This UML diagram is an SDSFIE-M -specific version of the corresponding Citation Package UML diagram (Figure A.16) found in ISO 19115:2003/Cor 1:2006. The diagram has been modified by replacing some of the CodeLists.

Figure

This diagram defines metadata describing authoritative reference information, including responsible party and contact information.






142

Figure 26 : Citation and Responsible Party

7.4.13.2 Citation

The data dictionary table presented in this section is based on the corresponding Citation data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.1). The ). The data type of the presentationForm element has been modified to align with


143

the North American Profile of ISO 19115:2003/Cor 1:2006 via the CodeList named SMF_PresentationFormCode.



Business Rule

CI_Citation standardized resource reference


from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

title name by which the cited resource is known


alternateTitle short name or other language name by which the cited information is known. Example: "DCW" as an alternative title for "Digital Chart of the World”


date reference date for the cited resource

M N Class / CI_Date <<DataType>> (7.4.13.6)

edition version of the cited resource O 1 CharacterString / Free text

editionDate date of the edition O 1 Class / Date (B.4.2)

identifier value uniquely identifying an object within a namespace


The NSG is moving to mandatory unique identifiers. Due to the fact that SDSFIE-M is aligned with NSG requirements, this element will be mandatory in future versions of SDSFIE-M.

citedResponsibleParty name and position information for an individual or organization that is responsible for the resource


In the case of more than a single pointOfContact element then the members of the set shall be ordered in descending priority of their recommended use, however not all implementations will necessarily honor the ordering

presentationForm mode in which the resource is represented

O N Class / PresentationFormCode <<CodeList>>

See Table 3 (PresentationFormCode)

series information about the series, or aggregate dataset, of which the dataset is a part

O 1 Class / CI_Series <<DataType>>(7.4.13.8)


144

otherCitationDetails other information required to complete the citation that is not recorded elsewhere


collectiveTitle common title with holdings note. NOTE title identifies elements of a series collectively, combined with information about what volumes are available at the source cited


ISBN international Standard Book Number


ISSN international Standard Serial Number


Table 81 : Citation

7.4.13.3 Responsible Party

The data dictionary table presented in this section is based on the corresponding Responsible Party data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.1). The data type of the role element has been modified to align with the North American Profile of ISO 19115:2003/Cor 1:2006 via the CodeList named SMF_RoleCode.



Business Rule

CI_ResponsibleParty identification of, and means of communication with, person(s) and organizations associated with the dataset


referencing object

Use maximum

occurrence from

referencing object

Class <<DataType>>

individualName name of the responsible person- surname, given name, title separated by a delimiter

C / organisationName and positionName not documented?


Wherever possible, avoid the use of personal names as they change more frequently than position name or organization and because their presence in a database or metadata record may make that record private as defined by various federal regulations.

organisationName name of the responsible organization

C / individualName

and positionName not documented?


positionName role or position of the responsible person

C / individualName

and organisationName not documented?


contactInfo address of the responsible party

O 1 Class / CI_Contact <<DataType>> (7.4.13.5)


145

role function performed by the responsible party

M 1 Class / RoleCode <<CodeList>>See Table 3 (RoleCode)

Table 82 : Responsible Party

7.4.13.4 Address

The data dictionary table presented in this section is based on the corresponding Address data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.2). The data type of the country element has been modified to align with the NMF via the CodeList named CountryCode.



Business Rule

CI_Address location of the responsible individual or organization


referencing object

Use maximum

occurrence from

referencing object

Class <<DataType>>

deliveryPoint address line for the location (as described in ISO 11180, annex A)


city city of the location O 1 CharacterString / Free text

administrativeArea state, province of the location O 1 CharacterString / Free text

postalCode ZIP or other postal code O 1 CharacterString / Free text

country country of the physical address O 1 Class / CountryCode <<CodeList>> See Table 3 (CountryCode)

electronicMailAddress

address of the electronic mailbox of the responsible organization or individual


Table 83 : Address

7.4.13.5 Contact

The data dictionary table presented in this section is based on the corresponding Contact data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.3).




Business Rule

CI_Contact information required to enable contact with the responsible person and/or organization

Use obligation/


object

Use maximum

occurrence from

referencing object

Class <<DataType>>


146

phone telephone numbers at which the organization or individual may be contacted

O 1 Class / CI_Telephone <<DataType>> (7.4.13.9)

address physical and email address at which the organization or individual may be contacted

O 1 Class / CI_Address <<DataType>> (7.4.13.4)

onlineResource on-line information that can be used to contact the individual or organization

O 1 Class / CI_OnlineResource <<DataType>> (7.4.13.7)

hoursOfService time period (including time zone) when individuals can contact the organization or individual


contactInstructions supplemental instructions on how or when to contact the individual or organization


Table 84 : Contact

7.4.13.6 Date

The data dictionary table presented in this section is based on the corresponding Date data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.4). The data type of the dateType element has been modified to align with the North American Profile of ISO 19115:2003/Cor 1:2006 via the CodeList named SMF_DateTypeCode.



Business Rule

CI_Date reference date and event used to describe it

Use obligation/con


object

Use maximum

occurrence from

referencing object

Class <<DataType>>

date reference date for the cited resource M 1 Class / Date (Annex B)

dateType event used for reference date M 1 Class / DateTypeCode <<CodeList>> See Table 3 (DateTypeCode)

Table 85 : Date

7.4.13.7 Online Resource

The data dictionary table presented in this section is based on the corresponding Date data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.5). The data type of the function element has been modified to align with the North American Profile of ISO 19115:2003/Cor 1:2006 via the CodeList named SMF_OnlineFunctionCode.



Business Rule


147

CI_OnlineResource information about on-line sources from which the dataset, specification, or community profile name and extended metadata elements can be obtained


from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

linkage location (address) for on-line access using a Uniform Resource Locator address or similar addressing scheme such as http://www.statkart.no/isotc211

M 1 Class / URL (IETF RFC1738 , IETF RFC 2056)

protocol connection protocol to be used O 1 CharacterString / Free text

The protocol should be taken from an official controlled list such as the Official Internet Protocol Standards published on the Web at http://www.rfceditor. org/rfcxx00.html or the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/numbers.html.

applicationProfile name of an application profile that can be used with the online resource


name name of the online resource O 1 CharacterString / Free text

description detailed text description of what the online resource is/does


function code for function performed by the online resource

O 1 Class / OnLineFunctionCode <<CodeList>> See Table 3 (OnLineFunctionCode)

Table 86 : Online Resource

7.4.13.8 Series

The data dictionary table presented in this section is based on the corresponding Series data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.6).




Business Rule

CI_Series information about the series, or aggregate dataset, to which a dataset belongs


from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

name name of the series, or aggregate dataset, of which the dataset is a part


issueIdentification information identifying the issue of the series



148

page details on which pages of the publication the article was published


Table 87 : Series

7.4.13.9 Telephone

The data dictionary table presented in this section is based on the corresponding Telephone data dictionary table found in ISO 19115:2003/Cor 1:2006 (Section B.3.2.7).




Business Rule

CI_Telephone telephone numbers for contacting the responsible individual or organization

Use obligation/condition from referencing

object

Use maximum

occurrence from

referencing object

Class <<DataType>>

voice telephone number by which individuals can speak to the responsible organization or individual


See Table 2 (TelephoneNumber).

facsimile telephone number of a facsimile machine for the responsible organization or individual


See Table 2 (TelephoneNumber).

Table 88 : Telephone


149



150

Annex A – Profiles (Normative)

A.1 Extending the SDSFIE-M Conceptual Schema Profile

A.1.1 Introduction

The SDSFIE-M Conceptual Schema Profile defines “what we all must understand” (as a set of metadata concepts) in the I&E community in regards to geospatial metadata in support of (e.g.) data discovery, determining data fitness for use, data access, data transfer, and mission-specific use of geospatial information.

The SDSFIE-M Conceptual Schema Profile cannot, practically, cover all possible uses; therefore, it will require extension in order to meet the requirements of specific products and data sets.

This section defines the methodology by which extensions for the SDSFIE-M Conceptual Schema Profile are created.

A.1.2 Extension Methodology

The following steps shall be taken when creating a new extension to the SDSFIE-M Conceptual Schema Profile:

1) Review ISO/TC 19115:2003/Cor 1:2006. If an appropriate entity or element is located there, the UML definition and data dictionary entry can be inserted into the SDSFIE-M Conceptual Schema Profile.

2) Review ISO/TC 19115-2:2009. If an appropriate entity or element is located there, the UML definition and data dictionary entry can be inserted into the SDSFIE-M Conceptual Schema Profile.

3) Review ISO/TC 211’s suite of Standards and Specifications. If an appropriate class or element is located there, the UML definition and data dictionary entry can be inserted into the SDSFIE-M Conceptual Schema Profile.

4) If no existing ISO/TC 211 entity or element is appropriate, an existing class or element shall be extended. This will require the creation of new UML classes and elements, and the creation of new data dictionary entries. Register the new metadata entities and/or elements in a suitable namespace in the Department of Defense Metadata Registry.

A.1.3 Existing Element

A.1.3.1 Introduction

If an existing metadata element has been identified as meeting the new requirement, there are three options for reusing existing elements.


151

Option 1, Domain Restriction: Use the element, but restrict the domain using a new codelist.

Option 2, Code list Restriction: Use the element and the suitable code list, but restrict the possible values by subsetting.

Option 3, Domain Expansion: Use the element and the suitable code list, but expand the possible values by extending the original codelist.

A.1.3.2 Domain Restriction

An existing metadata element is suitable, given that the “free text” domain of the identified element is restricted. No existing metadata code list can be identified within the metadata standard that meets the element requirements. In this circumstance a new metadata code list may be defined as an extension to meet the specific requirements of the profile.

The new metadata codelist should be defined in a style consistent with that of ISO 19115:2003/Cor 1:2006.

METHOD:

1) Define the new metadata code list in terms of Definition and Name. The definition of the new code list shall be consistent with the existing codelists as found in Clause B.5 of 19115:2003/Cor 1:2006.

2) Define the new metadata code list elements in terms of Definition and Domain code. This definition shall be consistent with the existing code list elements found in Clause B.5 of 19115:2003/Cor 1:2006.

3) Register the new metadata code list elements in the Department of Defense Metadata Registry, in a suitable namespace and published with a URL consistent with Section 0.

4) Update the appropriate UML diagram.

A.1.3.3 Code list Restriction

An existing metadata code list meets the requirement, but the profile requires that the elements defined for the code list be a restricted subset of the standard domain as specified in SDSFIE-M, when applicable, or established by the external standard (e.g., ISO 19115:2003/Cor 1:2006).

METHOD:

1) Identify the metadata element and record the constrained domain in terms of dataType and domainValue.


A.1.3.4 Domain Expansion

An existing metadata element is suitable, given that the metadata code list of the identified element is expanded. The new metadata code list elements should be defined


152

with reference to the existing set of elements. The expanded metadata code list must be a logical expansion of the standard set of values.

METHOD:

1) Identify the metadata element and record the expanded domain in terms of dataType and domainValue.

2) Register the new metadata code list elements in the Department of Defense Metadata Registry, in a suitable namespace and published with a URL consistent with Section 0

3) Update the appropriate UML diagram

A.1.4 New Element or Entity


If no existing element or entity can be identified that meets the new requirement, a new element or class can be defined.

A.1.4.2 New Element

No existing metadata element can be identified within the metadata standard that meets the element requirements. In this circumstance a new metadata element may be defined to meet the specific requirements of the profile.

The new metadata element shall be defined in a style consistent with that of ISO 19115:2003/Cor 1:2006.

METHOD:

1) Identify the existing metadata entity to which the new element should be added.

2) Define the new metadata element in terms of the extended element information as described in 19115:2003/Cor 1:2006: name, definition, obligation, condition, maximumOccurence, dataType, and domainValue.


4) Register the new metadata entities and/or elements in a suitable namespace in the Department of Defense Metadata Registry.

A.1.4.3 New Entity

No existing metadata element or entity can be identified within the metadata standard that meets the entity requirements, nor can an existing metadata entity be modified by the addition of simple metadata elements to meet the requirements. In this circumstance a new metadata entity may be defined to meet the specific requirements of the profile.

The new metadata entity shall be defined in a style consistent with that of ISO 19115:2003/Cor 1:2006.

METHOD:


153

1) Identify which groupings of metadata best describe the function of the new entity. Define the new metadata entity in terms of the extended element information as described in 19115:2003/Cor 1:2006: name, definition, obligation, condition, dataType, domainValue, maximumOccurence, parentEntity, rule, rationale and source. Data type is ‘Class’ for a metadata entity.

2) Identify the elements that form the metadata entity.

3) Define the new metadata element in terms of the extended element information as described in 19115:2003/Cor 1:2006: name, definition, obligation, condition, maximumOccurence, dataType, and domainValue.


5) Register the new metadata entities and/or elements in a suitable namespace in the Department of Defense Metadata Registry.

A.2 Profiling the SDSFIE-M Conceptual Schema Profile

A.2.1 Introduction

The geospatial metadata elements specified in the SDSFIE-M Conceptual Schema Profile should be understood by all I&E community participants. However, not all I&E community participants will necessarily employ all of these geospatial metadata elements in their business practices.

The decision to employ a set of geospatial metadata elements is documented by specifying a profile of the SDSFIE-M Conceptual Schema Profile. In a profile, metadata elements may be selected from the SDSFIE-M Conceptual Schema Profile (and its extensions) and their use constrained through specifying obligations and business rules.

This section specifies how to establish and document a profile of the SDSFIE-M Conceptual Schema Profile.

A.2.2 Profile Structure

A profile of the SDSFIE-M Conceptual Schema Profile is a subset of that schema. The “structure” of such a profile is based on three principles, as follows:

1. The conceptual element is specified by its name and its definition as specified in the SDSFIE-M

Conceptual Schema.

2. A selected element may have zero or more business rules.

a. Business rules may restrict the use of an element from its specification in SDSFIE-M

Conceptual Schema Profile; it may never broaden its use. Possible restrictions include:

i. Reducing the number of instances of the element value that are permitted (by “tightening” the multiplicity of the element);

ii. Reducing its value domain in an allowable manner (e.g., by substituting a well-specified Codelist for a “free text” CharacterString); and/or

iii. Adding context-dependent use constraints.

The allowable types of business rules are specified in Section A.2.3.

b. If no business rule is specified then the use of the conceptual element in the profile is identical to its specification in the SDSFIE-M Conceptual Schema Profile.


154

c. It is a Recommended Practice that at least one business rule be established for each profiled element in order to ensure that the element is used in a manner intended by the designers of the profile. At a minimum “extension guidance” should be given by documenting a range of “good examples” of its use if a simple and clear rule cannot otherwise be established.

3. Profiled elements may be organized into sets in such a manner as to facilitate the specification of business rules that apply to “the set as a whole”. The basis for these groupings is the type of geospatial resource that those elements shall be used to document. The use of any metadata elements in a grouping is conditioned by a business rule dependent on the geospatial resource type. In effect, every element in the grouping has as additional business rules those specified for the “set as a whole”.

a. Element sets shall not violate the element structure of the SDSFIE-M Conceptual Schema Profile; if an element is a member of an element set, then any elements comprising its value domain are also members of that element set.

b. Element sets thus specified must form a complete and non-overlapping partitioning of the elements in the profile; i.e., every element of the profile must belong to exactly one element set.

This structure of a profile allows for the direct specification of a profile-conformance test suite.

A.2.3 Business Rules


Enterprises operate according to constraints which may be captured in the form of business rules. Those constraints can be context-sensitive and dynamic. Such business rules describe the operation of an enterprise and can relate to something as high a level as privacy or security, or as low a level as the derivation of a particular metadata element value. It is generally not appropriate to build such constraints routinely into implementation database structures or even interfaces. However, such rules are still important and must be discerned, documented and accommodated in such a way that implementers will not overlook their importance, requirements builders will fully understand their impact, and acquisition personnel will recognize their necessity. Such analysis and comment is facilitated by moving business rules out of data models and architectures, as well as determining and expressing the rules separately from the models. When the business rules are explicitly dealt with as part of the analysis process, they are more likely to be challenged and corrected in time to serve as guidance for developers.

There is a strong inclination on the part of creators of metadata to “fill in all the blanks.” If an element is available, people want to use it in a resource description. Applications should be designed to make evident that not every available element is necessarily appropriate for every resource type. Similarly, applications should provide assistance where possible in selection of an appropriate value for a particular metadata element. To the extent that metadata creation facilities are built into content-creation applications, the application may identify values for some elements more reliably than the user, sometimes by accessing Codelists online that tend to be more volatile (meaning that the entire list of possible values is not known and therefore may change) and present a maintenance burden within a more static document.


155

Ultimately, the richness of metadata descriptions will be determined by policies and best practices designated by the agency creating the metadata, and those policies and practices will be guided by the functional requirements of services or applications.

Business rules on metadata elements should therefore be described in any profile. The following sections provide guidance on the types of business results that can be expressed and give examples of these expressions.

A.2.3.2 Constraints on Primitive Values

Business rules may constrain the value of a non-complex data type (see Section 7.2) in one of the following manners:

Value assignment – e.g., specifying a CharacterString value to be exactly “Version 1.0” or a Codelist value to be “dataset”.

Value constraint – e.g., two or more specific allowed values from a more extensive Codelist.

Value range restriction – e.g., the value of Real x must satisfy the inequalities: -180 <= x <= 180.

Value construction/test – e.g., a CharacterString value for a telephone number must follow the ITU-T Recommendation E.123.

Value assignment recommended but not obligated – e.g., it is a Recommended Practice that the Codelist value “utf8” be used.

Value absence – e.g., absence of an element/value implies that there is no applicable value as opposed to the value simply being “unknown” to the process populating the element.

A.2.3.3 Constraints on Value Sets

Business rules may constrain the members of a set of values in one of the following manners:

Value set uniqueness – e.g., the set of resource publishers should not include any duplicates.

Value set ordering – e.g., the values must be listed in descending “priority” order, or in temporal order.

A.2.3.4 Constraints on Elements

Business rules may simultaneously constrain the values of multiple elements in one of the following manners:

Element co-dependency – e.g., exactly one of the elements {Minimum Bounding Rectangle, Bounding Polygon, Bounding Point} should be populated.

Element dependency – e.g., if one element takes on a specified value (for whatever reason) then another element must take on a specified value.

Element co-constraint – e.g., the set of Text Locale Elements should be populated (together) as “utf8” and “eng” and “USA”.

Business rules may constrain the multiplicity of elements in one of the following manners:

Element conditional obligation – e.g., specify an element obligation of Mandatory contingent on a specified criterion.


156

Element multiplicity constraint – e.g., may further constrain (“narrow”) the conceptual element multiplicity than is required “merely” by the element obligation (e.g., the conceptual element multiplicity may have been [0..*], the profile may then specify an element obligation of Mandatory, and a Business Rule further revise the profile element multiplicity to [1..2]).

A.2.3.5 General Constraints

Business rules may provide general guidance on the use of elements (and populating their value) in the following manner:

Implementation guidance – e.g., the choice of a Codelist to be used as the value domain of a Country Code, such as fips10-4/digraph or ISO 3166-1/trigraph.


157



158

Annex B – Data Types (Normative)

This section provides definitions for data types used in this document. Many of these types are documented by other external standards. References to those governing standards are included in the type definitions below.

Angle

Amount of rotation need to bring one line or plane into coincidence with another, generally measured in radians or degrees.

NOTE As specified by ISO /TS 19103.

Boolean

Truth enumeration whose domain of values are { TRUE, FALSE }, representing the true and false values in a two-valued logic system

CharacterString

Character string with optional character encoding and localization attributes

Codelist

Value domain including a code for each permissible value

NOTE It is an open enumeration that may be extended during system runtime by adding additional named literal values.

Date

Indication of date expressed as a year, year-month, or year-month-day

NOTE As specified by ISO 8601.

DateTime

Indication of time expressed as a year, year-month, year-month-day, or year-month-day and time of day

NOTE 1 As specified by ISO 8601. NOTE 2 Time of day expressed using a 24 hour clock.

Distance

Number that is the length between two points

NOTE As specified by ISO /TS 19103.

FileName

A class needed to support explicitly referencing an external file corresponding to a property containing the name of the file. This is valuable in the case of ISO 19139's MX_File class with regards to the fileName attribute. A human readable file name might be a useful value for population of this attribute, but the additional src attribute provided


159

by the FileName class can provide a machine-readable absolute path to the location of the file.

NOTE As specified by ISO/TS 19139:2005.

GenericName

An abstract class for the representation of a name in a namespace. A GenericName can be either a LocalName or a ScopedName. As defined in ISO19139:2007, the representation of generic names follows the following XML schema:

<xs:element name="featureTypes" type="gco:GenericName_PropertyType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="AbstractGenericName" type="gml:CodeType" abstract="true"/> <xs:complexType name="GenericName_PropertyType">

<xs:sequence minOccurs="0"> <xs:element ref="gco:AbstractGenericName"/>

</xs:sequence> <xs:attribute ref="gco:nilReason"/>

</xs:complexType> <xs:element name="LocalName" type="gml:CodeType" substitutionGroup="gco:AbstractGenericName"/> <xs:element name="ScopedName" type="gml:CodeType" substitutionGroup="gco:AbstractGenericName"/>

An instance corresponding to a featureTypes element might appear in the document as follows:

<featureTypes> <LocalName codeSpace = “http://www....”>building</LocalName>

</featureTypes>

(see ISO/TS19103:2005, Geographic information - Conceptual schema language, clause 6.5.6.3).

GF_AttributeType

Class of attribute definitions of a feature type.

NOTE As specified by ISO 19109. NOTE Part of the General Feature Model described in section 7.3.6.

GF_FeatureType

Textual information describing the concept of a feature type, containing all feature types.

NOTE As specified by ISO 19109. NOTE Part of the General Feature Model described in section 7.3.4

GF_PropertyType

Textual information related to the feature type because its text comprises characteristics and behavior of any property of a feature type, as well as its roles within associations between features.

NOTE As specified by ISO 19109. NOTE Part of the General Feature Model described in section 7.3.5


160

GM_Object

Root class of the geometric object taxonomy That supports interfaces common to all geographically referenced geometric objects.


GM_Point

0-dimensional geometric primitive, representing a position, but not having extent.


Integer

Whole number (a number that does not have a fractional part)

Measure

Result from performing the act or process of ascertaining the extent, dimensions, or quantity of some entity. This class is documented in full in ISO/TS 19103.

MimeFileType

A class needed to support identification of the file type using the mime media type name and subtype name. This is useful in the case of ISO 19139's MX_File class with regards to the fileType attribute. The value of the fileType attribute might be "JPEG" and the type attribute of the MimeFileType class allows for the machine-readable Mime type content-type expression such as "image/jpeg".

NOTE As specified by ISO/TS 19139:2005.

Number

Abstract class that can be sub-typed to a specific number type (real, integer, decimal, double, float). This class is documented in full in ISO/TS 19103.

Real

Number that is either rational or irrational

Record

A structure of logically related elements. This class is documented in full in ISO/TS 19103.

RecordType

A specification of the content and structure of a Record. This class is documented in full in ISO/TS 19103.

Scale

The ratio of one quantity to another, often unitless. This class is documented in full in ISO/TS 19103.

SC_CRS

Coordinate reference system which is usually single but may be compound.



161

SC_VerticalDatum

Set of parameters describing the relation of gravity-related heights to the Earth.


Set

Finite collection of objects, where each object appears in the collection only once. A set shall not contain any duplicated instances. The order of the elements of the set is not specified.


Sequence

A collection with ordering between its elements. Sequences can be repeated, and may be used as a list or an array.


TM_PeriodDuration

Duration of a period as specified by ISO 8601.


TM_Primitive

Abstract class representing a non-decomposed element of geometry or topology.


URI

CharacterString containing a Uniform Resource Identifier.

NOTE As specified in IETF RFC 2396.

URL

CharacterString containing a Uniform Resource Locator.

NOTE As specified in IETF RFC 1738.


162

Annex C – Abstract Test Suite (ATS) (Normative)

C.1 Abstract test suite

C.2 Introduction

The realization of standardization objectives for I&E community metadata at the conceptual level, as described in SDSFIE-M, is significantly facilitated by describing what it means to conform to the provisions of the foundational document, and specifying the criteria by which conformance with SDSFIE-M is measured. In the case of SDSFIE-M, conformance testing is the evaluation of profiles or implementation specifications of SDSFIE-M for the existence of specific characteristics required by SDSFIE-M, its cited standards, and its profiling rules in order to determine the extent to which that profile or specification is conformant.

This Abstract Test Suite (ATS) focuses on conformance of the features and capabilities of documents that qualify as profiles or implementation specifications of SDSFIE-M. A geographic information profile, as defined by the ISO 19100-series of standards, is a set of one or more base standards or subsets of base standards, and where applicable, the identification of chosen clauses, classes, options and parameters of those base standards. The ISO 19100-series geographic information standards allow the base standards to be extended in a configuration managed manner when necessary to accomplish a particular function not directly supported by the base standards. Data and service specifications describe the physical application of the conceptual data models defined in the base standards and their various conceptual profiles. Just as the SDSFIE-M profile of NMF (which is, in turn, a profile of ISO 19115:2003/Cor 1:2006) is extended to address the security requirements of metadata in the I&E community, profiles and specifications that use SDSFIE-M consist of a choice of the metadata elements available in the SDSFIE-M conceptual metadata model and may extend to include the requirements of another metadata specification.

Those testing (evaluating) documentation will check for conformance with SDSFIE-M and also with the standards and specifications that were used as normative documents in the construction of SDSFIE-M. In addition to required and optional metadata elements, and extensions to the metadata defined by the profile/specification, the profile/specification will be tested for conformance with SDSFIE-M rules for profiles.

The intent is to provide a high level of confidence that the profile/specification conforms to the provisions of SDSFIE-M. Conformance testing for SDSFIE-M does not include acceptance testing, performance testing or robustness testing, because SDSFIE-M and its normative documents do not establish requirements for these areas.

The SDSFIE-M ATS is represented as a hierarchical structure of abstract test modules and test cases. Each test case includes a test purpose, the test methods, and a general reference to the SDSFIE-M provision to be tested.


163

The ATS presented in this Annex applies to Part 1 of the SDSFIE-M multi-part standard.

C.3 Test Purpose

The overall purpose of the test is to evaluate the degree to which the documentation required to conform to SDSFIE-M is indeed conformant. Since SDSFIE-M conforms to both ISO 19115:2003/Cor 1:2006 and the IC.ADD (Chapters 2 and 3), the SDSFIE-M-derived documentation shall also conform to the provisions of ISO 19115:2003/Cor 1:2006 and IC.ADD (Chapters 2 and 3).

C.4 Test Methods

Conformance testing methodology uses a combination of test cases designed to address the ability of profile/specification to comply with SDSFIE-M. If the documentation can be defined as a profile of SDSFIE-M, it shall be tested not only for conformance with the appropriate metadata standard, but for conformance with SDSFIE-M business rules, rules for encoding, and mapping/transformation to external metadata standards. Such documentation will also be tested for compliance with the SDSFIE-M rules for profiles.

To manage the conformance testing of different forms of SDSFIE-M implementation, (e.g. profiles, schemas, or specifications for data, systems, services, etc.) SDSFIE-M assigns items to one of two conformance classes:

Conformance class 1: Any I&E community documentation that claims to conform to SDSFIE-M and that is a pure subset of SDSFIE-M shall be subjected to all test modules described in this annex, with the exception of the metadata extension test module.

Conformance class 2: Any I&E community documentation that claims to conform to SDSFIE-M and that extends SDSFIE-M beyond the metadata elements and entities listed in Part 1 shall be subjected to all test modules described in this annex.

Individual test cases will be applied to the evaluation of the documentation that will encapsulate one or more test purposes and associated test criteria. Abstract test cases are independent of both the implementation and the values. They are complete in the sense that they are sufficient to enable a test verdict to be assigned unambiguously to each potentially observable test outcome (i.e. sequence of test events).

Conformance requirements may be classified as:

a) mandatory requirements and profile rules: these shall be observed in all cases;

b) conditional requirements and profile rules: these shall be observed if the conditions set out in the specification apply;

c) optional requirements: these may be selected to suit the implementation, provided that any requirements applicable to the option are observed.

Furthermore, conformance requirements may be stated

a) positively: they state what is required to be done;

b) negatively: they state what is required not to be done (prohibitions).


164

C.5 Test case – SDSFIE-M -derived Profiles

The following test case will be used to evaluate conformance with SDSFIE-M standard metadata.

C.5.1 Test Purpose

Evaluate conformance of proposed profiles derived from SDSFIE-M with the profiling provisions of SDSFIE-M.

C.5.2 Test Method

Inspection via manual or automated means.

C.5.3 Test Criteria

1. An evaluation of registered SDSFIE-M profiles was conducted to validate the need for creating an additional profile of SDSFIE-M.

2. The profile is comprised only of elements selected from the SDSFIE-M Conceptual Schema (Conformance Class 1).

3. The profile is comprised only of elements selected from the SDSFIE-M Conceptual Schema and authorized extension elements (Conformance Class 2).

4. The profile does not change the name, definition, or data type of an SDSFIE-M conceptual element.

5. All selected elements have a specified obligation.

6. The obligation for ‘minimum’ SDSFIE-M elements is ‘mandatory’.

7. Each element with a ‘conditional’ obligation has one or more business rules to specify its use.

8. Elements with an ‘optional’ obligation may include business rules and recommended practices.

9. Business rules do not broaden the use of an element (or an element set) from its specification in the SDSFIE-M Conceptual Schema. (Note: Business rules may place constraints on primitive values, value sets, and elements. See Clause A.2.3, Business Rules.)

10. The profile does not specify any requirements that would contradict or result in non-conformance to the SDSFIE-M Conceptual Schema Profile.

11. Any specializations of relationships in a profile are compliant to the relationships specified in SDSFIE-M, attributes and relations are inherited from SDSFIE-M, and relations at the supertype level can be specialized to the subtype level. Any specialization of an attribute or relationship from a base standard in the profile are done so that an implementation of the relationship or attribute as defined in SDSFIE-M remains valid and data can be correctly interpreted by an implementation of SDSFIE-M alone.


165

12. When opting to organize profiled elements into one or more sets of elements; if an element is a member of an element set, then any elements comprising its value domain are also members of that element set.

13. When used, element sets form a complete and non-overlapping partitioning of the profiled elements such that every element of the profile belongs to exactly one element set.

14. The profile includes an explicit statement of the capabilities which have been included, specifically addressing the relevant optional capabilities and limits, so that the profile can be tested for conformance to the relevant requirements.

15. The profile inherits the conformance requirements of SDSFIE-M by including all relevant test suites given in the conformance clause of SDSFIE-M. If the profile uses more than one base standard, then the abstract test suites of all of the referenced parts are also applied.

C.6 Test Case – Extensions to the SDSFIE-M Conceptual Schema Profile

C.6.1 Test Purpose

Evaluate conformance of proposed extensions to the SDSFIE-M Conceptual Schema Profile with the provisions of SDSFIE-M for extensions

C.6.2 Test Method

Inspection via manual or automated means

C.6.3 Test Criteria

1. Each ‘extended’ metadata section, metadata entity, and/or metadata element is unique and not already defined in SDSFIE-M.

2. Extended metadata is selected from ISO 19115:2003/Cor 1:2006 and then other 19100-series standard metadata whenever possible.

3. Each extended entity and element specification defines all attributes specified for extensions, i.e. name, definition, obligation, multiplicity, data type and domain are specified.

4. Any extension defined within a profile, as permitted within the context established by SDSFIE-M, does not invalidate any implementation of SDSFIE-M alone. Any subdivision of an element defined in SDSFIE-M into additional sub-elements in the profile are done so that an implementation of SDSFIE-M can interpret the data without the additional subdivision in a manner that still conforms to the base SDSFIE-M.

5. Extended metadata elements are not used to change the name, definition or data type of an existing element.

6. Extended metadata may be defined as entities and may include extended and existing metadata elements as components.


166

7. An extension does not permit anything not allowed by the standard.

C.7 Test Case – Conformance with Established SDSFIE-M -Based Profiles

C.7.1 Test Purpose

Evaluate conformance with established profiles of the SDSFIE-M Conceptual Schema Profile

C.7.2 Test Method

Inspection via manual or automated means

C.7.3 Test Criteria

1. All metadata defined as mandatory, or conditional when the described conditions apply, are present.

2. Each metadata element occurs no more than the number of times specified by the profile’s ‘Multiplicity’ value.

3. The value of each provided metadata element adheres to the data type specified by the profile.

4. The value(s) of each element falls with the allowed ‘Value Domain’ specified by the profile.


167



168

Annex D – UML Primer (Informative)

D.1 UML notations

The diagrams that appear in this document are presented using the Unified Modeling Language (UML) static structure diagram with the ISO Interface Definition Language (IDL) basic type definitions and the UML Object Constraint Language (OCL) as the conceptual schema language. The UML notations used in this Standard are described in Figure 27.

Figure 27 : UML Notation

D.2 UML model relationships

D.2.1 Associations

An association is used to describe a relationship between two or more classes. UML defines three different types of relationships, called association, aggregation and composition. The three types have different semantics. An ordinary association shall be used to represent a general relationship between two classes. The aggregation and composition associations shall be used to create part-whole relationships between two classes. The direction of an association must be specified. If the direction is not specified, it is assumed to be a two-way association. If one-way associations are intended, the direction of the association can be marked by an arrow at the end of the line.

Generalization

Dependency

Aggregation

Composition

Association


169

An aggregation association is a relationship between two classes in which one of the classes plays the role of container and the other plays the role of a containee.

A composition association is a strong aggregation. In a composition association, if a container object is deleted, then all of its containee objects are deleted as well. The composition association shall be used when the objects representing the parts of a container object cannot exist without the container object.

D.2.2 Generalization

A generalization is a relationship between a superclass and the subclasses that may be substituted for it. The superclass is the generalized class, while the subclasses are specified classes.

D.2.3 Instantiation / Dependency

A dependency relationship shows that the client class depends on the supplier class/interface to provide certain services, such as:

- Client class accesses a value (constant or variable) defined in the supplier class/interface;

- Operations of the client class invoke operations of the supplier class/interface; - Operations of the client class have signatures whose return class or arguments

are instances of the supplier class/interface.

An instantiated relationship represents the act of substituting actual values for the parameters of a parameterized class or parameterized class utility to create a specialized version of the more general item.

D.2.4 Roles

If an association is navigable in a particular direction, the model shall supply a “role name” that is appropriate for the role of the target object in relation to the source object. Thus in a two-way association, two role names will be supplied. Figure G-2 represents how role names and cardinalities are expressed in UML diagrams.


170

Figure 28 : UML Roles

D.3 UML model stereotypes

A UML stereotype is an extension mechanism for existing UML concepts. It is a model element that is used to classify (or mark) other UML elements so that they in some respect behave as if they were instances of new virtual or pseudo metamodel classes whose form is based on existing base metamodel classes. Stereotypes augment the classification mechanisms on the basis of the built-in UML metamodel class hierarchy. Below are brief descriptions of the stereotypes used in this document.

In this document the following stereotypes are used:

a. <<Type>> class used for specification of a domain of instances (objects), together with the operations applicable to the objects. A type may have attributes and associations.

b. <<Enumeration>> data type whose instances form a list of named literal values. Both the enumeration name and its literal values are declared. Enumeration means a short list of well-understood potential values within a class.

c. <<DataType>> a descriptor of a set of values that lack identity and whose operations do not have side effects. Datatypes include primitive pre-defined types


171

and user-definable types. Pre-defined types include numbers, string, and time. User-definable types include enumerations.

d. <<CodeList>> used to describe a more open enumeration. <<CodeList>> is a flexible enumeration. Code lists are useful for expressing a long list of potential values. If the elements of the list are completely known, an enumeration should be used; if the only likely values of the elements are known, a code list should be used.

e. <<Union>> describes a selection of one of the specified types. This is useful to specify a set of alternative classes/types that can be used, without the need to create a common super-type/class.

f. <<Abstract>> class (or other classifier) that cannot be directly instantiated. The UML notation for this is to show the name in italics.

g. <<Leaf>> package that contains definitions, without any sub-packages.

D.4 Package abbreviations

Two letter abbreviations are used to denote the package that contains a class. Those abbreviations precede class names, connected by a “_”. The standard that those classes are located in is indicated in parentheses. A list of those abbreviations follows.

CC Changing Coordinates (ISO 19111)

CI Citation (ISO 19115)

DQ Data quality (ISO 19115)

DS Dataset (ISO 19115)

EX Extent (ISO 19115)

FC Feature Catalogue (ISO 19110)

FE Feature (ISO 19109)

FT Feature Topology (ISO 19107)

GF General Feature (ISO 19109)

GM Geometry (ISO 19107)

LI Lineage (ISO 19115)

MD Metadata (ISO 19115)

RS Reference System (ISO 19115)

SC Spatial Coordinates (ISO 19111)

SV Services (ISO 19119)

TM Temporal (ISO 19108)

TP Topology (ISO 19107)


172

Bibliography

[1] ISO 639-2:1998, Codes for the representation of names of languages – Part 2: alpha-3 code

[2] ISO 3166-1:1997, Codes for the representation of names of countries and their subdivisions – Part 1: Country code

[3] ISO 3166-2:2007, Codes for the representation of names of countries and their subdivisions – Part 2: Country subdivision code

[4] ISO 3166-3:1999, Codes for the representation of names of countries and their subdivisions – Part 3: Code for formerly used names of countries

[5] ISO 4217:2001, Codes for the representation of currencies and funds

[6] ISO 15836:2003, Information and documentation - The Dublin Core Metadata Element Set, Version 1.1, 18 Dec 06, published by the Dublin Core Metadata Initiative (DCMI) (http://dublincore.org/)

[7] ISO/TS 19101-2:2008, Geographic information – Reference model – Part 2: Imagery

[8] ISO/TS 19103:2005, Geographic information – Conceptual schema language

[9] ISO 19105:2000, Geographic information – Conformance and Testing

[10] ISO 19106:2004, Geographic information – Profiles

[11] ISO 19111:2007, Geographic information – Spatial referencing by coordinates

[12] ISO 19114:2003, Geographic information – Quality evaluation procedure

[13] ISO/DIS 19115-2:2009, Geographic information – Metadata – Part 2: Extensions for imagery and gridded data

[14] ISO 19119:2005, Geographic information – Services

[15] ISO 19119:2005/Amd.1:2008, Geographic information – Services

[16] ISO 19123:2005, Geographic information – Schema for coverage geometry and functions

http://dublincore.org/


173

[17] ISO 19139:2007, Geographic information – Metadata – XML schema implementation

[18] ISO 19135:2005, Geographic information – Procedures for registration of geographic information items

[19] ISO 19136:2007, Geography Markup Language (GML)

[20] NSG Metadata Implementation Specification (NMIS), version 2.1

[21] Intelligence Community Technical Specification 500.D.V2, Abstract Data Definition (IC.ADD.V2)

[22] Department of Defense Discovery Metadata Specification (DDMS), version 4.0, 11 November 2011 (https://metadata.ces.mil/mdr/irs/ddms/)

[23] Geospatial Intelligence (GEOINT) Basic Doctrine, Publication 1.0, National System for Geospatial Intelligence, National Geospatial-Intelligence Agency (NGA), September 2006

[24] Geospatial Intelligence Support to Joint Operations, Joint Publication 2-03, Joint Chiefs of Staff, 22 March 2007

[25] NSG Statement of Strategic Intent, National System for Geospatial Intelligence, National Geospatial-Intelligence Agency (NGA), March 2007

[26] Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense, DoD Directive 8320.02, US Department of Defense, August 5, 2013

[27] Guidance for Implementing Net-Centric Data Sharing, DoD 8320.02-G, US Department of Defense, 12 April 2006

[28] Business Enterprise Architecture (BEA) Compliance Guidance, US Department of Defense, Business Transformation Agency (BTA), 10 April 2006

[29] Concept of Operations for the DoD Metadata Registry, Defense Information Systems Agency (DISA), version 1, 1 February 2007

[30] OMB Circular A-119, Federal Participation in the Development and Use of Voluntary Consensus Standards and in Conformity Assessment Activities, Revised 10 February 1998

[31] NATO STANAG 7074, Digital Geographic Information Exchange Standard (DIGEST), Digital Geospatial Information Working Group (DGWIG), Edition 2.1


174

[32] DT Metadata – Draft Implementing Rules for Metadata, Infrastructure for Spatial Information in Europe (INSPIRE), D1.3, 2 Feb 07

[33] MIL-STD-2500C, National Imagery Transmission Format (NITF), version 2.1, for the National Imagery Transmission Format Standard (NITFS), 1 May 2006 (http://www.gwg.nga.mil/ntb/)

[34] Imagery Product Library (IPL) Access and Discovery: Common Data Requirements for Interoperability, National Geospatial-Intelligence Agency (NGA), 31 Mar 2006 (available upon request)

[35] NATO STANAG 7023 NATO Primary Image Format, Edition 3, 16 Sept 2004 (http://www.nato.int/structur/AC/224/standard/7023/7023.htm)

[36] ITU-T Recommendation E.123, Notation for national and international telephone numbers, e-mail addresses and Web addresses, Recommendation E.123

http://www.gwg.nga.mil/ntb/

http://www.nato.int/structur/AC/224/standard/7023/7023.htm

SDSFIE Metadata (SDSFIE-M): Conceptual Schema · 28/8/2014 · M) is a standard which defines the...

Documents

Transcript of SDSFIE Metadata (SDSFIE-M): Conceptual Schema · 28/8/2014 · M) is a standard which defines the...