SDSFIE-M Implementation Guidance › Documents › SDSFIE-M-Implementatio… · Geospatial data can...

Spatial Data Standards for Facilities,

Infrastructure, and Environment (SDSFIE)

SDSFIE Metadata (SDSFIE-M): Implementation Guidance

FINAL

Version 2.0 (10 JUN 2020)

Prepared By: The IGI&S Governance Group

For: The Assistant Secretary of Defense (Sustainment)

© 2020

10 JUN 2020 FINAL SDSFIE M: Implementation Guidance v2.0

i

THIS PAGE IS INTENTIONALLY BLANK


2

Executive Summary This document contains implementation guidance for the Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) - Metadata standard, or SDSFIE-M. SDSFIE-M is a community standard for geospatial metadata, registered in the DoD IT Standards Registry (DISR). SDSFIE-M is a profile of the National System for Geospatial-Intelligence (NSG) Application Schema (NAS) by virtue of the fact that NAS 8.0 contains the most current ISO metadata baseline required by SDSFIE-M.

SDSFIE-M is applicable to (and mandated for use by) the Installation Geospatial Information and Services (IGI&S) user community, as defined in DoD Instruction (DoDI) 8130.01. This standard is intended to describe IGI&S spatial data holdings and services (e.g. those structured according to the Spatial Data Standard for Facilities, Infrastructure, and Environment-Vector (SDSFIE-V)).

This document defines the general requirement for IGI&S metadata and expresses, as a series of rules, other implementation requirements for SDSFIE-M such as the need for metadata to be accessible, the requirement to establish milestones and deadlines for the implementation of SDSFIE-M mandated versions, and the need for Components to develop their own implementation plans.

Information security is a very important data element addressed through metadata. This document provides rules concerning how information security markings shall be expressed for both metadata and the resources that the metadata describes.

Geospatial metadata is best created and maintained via automated tools. This document includes a rule that any implementation tool developed by an IGG member organization must conform to the rules defined in this guidance.


3

Revision History

Description Date Version Revision Initial IGG Approved Version 8 SEP 2015 1.0 0

Revision for SDSFIE-M 2.0 10 JUN 2020 2.0 0


4

Table of Contents Executive Summary ................................................................................................................................... 2

1 Overview .......................................................................................................................................... 6

2 Requirement for IGI&S Metadata ..................................................................................................... 6

3 Rules for Implementing SDSFIE-M .................................................................................................. 7 4 Metadata Content Best Practices and Rules ................................................................................. 10

4.1 Title, Abstract, Purpose, and Status ..................................................................................................... 10 4.1.1 Title .................................................................................................................................................. 10 4.1.2 Abstract ........................................................................................................................................... 10 4.1.3 Purpose ........................................................................................................................................... 11 4.1.4 Status .............................................................................................................................................. 11

4.2 Responsible Party Information ............................................................................................................. 11 4.3 Contact and Point of Contact Information ............................................................................................. 12

4.3.1 Responsibility Role .......................................................................................................................... 12 4.4 Establish and Document Web Services ............................................................................................... 12 4.5 Constraint Information .......................................................................................................................... 14

4.5.1 General Constraint Information........................................................................................................ 15 4.5.2 Resource Constraint Information ..................................................................................................... 15

5 Metadata Tools .............................................................................................................................. 23 5.1 SDSFIE-M Metadata Style for ArcGIS .................................................................................................. 24

6 References ..................................................................................................................................... 24

7 Definitions ...................................................................................................................................... 24

8 Abbreviations ................................................................................................................................. 25

9 Versioning Lifecycle States ............................................................................................................ 26


5

THIS PAGE IS INTENTIONALLY BLANK


6

1 Overview This document contains implementation guidance for the Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) - Metadata standard, or SDSFIE-M. SDSFIE-M is a community standard for geospatial metadata, registered in the DoD IT Standards Registry (DISR) and is a profile of the National System for Geospatial-Intelligence (NSG) Application Schema (NAS)1.

SDSFIE-M is applicable to (and mandated for use by) the Installation Geospatial Information and Services (IGI&S) user community, as defined in DoD Instruction (DoDI) 8130.01. This standard is intended to describe IGI&S spatial data holdings and services (e.g. those structured according to the Spatial Data Standard for Facilities, Infrastructure, and Environment-Vector (SDSFIE-V)).

Geospatial data can take many forms, making rapid search and discovery difficult. This is the reason why DoD developed the SDSFIE-M standard. The structure of SDSFIE-M supports the goals of making IGI&S data discoverable by automated means, understandable to users, and thus more trusted for DoD missions and decision making. By making IGI&S data discoverable, understandable, and trusted we provide users and managers the data awareness they need to prevent duplicative data acquisition. This allows DoD to focus scarce resources on acquiring only that data which is truly needed, and focuses data maintenance effort where it will provide the most cost-effective benefit to the enterprise.

2 Requirement for IGI&S Metadata In accordance with DoDI 8320.02 and as implemented by DoDI 8130.01 (with respect to IGI&S), all DoD IT resources shall be made discoverable, understandable, and trusted to the extent allowed by law and policy. These policies also support the goals of several federal statutes including the Open, Public, Electronic, and Necessary (OPEN) Government Data Act (2018) and the Geospatial Data Act of 2018. DoDI 8320.02 furthermore establishes the requirement that all DoD activities implement the applicable standards cited in the DoD IT Standards Registry (DISR), and that all authoritative data sources (ADSs) must be formally established and governed according to processes defined in DoDI 8320.07. The IGI&S ADS requirement, described in DoDI 8130.01 and further defined in the IGI&S ADS Implementation Guidance (2019), is an ADS which specifically applies to spatial data resources support DoD installations. In all cases, a key element of how ADSs function is the existence of current, complete, and accurate metadata.

Taken together these policies establish the mandate that DoD organizations which create or maintain IGI&S must conform to the SDSFIE standards that are registered in the DISR, including the SDSFIE-V and SDSFIE-M standards. SDSFIE-M records must be created for each applicable SDSFIE-compliant data set or geospatial service within DoD, and these records must be made discoverable within the Joint Information Enterprise as directed by the policy statements contained in DoDI 8130.01. SDSFIE-M records may also be created for other IGI&S data sets or services, at the discretion of the authoring organization.

To maintain interoperability and to establish a coordinated approach to IGI&S, each DoD Component shall follow the common guidance contained in this document to implement SDSFIE-M. The key elements of this guidance include:

• General rules that govern the implementation of SDSFIE-M (section 3).

• Rules and guidance pertaining specifically to metadata and resource constraints (section 4).

• Implementing guidance pertaining to automated metadata tools, specifically the SDSFIE-M Metadata Style for ArcGIS (section 4.5.2.2.1).

1 For additional details see the SDSFIE-M 2.0 conceptual schema document, https://www.sdsfieonline.org/Standards/Metadata#SDSFIE-M

https://www.sdsfieonline.org/Standards/Metadata#SDSFIE-M


7

• Metadata implementation references (section 6).

3 Rules for Implementing SDSFIE-M The IGI&S Governance Group (IGG) shall govern the implementation of SDSFIE-M in accordance with these rules:

Rule 3-1 Applicability

1) All DoD organizations subject to IGI&S standards (as defined in DoDI 8130.01) and that implement SDSFIE-M must conform to this implementation guidance.

2) This document (and its revisions) applies to all Mandated or Emerging versions of SDSFIE-M. It also applies to all Retired SDSFIE-M versions. See section 9 for the definition of Emerging, Mandated, and Retired.

Rule 3-2 SDSFIE-M Versioning2

1) SDSFIE-M shall employ a three-level version pattern where major, minor, and corrigendum versions are specified using integers, separated by periods (for example, 1.0.2). Until a corrigendum release exists, a two-level version pattern (for example, 2.0) will be used in practice.

2) Revisions of SDSFIE-M are defined as follows: a. A major revision re-structures metadata elements in such a way that would significantly

change the organization of existing implementation files. This type of change might occur when revising SDSFIE-M to conform to a new ISO metadata standards baseline. The initial version of a major revision has minor (and corrigendum) version set to zero.

b. A minor revision is one where the changes do not significantly change the organization of existing implementation files. This type of change might occur when new capability is added to SDSFIE-M through the introduction of one or more new elements. For example, extending the MD_FeatureCatalogue element to include attribute, enumeration, and enumerant information would likely require a new minor revision. The version attribute shall use the Major.Minor version number initially set at 0 and shall be incremented after each minor version (e.g., 2.0 to 2.1).

c. A corrigendum, defined as a “bug-fix”, is used to correct errors in previous versions with the same Major.Minor version designation. The version attribute shall use the complete Major.Minor.Corrigendum version number initially set at 0 and shall be incremented after each bug fix (e.g., 4.0 to 4.0.1 or 4.1.2 to 4.1.3).3

3) Only major and minor revisions will be considered as triggers for changing the specification’s status in the DISR.

4) The IGG shall determine when to recommend changing the lifecycle status of a version to Emerging or Mandated.

Rule 3-3 Mandated SDSFIE-M Version Milestones

1) As a condition of mandating an SDSFIE-M version, milestones and deadlines for the implementation of the standard shall be developed by the IGG. The IGG will forward these recommended milestones

2 The process of creating a new version is outlined in the SDSFIE Governance Plan, Revision 3, DISDI Program, 21 JAN 2019, https://metadata.ces.mil/dse/ns/DISDI/sdsfie 3 This versioning scheme is widely used for GEOINT standards and is specified in “Policy Directives for Writing and Publishing OGC Standards, Section 13, Document 06-135r7, Open Geospatial Consortium, 15 June, 2009.

https://metadata.ces.mil/dse/ns/DISDI/sdsfie


8

and deadlines to the ASD(S) in accordance with DoDI 8130.01. The following milestones (each of which should have a deadline) are necessary, as a minimum:

a) Completion (including IGG acceptance) of an XML implementation schema or SDSFIE-M Implementation Schemas (SMIS).

b) Development of implementation tools such as an ArcGIS Metadata Style, or equivalent.

c) Completion of Component implementation plans as defined in rule 3-4.

d) Milestone(s) for when all Components shall have complete metadata records for all applicable IGI&S data or services; this may be a sequence of milestones (e.g. percent completion goals) and may vary based on the type of data (i.e. vector, raster, services).

Rule 3-4 Component Implementation Plans

1) Within nine months of a Major version being mandated, or six months of a Minor version, Components shall develop an SDSFIE-M implementation plan aligning to the milestones and deadlines developed under Rule 3-3. Components may use one or more documents, but must include the following content (often referred to as a plan of action and milestones or POAM):

a) Metadata Development Plan and Schedule

i) A high-level description of the plan for developing metadata for their undocumented or newly created data holdings.

ii) A schedule for the metadata development.

b) Metadata Migration Plan and Schedule

i) A high-level description of the plan for migrating existing metadata from the current version (or a previous standard) to the new version.

ii) A schedule for the metadata migration.

2) Components shall submit their implementation plans to the IGG Chair, who will review and validate that the plans conform to this implementation guidance. Initial review comments or validation will be returned within 30 days of submission.

3) After first informing the Component and allowing not less than two weeks for their response, the IGG Chair shall inform the IGG of the results of this review in a timely manner.

4) Components may formally request an exception to the required milestones and deadlines to the IGG Chair, who shall follow the consensus process defined in the SDSFIE Governance Plan.

Rule 3-5 Existence of Metadata

1) All IGI&S data holdings shall be documented with SDSFIE-M compliant (the current DISR Mandated version) metadata unless the data is classified.

a) This requirement is intended to apply to all vector and raster data produced directly by or for the Components, as well as geospatial services provided by them.

b) This requirement is not intended to apply to data created for one-time, project-specific requirements (for example, those not standardized by SDSFIE).

2) Classified IGI&S data holdings shall be documented using NSG Metadata Foundation (NMF) compliant metadata (the current DISR Mandated version).


9

3) IGI&S data holdings designated as Controlled Unclassified Information (CUI) shall be documented using SDSFIE-M and must contain security constraint elements defined by this Implementation Guidance, in accordance with applicable DoD-level and Component-level data classification and handling guidance.

4) Metadata is required at the dataset (feature or object type), aggregate, and repository levels only.

a) This requirement is not intended to apply to feature level metadata.

Rule 3-6 Accessibility of Metadata; Support to Discovery

1) Components shall make metadata records accessible to the DoD IGI&S enterprise via the Defense Installations Spatial Data Infrastructure (DISDI) Program either statically or dynamically.

2) If the Component provides records statically, they shall be delivered annually as valid4 SDSFIE-M Implementation Schema (SMIS) documents to the DISDI Program for cataloging on the DISDI Portal.

3) If the Component provided records dynamically, they shall be maintained in an enterprise-accessible catalog that is registered with and searchable from the DISDI Portal by federation or other technique.

Rule 3-7 Component-level Governance

1) Component-level governance is the responsibility of the Component's IGI&S Program Manager.

2) A key element of the Component-level governance is the existence of written implementation guidance (may be part of the Component’s SDSFIE-M implementation plan or other guidance) which has been reviewed and validated by the IGG Chair.

Rule 3-8 Implementation Scorecard Inputs

The SDSFIE Governance Plan (SGP) defines an Implementation Scorecard as a mechanism for Components to report status of implementation of SDSFIE. The SGP also requires that the implementation guidance for each part define both the metrics required to achieve the Red, Yellow and Green status levels. The metrics associated with each reporting level for SDSFIE-M are as follows5:

Rule 3-9 SMIS Document Content

