SDSFIE Vector (SDSFIE-V): Implementation Guidance...Jan 31, 2017 · 31 JAN 2017 SDSFIE V: Implementation Guidance v4.0 Revision 2 1 1 Overview The Spatial Data Standards for Facilities,

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

SDSFIE Vector (SDSFIE-V): Implementation Guidance

Version 4.0

Revision 2

(31 JANUARY 2017)

Prepared By:

The IGI&S Governance Group

For:

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

© 2017

31 JAN 2017 SDSFIE V: Implementation Guidance v4.0

Revision 2

i

THIS PAGE IS INTENTIONALLY BLANK


Revision 2

ii

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 8130.01, Installation Geospatial Information and Services (IGI&S)


Revision 2

iii

Revision History

Description Date Version

Initial IGG Approved Version (approval date: 13 MAY 2015) 29 APR 2015 4.0

Minor updates from SDSFIE-V 4.0 Gold modeling (approval date: 8 SEP 2015)

20 AUG 2015 4.0, Revision 1

Minor update to reduce mapping of String(MAX) from 8000 to 2000.

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.

2 NOV 2016 4.0, Revision 2


Revision 2

iv

Table of Contents Executive Summary ................................................................................................................... ii

1 Overview ........................................................................................................................... 1

2 Rules for Governing Implementation of SDSFIE-V ........................................................... 2

3 Rules for Preparing and Submitting a Headquarters Adaptation ...................................... 7

4 Rules for Developing Adaptations ..................................................................................... 8

4.1 General Rules ........................................................................................................................................ 9

4.2 Rules Concerning Elements and Element Properties ........................................................................... 10

4.3 Entity Elements .................................................................................................................................... 13

4.4 Attribute Elements ................................................................................................................................ 14

4.5 Enumeration Elements ......................................................................................................................... 20

4.6 Enumerant Elements ............................................................................................................................ 21

4.7 Association Elements ........................................................................................................................... 23

4.8 Profiles ................................................................................................................................................. 25

4.9 Element Modification ............................................................................................................................ 26

4.10 Extensions ............................................................................................................................................ 29

4.11 Gold Element Property Rules ............................................................................................................... 32

5 References ...................................................................................................................... 34

6 Definitions ....................................................................................................................... 34

7 Abbreviations .................................................................................................................. 38

8 Element Name Properties ............................................................................................... 39

8.1 Overview .............................................................................................................................................. 39

8.2 Style Guide ........................................................................................................................................... 39

8.2.1 Model Name Property ...................................................................................................................... 40

8.2.2 Alias Name Property ........................................................................................................................ 40

8.2.3 Alternate Name Values .................................................................................................................... 40

9 Element Documentation Properties ................................................................................ 40

9.1 Overview .............................................................................................................................................. 40

9.2 Style Guide ........................................................................................................................................... 40

9.2.1 Definition Property ........................................................................................................................... 40

9.2.2 Description Property ........................................................................................................................ 41

9.2.3 Note Property .................................................................................................................................. 41

10 Versioning Lifecycle States ............................................................................................. 41


Revision 2

v

THIS PAGE IS INTENTIONALLY BLANK


Revision 2

1

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 8130.01, Installation Geospatial Information and Services (IGI&S)


Revision 2

2

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 Mandated3 or Emerging4 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 8.2.

4 Ibid.

5 Note that the soon-to-be retired “DoD Guidance for the Adaptation of SDSFIE 3.0”still applies to version 3.1.


Revision 2

3

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:


Revision 2

4

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 4.0.1 or 4.1.2 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 8130.01.

2) 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.


Revision 2

5

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 4.0”.


Revision 2

6

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 4.0.0.1, 4.0.0.2, and so forth. In another example, 4.1.2 would become 4.1.2.1, 4.1.2.2, 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 2-2.

5) 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);


Revision 2

7

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 4-10.

b) Adaptation Documentation

i) Adaptation Documentation shall be provided in human-readable form (for example, Excel, Word or PDF format).


Revision 2

8

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 4.0.0 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.


Revision 2

9

4.1 General Rules

For the purposes of SDSFIE-V, an Adaptation is a specific Profile6 (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 Profile7 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.


Revision 2

10

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 3200.15.

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 3200.15, Sustainment of Ranges and Operating Areas (OPAREAs), 2003.

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.


Revision 2

11

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 PascalCase8 and should not exceed 28 characters in length9 and shall not exceed 30 characters in length10.

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 camelCase11 and shall not exceed 30 characters in length12.

5) Enumeration Element “Model Name” property values shall be PascalCase13.

8 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.


Revision 2

12

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.


Revision 2

13

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


Revision 2

14

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 200014. 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)


Revision 2

15

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 10308 to 1.8 x 10308. 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 10308 to 1.8 x 10308. 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 4-27.

2) 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 4-27.

2) 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.


Revision 2

16

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”, “37.5678”, 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 Identifier15 (1) Model Name: entityNameIdpk16 (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.


Revision 2

17

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


Revision 2

18

(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

4165.14, January 17, 2014. (8) Is Nullable: true (9) Is Required: true


Revision 2

19

(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 4165.14, January 17, 2014. (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, 2015.

(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.


Revision 2

20

(6) Description: <null> (7) Note: Source: RPIM Version 8.1 March 31, 2015. (8) Is Nullable: false (9) Is Required: true (10) Must Justify Profile Action: false (11) Is PK: false (12) Constraining Enumeration: RpaInterestType17 (13) Justification: This attribute is necessary to ensure interoperability between IGI&S

systems and Real Property systems of record and to make the IGI&S data more directly useful for the EI&E mission requirements.

4.5 Enumeration Elements

Rule 4-36 Enumeration Elements Represent Attribute Value Constraints

1) Enumeration Elements represent a constraint on the value of an attribute.

2) Enumeration Elements can represent either a range constraint or a list constraint.

3) Enumeration Elements map to either Coded Values Domains or Range Domains in Esri implementations.

4) Enumeration Elements shall have an “Is List?” property whose value indicates whether the element represents a list constraint or not (meaning that it represents a range constraint).

a. An “Is List?” property value of true, indicates a list constraint. These map to a Coded Values Domain in an Esri implementation.

b. An “Is List?” property value of false, indicates a range constraint. These map to a Range Domain in an Esri implementation.

5) Enumeration Elements that represent range constraints constrain the range of values that an attribute can be assigned. For example, a range constraint representing pH can be assigned to an attribute whose values have a range of 0.0 to 14.0.

