sdsfie metadata implementation specification (smis) v1.0.2 ...sep 15, 2015 · @context metadata...

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

SDSFIE Metadata Implementation Specification (SMIS) v1.0.2

to

Project Open Data (POD)

Metadata Schema v1.1

Crosswalk

Version 1.0

(15 SEP 2015)

Prepared By:

The IGI&S Governance Group for

The Assistant Secretary of Defense (Energy, Installations & Environment)

© 2015

15 SEP 2015 — FINAL DRAFT SMIS to POD Crosswalk Decision Document

i

THIS PAGE IS INTENTIONALLY BLANK


i

Executive Summary

This document contains the recommendation for a crosswalk between SDSFIE Metadata Implementation Specification (SMIS) v1.0.2 and Project Open Data (POD) Metadata Schema v1.1. Any automated conversion between SMIS and POD documents shall follow the crosswalk documented herein to be considered valid for use by the DoD Installation and Environment community and USACE Civil Works.


ii

Revision History

Description Date Version

Initial Version (approved by Metadata Working Group: 3 SEP 2015) 4 SEP 2015 1.0


iii

Table of Contents Executive Summary .................................................................................................................................................... i

1 Overview ........................................................................................................................................................ 5

2 Introduction to POD ....................................................................................................................................... 5

2.1 Catalog Fields .................................................................................................................................................. 7

2.2 Dataset Fields .................................................................................................................................................. 7

2.3 Dataset Distribution Fields .............................................................................................................................. 9

2.4 Further Metadata Field Guidance ................................................................................................................. 10

3 SMIS v1.0.2 to POD v1.1 Crosswalk .............................................................................................................. 11

4 SMIS2POD Requirements ............................................................................................................................. 16

5 SMIS to POD Glossary .................................................................................................................................. 16

Annex A Recommendations For Ambiguous Fields .......................................................................................... 18

Decision 1: “modified” Field .............................................................................................................................. 18

Decision 2: “publishername” Field ................................................................................................................ 18

Decision 3: “publishersubOrganizationOf” Field ........................................................................................... 19

Decision 4: “contactPointfn” Field ................................................................................................................. 22

Decision 5: “contactPointhasEmail” Field ...................................................................................................... 23

Decision 6: “identifier” Field .............................................................................................................................. 23

Decision 7: “accessLevel” Field .......................................................................................................................... 24

Decision 8: “bureauCode” Field ......................................................................................................................... 24

Decision 9: “programCode” Field ...................................................................................................................... 24

Decision 10: “temporal” Field .............................................................................................................................. 29

Decision 11: “describedBy” Field ......................................................................................................................... 29


iv

THIS PAGE IS INTENTIONALLY BLANK


5

1 Overview

