FAQs
The GRA Service Specification Package (SSP) is a package of 12 templates that developers will find useful when developing a service specification. Please refer to the Global Reference Architecture (GRA) Service Specification Guideline V 1.0.0 (also located within GIST) for practical information on how to use the GRA SSP and the sample conformant GRA package and set of templates included in it.
Please click here to download the package.
The Law Enforcement National Data Exchange (N-DEx) is a criminal justice information sharing system that will provide nationwide connectivity to disparate local, state, tribal, and federal systems for the exchange of information. N-DEx will provide law enforcement agencies with a powerful new investigative tool to search, link, analyze, and share information (for example, incident and case reports) on a national basis to a degree never before possible. N-DEx will primarily benefit local law enforcement in their role as the first line of defense against crime and terrorism.
Through N-DEx’s proposed services and capabilities, N-DEx will allow participating agencies to detect relationships between people, places, things and crime characteristics; to link information across jurisdictions; and to “connect the dots” between apparently unrelated data without causing information overload. This capability will occur primarily in the realm of structured data but can also include unstructured data. In addition, N-DEx will provide contact information and collaboration tools for law enforcement agencies that are working on cases of mutual interest.
The N-DEx Core Capabilities
Provide an automatic correlation of specific identifying data (persons, places, and things) contained in the N-DEx inputs
Interactively identify and report similar or identical crime characteristics and, when available, modus operandi occurring between all crime incidents/events contained in the inputted data
Provide UCR statistical data to produce formatted or user-specified tables, charts, graphs, and reports to support quantitative analyses of crime and crime trends.
The N-DEx System
Provides repository and index for criminal justice information on a national scale
Links current and developing systems to identify and access pertinent information
Supplies access to information that can link and solve crimes and form investigative partnerships
Advances UCR statistical outputs for the 21st century
Affords an advanced crime-modeling tool for strategic, operational, and tactical analysis
Offers innovative investigative and analytic tools
Provides a system that does not need to be “knowledge driven”
Shared law enforcement crime data in N-DEx consists of:
Local, state, tribal and federal incidents and events
Information from the FBI CJIS Systems of Service: UCR, NCIC, III
Criminal Justice Information Fusion Centers information
Arrest, booking and incarceration data
Some of the features and services supported in N-DEx are:
Visualization tools to provide text, tabular and graphical outputs, as well as, advanced geographical mapping for all the automated and interactive correlations
Multi-jurisdictional sharing of information and system outputs
User notification and alarms of relevant activities
Role-based access to functions, information and systems outputs
User defined preferences (display, filtering, correlation, notification, etc.)
Online training
Identification of common investigative targets
Collaboration (e.g., email, a “tickler” system to provide reminders, and user folders to store and share information)
Links to indexed data sources
Web and document publishing
Detailed auditing and reporting of system use
Individual and agency-level data management
The IEPD Clearinghouse is a Bureau of Justice Assistance (BJA) sponsored initiative developed and supported by the Global Justice XML Data Model (GJXDM) Training and Technical Assistance Committee (GTTAC) and the IJIS Institute.
The Information Exchange Package Documentation (IEPD) Clearinghouse is a website that empowers government and industry IT professionals with information about planned, in-progress, and completed IEPD initiatives.
Public and private developers can maximize resources and time by using the IEPD Clearinghouse to gain access to Global Justice XML Data Model (GJXDM) and National Information Exchange Model (NIEM) conformant and reusable artifacts. Funding agencies, policy makers, and managers can avoid duplicative efforts by researching in-progress IEPD development initiatives. Most importantly, the IEPD Clearinghouse enables directly relevant collaboration between organizations and people working to solve similar problems within the justice and public safety community
What is an IEPD?
An IEPD is a collection of developer-originated artifacts that promote reuse and enable wider adoption of standards. These artifacts include data exchange and domain models as well as GJXDM- or NIEM-conformant data maps and XML schemas. Reuse of these IEPD artifacts allows developers to focus on local adaptation through extensions and refining or enhancing the global baseline.
IEPD Clearinghouse Benefits & Features
Enables search for information about planned, developed, or implemented IEPDs
Allows organizations to share IEPD information
Provides links to real-world, reusable IEPD artifacts
Accelerates the design & development processes
Promotes utilizing the Global Justice XML Data Model (GJXDM) and the National Information Exchange Model (NIEM)
IEPD Clearinghouse Access
The IEPD Clearinghouse is an interactive repository containing updated information about IEPDs that can be accessed via https://bja.ojp.gov/program/it/niss
Submitting IEPD Information to the Clearinghouse
In only a few minutes, a user can submit information about IEPDs to the Clearinghouse by downloading and completing the IEPD submission form and creating a user account.
IEPD Clearinghouse Support
For IEPD Clearinghouse inquiries or support, please contact the National Information Sharing Standards (NISS) Help Desk via:
Web https://bja.ojp.gov/program/it/niss
Telephone 1-877-333-5111 or 703-726-1919
E-mail [email protected]
The Georgia DHR Office of Child Support Enforcement has created an Information Exchange Package Documentation (IEPD) for child support related filings. The schema extension is designed to transfer information into courts for Petitions and Support Order Contempt Cases. The design is currently in only the preliminary stage where the Administrative Office of the Courts in Georgia is trying to determine if the namespace conventions and the extension methods used are valid for meeting the IEPD guidelines published on the OJP website.
Schema Website: http://schema.gaaoc.us
Document Schema: http://schema.gaaoc.us
Extension Schema: http://schema.gaaoc.us/body/ga/washington/document/cse/extension/extens…
Constraint Schema: http://schema.gaaoc.us/body/ga/washington/document/cse/jxdm/3.0.2/const…
Example Document (with all mandatory and optional fields): http://schema.gaaoc.us/body/ga/washington/document/cse/example-document…
Other IEPDs created that relate to child support filings include:
1. Delinquent Child Support Notification developed for the Texas Path to NIEM project. http://niem.gtri.gatech.edu/niemtools/iepdt/display/container.iepd?ref=…
2. Child Support – Support Order http://www.ncsc.org/Services-and-Experts/Technology-tools/National-stan… and
3. Child Support - Request Remedy http://www.ncsc.org/Services-and-Experts/Technology-tools/National-stan…
An “Information Exchange Package” (IEP) represents a set of data that is transmitted for a specific business purpose. It is the actual XML instance that delivers the payload or information.
An Information Exchange Package can be prefixed with “GJXDM” or “NIEM” to indicate or highlight that the IEP is GJXDM- or NIEM-conformant, as in “GJXDM Information Exchange Package” or “NIEM Information Exchange Package.” The fact that an IEP is GJXDM- or NIEM-conformant may be readily apparent from the context, so it is not absolutely necessary to use the prefixes.
Many justice, public safety, as well as other organizations have been working to define information exchanges, conformant with the Global Justice XML Data Model (GJXDM), or the National Information Exchange Model (NIEM) to be used within their information sharing enterprise. Recently, a number of justice practitioner and industry organizations have been working to define “reference” information exchanges, intended as models for information exchanges that meet specific business needs.
The XML Structure Task Force (XSTF) recognized the need to identify and describe a common set of artifacts to document the structure and content of a GJXDM-conformant XML instance used in an information exchange to meet a specific business purpose. This set of artifacts is referred to as “GJXDM Information Exchange Package Documentation (IEPD)” or “NIEM Information Exchange Package Documentation (IEPD).”
Information Exchange Package Documentation (IEPD) is necessary to define the data that is to be exchanged (and the structure of that data) for a particular business purpose, thereby providing interoperability at the Information Exchange Package level.
The GJXDM and NIEM provide a set of defined data and an object structure for that data. However, they do not define sets of data for particular business information exchanges. Without the IEPD, there would be no agreement on which GJXDM or NIEM properties (and extended properties) are used or how they are structured within the IEP. Given the same set of business data requirements, each implementing organization would likely come up with a different IEP to represent that same set of business data. It would be difficult for organizations receiving an IEP to understand it, since the organization wouldn’t necessarily know which properties or what structure to expect.
Even if the IEP from a particular sending organization could be interpreted, it would be expensive for organizations to handle the IEP variations from the different senders. By developing and reaching agreement on the IEPD for an information exchange within a particular justice enterprise, participants can send an IEP that can be understood by those receiving the IEP. Developing Reference Information Exchange Package Documentation further reduces the arbitrary variations in IEPD and the corresponding effort to implement multiple IEPD instances for a similar business purpose.
An Information Exchange Package Documentation (IEPD) is a GJXDM- or NIEM-conformant schema set, plus associated documentation, that defines a common information exchange.
For the last several years, the justice community has been developing functional XML specifications for common justice documents, such as Arrest Warrant, Arrest/Incident Report, Amber Alert, Rap Sheet, and Sentencing Order. The GJXDM and NIEM approach is to construct reference exchange documents with GJXDM or NIEM components and to provide these as model document schemas that can be used as is or extended to meet individual jurisdictional requirements.
One example of a GJXDM Reference IEPD is the Amber Alert IEPD, available on the OJP website. Others are the Incident Reporting, Arrest, Booking, and Charging document IEPDs developed by SEARCH; the Traffic Citation and Protection Order IEPDs developed by the National Center for State Courts; and prosecution-initiated IEPDs developed by the IJIS Institute.
To review existing IEPDs please visit IEPD Clearinghouse at https://bja.ojp.gov/program/it/niss
Practitioners and industry organizations are defining “reference” information exchange models for specific business needs to reduce arbitrary variations and promote interoperability at the Information Exchange Package level.
GJXDM and NIEM provide a set of defined data and an object structure for that data. However, the models do not define sets of data for particular business information exchanges.
Without the IEPD, there would be no agreement on which GJXDM or NIEM properties (and extended properties) are used or how they are structured within the IEPD. Given the same set of business data requirements, each implementing organization could develop a different IEP to represent that same set of business data. Even if the IEP from a particular sending organization could be interpreted, it would be expensive for organizations to handle the IEP variations from the different senders.
By developing and reaching agreement on the IEPD for an information exchange within a particular enterprise, participants can send an IEP that can be understood by those receiving the IEP whether it’s within the state, county, or nationally.
If Reference IEPD for an Incident Report is developed and recognized by a nationally respected organization, states are more likely to use that Reference Incident Report IEPD as a model for developing their state-specific Incident Report IEP. This minimizes unnecessary differences from state to state while still enabling each state to tailor the Incident Report IEPD to meet state-specific business needs. It may be that the Reference Incident Report IEPD is inclusive enough that it can be used as-is for a particular state. The state-specific Incident Report IEPD would be used to exchange incident information between different jurisdictions within the state or between a jurisdiction and the state repository.
Carrying this concept further down, a county-wide enterprise could use the state Incident Report IEPD as a reference model to develop the IEPD for an Incident Report meeting the specific business needs of the county. This county-specific Incident Report IEPD would be used to exchange incident information between different organizations within the county.
Continuing with this concept going up, the Reference IEPD for an Incident Report could be used as-is at the national enterprise level for exchanging incident information between states or between states and the federal government.
The benefit of this consistency is that organizations implementing information exchanges can more quickly and cost-effectively deploy them across multiple jurisdictions at all levels. IEPD (and Reference IEPD) takes the benefits of using GJXDM and NIEM to a higher level. Ultimately, organizations implement information exchanges based on IEPD, not on GJXDM or NIEM.
GJXDM IEPD Guidelines: https://it.ojp.gov/topic.jsp?topic_id=196
NIEM IEPD Guidelines: https://www.niem.gov/training/Documents/Mod08_NIEM_PI_IEPD_Concepts.pdf
An "Information Exchange Package" represents a set of data that is transmitted for a specific business purpose. It is the actual XML instance that delivers the payload or information. (The word "package" as used herein refers to a package of the actual data, not a package of artifacts documenting the structure and content of the data.) An Information Exchange Package can be prefixed with "GJXDM" or “NIEM” to indicate or highlight that the IEP is GJXDM- or NIEM-conformant, as in "GJXDM Information Exchange Package” or “NIEM Information Exchange Package” The fact that an IEP is GJXDM or NIEM-conformant may be readily apparent from the context, so it is not absolutely necessary to use the word "GJXDM" or NIEM even if the IEP is GJXDM- or NIEM-conformant.
An "Information Exchange Package Documentation " is a collection of artifacts that describe the structure and content of an Information Exchange Package. It does not specify other interface layers (such as web services). It can optionally be prefixed with "GJXDM" or NIEM to indicate or highlight that a resulting IEP is GJXDM- or NIEM-conformant.
Subject matter experts from the agencies participating in the exchange must first convene with the sole objective of gathering requirements for the exchange at hand. It is imperative that all requirements are clearly articulated and documented. The JIEM tool is commonly used for collecting and documenting requirements specific to an exchange. Another important step toward gathering requirements is to create a domain model specific to the information included in the exchange. The domain model should explicitly illustrate all data classes, attributes, and associations that are required for the exchange.
Once all requirements have been laid out and documented the next step is to compare these requirements to the IEPD and determine if any gaps exist. In the common case that gaps are identified information must be added to the IEPD in order to meet the exchange requirements. The newly identified elements should be mapped to existing elements in the NIEM/GJXDM, so this would mean that the IEPD's subset needs to be updated to include the new elements. If the required elements cannot be mapped to elements in the NIEM/GJXDM then extensions need to be created. It is important that all extensions are created in a namespace specific to this exchange and not in the extension namespace specific to the existing IEPD.
After the IEPD has been customized to meet the requirements determined during the needs gathering exercise, each participating agency must map their data to the information in the IEPD. Mapping is a very important process that should be well-documented in order to ensure that the correct information is being included in the exchange. The next step is to explore the architectural options and tools for processing a NIEM- or GJXDM-conformant IEP.
[Reference to article #318]
There is no systematic effort to identify projects or jurisdictions using reference IEPDs, so it is not possible to point to specific projects or jurisdictions..
The N-DEx initiative at the FBI has examined the Incident Reporting IEPD as part of defining the IEPDs for N-DEx. More information is available at http://www.fbi.gov/about-us/cjis/n-dex/ or email: [email protected].
This cannot be done using just a constraint schema, and is a common problem for widely reused objects such as address and person where a user wants a different subset of object properties depending on a particular use.
However, the user's needs CAN be met using xsd:restriction in an extension schema. The use of xsd:restriction is permitted by the NDR 1.3 in extension schemas. Here is how it would be accomplished for a particular property:
For example in a constraint schema, how does one go about constraining nc:StructuredAddressType as follows...
a. When used as...
nc:ContactInformation/[nc:ContactMeans]/nc:ContactMailingAddress/[nc:AddressRepresentation]/nc:StructuredAddress
...it should contain only:
nc:AddressDeliveryPointText
nc:LocationCityName
nc:LocationStateName
nc:LocationPostalCode
b. But when used as...
nc:Incident/nc:IncidentLocation/nc:LocationAddress/[nc:AddressRepresentation]/nc:StructuredAddress
...it should contain only:
nc:LocationCityName
nc:LocationCountyName
The attached word document contains a detailed step-by-step procedure on how to do this.
Documents