Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) SDSFIE Vector (SDSFIE-V): Implementation Guidance

Transcription

1 Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) SDSFIE Vector (SDSFIE-V): Implementation Guidance Version 4.0 (31 JANUARY 2017) Prepared By: The IGI&S Governance Group For: The Assistant Secretary of Defense (Energy, Installations & Environment) 2017

2 THIS PAGE IS INTENTIONALLY BLANK i

3 Executive Summary This document contains implementation guidance for the Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) - Vector standard, or SDSFIE-V. SDSFIE-V is applicable to (and mandated for use by) the Installation Geospatial Information and Services (IGI&S) user community, to define the most commonly used vector geospatial entities and related data types used for the mapping requirements related to energy, installations and environment (EI&E) management, test and training range management, and DoD civil works functions. SDSFIE-V includes the current SDSFIE Specification Document, as well as the current Gold Logical Data Model and all Component HQ-level Adaptation Logical Data Models. The SDSFIE Governance Plan requires that implementation guidance be developed for mandated SDSFIE parts. This document fulfills that requirement for SDSFIE-V. Users of SDSFIE-V are urged to review this implementation guidance and related SDSFIE-V artifacts before implementing SDSFIE-V 4.0, the first version of SDSFIE-V to which this guidance document applies. Each SDSFIE-V Gold model is designed as a stand-alone, enterprise-wide baseline community standard. Each Component within the IGI&S Community of Interest (COI) 1 will need to plan for the implementation of the standard as it becomes mandated and tailor (adapt) the standard to their mission through a process known as Adaptation. To maintain interoperability, each organization must follow common guidance to execute the Adaptation. This document provides that guidance according to this outline: Rules that apply to Components as they prepare for and execute the implementation of an SDSFIE-V version (section 2). Guidelines for preparing and implementing a headquarters Adaptation of an SDSFIE-V version (section 3). Rules governing the creation of both headquarters and subordinate Adaptations of SDSFIE-V that are necessary to ensure the interoperability of data (section 4). 1 As defined in DoDI , Installation Geospatial Information and Services (IGI&S) ii

4 Revision History Description Date Version Initial IGG Approved Version (approval date: 13 MAY 2015) 29 APR Minor updates from SDSFIE-V 4.0 Gold modeling (approval date: 8 SEP 2015) Minor update to reduce mapping of String(MAX) from 8000 to Corrected Rules 4-43 to 4-47 to clarify that they are referring to List Enumerations only. Inserted Rule 2-2 "SDSFIE-V Gold Changes" to define the method for introducing changes to SDSFIE-V Gold and to set forth the categorization of changes as Major, Minor, and Corrigendum. Rule 2-2 also contains the criteria for categorization of changes. Updated the new Rule 2-3 (was Rule 2-2) "SDSFIE-V Gold Versioning" to describe a Major, Minor, and Corrigendum release. Updated Rule 3-3 "Submission, Approval and Registration" to add clauses referring to the declaration of a parent at the time of submission, the requirement to make a Corrigendum release if there are corrigendum changes required for conformance of the HQ Adaptation, and the resetting of the parent to be that Corrigendum release. 20 AUG , Revision 1 2 NOV , iii

5 Table of Contents Executive Summary... ii 1 Overview Rules for Governing Implementation of SDSFIE-V Rules for Preparing and Submitting a Headquarters Adaptation Rules for Developing Adaptations General Rules Rules Concerning Elements and Element Properties Entity Elements Attribute Elements Enumeration Elements Enumerant Elements Association Elements Profiles Element Modification Extensions Gold Element Property Rules References Definitions Abbreviations Element Name Properties Overview Style Guide Model Name Property Alias Name Property Alternate Name Values Element Documentation Properties Overview Style Guide Definition Property Description Property Note Property Versioning Lifecycle States iv

6 THIS PAGE IS INTENTIONALLY BLANK v

7 1 Overview The Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) are a family of IT standards (models, specifications) which define a DoD-wide set of semantics intended to maximize interoperability of geospatial information and services for installation, environment and civil works missions. The SDSFIE Vector (SDSFIE-V) standard is the vector data model portion of the SDSFIE family. It is a dictionary of geospatial and related data types commonly used by the DoD mission areas for mapping energy, installations and environment (EI&E), test and training ranges, and civil works. SDSFIE-V includes the current SDSFIE Specification Document, as well as the current Gold Logical Data Model and all Component HQ-level Adaptation Logical Data Models. As shown in Figure 1, SDSFIE Gold consists of a specification document and a model stored in the SDSFIE Registry. These were developed using the new version process as defined in the SDSFIE Governance Plan. The SDSFIE Governance Plan requires the development of implementation guidance for mandated SDSFIE parts. This document represents the fulfillment of that requirement for SDSFIE-V. Users of SDSFIE-V should review these key artifacts before implementing SDSFIE-V 4.0, the first version of SDSFIE-V to which this particular guidance applies. Figure 1: SDSFIE 4.0 Standard and Implementing Documents Each SDSFIE-V Gold model is an enterprise-wide, baseline community standard for IGI&S vector data (aka geospatial features). Each Component within the IGI&S Community of Interest (COI) 2 will need to plan for the implementation of the standard as it becomes mandated and 2 As defined in DoDI , Installation Geospatial Information and Services (IGI&S) 1

8 tailor (adapt) the standard to their mission through a process known as Adaptation. To maintain interoperability, each organization must follow common guidance to execute the Adaptation. This document provides that guidance according to this outline: Rules that apply to Components as they prepare for and execute the implementation of an SDSFIE-V version (section 2). Guidelines for preparing and implementing a headquarters Adaptation of an SDSFIE-V version (section 3). Rules governing the creation of both headquarters and subordinate Adaptations of SDSFIE-V that are necessary to ensure the interoperability of data (section 4). 2 Rules for Governing Implementation of SDSFIE-V The IGI&S Governance Group (IGG) shall govern the implementation of SDSFIE-V in accordance with these rules: Rule 2-1 Applicability 1) All DoD organizations which implement SDSFIE-V must conform to this implementation guidance. 2) This document (and its revisions) applies to all Mandated 3 or Emerging 4 versions of SDSFIE-V. It also applies to all Retired SDSFIE-V versions from version 4.0 onward. 5 Rule 2-2 SDSFIE-V Gold Changes 1) Changes to SDSFIE-V Gold are made using the SDSFIE Governance Plan s Change Management Process (CMP) Change Requests (CRs) (hereafter referred to as CRs ). Changes are categorized by the level interoperability impact that they have on existing implementations. The categories of change are: a. A Major change re-structures elements within a part in such a way that would significantly change the organization of implementations and/or require a major level of effort to populate the new schema (via migration, for example). Major changes have significant impact on the interoperability of implementations. b. A Minor change is a change that does not significantly change the organization of implementations and require a minor level of effort to populate the new schema (via migration, for example). Minor changes have some impact on the interoperability of implementations. c. A Corrigendum change is used to a) correct technical errors in a current version such as typos or incorrectly encoded elements, or b) to introduce changes that do not significantly affect interoperability (such as adding optional elements). 3 See section Ibid. 5 Note that the soon-to-be retired DoD Guidance for the Adaptation of SDSFIE 3.0 still applies to version

9 Corrigendum changes have no (or extremely minor) impact on the interoperability of implementations. 2) The criteria for categorization of changes as major, minor, or corrigendum for SDSFIE are: a. Major change: i. Splitting an existing entity into multiple entities or merging multiple entities into a new entity b. Minor change: i. Adding a required entity that does not duplicate an existing concept ii. Modifying properties of an existing entity in a way that adversely affects interoperability (for example, changing the default or removing a permissible geometry) iii. Adding a required attribute to an entity iv. Modifying the properties of an attribute in non-interoperable ways (e.g., changing a data type, adding a constraining enumeration, adding a default value, decreasing the length, changing precision or scale) v. Changing the properties of an enumeration vi. Changing the meaning of one or more of the enumerants in an existing enumeration vii. Changing an existing association c. Corrigendum change: i. Adding an optional entity that does not duplicate an existing concept ii. Adding an optional attribute to an entity iii. Increasing the length of a string data type for an attribute iv. Adding an enumerant that did not previously exist to an existing enumeration v. Adding an optional association that did not previously exist vi. Adding an enumeration used by an optional attribute that did not previously exist (where the new enumeration cannot cover the same concept space as an existing enumeration and the optional attribute must not already have existed without the enumeration in the current release) vii. Adding a permissible geometry to an entity 3) Changes that do not match the above criteria shall be evaluated for their impact on interoperability and categorized accordingly. 4) Changes that do match any of the above criteria may be re-categorized by the recommendation of the IGG Chair and with unanimous concurrence of the IGG. Rule 2-3 SDSFIE-V Gold Versioning 1) SDSFIE-V versions are categorized into three levels depending on the interoperability impact they have on existing implementations and correspond to the change categories provided above. The version categories are: 3

10 a) A major version is used to collect existing, approved major, minor, and corrigendum changes and should be driven by requirements to implement some significant set of major and minor changes. The scale of changes is in the range of thousands to tens of thousands. The initial version of a major revision has minor (and corrigendum) version set to zero. b) A minor version is used to collect existing, approved minor and corrigendum changes in order to provide a new baseline for implementation and should be driven by requirements to implement some significant set of minor changes. The scale of changes is in the range of hundreds to thousands. The version attribute shall use the Major.Minor version number initially set at 0 and shall be incremented after each minor version (e.g., 4.0 to 4.1). c) A corrigendum version is used collect existing, approved corrigendum changes in order to provide a baseline for Component adaptations. The scale of changes is in the range of tens to hundreds. Each corrigendum version will incorporate all corrigendum-level change requests approved since the last version release of SDSFIE-V. The version attribute shall use the complete Major.Minor.Corrigendum version number initially set at 0 and shall be incremented after each corrigendum release (e.g. 4.0 to or to 4.1.3). 2) Only major and minor revisions will be considered as triggers for changing the specification s status in the DoD IT Standards Registry (DISR). The IGG shall determine when to recommend changing the lifecycle status of a version to Emerging or Mandated. Rule 2-4 Mandated SDSFIE-V Version Milestones 1) As a condition of mandating a major or minor SDSFIE-V version, milestones and deadlines for implementation of a Mandated version shall be developed by the IGG as a governance process and will be recommended for approval by the IGG to the ASD(EI&E) in accordance with DoD Instruction ) The milestones and deadlines that shall be developed for Mandated releases are as follows: Component Implementation Plans Reviewed and Validated Headquarters Adaptation Approved Data Migration Plan Complete Data Migration Complete Rule 2-5 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-V implementation plan aligning to the milestones and deadlines developed under Rule 2-4. 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) Headquarters Adaptation Development Plan and Schedule i) A high-level description of the plan for developing a headquarters Adaptation. 4