To develop a clear and comprehensive understanding of what data assets they possess, Federal Agencies are required to create an Enterprise Data Inventory (Inventory) that accounts for all data assets created or collected by the agency. This includes, but is not limited to, data assets used in the agency’s information systems. The Inventory must be enterprise-wide, accounting for data assets across programs and bureaus, and must use the required Project Open Data (POD) metadata schema available on Project Open Data (https://project-open-data.cio.gov/). After creating the Inventory, agencies should continually improve the usefulness of the Inventory by expanding, enriching, and opening the Inventory (concepts described in the framework below).

The objectives of this activity are to:

Build an internal inventory that accounts for data assets used in the agency’ s information systems

Include data assets produced through agency contracts and cooperative agreements, and in some cases agency-funded grants; include data assets associated with, but not limited to, research, program administration, statistical, and financial activities

Indicate if the data may be made publicly available and if currently available

Describe the data with POD metadata schema available on the Project Open Data web site (currently version 1.1).

The SDSFIE Metadata Implementation Specification (SMIS) is the metadata standard used for the documentation, discovery and exchange of geospatial datasets in the installation geospatial information and services (IGI&S) community, as defined in DoDI 8130.01. The SMIS specifies an Extensible Markup Language (XML) encoding of the SDSFIE Metadata (SDSFIE-M): Conceptual Schema that is conformant to ISO/TS 19139 Geographic information – Metadata – XML schema implementation, the XML Data Encoding Specification for Information Security Marking Metadata (DES.ISM.XML.V9), and the XML Data Encoding Specification for Need-To-Know Metadata (DES.NTK.XML.V7).. The SMIS XML encoding shall be used within the IGI&S community to document geospatial datasets for cataloguing, discovery and retrieval.

SMIS is much more comprehensive than the POD metadata schema, therefore the IGI&S Governance Group (IGG) has developed this process for converting SMIS metadata documents to POD metadata documents. A crosswalk exists between ISO 19115 (19139) metadata and POD v1.1 (https://project-open-data.cio.gov/v1.1/metadata-resources/#iso-19115-to-project-open-data-metadata-schema-v11-pod-v11-crosswalk). However, there is ambiguity in that crosswalk that must be resolved before an automatic conversion can be accomplished. Section 3 of this document contains an unambiguous crosswalk between SMIS v1.0.2 and POD v1.1 that was developed by addressing the ambiguities in the ISO 19115 to POD v11 crosswalk and also taking into account elements in SMIS v1.0.2.

The IGG will implement an SMIS2POD converter that follows the crosswalk exactly and will result in a valid POD file when a valid SMIS document is provided as input.

2 Introduction to POD

A POD document is a JavaScript Object Notation (JSON) file that contains a catalog of metadata about datasets. Each POD document conforms to a metadata schema (https://project-open-data.cio.gov/v1.1/schema/). Figure 1 depicts the object model of the POD v1.1 schema.

https://project-open-data.cio.gov/

https://project-open-data.cio.gov/v1.1/metadata-resources/#iso-19115-to-project-open-data-metadata-schema-v11-pod-v11-crosswalk

https://project-open-data.cio.gov/v1.1/metadata-resources/#iso-19115-to-project-open-data-metadata-schema-v11-pod-v11-crosswalk

https://project-open-data.cio.gov/v1.1/schema/


6

Figure 1: POD v1.1 Schema Object Model

Each of the properties in the above object model are described here for convenience:


7

2.1 Catalog Fields

These fields describe the entire Public Data Listing catalog file. Publishers must use the describedBy field to reference the default JSON Schema file used to define the schema (https://project-open-data.cio.gov/v1.1/schema/catalog.json). See the Catalog section under Further Metadata Field Guidance for more details.

Field Label Definition Required

@context Metadata Context URL or JSON object for the JSON-LD Context that defines the schema used. No

@id Metadata Catalog ID IRI for the JSON-LD Node Identifier of the Catalog. This should be the URL of the data.json file itself.

No

@type Metadata Type IRI for the JSON-LD data type. This should be dcat:Catalog for the Catalog. No

conformsTo Schema Version URI that identifies the version of the Project Open Data schema being used. Always

describedBy Data Dictionary URL for the JSON Schema file that defines the schema used. No

dataset Dataset A container for the array of Dataset objects. See Dataset Fields below for details. Always

2.2 Dataset Fields

See the Further Metadata Field Guidance section to learn more about the use of each element, including the range of valid entries where appropriate. Consult the SMIS v1.0.2 to POD v1.1 Crosswalk for a mapping from SMIS to POD.


@type Metadata Type IRI for the JSON-LD data type. This should be dcat:Dataset for each Dataset. No

title Title Human-readable name of the asset. Should be in plain English and include sufficient detail to facilitate search and discovery.

Always

description Description Human-readable description (e.g., an abstract) with sufficient detail to enable a user to quickly understand whether the asset is of interest.

Always

keyword Tags Tags (or keywords) help users discover your dataset; please include terms that would be used by technical and non-technical users.

Always

modified Last Update Most recent date on which the dataset was changed, updated or modified. Always

publisher Publisher The publishing entity and optionally their parent organization(s). Always


8

contactPoint Contact Name and Email Contact person’s name and email for the asset. Always

identifier Unique Identifier A unique identifier for the dataset or API as maintained within an Agency catalog or database.

Always

accessLevel Public Access Level The degree to which this dataset could be made publicly-available, regardless of whether it has been made available. Choices: public (Data asset is or could be made publicly available to all without restrictions), restricted public (Data asset is available under certain use restrictions), or non-public (Data asset is not available to members of the public).

Always

bureauCodeUSG Bureau Code Federal agencies, combined agency and bureau code from OMB Circular A-11, Appendix C (PDF, CSV) in the format of 015:11.

Always

programCodeUSG Program Code Federal agencies, list the primary program related to this data asset, from the Federal Program Inventory. Use the format of 015:001.

Always

license License The license or non-license (i.e. Public Domain) status with which the dataset or API has been published. See Open Licenses for more information.

If-Applicable

rights Rights This may include information regarding access or restrictions based on privacy, security, or other policies. This should also serve as an explanation for the selected “accessLevel” including instructions for how to access a restricted file, if applicable, or explanation for why a “non-public” or “restricted public” data asset is not “public,” if applicable. Text, 255 characters.

If-Applicable

spatial Spatial The range of spatial applicability of a dataset. Could include a spatial region like a bounding box or a named place.

If-Applicable

temporal Temporal The range of temporal applicability of a dataset (i.e., a start and end date of applicability for the data).

If-Applicable

distribution Distribution A container for the array of Distribution objects. See Dataset Distribution Fields below for details.

If-Applicable

accrualPeriodicity Frequency The frequency with which dataset is published. No

conformsTo Data Standard URI used to identify a standardized specification the dataset conforms to. No

dataQualityUSG Data Quality Whether the dataset meets the agency’s Information Quality Guidelines (true/false).

No

describedBy Data Dictionary URL to the data dictionary for the dataset. Note that documentation other than a data dictionary can be referenced using Related Documents (references).

No


9

describedByType Data Dictionary Type The machine-readable file format (IANA Media Type also known as MIME Type) of the dataset’s Data Dictionary (describedBy).

No

isPartOf Collection The collection of which the dataset is a subset. No

issued Release Date Date of formal issuance. No

language Language The language of the dataset. No

landingPage Homepage URL This field is not intended for an agency’s homepage (e.g. www.agency.gov), but rather if a dataset has a human-friendly hub or landing page that users can be directed to for all resources tied to the dataset.

No

primaryITInvestmentUIIUSG Primary IT Investment UII For linking a dataset with an IT Unique Investment Identifier (UII). No

references Related Documents Related documents such as technical information about a dataset, developer documentation, etc.

No

systemOfRecordsUSG System of Records If the system is designated as a system of records under the Privacy Act of 1974, provide the URL to the System of Records Notice related to this dataset.

No

theme Category Main thematic category of the dataset. No

2.3 Dataset Distribution Fields

Due to the fact that SDSFIE-M left off the MD_Distribution element, these (optional) fields will not be populated by SMIS2POD.

Within a dataset, distribution is used to aggregate the metadata specific to a dataset’s resources (accessURL and downloadURL), which may be described using the following fields. Each distribution should contain one accessURL or downloadURL. A downloadURL should always be accompanied by mediaType.


@type Metadata Type IRI for the JSON-LD data type. This should be dcat:Distribution for each Distribution.

No

accessURL Access URL URL providing indirect access to a dataset, for example via API or a graphical interface.

If-Applicable

conformsTo Data Standard URI used to identify a standardized specification the distribution conforms to. No

describedBy Data Dictionary URL to the data dictionary for the distribution found at the downloadURL. Note that documentation other than a data dictionary can be referenced using Related Documents as shown in the expanded fields.

No


10

describedByType Data Dictionary Type The machine-readable file format (IANA Media Type or MIME Type) of the distribution’s describedBy URL.

No

description Description Human-readable description of the distribution. No

downloadURL Download URL URL providing direct access to a downloadable file of a dataset. If-Applicable

format Format A human-readable description of the file format of a distribution. No

mediaType Media Type The machine-readable file format (IANA Media Type or MIME Type) of the distribution’s downloadURL.

If-Applicable

2.4 Further Metadata Field Guidance

Additional details for each field are provided at https://project-open-data.cio.gov/v1.1/schema/#further-metadata-field-guidance, broken down into sections for the overarching Catalog, each dataset, and each dataset’s distribution. Consult the SMIS v1.0.2 to POD v1.1 Crosswalk for a mapping from SMIS to POD.

https://project-open-data.cio.gov/v1.1/schema/#further-metadata-field-guidance


11

3 SMIS v1.0.2 to POD v1.1 Crosswalk

This crosswalk is organized in the same order as the POD v1.1 object model above. If a field is not present, then it is not to be considered and will be left out any document created through conversion of SMIS 1.0.2 to POD v1.1.

POD v1.1 Label Condition Repeats Guidance SMIS Description SMIS XPath

Catalog Fields

conformsTo Schema Version

required no populated by SMIS2POD

dataset Dataset required no populated by SMIS2POD

Dataset Fields

title Title required no title //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title/gco:CharacterString

description Description required no abstract //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:abstract/gco:CharacterString

keyword Tags required yes POD JSON validator expects unique keywords.

keywords (theme, place, temporal)

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:descriptiveKeywords/gmd:MD_Keywords/gmd:keyword/gco:CharacterString

modified Last Update required no identificationInfo / citation / date is mandatory. But SDSFIE-M is silent on which dateType(s) are required. SDSFIE-M implementations should populate at least two dates, one for the “creation” date and one for the “revision” date.

identificationInfo / citation / date where dateType = “revision”

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode[. = "revision"]/../../gmd:date/gco:Date.

Publisher (publisher)


12


name Publisher required no This will always take the organization and not the person.

identificationInfo / citation / responsibility party / organization where role = “publisher”

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='publisher']/../../gmd:organisationName/gco:CharacterString

subOrganizationOf Publisher Parent Organization

optional no See section Decision 3: for recommendation

ContactPoint (contactPoint)

fn Name required no point of contact individual name

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode/[@codeListValue='pointOfContact']/../../gmd:organisationName/gco:CharacterString

hasEmail Email required no point of contact email address

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode/[@codeListValue='pointOfContact']/../../gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:electronicMailAddress/gco:CharacterString

identifier Unique Identifier

required no This is supplied by the SDSFIE Online Browse/Generate Tool as the lifecycle identifier of the feature class

metadata identifier //gmd:fileIdentifier/gco:CharacterString

accessLevel Public Access Level

required no Always “public” N/A

bureauCode Bureau Code required yes Value(s) taken from the code table in Decision 8: and supplied to SMIS2POD during the conversion process.

N/A

programCode Program Code required yes Value(s) taken from the code table in

N/A


13


Decision 9:and supplied to SMIS2POD during the conversion process.

license License if applicable no Default value for Government information is “Public Domain”. Licensed data shall not be posted to data.gov.

N/A

rights Rights if applicable no legal access restriction code

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceConstraints/sdsfie:MD_LegalConstraints/gmd:accessConstraints/gmd:MD_RestrictionCode

spatial Spatial if applicable no Concatenated latitude/longitude values for the extent. Users must ensure that the extent is entered in WGS 1984 latitude / longitude.

Geographic Bounding Coordinates

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:geographicElement/gmd:EX_GeographicBoundingBox/gmd:westBoundLongitude/gco:Decimal + “, “ + //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:geographicElement/gmd:EX_GeographicBoundingBox/gmd:southBoundLatitude/gco:Decimal + “, “ + //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:geographicElement/gmd:EX_GeographicBoundingBox/gmd:eastBoundLongitude/gco:Decimal + “, “ + //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:geographicElement/gmd:EX_GeographicBoundingBox/gmd:northBoundLatitude/gco:Decimal

temporal Temporal concatenate values, e.g. 2015-01-01/2015-02-02

1. min and max value of multiple date ranges

2. time period begin and end dates

3. time instant

1. if more than two instances of this field exist choose the earliest date value and latest date value to populate the range of dates //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimeInstant/timePosition


14


2.

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimePeriod/gml:beginPosition

+ //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimePeriod/gml:endPosition

3. if single date use this field to populate as both start/end date //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimeInstant/timePosition

accrualPeriodicity Frequency optional no This is required by SDSFIE-M and will be populated.

resource maintenance and update frequency

//gmd:metadataMaintenance/gmd:MD_MaintenanceInformation/gmd:maintenanceAndUpdateFrequency/gmd:MD_MaintenanceFrequencyCode

Convert values of this field based on the following mapping:

continual - R/PT1S

daily - R/P1D

weekly - R/P1W

fortnightly - R/P0.5M

monthly - R/P1M

quarterly - R/P3M

biannually - R/P0.5Y

asNeeded - irregular

irregular - irregular

notPlanned - irregular

unknown - irregular

conformsTo Data Standard optional no This requires SDSFIE-M Metadata Style users to generate a feature catalog (in the Content tab). If it

//gmd:contentInfo/sdsfie:MD_FeatureCatalogueDescription/gmd:featureCatalogueCitation/gmd:CI_Citation/gmd:title/gco:CharacterString


15


is not populated, it is left out of the file.

describedBy Data Dictionary optional no This requires SDSFIE-M Metadata Style users to a) generate a feature catalog (in the Content tab) and b) then populate the feature catalog citation with an online resource linkage. If it is not populated, it is left out of the file.

Feature catalog citation URL

//gmd:contentInfo/sdsfie:MD_FeatureCatalogueDescription/gmd:featureCatalogueCitation/gmd:CI_Citation/gmd:onlineResource/gmd:CI_OnlineResource/gmd:linkage/gmd:URL

language Language optional yes //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:language/gmd:LanguageCode


16

4 SMIS2POD Requirements

Some requirements for the SMIS2POD converter stem from the analysis above and others from analyzing how best to create a useful crosswalk. This section details a list of requirements for the SMIS2POD converter.

1. SMIS2POD shall take a zip file containing one or more SMIS 1.0.2 documents as input and create a POD v1.1 JSON output “catalog” file with a “dataset” per SMIS 1.0.2 document.

2. SMIS2POD shall validate each SMIS 1.0.2 document with the SMIS 1.0.2 schema (using the Saxon-EE product) to ensure a valid SMIS 1.0.2 document before processing. When validation errors occur, SMIS2POD will emit errors and stop processing the SMIS documents.

3. SMIS2POD shall generate the “catalog” fields in the POD v1.1 JSON output automatically without further input.

4. (Deferred until a future version. See section Decision 3: for an explanation.) SMIS2POD shall provide a mechanism to ground the organization of a publisher as defined in the “publishersubOrganizationOf” discussion in section 3.1. This means that all SMIS 1.0.2 documents in the zip file must be published by an organization grounded at the organizational element selected.

5. SMIS2POD shall generate an array of “dataset” fields in the POD v1.1 JSON output using the crosswalk defined in section 3 and an XML Stylesheet Language Transformation (XSLT) that utilizes the XPath expressions listed in the table in section 3.

6. SMIS2POD will check each SMIS 1.0.2 file for an explicit mention of the ism:noticeType attribute value of DOD-Dist-A representing DoD Distribution Statement A which is defined as “Approved for public release: distribution unlimited.” If it does not see this notice, then it will emit an error and stop processing the SMIS document. Purpose: Only datasets approved for public release shall result in a successful output.

7. SMIS2POD will check each SMIS 1.0.2 file for an explicit mention of the ism:noticeType attribute value of DOD-Dist-B, DOD-Dist-C, DOD-Dist-D, DOD-Dist-E, or DOD-Dist-F then it will emit an error and stop processing the SMIS document. Purpose: Only datasets approved for public release shall result in a successful output.

8. SMIS2POD will check each SMIS 1.0.2 file for an explicit mention of a Publisher role in the Cited Responsibility section of the dataset identification. If it does not find such an element, then it will emit and error and stop processing the SMIS document. Purpose: Only datasets with a valid publisher listed in the metadata shall result in a successful output.

5 SMIS to POD Glossary

Term POD Defintion SMIS to POD Definition

Catalog A catalog is a collection of datasets or web services. A catalog is a collection of datasets represented as a zip file containing SMIS documents containing data asset/dataset/web service SMIS metadata.

Data Asset A collection of data elements or datasets that make sense to group together. Each community of interest identifies the Data Assets specific to supporting the needs of their respective mission or business functions. Notably, a Data Asset is a deliberately abstract concept. A given Data Asset may represent an entire database consisting of multiple distinct entity classes, or may represent a single entity class.

A data asset represents a feature class, image, elevation dataset, or web service. This is also referred to as the “resource” that is described by SMIS metadata.


17

Dataset A dataset is an organized collection of data. The most basic representation of a dataset is data elements presented in tabular form. Each column represents a particular variable. Each row corresponds to a given value of that column’s variable. A dataset may also present information in a variety of non-tabular formats, such as an extensible mark-up language (XML) file, a geospatial data file, or an image file, etc.

A dataset represents a feature class, image, elevation dataset, or web service. This is also referred to as the “resource” that is described by SMIS metadata.

Metadata To facilitate common understanding, a number of characteristics, or attributes, of data are defined. These characteristics of data are known as “metadata”, that is, “data that describes data.”

The SMIS documentation of the characteristics of a feature class, image, elevation dataset, or web service.

Web Service A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

A web service software system designed to support interoperable machine-to-machine interaction over a network using any of the members of the SMIS Distributed Computing Enviroment codelist (DCPList).


18

Annex A Recommendations For Ambiguous Fields

The following sections describe choices made by the IGI&S Governance group in the development of the Crosswalk.

Decision 1: “modified” Field

The “modified” or “Last Updated” field is defined as “Most recent date on which the dataset was changed, updated or modified.”

There are three possibilities from the ISO 19115 to POD crosswalk and DISDI has added a fourth. The possibilities are:

1. resource maintenance frequency

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:resourceMaintenance/gmd:MD_MaintenanceInformation/gmd:maintenanceAndUpdateFrequency/gmd:userDefinedMaintenanceFrequency/gts:TM_PeriodDuration

2. data citation revision date

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode == "revision" + gmi:MI_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:date/gco:Date

3. first data citation date available

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:date/gco:Date

4. DISDI Recommendation: the actual modification date

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:date/gmd:CI_Date/gmd:dateType/gmd:CI_DateTypeCode[. = "revision"]/../../gmd:date/gco:Date

DISDI Recommends Option #4 on the basis of the following analysis:

1. Option 1 does not correctly meet the definition because it is not a date but a definition of the update frequency.

2. Option 2 is partly correct (in the first part of the XPath) but incorrect in the second half because it only refers to the imagery and gridded data date citation. If the gmi:MI_Metadata portion was replaced with a /, it would be correct, but Option 4 is a direct XPath to the same thing.

3. Option 3 is a date, but it refers to the first date available and in SMIS that is usually the creation date.

4. Option 4 is the best match because this is a date that is always updated by the ArcGIS Style from the ArcGIS Metadata field //Esri/ModDate which reflect the last modification date.

Decision 2: “publishername” Field

The “publishername” or “Publisher” field is defined as “The publishing entity and optionally their parent organization(s).”

There are three possibilities from the ISO 19115 to POD crosswalk and DISDI has added three more possibilities. The possibilities are:

1. data citedResponsibleParty with publisher roleCode

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:organisationName/gmd:organisationName[../../gmd:role/gmd:CI_RoleCode/@codeListValue='publisher']

2. point of contact with publisher roleCode

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:organisationName[../../gmd:role/gmd:CI_RoleCode/@codeListValue='publisher']


19

3. distributor //gmd:distributionInfo/gmd:MD_Distribution/gmd:distributor/gmd:MD_Distributor/gmd:distributorContact/gmd:CI_ResponsibleParty/gmd:organisationName

4. point of contact with point of contact roleCode

//gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='pointOfContact']/../../gmd:organisationName/gco:CharacterString

5. data citedResponsibleParty with publisher roleCode (corrected)

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='publisher']/../../gmd:organisationName/gco:CharacterString

