One of the more critical, and somewhat confusing, concepts in the SDSFIE 3.0 is the notion of what constitutes a ‘compliant’ data set. SDSFIE 3.0 offers considerably more flexibility in schema options than earlier releases. This capability was created to permit individual DoD users some naming options to accommodate existing legacy applications that use geospatial data. But the capability comes with a risk… namely compromising the very nature of a standard.
Many new DoD contracts are being awarded with a clause stating that the data deliverables are to be submitted compliant with SDSFIE. Given the flexibility in schema naming and content, what does that really mean and how is that consistent with an absolute standard.
Within SDSFIE 3.0, there is a version called Gold. Gold is simply the union of all modeled elements (feature types, attributes, domains, and associations/ relationships) into a single set with names prescribed by the SMEs that created the requirements of the model. From Gold, each DoD Service; e.g. U.S. Army, created an ‘adaptation’ which tailored Gold to the requirements of their Service. These adaptations, called the ‘component adaptations’, may have simply been a direct copy of Gold, or they may have modified Gold in one of three ways:
Profile – the notion of removing elements (feature types, attributes, enumeration values) that are not applicable to the particular adaptation. Maybe the Army decides that it does not need piers. These feature types may be removed from the Army Component Adaptation, provided the DoD Headquarters has not coded the element as required. An example of a required element would be feature type names or descriptions in certain features. If the DoD designates an element as required, it cannot be removed (profiled out).
Extend – the notion of adding elements (same element set) that might be of unique interest to the Army. Any element added by extension must satisfy a set of rules for content and potential conflict with other existing elements within Gold. Users adding elements must provide a rigorous definition that will be reviewed and an ‘approval’ will be required prior to use in the field. This is the most powerful flexibility within SDSFIE 3.0 but it is one that comes with the most risk.
Rename – this notion that an element (same element set) can be renamed from its Gold name. Once again, there are rules which govern how elements can be named, since it is important that there not be any conflict between names. These changed names will also be subject to scrutiny and approval will be required prior to implementation.
All of these modifications are tied to an adaptation and the content of that adaptation is kept in the SDSFIE repository, a database which houses Gold, all adaptations (including those under development), and some prior releases of the SDSFIE.
So, the concept of compliance is that schemas in use in the field MUST MATCH precisely a known adaptation within the repository. Given the flexibility afforded by the repository, and the capability of the repository to generate various vendor configurations of geospatial datasets (PostGIS, Bentley, Oracle Spatial, Esri Geodatabase, etc.), this should not be an overwhelming task.
If a contract clause says ‘be SDSFIE compliant’, it is incumbent upon the contracting activity to specify the adaptation which represents the desired schema. The contractor will then know what schema is to be delivered.
As SDSFIE 3.0 is only now being implemented and the military services are in the process of finalizing their component adaptations, this process is likely to evolve over time. As part of our ongoing support for SDSFIE, we will be creating a web site for resources for contractors needing help in understanding SDSFIE 3.0 and creating compliant datasets.
You can get more information about SDSFIE 3.0 at www.sdsfie.org
This post was written by:
For more information on this post, SDSFIE, or Zekiah’s geospatial integration services, please e-mail us at firstname.lastname@example.org