11 ii) A schedule for the headquarters Adaptation development. b) Change Management of the headquarters Adaptation i) A description of the process for dealing with change management for the headquarters Adaptation. Component change management processes should follow a similar tiered approach as the SDSFIE Governance Plan Change Management Process (CMP), culminating with a consensus-based decision making step. ii) A description of how the Component change management process will link to the CMP. An example would be, the conditions that would cause a Component change request to be elevated to an IGG-level CR. c) Governance of Subordinate Adaptations i) A policy statement indicating whether subordinate Adaptations are allowed. ii) If subordinate Adaptations are allowed, a description of the governance processes associated with their creation, approval, and implementation. d) Data Migration Plan and Schedule i) A high-level description of the plan for migrating enterprise data from the current version to a new version. ii) A schedule for the enterprise data 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. The IGG Chair shall provide review comments or validation to the Components within 30 days of submission. 3) After first informing the Component and allowing time for their response, the IGG Chair shall inform the IGG of the results of this review in a timely manner. 4) Components may make a case for an exception to the required milestones and deadlines by submitting a formal request to the IGG Chair. Rule 2-6 Headquarters Adaptation 1) Once a version of SDSFIE-V has been mandated and an implementation plan has been developed, a Component shall create an Adaptation of SDSFIE-V Gold using the adaptation process defined in the SDSFIE Governance Plan. This Adaptation shall be referred to as the Components headquarters Adaptation. 2) The headquarters Adaptation shall conform to the rules in section 4, Rules for Developing Adaptations. 3) Once approved, each headquarters Adaptation must be registered and published in the SDSFIE Registry under a reasonable name as defined by the Component and in accordance with this document. a) A reasonable name shall contain the version number of the SDSFIE Gold model from which the model is adapted and some indication of the Component or Component IGI&S Program, for example GEOFidelis

12 b) If a Component updates their headquarters Adaptation, their version number would increment the fourth level version number for each update. For example, 4.0 would become , , and so forth. In another example, would become , , and so on. 4) Components shall create a headquarters Adaptation (and thus begin the implementation process) for a Mandated version of SDSFIE-V Gold according to the milestone and deadline developed under Rule ) No Component shall be more than one version behind the mandated version at any point in time without an exemption from ASD (EI&E). Rule 2-7 Subordinate Adaptations 1) Once Components have an approved and published headquarters Adaptation, Adaptations may be developed below Component headquarters level, depending on Component policy. The Adaptations shall be referred to as subordinate Adaptations. 2) Once Components have a reviewed, conformal plan or guidance for SDSFIE Adaptation, they shall have the authority to review and approve their own subordinate Adaptations. 3) Subordinate Adaptations shall be reviewed/ approved by that Component's IGI&S Program Manager or their designated representative. 4) Subordinate Adaptations may be stored in the SDSFIE Registry and published depending on Component policy. Rule 2-8 Availability of Adaptations 1) All headquarters Adaptations and supporting documentation shall be available to all IGG member organizations via the SDSFIE Registry and web site. 2) Components may, at their discretion, limit any registered subordinate Adaptations which can be seen or used by members of their organization (on the SDSFIE web site) using access control lists or similar methods. Rule 2-9 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 implementation plan or other guidance) which has been reviewed and validated by the IGG Chair. 3) If subordinate Adaptations are allowed, then the Component-level governance process must include a review of lower level proposed Adaptations and the Component headquarters must assert approval before they can be registered and implemented. 4) If subordinate Adaptations are allowed, then Component-level review must validate conformance with: a) SDSFIE-V implementation guidance and rules (i.e., this document); 6

13 b) All Component-level guidance and business rules. 5) Any issues arising from 4) must be resolved with the subordinate Adaptation developer prior to assertion of approval. 6) Copies of approval and supporting documentation shall be provided to the IGG Chair upon request and may be provided on SDSFIE Online. Rule 2-10 New SDSFIE-V Gold Versions Created Using the New Version Process Each new version of the SDSFIE-V shall follow the new version process from the SDSFIE Governance Plan and will include a review of all headquarters Adaptations from the prior release. 3 Rules for Preparing and Submitting a Headquarters Adaptation Components shall prepare and submit headquarters Adaptations according to the rules in this section. Rule 3-1 Consultation of Currently Registered Adaptations Registered Adaptations (of the same version) shall be consulted before embarking on the development of a new Headquarters Adaptation. The purpose of this rule is to promote consistency across Adaptations by providing the opportunity to identify and reuse existing elements meeting the requirements of the Component, rather than duplicate them. This rule will be enforced by the subjective evaluation of reviewers in the adaptation process. Rule 3-2 Headquarters Adaptation Model and Documentation 1) Headquarters Adaptations shall consist of two deliverables : a) Adaptation Model i) All entities, attributes, enumerations, enumerants, and associations that make up the Adaptation are loaded in the SDSFIE Registry. ii) The Adaptation model shall be delivered, as follows: (1) If developed in the SDSFIE Online Model Builder, then nothing further is required as all model elements already exist in the SDSFIE Registry. (2) If developed using the SDSFIE Online Migration Workflow, then nothing further is required as all model elements already exist in the SDSFIE Registry. (3) If Components make a decision to develop Adaptations using other tools or by hand, then the Adaptation model shall be delivered in spreadsheet form in the Adaptation Change Template. The spreadsheet shall have been validated without error i) by the submitting Component using the SDSFIE Online Model Builder tool or ii) by the SDSFIE Support Contractor using an Adaptation ingest tool. iii) The Adaptation model shall include the documentation elements described in Rule b) Adaptation Documentation i) Adaptation Documentation shall be provided in human-readable form (for example, Excel, Word or PDF format). 7

14 ii) The documentation shall include: (1) Introductory text that describes the Adaptation to the IGG audience should contain the following: (a) The process used to develop the Adaptation (b) The organizational context for the Adaptation (c) Description of any global or common attribution (d) Description of the data dictionary (optional) (2) A human-readable data dictionary organized by entity (optional) (a) The entities can be organized by any logical scheme, such as by functional area Rule 3-3 Submission, Approval and Registration 1) Once a Headquarters Adaptation is completed by a Component, the deliverables shall be submitted to the IGG via the IGG Chair thus initiating the adaptation process (defined in the current version of the SDSFIE Governance Plan). 2) For each Headquarters Adaptation submitted, the adaptation process shall be followed through approval and subsequent registration. 3) The submitting Component must declare the exact release of Gold used to create the Headquarters Adaptation (i.e. the parent Adaptation) at the time of submission so that the evaluation can be based on the proper model. Components may use any corrigendum release greater than or equal to as the parent for their Headquarters Adaptation. 4) As stated in Rule 3-1, the Headquarters Adaptation will be evaluated using the adaptation process. If CRs are required to make a conformal Adaptation, then at or before the time of approval a Corrigendum release must be made that contains all required Corrigendum level changes. The Corrigendum release version will become the new parent Adaptation of the Headquarters Adaptation. Any Minor level changes needed for conformance shall be rolled into the next Minor release. Any Major level changes needed for conformance shall be rolled into the next Major release. 4 Rules for Developing Adaptations The ability to adapt the SDSFIE-V is the primary mechanism by which the user community can tailor the specification (or schema) to meet implementation-level business requirements. The implementation flexibility afforded by Adaptation, however, needs to be sufficiently constrained in order to ensure the integrity of the standard and to maximize the interoperability of datasets conforming to Adaptations. This section describes rules and guidelines intended to provide a suitable measure of constraint and as such must be referenced or reflected in Component-level guidance or policy. 8

15 4.1 General Rules For the purposes of SDSFIE-V, an Adaptation is a specific Profile 6 (i.e., strict subset of a parent model) and all the Extensions (i.e., additional Entities, Attributes, and Enumerations) that have been added to the parent model to support the unique business requirements of an implementing organization. In the case of headquarters Adaptations, the parent model is an SDSFIE-V Gold model. In general, Adaptations shall conform to the following rules: Rule 4-1 All Adaptations Derive From SDSFIE-V Gold All Adaptations within a particular version shall be derived from SDSFIE-V Gold of the same version and must have a parent model of the same version. Rule 4-2 Headquarters Adaptations Directly Descend from SDSFIE-V Gold All headquarters Adaptations shall be direct descendants of SDSFIE-V Gold. All other (subordinate) Adaptations by a Component shall be derived from the headquarters Adaptation and are the subject of Component Implementation Guidance. Rule 4-3 DoD Enterprise Adaptations Directly Descend from SDSFIE-V Gold All enterprise-level (e.g., Department of Defense, Office of the Secretary of Defense) Adaptations shall be direct descendants of SDSFIE-V Gold. Other (subordinate) Adaptations may be derived from the enterprise Adaptations notwithstanding Rule 4-2, as appropriate. Rule 4-4 One Adaptation Per Authorized Level Organization (ALO) Only one Approved (Mandated) Adaptation shall be registered per ALO per version. This rule supports the concept that there is always one definitive Adaptation indicated per ALO and that new Adaptations are considered replacements of previous Adaptations which have been purposefully Deprecated (Retired). Rule 4-5 Each PDM Represents One Adaptation In order to preserve round-trip interoperability and migration support with SDSFIE Online, only one Adaptation (in whole or in part) shall apply per physical data model (PDM). Rule 4-6 Adaptations Are Class 2 Profiles An Adaptation shall be a Class 2 Profile 7 of the parent model. Rule 4-7 Business Requirement and Requirement Documentation 1) All Headquarters Adaptations shall include relevant Business Requirement and Requirement Documentation records. 2) Business Requirement records shall include: 6 It is important to understand that an Adaptation being a profile means that it contains all of the elements from the parent unless they are removed in the process of profiling. 7 ISO 19106:2004 Geographic information - Profiles details two classes of conformance, which may be generally thought of as profile types. Conformant Class 1 profiles are a pure subset of the ISO geographic information standards. Conformance class 2 allows profiles to include extensions. Using this nomenclature, a Class 2 profile is a subset of the parent model with the addition of extensions (and modifications) that follow the rules in section 4. 9

16 i) Name a brief name of the business requirement that provides an overview of the requirement. ii) Description a full description of the business requirement. iii) Owner the owner of the requirement. 3) Requirement Documentation records shall include: i) Abbreviation a short common name for the document. An example is DoDD ii) Description an explanation of the requirements document as it relates to the element created or changed. iii) Citation a full citation of the document. An example is DoDD , Sustainment of Ranges and Operating Areas (OPAREAs), iv) Issue Date the date that the document was issued. v) Issuing Authority the issuing authority for the document. The issuing authority must be taken from the following list: (a) osd Office of the Secretary of Defense (b) army Secretary of the Army (c) navy Secretary of the Navy (d) airforce Secretary of the Air Force (e) otherfederal Other Federal (non-dod, details should be provided) (f) other Other (non-dod and non-federal, details should be provided) vi) Issuing Authority Detail further clarification on the authority that issued the document beyond the issuing authority information. 4.2 Rules Concerning Elements and Element Properties Rule 4-8 Models Comprised of Elements Models (and therefore Adaptations) shall be comprised of Elements. Rule 4-9 Element Types Elements shall be one of the types: Entity, Attribute, Enumeration, Enumerant, or Association. Rule 4-10 Element Justification and Related Business Requirement, and Requirements Documentation Records 1) Entity, Attribute, Enumeration, and Association Elements shall have a textual Justification property that describes why the element is included in the Adaptation. Enumerant Elements may have a textual Justification property that describes why the element is included in the Adaptation. 2) Elements may be related to one or more Business Requirement and/ or one or more Requirements Documentation records (see Rule 4-7), if they exist. 10

17 3) Every Element in an Adaptation shall have a textual Justification that describes why the element is included. Justification values may: a) Cite specific business requirements, laws, policy, or regulations which are driving the format of EI&E spatial data elements being adapted. b) Cite specific business systems or processes used as a basis for extensions. c) Cite specific guidance or mechanisms to be used to maintain the Adaptation schema at the ALO level. Rule 4-11 Element Lifecycle ID Property Elements shall have a Lifecycle ID that is represented by a Globally Unique Identifier (GUID). The Lifecycle ID is managed by the SDSFIE Registry and is not directly available to an Adaptation being built outside of the SDSFIE Online environment (and would be populated automatically on ingest into the SDSFIE Registry). The Lifecycle ID uniquely identifies an Element within an Adaptation and also within and across versions within an Adaptation lineage. This enables the traceability of concepts and the management of subclasses. Rule 4-12 Element Model Name Property 1) Elements shall have a Model Name property that corresponds to the default physical name of the Element in a PDM environment. The Model Name property values shall be limited to alphanumeric characters (a-za-z0-9), shall begin with an alphabetic character (a-za-z), and shall not exceed 128 characters in length. 2) Entity Element Model Name property values shall be PascalCase 8 and should not exceed 28 characters in length 9 and shall not exceed 30 characters in length 10. 3) Entity Element Model Name property values for subclasses may include an underscore in the name to separate the parent class name from the child class name. However, this naming convention is no longer required as subclassing information is stored within the model itself (see Rule 4-71). 4) Attribute Element Model Name property values shall be camelcase 11 and shall not exceed 30 characters in length 12. 5) Enumeration Element Model Name property values shall be PascalCase PascalCase means that the name is made up of words (acronyms count as a word) without separating spaces or underscores where the first letter of each word is capitalized, including the first word (as in the name PascalCase ). 9 The 28 character length recommendation is driven by an Oracle database table name length limitation (30 characters) and the length of the commonly used default geometry name extensions ( _P, _L, _A, all 2 characters) that are added when physical implementations are generated by SDSFIE Online. Adapters should note that exceeding the limit can potentially cause truncation of names and/or interoperability issues. 10 The 30 character length requirement is driven by an Oracle database table (feature class) name length limitation. Adapters should note that exceeding the limit can potentially cause truncation of names and/or interoperability issues. 11 camelcase means that the name is made up of words (acronyms count as a word) without separating spaces or underscores where the first letter of each word is capitalized, with the exception of the first word (as in the name camelcase ). 12 The 30 character length requirement is driven by an Oracle database column (field) name length limitation. Adapters should note that exceeding the limit can potentially cause truncation of names and/or interoperability issues. 13 There is no reason to limit these to 28 characters because they are not mapped to table or column names. 11

18 6) Enumerant Element Model Name property values shall be camelcase. 7) Association Element Model Name property values shall be PascalCase. 8) For PascalCase names (Entity, Enumeration, and Association) the following rules apply: a. The first letter of the first word in the name is capitalized (Uppercase). b. The first letter of any subsequent word is always capitalized. c. None but the first letter in any word is capitalized. d. There are no spaces or underscores between words. e. Acronyms are treated as word(s), in above rules.bat f. For example, AboveGroundStorageTank or PolUtilityNode 9) For camelcase names (Attribute, Enumerant) the following rules apply: a. The first letter of the first word in the name is NOT capitalized (lowercase). b. The first letter of any subsequent word is always capitalized. c. None but the first letter in any word is capitalized. d. There are no spaces or underscores between words. e. Acronyms are treated as word(s), in above rules. f. For example, storagetanktype, htmllabel or labelhtml Rule 4-13 Element Alias Name Property Elements shall have an Alias Name property that is used to delineate Elements from one another and to indicate the purpose of the Element. The Alias Name property values shall be allowed to contain any character, except double quotes, and shall not exceed 255 characters. Rule 4-14 Alternate Name Mappings Models (and therefore Adaptations) may be associated with Alternate Name Mappings that provide physical names that differ from Model Names for one or more Elements within the model. Multiple Alternate Name Mappings may be associated with a single model. Mappings are applied to the model at the time a PDM is generated. Rule 4-15 Element Alternate Names Values 1) Elements can have an Alternate Name value that replaces the Model Name property as the physical name of the element in a PDM environment. A particular Element may have more than one Alternate Name value associated, but each Alternate Name value must belong to a single Alternate Name Mapping and, therefore, only a single Alternate Name value can exist for any one element in a PDM. Alternate Name values are stored separately from the Element and are not properties of the Element. 2) Entity or Attribute Element Alternate Name values should not exceed 28 characters in length and shall be limited to alphanumeric characters (a-za-z0-9) and the underscore character (_) and shall not exceed 128 characters in length. 3) Enumeration and Association Element Alternate Name values may be up to 128 characters in length and shall not contain a single quote (') or apostrophe (`) character. 4) Enumerant Element Alternate Name values may be up to 128 characters in length and may contain any character. 12

19 Rule 4-16 Element Definition Property All Elements shall have a populated Definition property that contains a precise statement of the nature, properties, scope, or essential qualities of the concept. The value of this property shall not exceed 4000 characters. Rule 4-17 Element Description Property All Elements shall have a Description property that contains an optional statement of the nature, properties, scope, or non-essential qualities of the concept that are not specified by the Definition. The Description property shall be the property where examples are provided as they serve to augment the Definition. The value of this property shall not exceed 4000 characters. Rule 4-18 Element Note Property All Elements shall have a Note property that contains optional, additional information regarding the concept, for example, constraints on usage or indications of other Elements that may be considered instead of this Element. The value of this property shall not exceed 4000 characters. Rule 4-19 Element Is Gold Property All Elements shall have an Is Gold property that indicates whether the element is from the SDSFIE-V Gold version model. If the value is true, then the Element exists in the SDSFIE-V Gold version. If the value is false, then the Element has been added by an Adaptation. Rule 4-20 Element Is Required Property All Elements shall have an Is Required property that indicates whether the Element is required to be maintained in any child Adaptation. If the value is true, then the Element shall not be profiled in an Adaptation. Rule 4-21 Element Must Justify Profile Action Property All Elements shall have a Must Justify Profile Action property that indicates whether the element can be profiled from any child adaptation as long as a justification is provided. If the Is Required property is true, then the Must Justify Profile Action property must be false. If the Must Justify Profile Action property is true, then the Is Required property must be false. Both of the Must Justify Profile Action and Is Required properties can be false. 4.3 Entity Elements Rule 4-22 Entity Elements Represent Feature and Object Types Entity Elements shall be used to represent Feature and Object Types. Rule 4-23 Entity Element Default Geometry property 1) Entity Elements shall have a Default Geometry property with the possible values of Point, Line, Area, or None. 2) Feature Types shall have a Default Geometry property value or Point, Line, or Area. 3) Object Types shall have a Default Geometry property value of None. Rule 4-24 Entity Element Permissible Geometry Property 13

20 1) Entity Elements shall have a Permissible Geometry property with the possible values that represent every possible combination of Point, Line, and Area or may be None. 2) Feature Types shall have a populated Permissible Geometry property that contains at least the Default Geometry property value and zero or more of the other two values. 3) Object Types shall have a Permissible Geometry property value of None. Rule 4-25 Entity Element Subclass Of Property 1) Entity Elements shall have a Subclass Of property that indicates the parent Entity Element if the Entity Element is a subclass (see Rule 4-71). 2) The value of the property in the SDSFIE Registry shall be a Lifecycle ID of the root Entity Element contained within the Adaptation lineage of the superclass and will, logically, refer to the instance of superclass in the parent model. 3) Subclasses built using the Adaptation Template methodology described in section 2 must simply supply the Model Name of the superclass Entity Element within the parent model or within Entity Extensions (see section 4.10). 4) If an Entity Element is not a subclass, then the value of the Subclass Of property shall be NULL. 4.4 Attribute Elements Rule 4-26 Attribute Elements Represent Feature or Object Type Attributes Attribute Elements shall be used to represent the attributes of Feature or Object Types. Every Attribute Element shall be associated with the Entity Element that represents the Feature or Object Type to which the attribute belongs. Rule 4-27 Attribute Element Data Type Property 1) Attribute Elements shall have a Data Type property that indicates the data type of the attribute. 2) A value of the Data Type attribute must be one of the following: a) String a sequence of characters from the ASCII character set. This maps to TEXT in Esri. The value of the Length or Precision property is passed along as the length of the sequence. The value of the Scale property is ignored. b) String(MAX) a sequence of characters from the ASCII character set that maps to a string with length of This maps to TEXT in Esri. The values of the Length or Precision and Scale properties are ignored. c) Integer a numeric representation of whole numbers for values within the specific range of -2,147,483,648 to 2,147,483,647. This maps to LONG INTEGER in Esri. The values of the Length or Precision and Scale properties are ignored. 14 This length is selected so that it avoids data type mismatch problems in Esri (specifically, SDE/Oracle) 14