4 XML validation is the process of checking a document written in XML (eXtensible Markup Language) to confirm that it is both well-formed and also "valid" in that it follows a defined structure. A well-formed document follows the basic syntactic rules of XML, which are the same for all XML documents. Valid means that the XML document follows the structure of SMIS schema hosted at http:/www.sdsfieonline.org/smis/version, where version is the currently mandated version of the SMIS. This structural validation is determined using a validating parser or validation tool to read the document and compare it against the schema. 5 Note that each level builds on the previous level. For example, to attain the Yellow reporting level, a Component Implementation Plan is also required.

Green: Metadata (compliant) is available for at least 95% of IGI&S data holdings (per Rule 3-5 and Rule 3-6).

Metadata (compliant) is available for at least 50% of IGI&S data holdings (per Rules 3-5 and 3-6), and Component-level governance is in place as defined in the Component Implementation Plan (per Rule 3-7).

Red: A Component Implementation Plan exists and is validated (per Rule 3-4).

Gray: No implementation plan exists (per Rule 3-4).


10

1) SDSFIE-M Implementation Schema (SMIS) documents shall include all mandatory and applicable conditional elements.

4 Metadata Content Best Practices and Rules This section contains a series of best practices and rules that guide the implementation of SDSFIE-M.

4.1 Title, Abstract, Purpose, and Status

This section is adapted from the Federal Geographic Data Committee’s (FGDC) Geospatial Metadata Guidelines and has been tailored to meet the requirements of the IGI&S community.

4.1.1 Title [MD_Metadata.identificationInfo.MD_Identification.citation.CI_Citation.title]

A title element is mandatory for all metadata records.

The title for SDSFIE-V feature classes should reflect the SDSFIE-V feature class name, at a minimum.

A title element for non-SDSFIE-V data should be descriptive and distinctive. The title element provides future data consumers a good sense of the resource content and context and enables them to distinguish among similar resources. According to the FGDC guidance, title elements should not try to replace an abstract or purpose element, but they should strive to relay the what, when, where and, if relevant, who, why, and how of the resource answering the following questions:

• What feature or feature collection does the resource represent?

• When did the content occur or when was it captured?

• Where is the content located on the earth?

• Who is the authority and source for the resource?

• Why was the resource created?

• How is the resource formatted?

Here is an example of such a title:

Desert tortoise siting polygons (exact locations obfuscated) on Fort Irwin collected via various techniques and reports, Geographic NAD83, Fort Irwin DPW Environmental Division, last modified 2020

4.1.2 Abstract [MD_Metadata.identificationInfo.MD_Identification.abstract]

An abstract element is mandatory for all metadata records.

The abstract for SDSFIE-V feature classes should reflect the SDSFIE-V definition, and, optionally, the description and note, if they exist.

Non-SDSFIE-V data should have an abstract element that provides the information necessary for data consumers to assess the relevance of an available data resource to their specific data needs. According to FGDC guidelines, to meet this objective, the abstract should include:

• a general description of the data resource content and features

• the form of the data resource, e.g. GIS, imagery, database, service, application, etc.

• the purpose for which the data resource was developed

• relevant place names and references


11

• the time period of the data resource content

• the scale/resolution of the resource

• information about special data characteristics or limitations, e.g. data access limitations, excluded geographies or content, completeness, etc.

Abstract elements should not be more than several paragraphs in length. Furthermore, an abstract element should not contain large sections of text cut and pasted wholesale from document sources. Such sources should, instead, be referenced using an additional documentation element (MD_Metadata.identificationInfo.MD_Identification.additionalDocumentation).

4.1.3 Purpose [MD_Metadata.identificationInfo.MD_Identification.purpose]

A purpose element is optional for metadata records.

The purpose for SDSFIE-V feature classes should reflect the SDSFIE-V justification, if it exists.

Non-SDSFIE-V data should have a purpose element that reflects the purpose for which the data was collected and should not be more than several paragraphs in length. Furthermore, purpose elements should not contain large sections of text cut and pasted wholesale from document sources. Such sources should, instead, be referenced using an additional documentation element (MD_Metadata.identificationInfo.MD_Identification.additionalDocumentation).

4.1.4 Status [MD_Metadata.identificationInfo.MD_Identification.status]

A status element is mandatory for all metadata records.

Status elements should reflect the lifecycle status of the resource with respect to its completion. The values of this element are taken from the MD_ProgressCode codelist.

4.2 Responsible Party Information

Responsible party elements are used in several locations within SDSFIE-M metadata documents, including:

• Metadata contact element [MD_Metadata.contact]

• Resource metadata element [MD_Metadata.identificationInfo.MD_Identification.pointOfContact]

• Resource Specific Usage User Contact Information element [MD_Metadata.identificationInfo.MD_Identification .resourceSpecificUsage.MD_Usage.userContactInfo]

• Process Step Processor element [MD_Metadata.resourceLineage.LI_Lineage.processStep or .LISource.sourceStep .LI_ProcessStep.processor] or [MI_Metadata.resourceLineage.LI_Lineage.processStep or .LISource.sourceStep .LE_ProcessStep.processor]

• Maintenance Contact element [MD_Metadata.metadataMaintenance or [MD_Metadata.identificationInfo.MD_Identification.resourceMaintenance .MD_MaintenanceInformation.contact]

• Distributor Contact element [MD_Metadata.distributionInfo.MD_Distribution.distributor .MD_Distributor.distributorContact]


12

• Format Distributor Contact element [.MD_Format.formatDistributor.MD_Distributor.distributorContact]

• Any Citation’s Cited Responsible Party element [.CI_Citation.citedResponsibleParty]

• Acquisition Platform Sponsor element [.MI_Platform.sponsor]

• Acquisition Requirement Requestor element [.MI_ Requirement.requestor]

• Acquisition Requirement Recipient element [.MI_Requirement.recipient]

• Acquisition Revision Responsible Party element [.MI_Revision.responsibleParty]

Rule 4-1 Responsible Party Element Always Organizational

1) Responsible party elements shall be an organization and NOT an individual. This means that all sub elements can only reference an organization, including the name, address (of all types, including electronic mail addresses), and phone.

4.3 Contact and Point of Contact Information

This section is adapted from FGDC Geospatial Metadata Guidelines and has been tailored to meet the requirements of the IGI&S community. This section applies to:

• Metadata contact element [MD_Metadata.contact]

• Resource Point of Contact element [MD_Metadata.identificationInfo.MD_Identification.pointOfContact]

Both are mandatory elements designating identification of, and means of communication with, person(s) and organization(s) associated with the metadata and the resource(s).

These elements must follow the rules from section 4.2 and in this section.

4.3.1 Responsibility Role [.CI_Responsibility.role]

The responsibility role is a mandatory element of both contact and point of contact elements.

Rule 4-2

1. The role element within the containing metadata contact or resource point of contact element shall carry the responsibility role of pointOfContact.

4.4 Establish and Document Web Services