6) Enumeration Elements that represent list constraints constrain the value of an attribute to a list of possible values, called Enumerants.

Rule 4-37 Enumeration Element “Data Type” Property

1) Enumeration elements shall have a “Data Type” property that indicates the data type of the attribute (see Rule 4-27 for allowable “Data Types”).

2) A value of the “Data Type” for Range Enumeration Elements must be one of Real, Decimal, Integer, Short Integer, Date, DateTime, or Time.

3) A value of the “Data Type” for List Enumeration Elements must be String.

17 The RpaInterestType enumeration is defined in SDSFIE 4.0 Gold and contains a set of eleven interest types including 1) Government/Private Agreement; 2) Easement; 3) U.S. Government owned property, DoD Accountability; 4) U.S. Government owned property, Non-DoD Accountability; 5) Leasehold; 6) Lesser Interest, as defined by a legal instrument; 7) Military Housing Privatization Initiative; 8) Owned by Foreign Government; 9) Owned by Private Entity; 10) Owned by State or Local Government; or 11) U.S. Government owned land, Public Domain


Revision 2

21

Rule 4-38 Enumeration Element “Length or Precision” Property

1) Enumeration 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 4-27.

2) Enumeration Elements whose “Is List?” property is true must have a “Length or Precision” property value equivalent to the maximum length of its associated Enumerant “Model Name” property values.

3) The “Length or Precision” property value shall not exceed 7999 for String “Data Types”.

4) The “Length or Precision” property value shall not exceed 15 for Real or Decimal “Data Types”.

Rule 4-39 Enumeration Element “Scale” Property

1) Enumeration Elements shall have a “Scale” property that indicates the scale of the data type, depending on the context described in Rule 4-27.

2) The “Scale” property value shall not exceed 15 for Real or Decimal “Data Types”.

4.6 Enumerant Elements

Rule 4-40 Enumerant Element “Enumeration” Property

1) Enumerant Elements shall have an “Enumeration” property that indicates the Enumeration Element to which the Enumerant belongs.

2) The value of the “Enumeration” property must be the “Model Name” of an “Enumeration” in the parent model or in a valid Enumeration Extension.

Rule 4-41 Range Enumeration Enumerant Values

1) Range Enumeration Elements must have two associated Enumerant Elements, one where the “Model Name” property must be “minimum” and the other where the “Model Name” property must be “maximum” (and whose “Alias Name” properties must be “Minimum Value” and “Maximum Value”, respectively).

2) The value of the Range Enumerant Elements’ “Definition” property must be consistent with the “Data Type”. For example, if the “Data Type” is Real, then the “minimum” and “maximum” should be a representation of the Real number such as “0.003”, “37.5678”, or “-1.8E08”. The value of the “minimum” must be logically “less than” the “maximum” value.

3) The value of the “Definition” property for the List Enumerant Element having the “Model Name” of “minimum” maps to the Range Domain “Minimum value” in an Esri implementation.

4) The value of the “Definition” property for the List Enumerant Element having the “Model Name” of “maximum” maps to the Range Domain “Maximum value” in an Esri implementation.

Rule 4-42 List Enumeration Enumerant Values

1) List Enumeration Elements can have any number of associated Enumerant Elements, whose “Model Name” and “Alias Name” follow the rules Rule 4-12 and Rule 4-15, respectively.


Revision 2

22

2) The value of the List Enumerant Elements’ “Model Name” property represents a Domain Code in an Esri implementation.

3) The value of the List Enumerant Elements’ “Definition” property represents a Domain Description (or Value) in an Esri implementation.

4) The value of the List Enumerant Elements’ “Alias Name” property can alternatively represent a Domain Description (or Value) in an Esri implementation.

Rule 4-43 Use of Enumerant “To Be Determined”

1) All List Enumeration Elements shall contain an Enumerant Element representing a “To Be Determined” value. The Enumerant Element shall have the following property values:

a. Alias Name: To Be Determined

b. Model Name: tbd

c. Definition: Has not been determined at date of record population, and should be revisited at a later date.

Rule 4-44 Use of Enumerant “Not Applicable”

1) List Enumeration Elements may contain an Enumerant Element representing a “Not Applicable” value. The Enumerant Element shall have the following property values:

a. Alias Name: Not Applicable

b. Model Name: na

c. Definition: Enumeration (and population of attribute) is not applicable for the particular feature (record).

Rule 4-45 Use of Enumerant “Unknown”

1) List Enumeration Elements may contain an Enumerant Element representing an “Unknown” value. The Enumerant Element shall have the following property values:

a. Alias Name: Unknown

b. Model Name: unknown

c. Definition: Has been found to be not knowable at the date of record population.

Rule 4-46 Use of Enumerant “Other”

1) List Enumeration Elements may contain an Enumerant Element representing an “Other” value. The Enumerant Element shall have the following property values:

a. Alias Name: Other

b. Model Name: other

d. Definition: Has been determined to be a specific value that is not present in the current constraining enumeration.

Rule 4-47 Constraining Attributes With List Enumeration Having the “Other” Enumerant

1) Entity elements that contain an Attribute Element constrained by a List Enumeration Element that contains an Enumerant Element called "Other" or that serves a similar purpose of indicating that the Attribute Elements' value is not in the set of Enumerant Elements shall


Revision 2

23

provide a mechanism for explaining the value of the Attribute Elements' value. At least two possibilities exist to implement this rule:

a. Place in the "Note" property of the Attribute Element language similar to "If the Other value is selected, the value of the attribute must be described in the sdsFeatureDescription attribute value." -or-

b. Create another attribute, named something like "otherValueExplanation", for the purpose of containing the description of the attribute value in the case that the Other value is selected and then place in the "Note" property of the Attribute Element language similar to "If the Other value is selected, the value of the attribute must be described in the otherValueExplanation attribute value."

4.7 Association Elements

Rule 4-48 Association Element “Parent (Destination) Entity” Property

1) Association Elements shall have a “Parent (Destination) Entity” property that indicates the Entity Element to which the parent or (destination) end of the association refers.