21 d) Short a numeric representation of whole numbers for values within the specific range of -32,768 to 32,767. This maps to a SHORT INTEGER in Esri. The values of the Length or Precision and Scale properties are ignored. e) Real a numeric representation of a number with a fractional part within the approximate range -2.2 x to 1.8 x This maps to a DOUBLE in Esri. The value of the Length or Precision property is passed as the precision of the number and the value of the Scale property is passed along as the scale. f) Decimal a numeric representation of a number with a fractional part within the approximate range -2.2 x to 1.8 x This maps to a DOUBLE in Esri. The value of the Length or Precision property is passed as the precision of the number and the value of the Scale property is passed along as the scale. g) Date, DateTime, Time a date and/or time. The value should be in the format mm/dd/yyyy hh:mm:ss plus AM or PM. This maps to DATE in Esri. The values of the Length or Precision and Scale properties are ignored. h) GUID a globally unique identifier. This maps to GUID in Esri. The values of the Length or Precision and Scale properties are ignored. i) Blob data stored as a long sequence of binary numbers. This maps to BLOB in Esri. The values of the Length or Precision and Scale properties are ignored. j) TrueOrFalse a representation of the values true and false. This maps to a TEXT of length 5 with the associated domain sdstrueorfalse in Esri. sdstrueorfalse has the values true, false, and tbd. The values of the Length or Precision and Scale properties are ignored. k) YesOrNo a representation of the values yes and no. This maps to a TEXT of length 3 with the associated domain sdsyesorno in Esri. sdsyesorno has the values yes, no, and tbd. The values of the Length or Precision and Scale properties are ignored. Rule 4-28 Attribute Element Length or Precision Property 1) Attribute Elements shall have a Length or Precision property that indicates the length or precision of the data type, depending on the context described in Rule ) The Length or Precision property value shall not exceed 7999 for String Data Types. 3) The Length or Precision property value shall not exceed 15 for Real or Decimal Data Types. Rule 4-29 Attribute Element Scale Property 1) Attribute Elements shall have a Scale property that indicates the scale of the data type, depending on the context described in Rule ) The Scale property value shall not exceed 15 for Real or Decimal Data Types. Rule 4-30 Attribute Element Is Nullable Property 1) Attribute Elements shall have an Is Nullable property that indicates whether the attribute can contain NULL values. 2) If the Is Nullable property is true, then the attribute can contain NULL values. 3) If the Is Nullable property is false, then the attribute shall not contain NULL values. 15

22 Rule 4-31 Attribute Element Is PK Property 1) Attribute Elements shall have an Is PK property that indicates whether the attribute represents the Primary Key attribute. 2) If the Is PK property is true, then the attribute does represent the Primary Key attribute. 3) If the Is PK property is false, then the attribute does not represent the Primary Key attribute. Rule 4-32 Attribute Element Default Value Property 1) Attribute Elements shall have an optional Default Value property that indicates the default value for the attribute when an Entity instance is created. 2) The Default Value property value must be consistent with the Data Type. For example, if the Data Type is Real, then the Default Value should be a representation of the Real number such as 0.003, , or -1.8E08. Rule 4-33 Attribute Element Constraining Enumeration Property 1) Attribute Elements shall have an optional Constraining Enumeration property that indicates the enumeration that constrains the value of the attribute. 2) The value of the Constraining Enumeration property must be the Model Name of an Enumeration Element that exists in the Adaptation. Rule 4-34 Every Entity Contains Standard Foundational Attributes 1) Every Entity Element shall have a set of associated standard, foundational Attribute Elements. 2) Feature and Object types shall have the following associated standard foundational Attribute Elements: a) Alias Name: Primary Key Identifier 15 (1) Model Name: entitynameidpk 16 (2) Data Type: String (3) Length: 40 (4) Scale: <null> (5) Definition: Primary Key. A unique, user defined identifier for each record or instance of an entity. (6) Description: <null> (7) Note: <null> (8) Is Nullable: false (9) Is Required: true (10) Is PK: true (11) Justification: Mandated by the IGG as a standard attribute. Intended as a common attribution for a locally unique identifier for inter-database identification that is also suitable for use across migrations (when implementation specific keys, such as the OID in Esri, typically get reset). 15 This is not strictly a primary key because that role is assumed in implementations by another variable. This is, however, intended to be the primary key for associations made with SDSFIE and thus the use of the term. 16 Where {entityname} is the model name of the Entity for which this attribute is the primary key. The entire model name will be 30 characters or less and {entityname} can either be truncated or adjusted to fit as decided by the modeler submitting the name. 16

23 b) Alias Name: Globally Unique Identifier (1) Model Name: sdsid (2) Data Type: GUID (3) Length: <null> (4) Scale: <null> (5) Definition: A unique identifier for all entities in the SDSFIE. (6) Description: <null> (7) Note: <null> (8) Is Nullable: true (9) Is Required: true (10) Is PK: true (11) Justification: Mandated by the IGG as a standard attribute. Intended as a common attribution for a global unique identifier for cross database identification that is also suitable for use across migrations (when implementation specific keys, such as the GlobalID in Esri, typically get reset). 3) Feature types shall have the following additional associated standard foundational Attribute Elements: a) Alias Name: Feature Name (1) Model Name: featurename (2) Data Type: String (3) Length: 80 (4) Scale: <null> (5) Definition: The common name of the feature. (6) Description: <null> (7) Note: <null> (8) Is Nullable: true (9) Is Required: true (10) Is PK: false (11) Justification: Mandated by the IGG as a standard attribute. Intended as a common attribution for the name of an individual feature. b) Alias Name: Feature Description (1) Model Name: featuredescription (2) Data Type: String(MAX) (3) Length: <null> (4) Scale: <null> (5) Definition: A narrative describing the feature. (6) Description: <null> (7) Note: <null> (8) Is Nullable: true (9) Is Required: true (10) Is PK: false (11) Justification: Mandated by the IGG as a standard attribute. Intended as a common attribution for a description of an individual feature. c) Alias Name: Media Identifier (1) Model Name: mediaid (2) Data Type: String (3) Length: 40 (4) Scale: <null> (5) Definition: Used to link the record to associated multimedia records that reference data. (6) Description: Example media types include imagery, video, audio, scanned documents, and drawings. (7) Note: See your DoD Component service implementation guidance for details as to the content of this attribute. (8) Is Nullable: true (9) Is Required: true 17

24 (10) Is PK: false (11) Justification: Mandated by the IGG as a standard attribute. Intended to provide a common mechanism for linking media to entities. d) Alias Name: Metadata Identifier (1) Model Name: metadataid (2) Data Type: String (3) Length: 80 (4) Scale: <null> (5) Definition: Used to represent or link to feature level metadata. (6) Description: <null> (7) Note: <null> (8) Is Nullable: true (9) Is Required: false (10) Must Justify Profile Action: true (11) Is PK: false (12) Justification: Mandated by the IGG as a standard attribute. Intended to provide a way to link to feature level metadata records or as a way to store feature level metadata. e) Alias Name: Installation Identifier (1) Model Name: installationid (2) Data Type: String (3) Length: 11 (4) Scale: <null> (5) Definition: The code assigned by the DoD Component used to identify the site or group of sites that make up an installation. (6) Description: <null> (7) Note: Components may extend this attribute by utilizing their own enumeration as a constraint. (8) Is Nullable: true (9) Is Required: false (10) Must Justify Profile Action: true (11) Is PK: false (12) Justification: Mandated by the IGG as a standard attribute. Intended to provide a way to represent or link to the installation on which the feature exists. Rule 4-35 Real Property Entity Contains Standard Real Property Attributes 1) Every Entity Element that represents a real property asset shall have a set of associated standard, real property Attribute Elements. 2) Feature types that represent Real Property Assets may have one or more of the following standard real property Attribute Elements as determined by the IGG (and subject matter experts): a) Alias Name: Real Property Unique Identifier (1) Model Name: rpuid (2) Data Type: String (3) Length: 18 (4) Scale: <null> (5) Definition: A non-intelligent code used to permanently and uniquely identify a DoD real property asset. (6) Description: RPUIDs are exclusively issued by the Real Property Unique Identifier Registry (RPUIR). (7) Note: All of the characters in the RPUID value must be numeric [0-9]. Source: DoDI , January 17, (8) Is Nullable: true (9) Is Required: true 18

25 (10) Must Justify Profile Action: false (11) Is PK: false (12) Justification: This attribute is necessary to ensure interoperability between IGI&S systems and Real Property systems of record. b) Alias Name: Real Property Site Unique Identifier (1) Model Name: rpsuid (2) Data Type: Integer (3) Length: <null> (4) Scale: <null> (5) Definition: A non-intelligent code used to permanently and uniquely identify a DoD real property site. (6) Description: RPSUIDs are exclusively issued by the Real Property Unique Identifier Registry (RPUIR). (7) Note: Source: DoDI , January 17, (8) Is Nullable: true (9) Is Required: true (10) Must Justify Profile Action: false (11) Is PK: false (12) Justification: This attribute is necessary to ensure interoperability between IGI&S systems and Real Property systems of record. c) Alias Name: Real Property Network Identifier (1) Model Name: rpnid (2) Data Type: String (3) Length: 4 (4) Scale: <null> (5) Definition: The designator that distinguishes one real property network (RPN) from another within a RPI database. (6) Description: Each Real Property Network Identifier is system dependent (likely system generated) at the site/installation level. For combined data from multiple databases and upward reporting, the Real Property Network Identifier can be concatenated with the Real Property Site Unique Identifier (RPSUID) to identify the specific network. Each real property network shall have an installation unique Real Property Network Identifier in the base/installation RPI database. A site/installation may have multiple real property networks of the same type; each independent network must have its own Real Property Network Identifier. There must be at least one linear structure assigned to each Real Property Network Identifier. (7) Note: All of the characters in the RPNID value must be alphanumeric [0-9a-zA-Z]. Source: RPIM Version 8. 1 March 31, (8) Is Nullable: true (9) Is Required: true (10) Must Justify Profile Action: false (11) Is PK: false (12) Justification: This attribute is necessary to ensure interoperability between IGI&S systems and Real Property systems of record. Real property assets shall be reviewed for groups of interrelated buildings, structures, linear structures and land parcels over a large area or throughout the site. Where interrelationships are found, they shall be added to a Real Property Network and assigned a RPNID. Source: DUSD (I&E), Real Property Accountability Transformation Support Scenarios: Life Cycle Management of Real Property Networks, February 10, 2009 (updated: January 31, 2015) d) Alias Name: Real Property Interest (1) Model Name: rpinterest (2) Data Type: String (3) Length: 29 (4) Scale: <null> (5) Definition: A designator used to identify the type of legal interest that DoD holds in a real property asset. 19