6. point of contact with publisher roleCode (corrected)

//gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='pointOfContact']/../../gmd:organisationName/gco:CharacterString


1. Option 1 is an incorrect XPath and is corrected in Option #5.

2. Option 2 is an incorrect XPath and is corrected in Option #6.

3. Option 3 is a correct XPath, but it refers the MD_Distribution element which was removed from SDSFIE-M.

4. Option 4 suggests that the organization of the point of contact should be the publisher name. This is desirable because point of contact is mandatory and will be always required by SDSFIE-M and any implementation tool.

5. Option 5 is the corrected XPath from Option #1. It suggests that an explicit publisher role be created as part of the Citation information. While this is not currently required by SDSFIE-M, it can be required by the SMIS2POD tool. The tool can issue an error message if the publisher role is missing to indicate to the user that they will need to add such a role in their metadata editing environment before publishing the resource.

6. Option 6 is the corrected XPath from Option #2. It suggests a point of contact with the publisher role and is very similar to the solution in Option #5. This is also not currently required by SDSFIE-M.

Decision 3: “publishersubOrganizationOf” Field

The “publishersubOrganizationOf” field is defined as the parent of the publisher organization. It is the intention of the POD to list these hierarchically in succession downward from the root “U.S. Government”. An example for the DISDI Program Office might be:

"publisher": {

"@type": "org:Organization",

"name": "DISDI Program",

"subOrganizationOf": {


"name": "Business Systems and Information Office",



"name": "Office of Assistance Secretary of Defense for Energy, Installations, and Environment",



"name": "Office of the Under Secretary of Defense for Acquisition, Technology and Logistics",


20



"name": "Office of the Secretary of Defense",



"name": "Department of Defense",



"name": "U.S. Government"

}

}

}

}

}

}

}

The capability to provide a hierarchy of organizational relationship like this is not present in ISO 19115 or SDSFIE-M.

Options are as follows:

Option #1: List only the organization referred to in the publisher element and, in keeping with the optionality of the subOrganizationOf element, do not list a hierarchy at all stopping at the first level. For example:

"publisher": {


"name": "DISDI Program"

}

Option #2: Provide guidance to components about how to specify their organization and allow that to be grounded to a relatively shallow hierarchy provided by DISDI and made available at the time of generation of POD v1.1 JSON. The hierarchy would be something like the following with Components grounding themselves to one of the items in the list (except for those in ALL CAPS):

Department of the Army

Office of the Secretary of the Army

Assistant Secretary of the Army (Civil Works)

United States Army Corps of Engineers

The Army Staff

The Army

Department of the Navy

Office of the Chief of Naval Operations

The Navy

Office of the Secretary of the Navy

Headquarters Marine Corps

The Marine Corps

Department of the Air Force

Office of the Secretary of the Air Force

The Air Staff

The Air Force

Joint Chiefs of Staff

COMBATANT COMMANDS

Africa Command


21

Central Command

European Command

Northern Command

Pacific Command

Southern Command

Special Operations Command

Strategic Command

Transportation Command

Office of the Secretary of Defense

Deputy Secretary of Defense

Executive Secretary of the Department of Defense

Under Secretary of Defense for Acquisition, Technology and Logistics (AT&L)

Under Secretary of Defense Comptroller/Chief Financial Officer (USD(C)/CFO)

Under Secretary of Defense for Intelligence

Under Secretary of Defense for Personnel and Readiness (P&R)

Under Secretary of Defense for Policy

Deputy Chief Management Officer

Assistant Secretary of Defense for Acquisition (ASD(A))

Assistant Secretary of Defense for Asian & Pacific Security Affairs (APSA)

Assistant Secretary of Defense for Global Strategic Affairs (GSA)

Assistant Secretary of Defense for Health Affairs (HA)

Assistant Secretary of Defense for Homeland Defense and Global Security

Assistant Secretary of Defense for International Security Affairs (ISA)

Assistant Secretary of Defense for Legislative Affairs (LA)

Assistant Secretary of Defense for Logistics and Materiel Readiness (L&MR)

Assistant Secretary of Defense for Chief Information Officer (DoD CIO)

Assistant Secretary of Defense for Nuclear & Chemical & Biological Defense Programs (NCB)

Assistant Secretary of Defense for Operational Energy Plans and Programs (OEP&P)

Assistant Secretary of Defense for Public Affairs (PA)

Assistant Secretary of Defense for Research & Engineering ASD(R&E)

Assistant Secretary of Defense for Reserve Affairs (RA)

Assistant Secretary of Defense for Special Operations and Low Intensity Conflict (SO/LIC)

Assistant Secretary of Defense for Strategy, Plans and Capabilities

General Counsel of the Department of Defense

Inspector General of the Department of Defense

Director of OSD Cost Assessment and Program Evaluation (CAPE)

Director of Operational Test and Evaluation (DOT&E)

Assistant to the Secretary of Defense for Intelligence Oversight (IO)

Director of Administration and Management (DA&M)

Deputy Under Secretary of Defense for Advanced Systems and Concepts

Deputy Assistant Secretary of Defense for Civilian Personnel Policy


22

Deputy Assistant Secretary of Defense Manufacturing and Industrial Base Policy

Deputy Under Secretary of Defense for Installations and Environment (I&E)

Deputy Under Secretary of Defense for Logistics and Material Readiness

Deputy Assistant Secretary of Defense for Military Community and Family Policy

Deputy Assistant Secretary of Defense for Military Personnel Policy

Deputy Assistant Secretary of Defense for Readiness

Deputy Assistant Secretary of Defense for Wounded Warrior Care and Transition Policy

DEFENSE AGENCIES

Defense Advanced Research Projects Agency

Defense Commissary Agency

Defense Contract Audit Agency

Defense Contract Management Agency *

Defense Finance and Accounting Service

Defense Information Systems Agency *

Defense Intelligence Agency *

Defense Legal Services Agency

Defense Logistics Agency *

Defense Security Cooperation Agency

Defense Security Service

Defense Threat Reduction Agency *

Missile Defense Agency

National Geospatial-Intelligence Agency *

National Reconnaissance Office *

National Security Agency/Central Security Service *

Pentagon Force Protection Agency

FIELD ACTIVITIES

Defense Media Activity

Defense POW/Missing Personnel Office

Defense Technical Information Center

Defense Technology Security Administration

DoD Education Activity

DoD Human Resources Activity

DoD Test Resource Management Center

Office of Economic Adjustment

TRICARE Management Activity

Washington Headquarters Services

DISDI recommended Option #2 on the basis that it is in the spirit of the Open Data initiative by providing somewhat of a hierarchy but does not go into a full hierarchy. However, we decided to go with option #1 for the first version of the converter while we work out the hierarchy and integration with another mechanism used by the Corps of Engineers.

Decision 4: “contactPointfn” Field

The “contactPointfn” or “Name” field is defined as “Contact person’s name [and email] for the asset.


23

There are two options with alternatives for a total of six possibilities from the ISO 19115 to POD crosswalk. The possibilities are:

1. point of contact //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode/@codeListValue='pointOfContact']

a. person name + ../../gmd:individualName/gco:CharacterString

b. organization + ../../gmd:organisationName/gco:CharacterString

c. position + ../../gmd:positionName/gco:CharacterString

2. data citedResponsibleParty with ‘pointOfContact’ roleCode

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='pointOfContact']

a. person name + ../../gmd:individualName/gco:CharacterString

b. organization + ../../gmd:organisationName/gco:CharacterString

c. position + ../../gmd:positionName/gco:CharacterString

DISDI Recommends Option #1b on the basis of the following analysis:

1. Options 1a, 1b, and 1c are all related to the Point of Contact provided for the resource. This is mandatory in SDSFIE-M and is the best choice. Option 1b most closely matches the previous IGG agreement to use organizational points of contact.

2. Options 2a, 2b, and 2c are all related to a cited responsible person with the point of contact role. This is optional in SDSFIE-M.

Decision 5: “contactPointhasEmail” Field

The “contactPointhasEmail” or “Email” field is defined as “Contact person’s [name and] email for the asset.

There are two options from the ISO 19115 to POD crosswalk. The possibilities are:

1. point of contact email //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:pointOfContact/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='pointOfContact']/../../gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:electronicMailAddress/gco:CharacterString

2. data citedResponsibleParty with ‘pointOfContact’ roleCode email

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:role/gmd:CI_RoleCode[.='pointOfContact']/../../gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:electronicMailAddress/gco:CharacterString


1. Option 1 is related to the Point of Contact provided for the resource. This is mandatory in SDSFIE-M and is the best choice. NOTE: This should be an organizational email and not an individual email address!

2. Option 2 is related to a cited responsible person with the point of contact role. This is optional in SDSFIE-M.

Decision 6: “identifier” Field

The “identifier” or “Unique Identifier” field is defined as “A unique identifier for the dataset or API as maintained within an Agency catalog or database”.

There are four options from the ISO 19115 to POD crosswalk. The possibilities are:


24

1. Digital Object Identifier (DOI) URL

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:identifier/gmd:MD_Identifier/gmd:code/gmx:Anchor/@xlink:href

2. data identifier //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:identifier/gmd:MD_Identifier/gmd:code

3. metadata identifier //gmd:fileIdentifier/gco:CharacterString

4. title //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title


1. Option 1 is related to a digital object identifier that is optional in SDSIFE-M and that is not otherwise well-defined.

2. Option 2 is related to a data identifier that is optional in SDSIFE-M and that is not otherwise well-defined.

3. Option 3 is related to the metadata (or file) identifier that is mandatory in SDSIFE-M and that is populated by the SDSFIE Online Browse/Generate tool with the lifecycle identifier of the SDSFIE Registry entity represented by the feature class. This is the best choice..

4. Option 4 is related to the title of the dataset and fail to meet the spirit of the POD definition.

Decision 7: “accessLevel” Field

The “accessLevel” shall always be “public”. DISDI recommends that POD records for “non-public” or “restricted public” data not be created until such time as an appropriate federal data sharing environment exists for such restricted/sensitive data.

Decision 8: “bureauCode” Field

The “bureauCode” is to be drawn from the following table.

Department Agency Bureau Code

Department of Defense--Military Programs Department of Defense--Military Programs 7:0

Department of Defense--Military Programs Military Personnel 7:5

Department of Defense--Military Programs Operation and Maintenance 7:10

Department of Defense--Military Programs International Reconstruction and Other Assistance 7:12

Department of Defense--Military Programs Procurement 7:15

Department of Defense--Military Programs Research, Development, Test, and Evaluation 7:20

Department of Defense--Military Programs Military Construction 7:25

Department of Defense--Military Programs Family Housing 7:30

Department of Defense--Military Programs Revolving and Management Funds 7:40

Department of Defense--Military Programs Allowances 7:45

Department of Defense--Military Programs Trust Funds 7:55

Department of Defense--Civil Programs Corps of Engineers--Civil Works 202:0

Decision 9: “programCode” Field

The “programCode” is to be drawn from the following table. DISDI recommends deleting all codes except the generic DoD code and all the USACE codes.


25

Agency Name Program Name Program Code

Department of Defense

(Primary Program Not Available) 007:000


Bomber Forces 007:001


Intercontinental Ballistic Missiles (ICBMs) 007:002


Strategic Land-Based missile (SLBM) 007:003


Activities Supporting Bombers & ICBMs 007:004


Space Defense 007:005


Ballistic Missile Defense 007:006


Interceptors 007:007


North American Aerospace Defense Command (NORAD) and Space Command (SPACECOM) Support

007:008


Surveillance 007:009


Air Defense Initiative 007:010


Surveillance/Warning 007:011


Command Centers 007:012


Communications 007:013


Army Division Increment 007:014


Army Non-Divisional Combat Increment 007:015


Army Tactical Support Increment 007:016


Marine Ground Forces 007:017


Army Special Mission Forces 007:018


Army Base Operations Support (BOS) and Mgmt., Headquarters (HQ)s

007:019


Army Operational Support 007:020


Army Research and Development Support (R&D) 007:021


26


Army Systems Support 007:022


Marine Ground Forces Support 007:023


Air Force 007:024


Marine 007:025


Navy 007:026


Submarines 007:027


Surface Combatants 007:028


Amphibious Forces 007:029


Service Forces 007:030


Mine Warfare Forces 007:031


Maritime Patrol & Undersea Surveillance 007:032