This section is adapted from FGDC Geospatial Metadata Guidelines and has been tailored to meet the requirements of the IGI&S community.

Web services play a key role in the emerging ADS Reference Architecture and they allow users to access data, layers, and maps in two ways:

• Application services (tools) that run in a browser so users can perform useful tasks

• Web services that a developer integrates into their own application, through standards-based application program interfaces (APIs).


13

In the future, Components are expected to establish web services6 for their geospatial data and to document them in a manner that enables users to access and ingest those services.

SDSFIE-M allows for the documentation of services as:

• a Service Identification within a dataset metadata record

• a Distribution Method within a dataset metadata record or

• a stand-alone Service (vs dataset) metadata record.

By creating a stand-alone service metadata record, the metadata for datasets hosted by the service, current and future, can be linked to the same service metadata record and information about the service is maintained and updated in a central location.

Most existing metadata creation workflows do not include the creation of stand-alone service metadata records. Components are encouraged to incorporate the production of service metadata records into their workflow. Until then, service information should be added to existing dataset metadata records within the Online Resource component of any of the following:

• Data Citation [MD_Metadata.identificationInfo.MD_Identification.citation .CI_Citation.onlineResource]

• Distribution Transfer Option [MD_Metadata.distributionInfo.MD_Distribution.transferOptions .MD_DigitalTransferOptions.onlineResource]

• Distribution Distributor [MD_Metadata.distributionInfo.MD_Distribution.distributor .MD_Distributor.distributorTransferOptions .MD_DigitalTransferOptions.onlineResource]

This metadata for a web service should include:

1. A name for the service.[(xpath from above).CI_OnlineResource.name]

2. A description that outlines the purpose and content of the service. [(xpath from above).CI_OnlineResource.description]

3. An actionable (i.e., online and consumable) service endpoint URL that provides direct access to the geospatial web service of the specified resource type. The URL must enable uniform and reliable access to a dataset as maps and layers via online services that are compliant with the OGC WMS and/or Esri REST API specifications. If there are multiple services for an individual dataset, all the endpoint URLs for map services that host the dataset should be documented. [(xpath from above).CI_OnlineResource.linkage]

4. The URI that uniquely identifies the appropriate service application profile specification associated with the geospatial web service. The following specifications are based on the OGC online resource naming scheme for identifying persistent names for online resources. [(xpath from above).CI_OnlineResource.applicationProfile]

6 In order for Components to meet a high-level of maturity in their ADS (see IGI&S ADS Implementation Guidance, https://rsgisias.crrel.usace.army.mil/disdiportal/DISDI_PORTAL_PROD.download_file?p_doc_id=41375) implementation, web services are required

https://rsgisias.crrel.usace.army.mil/disdiportal/DISDI_PORTAL_PROD.download_file?p_doc_id=41375


14

a. OGC Web Map Service (WMS) http://opengis.net/spec/wms a service compliant with an approved OGC Web Map Service implementation specification, or specific version, e.g., OGC Web Map Service version 1.1: http://opengis.net/spec/wms/1.1

b. OGC Web Feature Service (WFS) http://opengis.net/spec/wfs a service compliant with an approved OGC Web Feature Service implementation specification, or specific version, e.g., OGC Web Feature Service version 1.0: http://opengis.net/spec/wfs/1.0

c. OGC Web Coverage Service (WCS) http://opengis.net/spec/wcs a service compliant with an approved OGC Web Coverage Service implementation specification, or specific version, e.g., OGC Web Coverage Service version 1.0: http://opengis.net/spec/wcs/1.0

d. OGC Web Map Tile Service (WMTS) http://opengis.net/spec/wmts a service compliant with an OGC Web Map Tile Service implementation specification, or specific version, e.g., OGC Web Map Tile Service 1.0.0: http://opengis.net/spec/wmts/1.0.0

e. OGC Catalog Service (CSW) http://opengis.net/spec/csw a service compliant with an OGC Catalog Service for the Web implementation specification, or specific version, e.g., OGC Catalogue Service Specification 2.0.2: http://opengis.net/spec/csw/2.0.2

f. OGC Keyhole Markup Language (KML) http://opengis.net/spec/kml a service that produces a document that is compliant with the OGC Keyhole Markup Language specification, or specific version, e.g., OGC Keyhole Markup Language version 2.2: http://opengis.net/spec/kml/2.2

g. Esri REST Map Service http://www.geoplatform.gov/spec/esri-map-rest a service compliant with the Esri ArcGIS Map Server REST API.

h. Esri REST Image Service http://www.geoplatform.gov/spec/esri-image-rest a service compliant with the Esri ArcGIS Image Server REST API.

i. Esri REST Feature Service http://www.geoplatform.gov/spec/esri-feature-rest a service compliant with the Esri ArcGIS Feature Server REST API.

4.5 Constraint Information

[MD_Metadata.metadataConstraints] for constraints on metadata or [MD_Metadata.identificationInfo.MD_Identification.resourceConstraints] for constraints on resources.

http://opengis.net/spec/wms/1.1

http://opengis.net/spec/wfs/1.0

http://opengis.net/spec/wcs/1.0

http://opengis.net/spec/wmts/1.0.0

http://opengis.net/spec/csw/2.0.2

http://opengis.net/spec/kml/2.2


15

This section contains guidance concerning the marking of metadata and resources with information about constraints. The constraints apply only to UNCLASSIFIED data, to include the expression of CUI markings (see Rule 3-5.2) as well as other access and use constraints. Additionally, the constraints are NOT intended to classified national security information (CNSI) or to support an automated access determination.

To document access and use requirements in SDSFIE-M, constraint information is used to describe the constraints placed on the resource as well as on the metadata itself. These must be included even if the constraint simply states that the information is UNCLASSIFIED and has no use or access restrictions.

4.5.1 General Constraint Information Every constraint, whether a security or a legal constraint, can contain the following information elements (as appropriate).

4.5.1.1 Use Limitation [.useLimitation]

Use limitation elements are optional and each contains an explanation of a limitation affecting the fitness for use of the resource or metadata. For example, a use limitation on a military training route corridor dataset might be “Not to be used for navigation.”

4.5.2 Resource Constraint Information [.ResourceConstraints]

The resource constraint elements enable the expression of CUI markings as well as use and access restrictions for a resource or metadata. Access constraints and use constraints are both drawn from a codelist that details the type of restriction on access and use, respectively. Also included in the are textual description of the access or use constraint and the party(ies) that are provided use or access under the restrictions.

4.5.2.1 Controlled Unclassified Information Markings [.ResourceConstraints.cuiMarkings]

The first subset of resource constraint elements, CUI markings, provides the opportunity to document any controlled unclassified information markings relevant for a resource or metadata.

Rule 4-3 Controlled Unclassified Information Marking

1) The controlled unclassified information markings element within resource constraints shall be populated independent of whether a resource or metadata is designated as Controlled Unclassified Information.

