US Army Corps of Engineers BUILDING STRONG ® Local Data Requirements and Definitions USACE SDSFIE Training Prerequisites: Creating a Data Dictionary for Your Local Data

BUILDING STRONG ® Video sequence 2 of 24

BUILDING STRONG ® Objectives  Understanding “source” and “target” terminology  Understanding what is a valid SDSFIE element  Understanding how to validate and refine local requirements in a Source Data Dictionary  Understanding where to obtain the definitions to populate a Source Data Dictionary  Understanding how to develop a geodatabase consistent with the final Source Data Dictionary 3 of 24

BUILDING STRONG ® TERMINOLOGY: “SOURCE” AND “TARGET 4 of 24

BUILDING STRONG ® “Source” and “Target”  “source” = current or “as-is” condition of your local data, or local geodatabase schema  “target” = future or “to-be” condition of your local data, or local SDSFIE Adaptation schema 5 of 24 from Source to Target  “Source data”  “Source data dictionary”  “Source geodatabase”  “Source schema”  “Target data”  “Target data dictionary”  “Target geodatabase”  “Target schema” or “Adaptation schema”

BUILDING STRONG ® VALID ELEMENT DEFINITIONS IN THE SDSFIE STANDARD 6 of 24

BUILDING STRONG ® SDSFIE Element Uniqueness: Names and Definitions  Every SDSFIE element has a specific name and one unique definition  Definitions of SDSFIE elements must be unique in meaning; semantic overlap must be minimized  No two SDSFIE elements of same type (e.g., feature type) can have same name, but different definitions  No two SDSFIE elements with different names can have the same definition. ► Generally, no renaming in USACE Adaptations ► Implementation exceptions are provided; in USACE adaptations, the use of an alias is allowable but must be justified 7 of 24

BUILDING STRONG ® Valid SDSFIE Elements: Definitions Relevant rules relative to SDSFIE elements that already exist, and adaptation extenstions:  Rule 4-12: Extended feature types must be logically unique, with non-duplicate names  Rule 4-14: Extended attributes may not have duplicative or conflicting definitions  Section 4.2: “No SDSFIE Adaptation can change the definition or data type of an existing element.” 8 of 24 *Guidance for the Adaptation of SDSFIE 3.0, DISDIG, Version 1.0, 11 May 2011

BUILDING STRONG ® Implications of SDSFIE Element Name and Definiton Policy For the purposes of developing your data dictionary, implement this guidance and these rules as follows:  Do not address definitional conflicts with 3.1 model elements at this time. (That will be done later.)  Address definitional conflicts among your high-level data elements (i.e., feature classes and object tables)  Focus on identifying and resolving any potential conflicts involving your non-standard (custom) high-level data elements 9 of 24

BUILDING STRONG ® VALIDATING LOCAL REQUIREMENTS IN YOUR DRAFT DATA DICTIONARY 10 of 24

BUILDING STRONG ® Validating Local Requirements in your Data Dictionary Steps for reviewing the local requirements, as expressed in your draft data dictionary:  Review all elements to verify they are required  Flag any element that can be excluded  Flag any element that is questionable with respect to inclusion criteria  Identify additional requirements 11 of 24

BUILDING STRONG ® WHERE TO OBTAIN ELEMENT DEFINITIONS TO POPULATE YOUR DATA DICTIONARY 12 of 24

BUILDING STRONG ® Element Definitions Missing from the Data Dictionary have been Highlighted 13 of 24

BUILDING STRONG ® Definitions Sources for Elements from a “Prior Release”  Elements in your local geodatabase may have originated in a prior release of the standard, e.g., SDSFIE 2.6 or SDSFIE 3.0 Gold  With the exception of domain values (aka enumerants), SDSFIE 2.6 Elements are all lowercase and use underscores, e.g., ► soil_sample_point (a 2.6 feature class) ► samp_typ_d (a 2.6 attribute) ► d_smpmeth (a 2.6 domain) ► VIBRACORE (a 2.6 domain value) 14 of 24

BUILDING STRONG ® Obtaining Definitions for Elements from a “Prior Release”  3.0 element definitions are already in your data dictionary if you followed steps in Video 4.  If there are only a very few 2.6 and/or 3.0 feature classes and/or object tables: ► use the website’s Browse interface to obtain definitions 15 of 24

BUILDING STRONG ® Using the Browse Interface to Obtain Definitions 16 of 24  Log in at sdsfieonline.org sdsfieonline.org  Go to the Models & Workflows page  Select the data model ► Click SDSFIE Gold to expand ► Click SDSFIE Retired to select that data model  Scroll down in the Model Elements view to find and select the feature type or object table for which you need the definition  Highlight and copy the required definition

BUILDING STRONG ® Obtaining Definitions for Elements from a “Prior Release”  If you have many 2.6 and/or 3.0 feature classes and/or object tables: ► download the 2.6 or 3.0 Gold workbook model to obtain definitions; these can be found on USACE page of the sdsfieonline.org website: 17 of 24

BUILDING STRONG ® Definition Sources for Elements with non-SDSFIE origin For those elements of your local data that were not based on a prior release of the SDSFIE, these sources may be helpful in obtaining definitions:  Metadata for feature classes and object tables may contain required definitions, including attribute definitions ► If metadata is stored in ArcCatalog metadata model, then access definition through the ArcCatlog’s Description view ► Metadata may be stored in documents outside of the geodatabase and/or ArcCatalog, e.g., text, html, or PDF format ► Other locations (e.g., a domain-specific data dictionary, if you built feature classes from that schema) 18 of 24

BUILDING STRONG ® Communications within Data Owners and Others  For definitions still missing, ask others: ► data owner ► business process owner ► data users  Provide list of elements flagged as “questionable for inclusion in adaptation”  Ask for any additional, known, near-future requirements 19 of 24

BUILDING STRONG ® Finalizing the Source Data Dictionary  Fill in all missing definitions  Make any additional exlusions, found in review  Make any additions (e.g., new requirements)  Resolve any definitional conflicts (e.g., semantic overlap)  (Optional) Send entire data dictioary to local data owners and local data users for final review; solicit final feedback  Make any final changes to data dictionary 20 of 24

BUILDING STRONG ® DEVELOPING A GEODATABASE ALIGNED TO YOUR FINAL DATA DICTIONARY 21 of 24

BUILDING STRONG ® Creating the Final “Source” Geodatabase  Remember that you are still working on the copy of your local geodatabase that you made earlier  Make deletions based on additional exclusions developed in the review process  Do NOT make additions to your schema (e.g., adding a feature class or attribute) if there are no data records present for the element(s)  Implement any other changes resulting from the review process 22 of 24

BUILDING STRONG ® Review 23 of 24  Understanding “source” and “target” terminology  Understanding what is a valid SDSFIE element  Understanding how to validate and refine local requirements in a Source Data Dictionary  Understanding where to obtain the definitions to populate a Source Data Dictionary  Understanding how to develop a geodatabase consistent with the populated Source Data Dictionary

BUILDING STRONG ® Next steps  Videos should be seen next are ► Creating the Local Adaptation  Contact with comments or additional 24 of 24