2) The value of the “Parent (Destination) Entity” property must be the “Model Name” of an “Entity” in the parent model or in a valid Entity Extension.

Rule 4-49 Association Element “Parent (Destination) Attribute” Property

1) Association Elements shall have a “Parent (Destination) Attribute” property that indicates the Attribute Element to which the parent or (destination) end of the association refers.

2) The value of the “Parent (Destination) Attribute” property must be the “Model Name” of an “Attribute” in the parent model or in a valid Attribute Extension.

Rule 4-50 Association Element “Parent (Destination) Role” Property

1) Association Elements shall have a “Parent (Destination) Role” property that indicates the role that the parent or (destination) end of the association fulfills.

2) The value of the “Parent (Destination) Role” property shall be allowed to contain any character, except double quotes and shall not exceed 255 characters.

Rule 4-51 Association Element “Child (Origin) Entity” Property

1) Association Elements shall have a “Child (Origin) Entity” property that indicates the Entity Element to which the child or (origin) end of the association refers.

2) The value of the “Child (Origin) Entity” property must be the “Model Name” of an “Entity” in the parent model or in a valid Entity Extension.

3) The value of the “Child (Origin) Entity” property shall not be equivalent to the value of the “Parent (Destination) Entity” property.

Rule 4-52 Association Element “Child (Origin) Attribute” Property

1) Association Elements shall have a “Child (Origin) Attribute” property that indicates the Attribute Element to which the child or (origin) end of the association refers.

2) The value of the “Child (Origin) Attribute” property must be the “Model Name” of an “Attribute” in the parent model or in a valid Attribute Extension.


Revision 2

24

3) The value of the “Child (Origin) Attribute” property shall not be equivalent to the value of the “Parent (Destination) Attribute” property unless the “Parent (Destination) Entity” and “Child (Origin) Entity” properties differ.

Rule 4-53 Association Element “Child (Origin) Role” Property

1) Association Elements shall have a “Child (Origin) Role” property that indicates the role that the child or (origin) end of the association fulfills.

2) The value of the “Child (Origin) Role” property shall be allowed to contain any character, except double quotes and shall not exceed 255 characters.

3) The value of the “Child (Origin) Role” property shall not be equivalent to the value of the “Parent (Destination) Role” property.

Rule 4-54 Association Element “Multiplicity” Property

1) Association Elements shall have a “Multiplicity” property that indicates the number of records in the Child (Origin) Entity that can relate to a number of records in the Parent (Destination) Entity.

2) The value of the “Multiplicity” property shall be one of the following three values:

a) “One-to-One” – indicates that one Child (Origin) record can relate to only one Parent (Destination) record.

b) “One-to-Many” – indicates that one Child (Origin) record can relate to many Parent (Destination) records.

c) “Many-to-Many” – indicates that one Child (Origin) record can relate to many Parent (Destination) record and conversely, one Parent (Destination) record can relate to many Child (Origin) records.

3) When the value of the “Multiplicity” property is “Many-to-Many,” an intermediate table is automatically created and stored in the physical implementation that has a primary key named “RID” (which stands for relationship identifier) and two foreign keys named “childID” and “parentID” that point to the corresponding record in the Child (Origin) and Parent (Destination) Entity, respectively.

Rule 4-55 Association Element “Update Direction” Property (Esri-specific)

1) Association Elements shall have an “Update Direction” property that is used to set the messaging that will be used in the relationship class created for Esri implementations. This property is used exactly like the notification parameter on a relationship class.

2) The value of the “Update Direction” property shall be one of the following values:

a) “Forward” – messages are sent only from Child (Origin) records to Parent (Destination) records.

b) “Backward” – messages are sent only from Parent (Destination) records to Child (Origin) records.

c) “Both” – messages are sent in both directions.

d) “None” – no messages are sent.

Rule 4-56 Association End Point Attribute Data Types

1) The Parent and Child attribute end points of an Association Element shall have one of the data types String, Decimal, Real, Date, Time, DateTime, Integer, Short, GUID


Revision 2

25

2) The Parent and Child attribute end points shall have equivalent data types.

3) The following additional constraints must also hold true:

a) String – the “Length or Precision” property value must also equate

b) Decimal – the “Length or Precision” and “Scale” property values must also equate

c) Real – the “Length or Precision” and “Scale” property values must also equate

4.8 Profiles

Authorized level organizations may not need to implement all the feature types of the parent model. Profiling is the process of selectively removing (subsetting) optional elements (most notably Entity Elements) from the parent model to create an Adaptation for headquarters or an authorized subordinate level organization (e.g., installation, major command, or regional command).

Rule 4-57 Entity Profiling

1) Entity Elements shall not be profiled if the Entity Elements’ “Is Required” property is true.

2) Entity Elements may be profiled without justification from the parent if the Entity Elements’ “Is Required” property is false and “Must Justify Profile Action” property is false.

3) Entity Elements may be profiled with justification from the parent if the Entity Elements’ “Must Justify Profile Action” property is true and the “Is Required” property is false.

4) Entity Elements shall not be profiled simply to “make way” for a non-standard Entity Extension that logically overlaps the Entity Element.

5) Entity Elements shall not be profiled if any of their attributes are the end point of an Association that still exists in the Adaptation after profiling.

Rule 4-58 Attribute Profiling

1) Attribute Elements shall not be profiled if the Attribute Elements’ “Is Required” property is true.

2) Attribute Elements may be profiled without justification from the parent if the Attribute Elements’ “Is Required” property is false and “Must Justify Profile Action” property is false.

3) Attribute Elements may be profiled with justification from the parent if the Attribute Elements’ “Must Justify Profile Action” property is true and the “Is Required” property is false.

4) Attribute Elements shall not be profiled if they are the end point of an Association that still exists in the Adaptation after profiling.

Rule 4-59 Enumeration Profiling

1) Enumeration Elements shall not be profiled if the Enumeration Elements’ “Is Required” property is true.

2) Enumeration Elements may be profiled without justification from the parent if the Enumeration Elements’ “Is Required” property is false and “Must Justify Profile Action” property is false.

3) Enumeration Elements may be profiled with justification from the parent if the Enumeration Elements’ “Must Justify Profile Action” property is true and the “Is Required” property is false.


Revision 2

26

4) If there are Attribute Elements in an Adaptation where the “Constraining Enumeration” property refer to an Enumeration Element, then that Enumeration Element shall not be profiled.

5) If there are no Attribute Elements in an Adaptation where the “Constraining Enumeration” property refer to an Enumeration Element, then that Enumeration Element shall be profiled.

Rule 4-60 Enumerant Profiling

1) Enumerant Elements shall not be profiled if the Enumerant Elements’ “Is Required” property is true.

2) Enumerant Elements may be profiled without justification from the parent if the Enumerant Elements’ “Is Required” property is false and “Must Justify Profile Action” property is false.

3) Enumerant Elements may be profiled with justification from the parent if the Enumerant Elements’ “Must Justify Profile Action” property is true and the “Is Required” property is false.

Rule 4-61 Association Profiling

1) Association Elements shall not be profiled if the Association Elements’ “Is Required” property is true.

2) Association Elements may be profiled without justification from the parent if the Association Elements’ “Is Required” property is false and “Must Justify Profile Action” property is false.

3) Association Elements may be profiled with justification from the parent if the Association Elements’ “Must Justify Profile Action” property is true and the “Is Required” property is false.

4.9 Element Modification

In some cases, Adaptations may require modifications to elements in the parent model. This section provides rules governing modification of elements.

Rule 4-62 Some Parent Model Entity Properties Immutable

1) If an Entity Element in the parent model is NOT profiled in an Adaptation, then the following Entity Element Properties are immutable (except as noted under the described circumstances):

a) “Model Name” — the “Alternate Name” property can be utilized to provide a different name in an implementation.

b) “Definition”

c) “Description” — the “Description” property can be augmented with additional information.

d) “Note” — the “Note” property can be augmented with additional information.

e) “Is Required” — if false in the parent, it can be changed to true in the Adaptation.

f) “Is Gold”

g) “Subclass Of”

h) “Default Geometry”


Revision 2

27

i) “Permissible Geometry” — the “Permissible Geometry” property can be modified to add or remove geometry values except for the “Default Geometry” property value which must be retained.

Rule 4-63 Parent Model Attribute “Constraining Enumeration” Shall not Be Profiled

If an Attribute Element in the parent model is NOT profiled in an Adaptation and it has a “Constraining Enumeration” property whose value is set, it shall not be removed in the Adaptation.

Rule 4-64 Some Parent Model Attribute Properties Immutable

1) If an Attribute Element in the parent model is NOT profiled in an Adaptation, then the following Attribute Element Properties are immutable (except as noted under the described circumstances):


b) “Definition”



e) “Data Type”

f) “Length or Precision” — this value can change, if the attribute element is constrained by an enumeration and the maximum length of the associated Enumerant “Model Name” properties changes.

g) “Scale”

h) “Is Required” — if false in the parent, it can be changed to true in the Adaptation.

i) “Is Gold”

j) “Is PK”

k) “Is Nullable” — if true in the parent, it can be changed to false in the Adaptation

Rule 4-65 Some Parent Model Enumeration Properties Immutable

1) If an Enumeration Element in the parent model is NOT profiled in an Adaptation, then the following Enumeration Element Properties are immutable (except as noted under the described circumstances):


b) “Definition”



e) “Data Type”

f) “Length or Precision” — this value can change, if the maximum length of the “Model Name” properties of associated Enumerant elements changes.

g) “Scale”


Revision 2

28

h) “Is Required” — if false in the parent, it can be changed to true in the Adaptation.

i) “Is Gold”

Rule 4-66 Some Parent Model Enumerant Properties Immutable

1) If an Enumerant Element in the parent model is NOT profiled in an Adaptation, then the following Enumerant Element Properties are immutable (except as noted under the described circumstances):


b) “Definition”



e) “Is Required” — if false in the parent, it can be changed to true in the Adaptation.

f) “Is Gold”

Rule 4-67 Some Parent Model Association Properties Immutable

1) If an Association Element in the parent model is NOT profiled in an Adaptation, then the following Association Element Properties are immutable (except as noted under the described circumstances):

a. “Model Name” — the “Alternate Name” property can be utilized to provide a different name in an implementation.

b. “Definition”

c. “Description” — the “Description” property can be augmented with additional information.

d. “Note” — the “Note” property can be augmented with additional information.

e. “Is Required” — if false in the parent, it can be changed to true in the Adaptation.

f. “Is Gold”

g. “Parent (Destination) Entity”

h. “Parent (Destination) Attribute”

i. “Parent (Destination) Role” — the “Parent (Destination) Role” may be modified to provide a different role name.

j. “Child (Destination) Entity”

k. “Child (Origin) Attribute”

l. “Child (Origin) Role” — the “Child (Origin) Role” may be modified to provide a different role name.

m. “Multiplicity”

n. “Update Direction”


Revision 2

29

4.10 Extensions

The concept of extending the parent model enables implementing organizations to make additions to the standard to better address the specific business requirements of that organization. Before creating an extension, SDSFIE-V Gold and all registered Adaptations must be thoroughly reviewed to ensure that the extension(s) being considered are not already addressed in some portion of the standard. See Rule 4-10 for supporting documentation requirements necessary for justification of most profiling and extension actions.

Rule 4-68 Entity Extensions Must Be Logically Unique18

1) Entity Elements can be added to an Adaptation provided they represent a concept that is logically unique from Entity Elements already included in the parent model. These added Entity Elements are referred to as Entity Extensions.

2) The value of an Entity Extensions’ “Model Name” property shall not duplicate the value of any other Entity Elements’ “Model Name”.

3) The value of an Entity Extensions’ “Alias Name” property shall not duplicate the value of any other Entity Elements’ “Alias Name”.

4) The value of an Entity Extensions’ “Definition” property shall not duplicate the value of any other Entity Elements’ “Definition”.

Rule 4-69 Entity Extensions Must Contain Standard Foundational Attributes

Entity Extensions must contain the standard foundational attributes defined in Rule 4-34.

Rule 4-70 Some Entity Extensions Must Contain Standard Real Property Attributes

Entity Extensions that represent a Real Property Asset must contain the standard real property attributes as defined in Rule 4-35.

Rule 4-71 Subclass Entity Extensions

1) As stated in the definition of subclass provided in Section 6, a subclass is a derivative class that inherits Attribute Elements of a parent Entity Element. The purpose of a subclass is to specialize the superclass by adding Attribute Elements needed by the subclass. This means that it is a narrowing of the parent entity concept to mean something more specific. Entity Extensions that are have a purpose different than that just stated shall follow Rules 4-68-70.

2) Entity Extensions that represent subclasses (hereafter referred to as “subclasses”) shall only be based on Entities from the parent model or that exist as Entity Extensions (In other words, an Entity superclass for every Entity subclass must exist in the Adaptation).

3) Subclasses represent a specialization or narrowing of the parent entity concept, therefore there must be a “basis” for the narrowing. This basis shall be:

18 Logically Unique: Logical uniqueness is established by two criteria (must meet both): (1) The values of the "Model Name", "Alias Name", and "Definition" properties of an entity element must each be distinct from all other values in the same Adaptation and employ unambiguous semantics (meaning); and (2) The concept represented must also be distinct (unique) from other feature concepts in the model. The first criteria can be measured objectively, but the second is subjective and shall be left to the interpretation of the reviewers, subject to the DISDI Group Consensus Process.


Revision 2

30

i) an attribute that supports a finite narrowing (hereafter referred to as an “attribute-based subclass” with the attribute referred to as the “basis attribute”) or

ii) the geometry of the entity (hereafter referred to as a “geometry-based subclass”).

4) If the subclass is an attribute-based subclass, the basis attribute possibilities shall include:

i) an attribute constrained by a list enumeration,

ii) an attribute of data type TrueOrFalse, or

iii) an attribute of data type YesOrNo.

5) Attribute-based subclasses must contain all required (see Rule 4-20 and Rule 4-58) attributes of the parent with the possible exception of the basis-attribute.

6) Attribute-based subclasses can contain the basis attribute and, if so, the “Default Value” property of the basis attribute in the subclass shall become one of the values of the basis attribute (hereafter referred to as the basis attribute value).

7) The basis attribute value from the constraining enumeration on the basis attribute should be profiled from the constraining enumeration to remove ambiguity in the adaptation. However, care should be taken to ensure that the impact of this profile not affect other attributes using the enumeration within the adaptation.

8) It is not necessary that all possible subclasses representing the cases from the basis attribute be included in any adaptation.

9) If the subclass is a geometry-based subclass, the geometry basis shall come from the “Permissible Geometries” property values of the parent and shall become the value for the subclasses “Default Geometry” property. NOTE: The value of the basis attribute should never change in Implementations.

10) If the subclass is a geometry-based subclass, it must also include additional attribution that is specific to the geometry of the subclass. This is considered to be the only allowable use case for such subclasses.

11) The “Model Name” property value of a subclass must be different that the superclass and shall not duplicate the value of any other Entity Elements’ “Model Name”.

12) The “Alias Name” property value of a subclass must be different that the superclass and shall not duplicate the value of any other Entity Elements’ “Alias Name”.

13) The “Definition” property value of a subclass must be different that the superclass shall not duplicate the value of any other Entity Elements’ “Definition”.

14) The “Note” property value of a subclass should indicate the relationship to the superclass in a way that provides implementation guidance to the user of the subclass, especially in cases where sub rule 7 cannot be implemented. The “Note” property of the superclass should similarly provide implementation guidance to the user.

15) Notwithstanding the naming rules already provided for Elements, it is not necessary that subclasses be named in any special way), but they must have the “Subclass Of” property value set as provided in Rule 4-25.

Rule 4-72 Entity Elements Can Be Extended By Adding Attributes

1) Entity Elements and Entity Extensions can be extended by adding Attribute Elements not in the parent model. Such Attribute Elements are referred to as Attribute Extensions.


Revision 2

31

2) Attribute Extensions must follow all Rules Concerning Elements and Element Properties (section 4.2) and Attribute Elements (section 4.4).

Rule 4-73 Attribute Extensions Must Be Logically Unique

1) Attribute Extensions must be logically unique from Attribute Elements already included in the parent model19 within the scope of a single Entity Element.

2) The value of an Attribute Extensions’ “Model Name” property shall not duplicate the value of any other Attribute Elements’ “Model Name” within the context of a single Entity Element.

3) The value of an Attribute Extensions’ “Alias Name” property shall not duplicate the value of any other Attribute Elements’ “Alias Name” within the context of a single Entity Element.

4) The value of an Attribute Extensions’ “Definition” property shall not duplicate the value of any other Attribute Elements’ “Definition” within the context of a single Entity Element.

Rule 4-74 Attribute Extensions Must Be Justified

1) In general, non-spatial (business) Attribute Elements should be collected into business Entity Elements that are separate but linked to the (adapted) Entity Element. In exceptional cases however, new attributes may be added to the (adapted) Entity Element. New Attribute Elements may be added to an (adapted) Entity Element under the following guidelines:

a) If a foreign key relationship needs to be established with some existing business system or data set managed by the ALO.

b) Non-spatial or “business” attributes may be added to an Entity Element whose “Is Gold” property value is true in special situations with due consideration of these guidance constraints:

i) A business reason must exist, and be documented in the “Justification” property value of the Attribute Element, supporting the addition in lieu of adding the Attribute Element to another related Entity Element or an external database.

ii) The number of attributes being added should be kept to a minimum. The intent is to reduce burden on technicians who may otherwise be required to enter data they do not readily know.

iii) The business line (i.e., the proponent or functional area) responsible for the addition should also be directly responsible for the creation and maintenance of the Entity Element being extended.

Rule 4-75 Enumeration Extensions Must Be Logically Unique

1) Enumeration Extensions can be added to an Adaptation provided they are logically unique from Enumeration Elements already included in the parent model.

2) The value of an Enumeration Extensions’ “Model Name” property shall not duplicate the value of any other Enumeration Elements’ “Model Name”.

19 It must be noted that an Attribute Extension (α) on an Entity (δ) whose properties are identical to an Attribute Element (β) on an Entity (ε) that is logically unique from Entity (δ) is considered logically unique from Attribute Element (β).


Revision 2

32

3) The value of an Enumeration Extensions’ “Alias Name” property shall not duplicate the value of any other Enumeration Elements’ “Alias Name”.

4) The value of an Enumeration Extensions’ “Definition” property shall not duplicate the value of any other Enumeration Elements’ “Definition”.

5) Enumeration Extensions shall not be proposed simply to avoid the change request process required in Rule 4-76.5

Rule 4-76 Enumerant Extensions Must Be Logically Unique

1) Enumerant Extensions can be added to an Adaptation provided they are logically unique from Enumerant Elements already included in the parent model within the context of an Enumeration Element.

2) The value of an Enumerant Extensions’ “Model Name” property shall not duplicate the value of any other Enumerant Elements’ “Model Name” within the context of an Enumeration Element.

3) The value of an Enumerant Extensions’ “Alias Name” property shall not duplicate the value of any other Enumerant Elements’ “Alias Name” within the context of an Enumeration Element.

4) The value of an Enumerant Extensions’ “Definition” property shall not duplicate the value of any other Enumerant Elements’ “Definition” within the context of an Enumeration Element.

5) Any such Enumerant Extension, when applied to a Gold enumeration, must be the subject of an approved Change Request.

Rule 4-77 Association Extensions Must Be Logically Unique

1) Association Extensions can be added to an Adaptation provided they are logically unique from Association Elements already included in the parent model.

2) The value of an Association Extensions’ “Model Name” property shall not duplicate the value of any other Association Elements’ “Model Name”.

3) The value of an Association Extensions’ “Alias Name” property shall not duplicate the value of any other Association Elements’ “Alias Name”.

4) The value of an Association Extensions’ “Definition” property shall not duplicate the value of any other Association Elements’ “Definition”.

5) The combined values of an Association Extensions’ “Parent (Destination) Entity”, “Parent (Destination) Attribute”, “Child (Origin) Entity”, and “Child (Origin) Attribute” shall not be identical to the same set of values from any other Association Element. In other words, two Association Elements shall not have the identical end points.

4.11 Gold Element Property Rules

The rules in this section apply to SDSFIE-V Gold element properties.

Rule 4-78 Gold Entity Element “Is Required” Property Value

1) The “Is Required” property shall be false for all Gold entity elements.

Rule 4-79 Gold Attribute Element “Is Required” Property Value


Revision 2

33

1) The “Is Required” property shall be true for Standard Foundational Attributes and Standard Real Property Attributes.

2) The “Is Required” property shall be false for all other Gold attributes unless changed by consensus of subject matters experts (SME) participating in Gold Modeling. Care shall be taken to ensure that feedback is gathered from all IGG stakeholders before finalizing a decision to change the property value to true.

Rule 4-80 Gold Enumeration Element “Is Required” Property Value

1) The “Is Required” property shall be true for all enumeration elements used to constrain attribute elements in the Gold model.

Rule 4-81 Gold Enumerant Element “Is Required” Property Value

1) The “Is Required” property shall be false for all enumerant elements of enumeration elements used to constrain attribute elements in the Gold model.

Rule 4-82 Gold Association Element “Is Required” Property Value

1) The “Is Required” property shall be false for all association elements.

Rule 4-83 Gold “Must Justify Profile Action” Property Values In General

1) The “Must Justify Profile Action” property value shall be false for all elements when the “Is Required” property value is true to ensure that there is no confusion about the ability to profile required elements.

Rule 4-84 Gold Entity Element “Must Justify Profile Action” Property Value

1) The “Must Justify Profile Action” property shall be false for all Gold entity elements except for entity elements identified as Common Installation Picture20 entities at the time of the Gold release in which case the property value shall be true.

Rule 4-85 Gold Attribute Element “Must Justify Profile Action” Property Value

1) The “Must Justify Profile Action” property shall be true for all Gold attribute elements that can be profiled (those with an “Is Required” property value of false).

Rule 4-86 Gold Enumeration Element “Must Justify Profile Action” Property Value

1) The “Is Required” property shall be false for all enumeration elements used constrain attribute elements in the Gold model.

Rule 4-87 Gold Enumerant Element “Must Justify Profile Action” Property Value

1) The “Is Required” property shall be false for all enumerant elements of enumeration elements used to constrain attribute elements in the Gold model.

Rule 4-88 Gold Association Element “Must Justify Profile Action” Property Value

1) The “Is Required” property shall be false for all association elements.

Rule 4-89 Gold Attribute Element “Is Nullable” Property Value

20 As defined in DoDI 8130.01


Revision 2

34

1) The “Is Nullable” property shall be false for the Gold Primary Key Identifier (entityNameIdpk) attribute elements.

2) The “Is Nullable” property shall be true for all other Gold attributes unless changed by consensus of subject matters experts (SME) participating in Gold Modeling. Care shall be taken to ensure that feedback is gathered from all IGG stakeholders before finalizing a decision to change the property value to false.

5 References

The following referenced documents provide the background for SDSFIE-V and these implementation guidelines.

DODI 8130.01. Installation Geospatial Information and Services (IGI&S), April 9, 2015. http://www.dtic.mil/whs/directives/corres/pdf/813001p.pdf

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE) Governance Plan, Version 1.0, 13 MAY 2014, http://metadata.ces.mil/dse/ns/DISDI/sdsfie

Spatial Data Standards for Facilities, Infrastructure, and Environment (SDSFIE), Version 3.1, Specification Document, 13 NOV 2013, http://metadata.ces.mil/dse/ns/DISDI/sdsfie-v/3.1/SDSFIE-3.1-SpecDoc-20131113.pdf

6 Definitions

This section provides definitions for terms used in this document.

Adaptation

A formalized alteration of a model which results in another model tailored to the particular business requirements of an implementing organization. An Adaptation consists of a specific Profile and/or all the Extensions that are required to meet specific business requirements.

Adaptation Lineage

The lineal descent from an ancestor of an Adaptation.

For example, the Adaptation Lineage of the entity named AboveGroundStorageTank in SDSFIE-V Gold 4.0 is regulated_aboveground_storage_tank_area (SDSFIE 2.61) AboveGroundStorageTank (SDSFIE 3.0 Gold) AboveGroundStorageTank (SDSFIE 3.1 Gold) AboveGroundStorageTank (SDSFIE 4.0 Gold).

Adapted Model

The result of the Adaptation of another model (either SDSFIE Gold model or another Adapted model). The Adapted model is subsequently stored in the SDSFIE Registry.

Alias Name

A name that is used to distinguish Elements from one another and is used, primarily, in display situations in Implementations.

Alternate Name


Revision 2

35

A name that replaces the “Model Name” property as the physical name of an Element in a PDM environment. Alternate names can be included in an Alternate Name mapping that that can be applied to a PIM representation of an LDM at the time of PDM generation.

Authorized Level Organization (ALO)

As defined by each IGI&S program, the lowest level organization(s) authorized to adapt the SDSFIE-V standard.

Business Requirement

A statement of the mission-based need for a model element (see Rule 4-7.2 for the structure of a Business Requirement record).

Component

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

Element

Any individual item of the SDSFIE-V LDM including entities, attributes, enumeration, enumerant, and associations.

Entity

An information concept used to represent either feature types or object types.

Extension

The addition of a new element (e.g., entity or attributes) to a model provided that element does not conflict with the definitions of elements already defined by higher authority.

Feature Type

An abstraction of real world phenomena represented as an information concept that includes geospatially referenced geometric representation(s).

Headquarters (or Component) Adaptation

An Adaptation of a version of SDSFIE-V Gold created by a Component for use across the Component; serves as the primary benchmark of implementation compliance within the Component.

IGI&S Programs

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

Implementation

The creation and use of a geographic information system database whose schema is a PDM.

Implementation Compliance

Compliance is measured with respect to a PDM. An Implementation is considered compliant if its schema is a PDM that meets one of the following two criteria:

1) it has a schema that is identical the model to which it purports to comply; or

2) it has a schema (PDM) that has been adapted directly from the model to which it purports to comply according to the rules in this guidance.


Revision 2

36

If the PDM has been altered in the implementation environment, it may or may not be out of compliance.

Length

An expression of the number of characters used in a sequence. In SDSFIE-V, the length is the maximum number of characters allowed in an attribute of the String data type.

Logical Data Model (LDM)

A structured representation of business data requirements using data abstraction and inheritance techniques and has been validated and approved by business representatives and which contains both entities and relationships of importance within an organized framework, and business textual definitions and examples. It is the basis of physical database design.

Model or Platform Independent Model (PIM)

An intermediate data representation derived from an LDM that has removed data abstractions and inheritance properties but does not contain restrictions specific to a particular implementation environment. The SDSFIE Registry contains a physical representation of the SDSFIE-V Gold versions (2.61 and forward) and all Adaptations in the PIM form that is used by the SDSFIE tools.

NOTE: This concept is similar to and derived from the Object Management Group (OMG) specified concept of the same name, but it is not identical to that concept in that we are referring to the stored representation of the PIM.

Model Name

A name that is used to distinguish Elements from one another. The Model Name is the default physical name of an Element in a PDM environment and, as a result, is subject to Rule 4-12.

Object Type

An information concept, other than a feature type. Object types are used to represent non-geographic information that is related to geographic information (typically through a foreign key relationship in a relational database).

Parent Model

A model that is the direct ancestor of an Adapted model. The parent of a headquarters Adaptation is always an SDSFIE-V Gold model.

Physical Data Model (PDM or Physical Implementation)

The representation of a data design that conforms to the concepts in a logical data model and takes into account the structure and constraints of a given database management system or geographic information system; includes all the database artifacts required to create relationships between tables or achieve performance goals, such as indexes, constraint definitions, linking tables, partitioned tables or clusters. PDMs can be generated from approved Adaptations stored in the SDSFIE Registry. An Esri XML Workspace Document generated by SDSFIE Online from a model is the most recognizable example of a PDM.

Precision

A measure of the detail in which a quantity is expressed. In the case of SDSFIE-V, the measure is expressed in the number of decimal digits used to represent a number. For example, the precision of 123.4567 is 7. Precision and scale are used together in SDSFIE-V. This term is NOT the same as mapping precision, rather it is the database related term.


Revision 2

37

Profile (Class 1)

Conformance class 1 is satisfied when a profile is established as a pure subset of a standard [ISO 19106:2006].

In application to SDSFIE-V, the subset is limited to the rules provided in section 4.8.

Profile (Class 2)

Conformance class 2 allows profiles to include extensions within the context permitted in the base standard [ISO 19106:2006].

In application to SDSFIE-V, this means that the subset and extensions (and modifications) are the subject to all of the rules in section 4.

Renaming

The process of altering or replacing element names (e.g., entity names or attribute names). Renaming is accomplished via the use of Alternate Name.

Requirement Document

A citation of a document which prescribes one or more Business Requirements (see Rule 4-7.3 for the structure of a Requirement Document record).

Scale

A measure of the detail in which a quantity is expressed. In SDSFIE-V, the measure is used to express the specific number of decimal digits to the right of the decimal point used to represent a number. For example, the scale of 123.4567 is 4. Precision and scale are used together in SDSFIE-V. This term is NOT the same as map scale, rather it is the database related term.

SDSFIE-V Gold

The sum collection of all elements (defined above) resulting from the SDSFIE-V Gold modelling efforts. Any SDSFIE-V Gold version is an Adaptation of the previous SDSFIE-V Gold version. SDSFIE-V Gold represents the common consensus model for use as the basis for all headquarters Adaptations of the same version (and it is thus the root for all Adaptations having the same version).

SDSFIE Registry

The SDSFIE Registry is a relational database management system that stores all models relevant to SDSFIE-V (including SDSFIE-V Gold and Adaptations). The SDSFIE Registry is central to the operation of all tools in the SDSFIE Toolset.

Subclass

A derivative class that inherits one or more language entities from one or more other classes (called superclasses, base classes, or parent classes). In SDSFIE-V, subclass is applied only to Entity Elements and the “language entities” that are inherited are the Attribute Elements of the parent and some of the Attribute Element properties. Additionally, a subclass can only inherit from one superclass in SDSFIE-V. A subclass should only be used to when there is a need to specialize the superclass by adding Attribute Elements needed by the subclass. A subclass is not the same concept as, and should not be confused with, a subtype in the Esri environment.

Subordinate Adaptation

An Adaptation of a headquarters Adaptation or of another subordinate Adaptation.


Revision 2

38

7 Abbreviations

ALO – Authorized Level Organization

ASCII – American Standard Code for Information Interchange

ASD (EI&E) – Assistant Secretary of Defense (Energy, Installations & Environment)

BLOB – Binary Large Object

COI – Community of Interest

CMP – Change Management Process

CR – Change Request

DISDI – Defense Installations Spatial Data Infrastructure

DISR – Department of Defense Information Technology Standards Registry

DoD – Department of Defense

DoDI – Department of Defense Instruction

DoDD – Department of Defense Directive

GEOINT – Geospatial Intelligence

GUID – Globally Unique Identifier

ID – Identifier

IGG – IGI&S Governance Group (formerly known as the DISDI Group)

IGI&S – Installation Geospatial Information & Services

I&E – Installations & Environment

ISO – International Organization for Standardization

IT – Information Technology

LDM – Logical Data Model

NA – Not Applicable

OGC – Open Geospatial Consortium

OID – Object Identifier

PDM – Physical Data Model

PK – Primary Key

PIM – Platform Independent Model

RPI – Real Property Inventory

RPIM – Real Property Information

RPN – Real Property Network

RPNID – Real Property Network Identifier

RPSUID – Real Property Site Unique Identifier

RPUID – Real Property Unique Identifier


Revision 2

39

RPUIR – Real Property Unique Identifier Registry

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

SDSFIE-V – SDSFIE Vector

TBD – To Be Determined

XML – Extensible Markup Language

8 Element Name Properties

8.1 Overview

Flexibility in naming in the implementation (or PDM) realm is important because it allows users to refer to entities, attributes, and other elements in a way that 1) is familiar, 2) meets with local custom or practice, 3) meets particular database system dependencies, and, probably most importantly, 4) retains connection to legacy business systems that require particular naming schemes. The flexibility at the PDM realm must be met with the standardization of names required for interoperability at the logical (or LDM) realm. In September 2014, the IGG (then known as the DISDI Group) agreed on a naming scheme for model elements that provides for naming flexibility and still retains as much interoperability as possible. In this naming scheme there are several name properties for every model element that span the modeling and implementation realms. Table 1 depicts these four name properties, when they are active, and their obligation in each realm.

In the LDM stage, only the “Model Name” and the “Alias Name” exist and they refer to the name of the element in the LDM and PIM (and potentially the PDM) and a name to be used for “display” purposes, respectively. Because the “Alias Name” is mandatory at the PIM stage, if an “Alias Name” is not specifically provided by the model owner as the LDM is created, it is assigned to be equivalent to the “Model Name”.

In the PDM stage, the “Name” is created. By default, its value is equivalent to the PIM “Model Name”, unless an “Alternate Name” is provided.

Table 1: Name obligation by property, stage and realm

Modeling Realm Implementation Realm

Property (Value) LDM Stage PIM Stage PDM Stage

Name M

Alias Name O M O

Model Name M M O

Alternate Name O

Obligation conditions are “O” = Optional and “M” = Mandatory

8.2 Style Guide

Good names are important because they help the user more rapidly understand the purpose and intent of elements. Aspects of good names are:


Revision 2

40

Succinct expressed in few words, concise, terse.

Specific having a special application, bearing, or reference; specifying, explicit, or definite

Singular noting or pertaining to a member of the category of number found in many languages that indicates that a word form has one referent or denotes one person, place, thing, or instance

8.2.1 Model Name Property

Rules concerning the “Model Name” property are provided within Rule 4-12. Beyond those rules, “Model Name” property values should be succinct, specific, and singular.

8.2.2 Alias Name Property

Rules concerning the “Model Name” property are provided within Rule 4-13. Beyond those rules, “Alias Name” property values should be specific and singular, but not, necessarily, succinct.

8.2.3 Alternate Name Values

Rules concerning the “Alternate Name” values are provided within Rule 4-15. Because alternate names are provided with a specific purpose in mind, there is no further style guidance.

9 Element Documentation Properties

9.1 Overview

Earlier versions of SDSFIE contained only a definition to be used as the documentation of logical data model elements. The definitions became long and unwieldy in many circumstances. Furthermore, they became replete with examples that were often Component-specific. Sometimes, the definition included guidance for implementation of the element. In September 2014, the IGG agreed on a documentation scheme for model elements that provides for all of the above and specifies their placement to ensure consistency in the documentation of logical data models.

9.2 Style Guide

Good documentation is important for model understanding and to guide both adapters and users in the proper use of model elements. This section provides a style guide intended to foster better, more understandable documentation of SDSFIE-V and its Adaptations.

9.2.1 Definition Property

The basic description of the data concept. Best practices for definitions include a) be concise, typically keep to one sentence, b) use a complete sentence, c) avoid circular definitions, and d) leave out examples.

Table 2: Definition Examples

AboveGroundStorageTank A receptacle or chamber, at least 90% above ground, used for storing bulk commodities, fuels, or chemicals.


Revision 2

41

Fence A freestanding structure designed to restrict or prevent movement across a boundary.

rpuid (Real Property Unique Identifier)

A non-intelligent code used to permanently and uniquely identify a DoD real property asset.

9.2.2 Description Property

An elaboration of the model element definition. Examples are included in the Description.

Table 3: Description Examples

rpuid RPUIDs are exclusively issued by the Real Property Unique Identifier Registry (RPUIR). Source: DoDI 4165.14, January 17, 2014.

Fence It is generally distinguished from a wall by the solidity of construction: a wall is usually restricted to such barriers made from solid brick or concrete.

9.2.3 Note Property

Constraints on use of the element

Implementation information about the use of the element

Table 4: Note Examples

AboveGroundStorageTank If the tank contains fuels and participates in a POL distribution network, consider also representing this tank as a PolUtilityNode. If the tank contains water and participates in a water distribution network, consider also representing this tank as a WaterUtilityNode.

rpuid All of the characters in the RPUID value must be numeric [0-9].

10 Versioning Lifecycle States

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

1) Emerging

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

2) Mandated


Revision 2

42

a) The version is to be implemented and considered essential for interoperability in the DoD EI&E community. There can only be one Mandated version at a time. The milestones and deadlines for implementation of the Mandated version shall be developed by the IGG and approved by ASD (EI&E) in accordance with DoD policy (DoDI 8130.01).

3) Retired

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