Sea Based Anti-Submarine Warfare (ASW) Air Forces 007:033


Non-Strategic Nuclear Naval Forces 007:034


Fleet Support 007:035


Navy Systems Support 007:036


Navy R&D Support 007:037


Navy BOS & Mgmt., HQs 007:038


Other Operational Support 007:039


Multimode & lntermodal Lift 007:040


Airlift Forces 007:041


Sealift Forces 007:042


Land Mobility Forces 007:043


SOF Operations 007:044


27


SOF Support Activities 007:045


General Purpose Support 007:046


Theater Missile Defense 007:047


Counterdrug Support 007:048


Defense-Wide Intelligence Program 007:049


Centrally Managed Communications 007:050


Satellite Communications 007:051


Command & Control Activities 007:052


Information Management Activities 007:053


Technology Base 007:054


Advanced Development 007:055


Undistributed Demonstration / Validation (DemVal) Programs

007:056


Undistributed Engineering and Manufacturing Development (EMD) Programs

007:057


R&D Support Activities 007:058


R&D BOS & Mgmt. HQs 007:059


Geophysical Activities 007:060


Geophysical BOS & Mgmt., HQs 007:061


Space Launch Support 007:062


Nuclear Weapons Support 007:063


International Support 007:064


Security & Investigative Activities 007:065


Supply Operations 007:066


Maintenance Operations 007:067


28


Logistics Support to R&D Activities 007:068


Logistics Support to Procurement Activities 007:069


Logistics Support to MILCON Activities 007:070


Logistics BOS & Mgmt. HQs 007:071


Other Logistics Support 007:072


Personnel Acquisition 007:073


Personnel Acquisition Base Operations 007:074


Military Personnel Training 007:075


Civilian Personnel Training 007:076


Flight Training 007:077


Intelligence Skill Training 007:078


Health Personnel Training 007:079


Training BOS & Management. HQs 007:080


Hospitals & Other Medical Activities 007:081


Medical BOS & Mgmt. HQs 007:082


Individuals 007:083


Federal Agency Support 007:084


Family Housing 007:085


Dependent Education 007:086


Other Personnel Support Activities 007:087


Personnel BOS & Mgmt., HQs 007:088


Departmental HQ 007:089


Departmental Services 007:090


29


Departmental BOS & Mgmt., HQs 007:091

US Army Corps of Engineers

(Primary Program Not Available) 202:000


Navigation 202:001


Flood Risk Management 202:002


Environment 202:003


Hydropower 202:004


Regulation and Aquatic Resources 202:005


Disaster Response and Emergency Management 202:006


Recreation 202:007


Water Supply 202:008

Decision 10: “temporal” Field

The “temporal” or “Temporal” field is defined as “The range of temporal applicability of a dataset (i.e., a start and end date of applicability for the data).”

There are three possibilities from the ISO 19115 to POD crosswalk. The possibilities are:

1. min and max value of multiple date ranges

if more than two instances of this field exist choose the earliest date value and latest date value to populate the range of dates //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimeInstant/timePosition

2. time period begin and end dates

//gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimePeriod/gml:beginPosition

+ //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimePeriod/gml:endPosition

3. time instant if single date use this field to populate as both start/end date //gmd:identificationInfo/gmd:MD_DataIdentification/gmd:extent/gmd:EX_Extent/gmd:temporalElement/gmd:EX_TemporalExtent/gmd:extent/gml:TimeInstant/timePosition

DISDI Recommends all three options be used and that SMIS2POD check these conditions generating output on the first condition that matches in the order presented here.

Decision 11: “describedBy” Field

The “describedBy” or “Data Dictionary” field is defined as “URL to the data dictionary for the dataset. Note that documentation other than a data dictionary can be referenced using Related Documents”


30

There are two possibilities from the ISO 19115 to POD crosswalk and DISDI has added one possibility. The possibilities are:

1. feature catalog url //gmd:contentInfo/gmd:MD_FeatureCatalogueDescription/featureCatalogueCitation/CI_Citation/citedResponsibleParty/CI_ResponsibleParty/contactInfo/CI_Contact/onlineResource/CI_OnlineResource/linkage/URL

2. data dictionary URL //gmd:aggregationInfo/gmd:MD_AggregateInformation/gmd:aggregateDataSetName/gmd:CI_Citation/gmd:citedResponsibleParty/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:onlineResource/gmd:CI_OnlineResource/gmd:CI_OnlineResource/gmd:linkage/gmd:URL

WHERE:

//gmd:aggregationInfo/gmd:MD_AggregateInformation/gmd:initiativeType/gmd:DS_InitiativeTypeCode == dataDictionary

3. revised feature catalog URL

//gmd:contentInfo/sdsfie:MD_FeatureCatalogueDescription/gmd:featureCatalogueCitation/gmd:CI_Citation/gmd:onlineResource/gmd:CI_OnlineResource/gmd:linkage/gmd:URL


1. Option 1 is incorrect, it is corrected in Option #3.

2. Option 2 is related to a data identifier that is optional in SDSIFE-M and that is not otherwise well-defined.

3. Option 3 has the same intent as Option #1, but is related to the URL of the data dictionary (which should be available at SDSFIE Online, in most cases). The user will need to make sure that they reference the correct URL in the feature catalog, in any case.