FAQs
The newly-developed, interactive Global Information Sharing Toolkit (GIST) Web portal, was designed to help you locate the best Global tools and solutions for your business needs.Whether you are tackling a justice information sharing business problem, targeting a general area of interest, or are looking for a specific Global publication, the Global Wizard has the solution. This tool is designed to give you, the user, options for locating the best solutions from developing a privacy policy to establishing a fusion center to seeking guidance on First Amendment rights or implementing Global Reference Architecture standards, the GIST will make that much easier.
Also see attached flier.
Documents
https://bja.ojp.gov/media/document/30126
The GFIPM System-to-System Profile and GFIPM Implementation Guide provides the details in the implementation techniques to consider in GFIPM.
An organization wishing to participate in the federation MUST adhere to the following sequence of membership phases and associated processes:
- Request-to-Join Process
- Application Process
- Onboarding Process
- Ongoing Membership
For further details on the participation process, please refer to GFIPM Operational Policies and Procedures
The training is video-based and hosted on YouTube for easy access from any YouTube-enabled device. The videos are high-definition, ensuring readable on-screen XML for examples and exercises. There's over six hours of video instruction, broken and organized into manageable sections of 15 minutes or less.
The training contain serveral topics:
NIEM Advanced Technical Concepts
NIEM XML Artifacts
NIEM IEPDs
And more!
For more information regarding Video-Based Training see here - http://niemtraining.org/video.php.
The PersonSSNIdentification element is of type IdentificationType, which in turn has an element IdentificationID of type string. Clearly IdentificationID needs to accept arbitrary strings. However, in the context of PersonSSNIdentification, the IdentificationID needs to be nine characters, the first three digits of which cannot be 000 or 666 (plus a bunch of other rules enforceable using regex). Here is a simple business rules for SSN to be enforced by the XML schema that you can define a PersonSSNIdentificationID in your own namespace and use xsd:pattern:
<xsd:simpleType name="PersonSSNIdentificationID">
<xsd:restriction base="xsd:token">
<xsd:pattern value="[0-9]{3}-[0-9]{2}-[0-9]{4}"/>
[additional pattern facets to specify remaining business rules]
</xsd:restriction>
</xsd:simpleType>
Or, you can use the substitution method as below:
<nc:Person>
<nc:PersonSSNIdentification>
<nc:IdentificationID>123-45-6789</nc:IdentificationID>
</nc:PersonSSNIdentification>
</nc:Person>
<nc:Person>
<nc:PersonSSNIdentification>
<your:SSNIdentificationID>123-45-6789</your:SSNIdentificationID>
</your:PersonSSNIdentification>
</nc:Person>
It highly recommend to use the simple method before going into the substitution method. In case of using the substitution method, you have to ensure that the IEPD documentation is clear that your:SSNIdentificationID is to be used for SSN (as a substitution for nc:IdentificationID), and nc:IdentificationID is not to be used for SSN. If you need to enforce that, the receiver will have to use a means other than XML schema validation, as is the case with many business rules that cannot be represented using XML schema validation as is or constrained by the NIEM NDR.
Using a "Constraint Schema" one simply takes a copy of the native NIEM schema subset and modifies the base type as required. The follow example from step 1 to 4 will show how you can max out the length of a person name.
Example:
Use Case: Add Max Length to nc:PersonGivenName
Step 1:
Copy "subset" directory to a new directory called something like "constraint"
Step 2:
Modify all extension and document schemas to point at "constraint" directory instead of "subset" directory.
Step 3:
Edit ./constraint/niem/niem-core/2.x/niem-core.xsd to add your constraints
... ... ...
<xsd:element name="PersonGivenName" type="nc:NewNameTextType"> <xsd:annotation> <xsd:documentation>A first name of a person.</xsd:documentation> </xsd:annotation> </xsd:element> ... ... ... <xsd:complexType name="NewNameTextType"> <xsd:annotation> <xsd:documentation>Special restricted name text type.</xsd:documentation> </xsd:annotation> <xsd:simpleContent> <xsd:extension base="nc:restricted-string"> <xsd:attributeGroup ref="s:SimpleObjectAttributeGroup"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> <xsd:simpleType name="restricted-string"> <xsd:restriction base="xsd:string"> <xsd:maxLength value="10"/> </xsd:restriction> </xsd:simpleType> ... ... ...
|
Use <xsd:pattern/> with a regex expression instead of <xsd:maxLength/> for any more complex validation.
If a lot of constraints are being added, you may want to add the constrained data types to a new schema file and simply import the file so as to minimize the changes directly to the niem-core.xsd file.
Step 4 (DO NOT SKIP THIS STEP):
Test and document changes. . . .ANY TIME you update the subset (yes this happens A LOT), you will need to reapply the constraints, so it is CRITICAL to document what constraints you added.
Below are the NIEM valid codes:
<xsd:simpleType name="SKNCodeSimpleType">
<xsd:annotation>
<xsd:documentation>A data type for Skin Color.</xsd:documentation>
<xsd:appinfo>
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:token">
<xsd:enumeration value="ALB">
<xsd:annotation>
<xsd:documentation>ALBINO</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="BLK">
<xsd:annotation>
<xsd:documentation>BLACK</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="DBR">
<xsd:annotation>
<xsd:documentation>DARK BROWN</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="DRK">
<xsd:annotation>
<xsd:documentation>DARK</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="FAR">
<xsd:annotation>
<xsd:documentation>FAIR</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="LBR">
<xsd:annotation>
<xsd:documentation>LIGHT BROWN</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="LGT">
<xsd:annotation>
<xsd:documentation>LIGHT</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="MBR">
<xsd:annotation>
<xsd:documentation>MEDIUM BROWN</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="MED">
<xsd:annotation>
<xsd:documentation>MEDIUM</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="OLV">
<xsd:annotation>
<xsd:documentation>OLIVE</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="RUD">
<xsd:annotation>
<xsd:documentation>RUDDY</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="SAL">
<xsd:annotation>
<xsd:documentation>SALLOW</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="YEL">
<xsd:annotation>
<xsd:documentation>YELLOW</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
You can't add codes to an existing code table. (The reason is that code tables are done via restriction instead of extension. Once you've restricted something, you can only restrict it further. You can't extend the restriction.)
The solution here is to literally copy the code table XML into an extension schema and add the code to this local namespace.
In NIEM, harmonization is a process for modeling and integrating new and existing data components in ways that remove duplication, resolve conflicts, reduce variation, and achieve consistency. The goal of harmonization is to bring new content into NIEM while reestablishing and maintaining standardization and uniformity across the data model under the NIEM Naming and Design Rules (NDR).
Upon identification of information exchange requirements, the process of mapping data elements to NIEM requires developers to search through the model to identify semantic equivalent elements between an organization's data set and the NIEM model. There are a number of ways to explore the model to aid this process: the Data Model Browser; several alternate model formats, such as spreadsheets and a database; the Subset Schema Generation Tool (SSGT); and third party toolsets.
The NIEM architecture consists of two sets of vocabularies-NIEM Core and the individual NIEM domains. NIEM Core includes "universal" components, concepts that are commonly understood across all (or the majority of) NIEM domains, such as person, activity, date, time, and location. The individual NIEM domains contain mission-specific data components that build upon concepts in NIEM Core.
The current NIEM release can be found here.
Data Model Browser is a great tool for the user to practice before they get into the real NIEM work. This tool create by GTRI developer team that associate along with the Subset Schema Generation Tool (SSGT). Before you get to this browser or receive an error while try to access to this tool, please follow the instruction below to configure your browser:
First, go to "Internet Options", click on "Security" tab on top, click on "Trust sites", and click on the "Sites" button. After that, you add the this site http://tools.niem.gov/ to here.
Download the JAVA Runtime Environment 7 version or above, and install on your computer.
Please unlock the pop-up to this site http://tools.niem.gov/
The Global Federated Identity and Privilege Management (GFIPM) standards and specifications provide a security framework for securely connecting justice and public safety personnel to interagency applications and data over the Internet.
The GFIPM Governane Guidelines document defines the governance structure for a GFIPM federation, including the parties that play a role in the governance structure (e.g., Board of Directors, Federation Management Organization, Identity Provider Organizations, Service Provider Organizations, Trusted Identity Broker Organizations, etc.) and the decisions to be made by each party.
The GFIPM Web Services Concept of Operations document (section 1.2) provides a brief discussion of the major standards, specifications, and profiles that are used and referenced by the GFIPM-WS standards.
The Global Federated Identity Privilege Management (GFIPM) Security Interoperability Demonstration Project Report, provides a good example of an existing implementation.