4.5.2.1.1 Classification [.ResourceConstraints.cuiMarkings.resClassification]

A classification CUI marking element is mandatory and its value shall be “U”.

4.5.2.1.2 CUI Designating Agency [.ResourceConstraints.cuiMarkings.resCuiDesignatingAgency]

A CUI designating agency CUI marking element is mandatory and reflects the organization of the individual designating the metadata or resource as CUI.

Rule 4-4 CUI Designating Agency Name Format

1) The CUI designating agency CUI marking element shall contain the name of the organization of the designating individual and shall begin with the phrase “Designated by:” (for example, “Designated By: ODASD(INF), BSI, DISDI Program”)


16

4.5.2.1.3 CUI Categories The process of selecting the applicable CUI Basic or Specified categories is guided by the following policy and guidance:

• Executive Order 13556, “Controlled Unclassified Information”, November 4, 20107

• 32 CFR Part 2002, “CONTROLLED UNCLASSIFIED INFORMATION (CUI)”8

• DoD Instruction 5200.48, “Controlled Unclassified Information”, March 6, 2020

• CUI Marking Handbook, Version 1.1, December 6, 20169

Furthermore, the DASD(Infrastructure) plans to develop and publish a “Security Classification Guide” which specifically applies to DoD installations and environment data. This guide is expected to apply to all IGI&S data, and provide specific guidance for marking metadata about resources that are SDSFIE-V feature classes. This guidance will include whether or not to mark a resource CUI and if so, what the applicable CUI Basic and/or Specified categories should be.

Components may also determine that a resource needs to be marked as CUI under their own policy and guidance.

Rule 4-5 CUI Metadata or Resource CUI Basic or Specified Categories

1) If metadata or a resource is determined to be CUI, then it shall be documented with the one or more CUI Basic or Specified categories under which the determination was made.

4.5.2.1.3.1 CUI Basic Categories [.ResourceConstraints.cuiMarkings.resCuiBasicCategory]

A CUI Basic CUI marking element is optional and designates what CUI Basic category(ies) apply to the metadata or the resource. The content is a list of resCuiBasicCategory elements each containing an applicable category drawn from the ResCuiBasicCategory codelist.

4.5.2.1.3.2 CUI Specified Categories [.ResourceConstraints.cuiMarkings.resCuiSpecifiedCategory]

A CUI Specified CUI marking element is optional and designates what CUI Specified category(ies) apply to the metadata or the resource. The content is a list of resCuiSpecificCategory elements each containing an applicable category drawn from the ResCuiSpecifiedCategory codelist.

4.5.2.1.4 Dissemination Controls [.ResourceConstraints.cuiMarkings.resCuiDissemControlType]

A dissemination control CUI marking element is optional and designates the applicable limited dissemination control (LDC) marking for the metadata or resource based on the applicable CUI Basic and/or Specified categories. The content is a list of resCuiDissemControlType elements each containing an applicable control drawn from the ResCuiDissemControlType codelist. Table 1 is provided to help understanding which LDC to apply with any other LDC and other CUI marking elements.

CUI Metadata or Resource Limited Dissemination Control (LDC)

7 https://www.federalregister.gov/articles/2010/11/09/2010-28360/controlled-unclassified-information 8 https://www.govinfo.gov/content/pkg/CFR-2018-title32-vol6/pdf/CFR-2018-title32-vol6-part2002.pdf 9 https://www.archives.gov/files/cui/documents/20161206-cui-marking-handbook-v1-1-20190524.pdf


17

1) If metadata or a resource is determined to be CUI and the applicable CUI Basic and/or Specified categories indicate a limited dissemination, then the metadata or resource shall be documented with the most restrictive LDCs

2) The LDCs marking shall follow all NARA and DoD policy and guidance. Table 1: Limited Dissemination Controls with the Descriptions and Business Rules

Limited Dissemination Control

Description Business Rules

Attorney Client Dissemination of information is protected by the attorney client privilege beyond the attorney, the attorney’s agents, and the client.

• May be combined with any other indicated LDC

Attorney Work Product Dissemination of information is protected by the Attorney Work Product Privilege beyond the attorney, the attorney’s agents, and the client.


Authorized for release to certain nationals only

Information has been predetermined by the designating agency to be releasable, or has been released, only to the foreign country(ies)/international organization(s) indicated, through established foreign disclosure procedures and channels.

• One or more resCuiDissemCtrlDiscloseTo CUI marking elements must also be populated to indicate which recipients are allowed

• May be used in conjunction with other allowable LDCs, except: o Display Only o No foreign dissemination

Deliberative Process Dissemination of information is protected by the deliberative process privilege beyond the department, agency, or U.S. Government decision maker who is part of the policy deliberation.


Display Only Information is authorized for disclosure to a foreign recipient (included on an accompanying dissemination list), but without providing the foreign recipient with a physical copy for retention, regardless of medium to the foreign country(ies)/international organization(s) indicated, through established foreign disclosure procedures and channels.

• One or more resCuiDissemCtrlDiscloseTo CUI marking elements must also be populated to indicate which recipients are allowed

• May be used in conjunction with other allowable LDCs, except: o Authorized for release to certain

nationals only o No foreign dissemination

Dissemination List Controlled

Dissemination authorized only to those individuals, organizations, or entities included on an accompanying dissemination list.

• One or more resCuiLimDissemControlParty CUI marking elements must also be populated to indicate which recipients are allowed

• May be combined with the following controls, if indicated: o Attorney Client o Attorney Work Product o Authorized for release to certain

nationals only o Deliberative Process o Display Only o No foreign dissemination

• Shall not be used with: o Federal Employees and Contractors

Only o Federal Employees Only o No dissemination to Contractors


18

Federal Employees and Contractors Only

Dissemination authorized only to (1) employees of United States Government Executive branch departments and agencies (as agency is defined in 5 U.S.C. 105), (2) armed forces personnel of the United States or Active Guard and Reserve (as defined in 10 USC 101), or (3) individuals or employers who enter into a contract with the United States (any department or agency) to perform a specific job, supply labor and materials, or for the sale of products and services, so long as dissemination is in furtherance of that contractual purpose.



• Shall not be used with: o Dissemination List Controlled o Federal Employees Only o No dissemination to Contractors

Federal Employees Only Dissemination authorized only to (1) employees of United States Government Executive branch departments and agencies (as agency is defined in 5 U.S.C. 105), or (2) armed forces personnel of the United States or Active Guard and Reserve (as defined in 10 USC 101).



• Shall not be used with: o Dissemination List Controlled o Federal Employees and Contractors

Only o No dissemination to Contractors

No dissemination to Contractors

No dissemination authorized to individuals or employers who enter into a contract with the United States (any department or agency) to perform a specific job, supply labor and materials, or for the sale of products and services.



• Shall not be used with: o Dissemination List Controlled o Federal Employees and Contractors

Only o Federal Employees Only

No foreign dissemination Information may not be disseminated in any form to foreign governments, foreign nationals, foreign or international organizations, or non-US citizens.

• May be used in conjunction with other allowable LDCs

• Shall not be used with: o Authorized for release to certain

nationals only o Display Only

4.5.2.1.5 Dissemination Control Disclose To [.ResourceConstraints.cuiMarkings.resCuiDissemCtrlDiscloseTo]

A dissemination control disclose to element is mandatory when either a “Display Only” or “Authorized for release to certain nationals only” LDC is associated with metadata or a resource. This element provides the set of countries and/or international organizations that can view or receive the metadata or resource.


19

The content is a list of resCuiDissemCtrlDiscloseTo elements each containing an applicable country or international organization drawn from the ResCuiDissemControlDiscloseTo codelist.

4.5.2.1.6 Decontrol Date [.ResourceConstraints.cuiMarkings.resCuiDecontrolDate]

A decontrol date CUI marking element is optional and designates the specific date when the resource shall be automatically decontrolled. The assumption for CUI is that if a date or event are not provided, then the information will remain controlled.

4.5.2.1.7 Decontrol Event [.ResourceConstraints.cuiMarkings.resCuiDecontrolEvent]

A decontrol event CUI marking element is optional and provides the description of an event upon which the information shall be automatically decontrolled.

4.5.2.1.8 Required Indicator Per Authority [.ResourceConstraints.cuiMarkings.resCuiReqIndPerAuth]

A required indicator per authority CUI marking element is optional and provides the text of an additional required indicator, including marking, dissemination, informational, distribution-limiting, or warning statements, that is mandated by U.S. authorizing law, regulation, or government-wide policy (otherwise known as the authority or sanction) associated with a CUI Basic or Specified category. For example, a Privacy Act Notice is required for resources designated under the Privacy Act.

4.5.2.1.8.1 DoD Distribution Statements This section describes a special type of required indicator per authority called the DoD Distribution Statement.

Rule 4-6 Use of DoD Distribution Statements

1) Metadata and resources that are a) designated CUI and b) given the CUI Category “Controlled Technical Information” or “CTI” shall include a required indicator per authority CUI marking element populated with the appropriate distribution statement as defined by DoDI 5230.24 and summarized below.

Although DoDI 5230.24 is only mandatory for marking and managing technical documents (including research, development, engineering, test, sustainment, and logistics information), it is widely used in the GEOINT community to mark GI&S data and products, a use which is not prohibited by the policy.

The statements defined in DoDI 5230.24 are used to denote the extent to which they are available for secondary distribution, release, and dissemination without additional approvals or authorizations. Table 2 from 5230.24, recreated for convenience below, defines a series of distribution statements that are used to inform approved distribution and the reasons for those distribution decisions.

Table 2: Distribution Statements and Their Corresponding Reasons for Use

DISTRIBUTION A. Approved for public release: distribution unlimited.

DISTRIBUTION B. Distribution authorized to U.S. Government agencies (reason) (date of determination). Other requests for this document shall be referred to (controlling DoD office).

DISTRIBUTION C. Distribution authorized to U.S. Government agencies and their contractors (reason) (date of determination). Other requests for this document shall be referred to (controlling DoD office).

DISTRIBUTION D. Distribution authorized to Department of Defense and U.S. DoD contractors only (reason) (date of determination). Other requests for this document shall be referred to (controlling DoD office).

DISTRIBUTION E. Distribution authorized to DoD Components only (reason) (date of determination). Other requests for this document shall be referred to (controlling DoD office).


20

DISTRIBUTION F. Further dissemination only as directed by (controlling office) (date of determination) or higher DoD authority.

Reason A B C D E

PUBLIC RELEASE. X

ADMINISTRATIVE OR OPERATIONAL USE: To protect technical or operational data or information from automatic dissemination under the International Exchange Program or by other means. This protection covers publications required solely for official use or strictly for administrative or operational purposes. This statement may apply to manuals, pamphlets, technical orders, technical reports, and other publications containing valuable technical or operational data.

X X X X

CONTRACTOR PERFORMANCE EVALUATION: To protect information in management reviews, records of contract performance evaluation, or other advisory documents evaluating programs of contractors.

X X

CRITICAL TECHNOLOGY: To protect information and technical data that advance current technology or describe new technology in an area of significant or potentially significant military application or that relate to a specific military deficiency of a potential adversary. Information of this type may be classified or unclassified.

X X X X

DIRECT MILITARY SUPPORT: The document contains export-controlled technical data of such military significance that release for purposes other than direct support of DoD-approved activities may jeopardize an important technological or operational military advantage of the United States, another country, or a joint U.S.-foreign program. Designation of such data is made by competent authority in accordance with Reference (d).

X

EXPORT CONTROLLED: To protect information subject to the provisions of Reference (d). X X X X

FOREIGN GOVERNMENT INFORMATION: To protect and limit distribution in accordance with the desires of and agreements with the foreign government that furnished the technical information.

X X X X

OPERATIONS SECURITY: To protect information and technical data that may be observed by adversary intelligence systems and determining what indicators hostile intelligence systems may obtain that could be interpreted or pieced together to derive critical information in time to be useful to adversaries.

X X

PREMATURE DISSEMINATION: To protect patentable information on systems or processes in the development or concept stage from premature dissemination. X X

PROPRIETARY INFORMATION: To protect information not owned by the U.S. Government and marked with a statement of a legal property right. This information is received with the understanding that it will not be routinely transmitted outside the U.S. Government.

X X

TEST AND EVALUATION: To protect results of test and evaluation of commercial products or military hardware when disclosure may cause unfair advantage or disadvantage to the manufacturer of the product.

X X

SOFTWARE DOCUMENTATION: To protect technical data relating to computer software that is releasable only in accordance with the software license in subpart 227.72 of Reference (s). It includes documentation such as user or owner manuals, installation instructions, operating instructions, and other information that explains the capabilities of or provides instructions for using or maintaining computer software.

X X X X


21

SPECIFIC AUTHORITY: To protect information not specifically included in the above reasons, but which requires protection in accordance with valid documented authority (e.g., Executive orders, statutes such as Atomic Energy Federal regulation). When filling in the reason, cite “Specific Authority (identification of valid documented authority).”

X X X X

VULNERABILITY INFORMATION: To protect information and technical data that provides insight into vulnerabilities of U.S. critical infrastructure, including DoD warfighting infrastructure, vital to National Security that are otherwise not publicly available.

X X X X

4.5.2.1.9 Supplemental Administrative Marking [.ResourceConstraints.cuiMarkings.resCuiSupAdminMarking]

A supplemental administrative marking CUI marking element is optional and provides the text of a administrative marking for the content of a resource (specific items of information) which may be used in conjunction with Controlled Unclassified Information (CUI) markings where required by U.S. law, regulation, or government-wide policy.

4.5.2.1.10 Designating Agency [.ResourceConstraints.cuiMarkings.resCuiDesignatingAgency]

A designating agency CUI marking element is mandatory and provides information about the agency that designated the information as CUI.

Rule 4-7 Designating Agency Element Always Organizational

1) Designating agency elements shall be an organization and NOT an individual. This means that all sub elements can only reference an organization, including the name, address (of all types, including electronic mail addresses), and phone.

4.5.2.1.11 Limited Dissemination Control Party [.ResourceConstraints.cuiMarkings.resCuiLimDissemControlParty]

At least one limited dissemination control party CUI marking element is mandatory when the “Dissemination List Controlled” LDC is associated with metadata or a resource. These elements provide information about the individual(s) or organization(s) to whom the metadata or resource can be released.

Rule 4-8 Limited Dissemination Control Party Elements May Be Organizational or Individual

1) Limited dissemination control party elements may be an organization or an individual. However, individual references should be used only in circumstances where they cannot be avoided.

2) If a limited dissemination control party element references an organization, then all sub elements can only reference an organization, including the name, address (of all types, including electronic mail addresses), and phone.

4.5.2.2 Access or Use Restrictions [.ResourceConstraints.resourceAccessControl] or [.ResourceConstraints.resourceUseControl]

Access or use restrictions are sometimes required to limit the release of metadata or resources for legal reasons different and are separate from Controlled Unclassified Information reasons. Examples, include copyright or licensing issues. These restrictions may be used to document restrictions that occur on metadata or resources that are also designated as CUI, but that case will probably be extremely rare.


22

The model for these restrictions is based on the National Archives and Record Administration Lifecycle Data Requirements Guide, Second Edition (January 18, 2002)10. The term access is best understood as the ability to view (examine) the resource and the term use is best understood as the ability to obtain (download) the resource.

Rule 4-9 Access or Use Restrictions on Metadata and Resource

1) Access or use restrictions on both the metadata and the resource shall be documented using resource access or use control elements.

2) If there are no access or use restrictions on either the metadata or the resource, then the elements shall not be included.

Rule 4-10 Access or Use Restrictions Do Not Replace CUI Basic or Specified Markings

1) Access or use restrictions shall not replace CUI Basic or Specified markings but can be used to augment these markings, if necessary.

4.5.2.2.1 Resource Access Control The following section details the elements that are used when a there are one or more resource access controls required due to access restrictions.

4.5.2.2.1.1 Specific Access Restrictions [.ResourceConstraints.resourceAccessControl.resourceSpecAccessRestrict]

A specific access restriction element is mandatory and provides the type of access restriction on the metadata or resource. The content is a resourceSpecAccessRestrict element containing an applicable access restriction drawn from the ResourceSpecificAccessRestriction codelist. Example access restrictions are 1) donated indicating a restriction imposed by the donor of the information or 2) license indicating a licensing restriction.

4.5.2.2.1.2 Access Restriction Note [.ResourceConstraints.resourceAccessControl.resourceAccessRestrictNote]

An access restriction note element is optional and provides further information about the access restriction for the metadata or resource beyond that provided by the specific access restriction element.

Rule 4-11 Circumstance Where Access Restriction Note Is Mandatory

1) The access restriction note element shall be populated if the type indicated by the specific access restriction element is otherRestriction.

4.5.2.2.1.3 Authorized Access Party [.ResourceConstraints.resourceAccessControl.resourceAuthAccessParty]

An authorized access party element is optional and provides information about the individual(s) or organization(s) that have legitimate authorization to access to the metadata or resource.

Rule 4-12 Circumstance Where Authorized Access Party Is Mandatory

1) The authorized access party element shall be populated if the specific access restriction limits access to specific party(ies). Care should be taken to ensure that the party(ies) having authorized access are properly described.

4.5.2.2.2 Resource Use Control

10 https://www.archives.gov/research/catalog/lcdrg


23

The following section details the elements that are used when a there are one or more resource use controls required due to use restrictions.

4.5.2.2.2.1 Specific Use Restrictions [.ResourceConstraints.resourceUseControl.resourceSpecUseRestrict]

A specific use restriction element is mandatory and provides the type of use restriction on the metadata or resource. The content is a resourceSpecUseRestrict element containing an applicable access restriction drawn from the ResourceSpecificUseRestriction codelist. Example use restrictions are 1) copyright indicating a restriction determined by copyright law as specified by title 17 of the U.S. Code or 2) license indicating a licensing restriction).

4.5.2.2.2.2 Use Restriction Note [.ResourceConstraints.resourceUseControl.resourceUseRestrictNote]

A use restriction note element is optional and provides further information about the use restriction for the metadata or resource beyond that provided by the specific use restriction element.

Rule 4-13 Circumstance Where Use Restriction Note Is Mandatory

1) The use restriction note element shall be populated if the type indicated by the specific use restriction element is otherRestriction.

4.5.2.2.2.3 Authorized Use Party [.ResourceConstraints.resourceUseControl.resourceAuthUseParty]

An authorized use party element is optional and provides information about the individual(s) or organization(s) that have legitimate authorization to use the metadata or resource.

Rule 4-14 Circumstance Where Authorized Use Party Is Mandatory

1) The authorized use party element shall be populated if the specific use restriction limits use to specific party(ies). Care should be taken to ensure that the party(ies) having authorized use are properly described.

4.5.2.2.3 Copyright Notice [.ResourceConstraints.copyrightNotice]

A copyright notice element is optional and provides a method to document copyright notices. For example, “Copyright 2020. DigitalGlobe.”, in which case the copyright information for use of such imagery needs to be stated; and would accompany a specific use restriction value of copyright. A non-copyright data, for example “Copyright 2004 by the National Geospatial-Intelligence Agency, U.S. Government. No domestic copyright claimed under Title 17 U.S.C. All rights reserved.” could also be documented using this element, but would NOT require an accompanying specific use restriction.

5 Metadata Tools The DISDI Program and Components may develop and disseminate tools that support the implementation of SDSFIE-M (and metadata generally) across the IGI&S community. This implementation guidance does not mandate the use of any one tool by all Components primarily because the IGI&S community uses multiple software vendors, each of whom handle metadata differently.

Rule 5-1 Tools Must Conform

Any tool that is developed by any IGG member organization for the implementation of SDSFIE-M shall conform to the rules defined in this guidance.


24

5.1 SDSFIE-M Metadata Style for ArcGIS

The DISDI Program has developed a metadata style for use with the Esri ArcGIS platform and intends to maintain it, subject to availability of resources. This tool enables the Components to develop and maintain their metadata more efficiently, and promotes uniform implementation of the standard.

A metadata style configures ArcGIS to create metadata according to a particular metadata standard and workflow. Choosing a metadata style is like applying a filter to an item's metadata. The style controls how you view the metadata and also the pages that appear for editing metadata in the Description tab in ArcGIS. The SDSFIE-M Metadata Style for ArcGIS is designed to support SDSFIE Metadata Implementation Schema (SMIS). Therefore, the style will determine how metadata is exported and validated for SDSFIE-M.

6 References The following referenced documents provide the background for SDSFIE-M and these implementation guidelines.

• SDSFIE Metadata (SDSFIE-M): Conceptual Schema, version 2.0 R2, 11 SEP 2019, https://www.sdsfieonline.org/Standards/Metadata#SDSFIE-M

• Executive Order 13526, Classified National Security Information, 29 DEC 2009, http://www.gpo.gov/fdsys/pkg/CFR-2010-title3-vol1/pdf/CFR-2010-title3-vol1-eo13526.pdf

• DODI 5230.24, Distribution Statements on Technical Documents, 23 AUG 2012, http://www.dtic.mil/whs/directives/corres/pdf/523024p.pdf

• National Counterintelligence and Security Center (NCSC), Special Security Directorate (SSD), Security Markings Program (SMP), Intelligence Community Markings System, Register and Manual, 30 DEC 2014, https://intelshare.intelink.gov/sites/odni/cio/ea/library/Technical%20Specifications/TechSpec%20Policy%20Regs/Policy/CAPCO/2014-DEC-30-IC_Marking_System_Register_Manual/CleanedIC_Markings_System_Register_and_Manual_FOUO_December2014.pdf [Requires Valid PKI Certificate (i.e. DOD CAC, FED PIV)]

• Executive Order 13642, Making Open and Machine Readable the New Default for Government Information, 9 MAY 2013, http://www.gpo.gov/fdsys/pkg/FR-2013-05-14/pdf/2013-11533.pdf

• Office of Management and Budget Memorandum M-13-13, Open Data Policy-Managing Information as an Asset, 9 MAY 2013, http://www.whitehouse.gov/sites/default/files/omb/memoranda/2013/m-13-13.pdf

7 Definitions This section provides definitions for terms used in this document.

Component A Military Department, Defense Agency, DoD Field Activity, or organization within the Office of the Secretary of Defense

IGI&S Programs

http://www.gpo.gov/fdsys/pkg/CFR-2010-title3-vol1/pdf/CFR-2010-title3-vol1-eo13526.pdf

http://www.gpo.gov/fdsys/pkg/CFR-2010-title3-vol1/pdf/CFR-2010-title3-vol1-eo13526.pdf

http://www.dtic.mil/whs/directives/corres/pdf/523024p.pdf

https://intelshare.intelink.gov/sites/odni/cio/ea/library/Technical%20Specifications/TechSpec%20Policy%20Regs/Policy/CAPCO/2014-DEC-30-IC_Marking_System_Register_Manual/CleanedIC_Markings_System_Register_and_Manual_FOUO_December2014.pdf




http://www.gpo.gov/fdsys/pkg/FR-2013-05-14/pdf/2013-11533.pdf

http://www.gpo.gov/fdsys/pkg/FR-2013-05-14/pdf/2013-11533.pdf

http://www.whitehouse.gov/sites/default/files/omb/memoranda/2013/m-13-13.pdf


25

The DoD Component headquarters level activities responsible for oversight, policy, and guidance pertaining to installation geospatial information and services.

Implementation The creation and maintenance of metadata for geographic information system data holdings.

Implementation Compliance Compliance is measured with respect to a metadata standard. An Implementation is considered compliant if metadata documents can be generated that validate against the SMIS schema for the currently mandated version of SDSIFE-M.

8 Abbreviations ADS – Authoritative Data Source

API – Application Programming Interface

ARH – Access Rights and Handling

ASD (S) – Assistant Secretary of Defense (Sustainment)

CAPCO – Controlled Access Program Coordination Office

CFR – Code of Federal Regulations

CIP – Common Installation Picture

CMP – Change Management Process

COI – Community of Interest

CUI – Controlled Unclassified Information

CSW – OGC Catalog Service

CTI – Controlled Technical Information

DASD(INF) – Deputy Assistant Secretary of Defense for Infrastructure

DISDI – Defense Installations Spatial Data Infrastructure

DISR – Department of Defense Information Technology Standards Registry

DoD – Department of Defense

DOE – Department of Energy

DoDI – Department of Defense Instruction

EO – Executive Order

FGDC – Federal Geographic Data Committee

GEOINT – Geospatial Intelligence

GIS – Geographic Information Systems

IC – Intelligence Community

IGI&S – Installation Geospatial Information & Services

IGG – IGI&S Governance Group

ISM – Information Security Markings

ISO – International Organization for Standardization

IT – Information Technology


26

KML – OGC Keyhole Markup Language

LDC – Limited Dissemination Control

LRGWP – Law, regulation, or Government-wide policy

NAS – NSG Application Schema

NATO – North Atlantic Treaty Organization

NMF – National System for Geospatial-Intelligence (NSG) Metadata Foundation

NSG – National System for Geospatial-Intelligence

NTK – Need to Know

OGC – Open Geospatial Consortium

OPEN – Open, Public, Electronic, and Necessary

POAM – Plan of Action & Milestones

RD – Restricted Data

REST – Representational State Transfer

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

SDSFIE-M – SDSFIE Metadata

SDSFIE-V – SDSFIE Vector

SGP – SDSFIE Governance Plan

SMIS – SDSFIE Metadata (or SDSFIE-M) Implementation Schema (formerly, Specification)

URI – Uniform Resource Identifier

URL – Uniform Resource Locator

US – United States

WCS – OGC Web Coverage Service

WFS – OGC Web Feature Service

WMS – OGC Web Map Service

WMTS – OGC Web Map Tile Service

XML – Extensible Markup Language

9 Versioning Lifecycle States The following set of versioning lifecycle states if taken from the SDSFIE Governance Plan and is repeated here for the convenience of the reader.

1) Emerging

a) The version is created and approved but it is not yet Mandated. The version is expected to be Mandated within one to two years. Because each case may be unique, implementing organizations should consider the potential compatibility risks and impacts before considering whether to upgrade to an Emerging standard. For example, upgrading to a minor version may involve less risk than to a major version. The version may be implemented, but not in lieu of Mandated version.

2) Mandated


27

a) The version is to be implemented and considered essential for interoperability in the IGI&S community. The milestones and deadlines for implementation of the Mandated version shall be developed by the IGG and approved by ASD (S) in accordance with DoDI 8130.01.

3) Retired

A version that is no longer Mandated because a new version has been Mandated. Continued use of the Retired version may be allowed if the Component is still in the process of migrating to the mandated version. An implementation plan with milestones may be required by the IGG.

SDSFIE-M Implementation Guidance › Documents › SDSFIE-M-Implementatio… · Geospatial data can...

Documents

Transcript of SDSFIE-M Implementation Guidance › Documents › SDSFIE-M-Implementatio… · Geospatial data can...