Justice Information Sharing: GFIPM, IEPD, & GRA

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.

The table below addresses roles and responsibilities from a GFIPM organizational standpoint.

The table below addresses roles and responsibilities from a GFIPM Technical standpoint.

The table below illustrates how the set of GFIPM organizational roles maps onto the set of GFIPM technical roles.

The table below contains a “Terminology Map” that provides a concise comparison between GFIPM and several other prominent identity management paradigms in terms of what terminology is used to express various aspects of each paradigm.

GFIPM Points of Contact

1. Global Security Working Group
   
   Mr. John Ruegg
   Los Angeles County Information Systems Advisory Body
   [email protected]
    
2. GFIPM Delivery Team
   
   Mr. John Ruegg
   Los Angeles County Information Systems Advisory Body
   [email protected]

Mr. James Dyche
Pennsylvania Justice Network
[email protected]

The value of GFIPM at a glance include:

1. Improves privacy and security
2. Significant cost savings
3. Reduces administrative burden
4. Fewer user credentials per user
5. Distributed and highly scalable
6. Reduces complexity of systems

It is a document via which information is delivered to GFIPM federation participants, which defines the most current cryptographic security context of the federation. The document contains an entry for each communications endpoint in the federation, including identity providers (IDPs), service providers (SPs), Web Service consumers (WSCs), Web Service providers (WSPs), and others.

For further details, see GFIPM Cryptographic Trust Model Document

GFIPM uses a standardized XML credential as the key part of federated identity to be used by members and partners of the justice community. Using the GFIPM credential will allow information to be shared in a new way-with reduced management burden and improved security and on a broader scale. It represents a strategic change and dramatic improvement in the way justice organizations establish the electronic trust needed to share information.

At the highest level of concept within the GFIPM model, there are three vital components that must interact between users of multiple systems:

Identity Provider (IDP)
Service Provider (SP)
User Credential Assertions (Metadata)

Within a federation, organizations play one or both of two roles: identity provider and/or service provider. The identity provider is the authoritative entity responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners. The identity provider is responsible for account creation, provisioning, password management, and general account management. This may be achieved with existing locally accepted security mechanisms and tools.

Federation partners who offer services or share resources are known as service providers. The service provider relies on the identity provider to assert information about a user via an electronic user credential, leaving the service provider to manage access control and dissemination based on a trusted set of user credential assertions. As mentioned above, an organization that is a service provider can also be an identity provider.

For further details, see GFIPM Overview or download the PDF file below for offline reading.

Because the GRA takes a services approach to information sharing, it incorporates and reuses appropriate subsets of the National Information Exchange Model (NIEM), Global Federated Identity and Privilege Management (GFIPM), and Global privacy products. It is also being used to produce compliant services for fusion centers that address challenges identified by the Global Intelligence Working Group and Criminal Intelligence Coordinating Council (CICC). The GRA supports national programs such as the Federal Bureau of Investigation’s Law Enforcement National Data Exchange (N-DEx), which also uses NIEM as a common data format. The GRA is directly related to other Global/federal initiatives, including NIEM and GFIPM, and, in fact, provides practitioners with overarching guidance that demonstrates how these initiatives work together.

The Services Task Team effort, a BJA-sponsored working group, is charged with implementing the Global GRA by producing reference service specifications for fusion centers, biometrics exchanges, and other future services to be determined. These specifications will further show alignment with national strategies and projects.

Global Reference Architecture (GRA) is a service-oriented reference architecture for justice and public safety information sharing. It is an information exchange solution designed to cut 80 percent of implementation time and costs for state and local justice agencies through reuse of established promising practices in IT architecture and design. GRA adheres to the principles of service-oriented architecture (SOA) and it is the culmination of Global's efforts to follow through on the recommendation of adopting SOA as the standard approach to justice and public information sharing. A jurisdiction that develops an information sharing architecture based on the GRA-by explicitly adopting and following a service-oriented architecture in alignment with Global's recommendation.                                                                                                                                                

Source: A Framework for Justice Information Sharing: Service-Oriented Architecture (SOA).

The Global Reference Architecture (GRA) addresses various areas in the implementation of information exchange. Together, these areas form critical components of a comprehensive, replicable, and scalable solution to information sharing that balances varied technologies with dynamic policy considerations:

Reference Architecture Planning
The GRA includes recommendations for technical implementation that leverage Service Oriented Architecture concepts, customized for the justice domain. GRA addresses the full range of information sharing use cases by providing a flexible blueprint for implementing interoperable data sharing services across both technologically advanced organizations and those with limited technology resources. Guidelines for beginning implementation projects are available.

Service Specification Packages
GRA solutions to information exchange are made up of a combination of the connection method (often Web Services), the exchange language (use of NIEM is encouraged), and the security specifications (encryption at the transport layer, data layer, etc.). These specifications are packaged into a GRA solution that can be customized to meet an individual organization’s needs. A repository of Reference Service Specification Packages (SSPs) for information exchange in the justice community is being established; however, individual Reference SSPs are available in the interim.

Technical Implementation Guidance
Integrating a Reference Service Specifications Package (SSP) into existing IT infrastructure, despite the level of customization available in a Reference SSP, can involve a learning curve for those new to the implementation of GRA. Technical guidance regarding the GRA specification itself, as well as various guides on the interaction of different services and other aspects of information exchange, are available. In addition, personal assistance in implementing GRA is available through a number of valuable resources. See the Implementation Assistance section for more information.

Policy Guidance
In coordination with the technical implementation of a GRA Reference Service Specification Package, policy-level documents guide interaction between the agencies exchanging information. Examples include Service Level Agreements (SLA), access and identity management specifications, Memoranda of Understanding (MOUs), and many others. While these documents are never specific to GRA implementations, some specific resources available may be helpful in policy agreements. Source:

Source: https://bja.ojp.gov/program/it/national-initiatives/gra

The document - Global Reference Architecture REST Technical Note provides information regarding the compatibility issues between GRA and REST. See document link below.

Link: https://bja.ojp.gov/sites/bja/files/media/document/GlobalReferenceArchi…

Resources available for GRA implementation are listed below:

Reference Architecture Planning
GRA Framework v1.9
GRA Guidelines for Identifying and Designing Services v1.1
GRA Service Specification Guideline, Working Draft v0.9.7

Reference Service Specification Packages (SSPs)
Arrest Warrant Information Exchange (AWIE) Service Specification, Working Draft v0.9.6
Fingerprint (FP) Service Specification, Working Draft v0.9.3
Inmate Release Information (IRI) Service Specification, Working Draft v0.9.4
Request for Information (RFI) Service Specification, Working Draft v0.9.2
Submit Suspicious Activity (SSA) Field Interview Report (FIR) Service Specification, Draft v.0.9.5
Submit Suspicious Activity (SSA) Suspicious Activity Report (SAR) Service Specification Draft v.0.9.5
Terrorist Screening Center Encounter Information (TSCEI) Service Specification, Draft v.0.9.4

Technical Documents
GRA Specification v1.8
GRA Service Specification Package, Working Draft v0.9.7
GRA Execution Context Guidelines v1.1
GRA Web-Services Service Interaction Profile v1.3
GRA ebXML Messaging Service Interaction Profile v1.1
GRA Reliable Secure Web Services, Service Interaction Profile v1.1

Policy Documents
GRA Information Sharing Enterprise Statement of Participation v1.1
GRA Information Sharing Enterprise Service-Level Agreement v1.1

Source: https://bja.ojp.gov/program/it/national-initiatives/gra

GRA defines a service interface as "the means for interacting with a service." It includes the specific protocols, commands, and information exchange by which actions are initiated on the service. A service interface is what a system designer or implementer (programmer) uses to design or build executable software that interacts with the service. Since the service interface is the physical manifestation of the service, best practices call for a service interface which can be described in an open-standard, referenced format.

Service Specifications support the two (2) primary use cases of the GRA, which are:

1. To provide the justice information sharing community with an architecture and supporting specifications and guidance such that practitioners can implement SOA more efficiently. As such, the JRA and related documents provide an 80 percent solution that eliminates the need for individual justice practitioners to invent their SOA solutions from scratch and enhances the likelihood of reuse.

2. To provide a framework within which the JRA can be maintained and enhanced and national reference services can be developed to enhance interoperability.

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.

N-DEx: https://www.fbi.gov/services/cjis/ndex

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

• https://bja.ojp.gov/media/document/30116

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:

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:

[email protected]

*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: