FAQs
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
How many message sets should one IEPD cover:
1) A single message, a portion of a set;
2) A single message set, a single exchange from start to end;
3) Many message sets?
What is the impact of placing to many or to few message sets in an IEPD?
There is no guidance at this point as to how many exchanges an IEPD should cover.
In fact, PMO is in the process of refining an IEPD specification, so some of this may be subject to change in the future.
That said, the concept of an IEPD is meant to be simple and scalable. If I create an IEPD for a set of related exchanges (or message payloads) like a set of queries and associated responses, and they all use the same subset and extension schemas, then it's probably a good idea to put them all into a single IEPD with a name that embodies the business purpose or function of these queries/responses. If I have a fairly large exchange (such as a Rap Sheet or a SAR) then it's probably better to keep that by itself in a single IEPD. If some kind of small query goes with that exchange (to trigger it or request it), then it's probably a good idea to keep that in that IEPD as well. The user must decide how cohesive a set of exchanges are. The more cohesive a set of exchanges are (either from a business perspective, functional perspective, or possibly organizational perspective, the more likely they should be together in one IEPD, especially if they employ/share the same subset and extension schemas.
The impact of too many or too few? As far as we know, there is no answer to this question. Again, the IEPD concept is meant to be simple. Does it simplify usability and understanding to combine exchanges into a single IEPD with one set of documentation? Are the exchanges fairly cohesive and depend on the same subset and extension schemas? Will creating a single large IEPD (with many exchanges) be more confusing or less confusing than making each a separate IEPD (possibly with lineage)? These are the kinds of questions a developer must answer to determine the best approach.
Occasionally, you may find yourself needing a wantlist that does not exist. This typically occurs when dealing with older IEPDs from the GJXDM era.
Why you might need the wantlist?
1) You need to make modifications to GJXDM subset schemas. The SSGT cannot import subset schemas. Instead, it needs a wantlist. If you have the subset schemas but no wantlist, then you can't modify the subset schemas with the SSGT.
2) You need to migrate a GJXDM IEPD to the NIEM. The NIEM Migration Tool requires a wantlist from which to migrate. Again, if you only have the subset schemas, you can't use the tool.
A quick aside here: If your problem is that you have a GJXDM 3.0 or 3.0.2 wantlist and see that the Migration Tool only supports GJXDM 3.0.3 wantlists, the solution is simple. Open the wantlist file in a text or XML editor and simply change the version number to 3.0.3. Because GJXDM 3.x versions are backwards compatible, earlier versioned wantlists cannot have anything in them that isn't also in version 3.0.3. So you can safely rename the version and use that for migration.
Why is it missing?
In many cases, the wantlist doesn't exist simply because the IEPD predates the advent of wantlists in the Subset Schema Generation Tool (SSGT). The SSGT initially had no way of saving a partially completed subset. Wantlists were originally a means for a user to save their place. The wantlists themselves later became the standard for listing needed elements and types.
In other cases, the subset schemas may have been created in tools other than the SSGT, which may not have also produced a wantlist.
Additionally, some subset schemas were actually created by hand, in standard XML editors, or even in text editors.
Finally, there may have once been a wantlist at the time subset schemas were created for an IEPD, and yet it may have been omitted from a published IEPD through neglect or oversight.
What to do about it?
There are a few alternatives. The first one is to simply re-select all the elements in the SSGT. In the case of a minimal exchange, this may be the simplest method. In other cases, this will be a long and tedious process.
Another alternative is to create a tool to read the subset schemas and produce a wantlist. The format for wantlists is standardized and publicly available. It is also fairly simple. XSLT would be an good basis for such a tool.
A final alternative is to find someone who has already created such a tool. One example is gotWantlist, a whimsically named tool hacked together quickly to create wantlists while migrating some very old GJXDM IEPDs.
As an admitted hack, gotWantlist comes with a laundry list of requirements and caveats.
Firstly, gotWantlist is written in PHP5, so PHP5 must be installed, either locally or on a web server somewhere. The code can either be run from the command line, directing the output into a file. Or it can be saved on a web server somewhere and run via a browser, saving the output as plain text.
Using gotWantlist requires a small bit of preparation. Here are the steps:
1) Save your GJXDM subset somewhere. (Really, all you need is the "3.0.2/jxdm.xsd" file.)
2) Put gotWantlist.php in the "jxdm" directory for the subset.
3) Open "jxdm.xsd" in a text editor and delete all the "xsd:" occurrences. It's just a simple search and replace. Save it as "f-jxdm.xsd". The reason is that the code was a quick hack using PHP's SimpleXML parsing, which was choking on namespaces. This workaround was faster than trying to figure out the namespace problem.
4) Run gotWantlist.php. It'll parse through "f-jxdm.xsd" and output a wantlist to standard output.
gotWantlist is GPLed. Feel free to use it or share it within the confines of the GPL. The code comes with absolutely no guarantee of any kind.
The code can be obtained from the NISS Helpdesk.
*Web Site Link:
http://niem.gtri.gatech.edu/niemtools/iepdt/display/container.iepd?ref=mZWCE8Akaqw
Description:
MemphisUASI IncidentArrest IEPD
*Exchange Partners:
|
Clerk's Office Court FBI Grand Jury Juvenile Justice Law Enforcement Local Probation Service Agency State Repository Victim Victim Services Others (list below) |
Other Exchange Partners:
Law enforcement agencies in MemphisUASI area
*NIEM/GJXDM Version:
NIEM 2.1
*Project Start Date:
02/25/2010
Last Revision Date:
10/05/2010
Next Revision Date:
*Status:
Draft
Status Description:
IEPD development is complete (draft). The actual exchange implementation is in the development/test stage.
Schedule:
*Participating Organizations:
Memphis/UASI partner agencies
*Contact Name:
Zedekia Jimbo
*Contact E-mail:
*Contact Phone:
901-678-3860
Contact Fax:
*Contact Organization:
University of Memphis Center for Community Criminology and Research/Memphis Police Department
Organization Web Site:
Street Address:
City:
Memphis
State:
TN
Country:
USA
Zip Code: