FAQs
Sample XML instance documents based on the FilingSubmissions.xml schema are attached to the answer.
Cardinality rules can be specified by editing the default cardinality specifications (minOccurs=0, maxOccurs= unbounded) in a generated subset schema. However, this introduces a development maintenance burden, since each time the subset is regenerated out of the Subset Schema Generation Tool (SSGT), the same edits must be reapplied.
For this reason, a best practice has evolved in the community to represent cardinality rules in constraint schemas.
A feature has been requested for the SSGT to allow specification of cardinality constraints directly in subset schemas. So far, this feature has not been implemented by GTRI.
GJXDM has technical documentation and it explains the technical foundation behind the Global Justice XML Data Model and Dictionary. Its goal is to provide a solid infrastructure for storing and managing relationships between data entities independent of XML. These entities, and the relationships between them, are defined precisely and flexibly using two kinds of components: types and properties.
Reference link: https://www.niem.gov/technical/Pages/niem.aspx
When describing GJXDM and NIEM, the term "structure" is often used, but what is really meant by that? In this case, structure refers to the representation of data dictionary entities in XML Schema. The key factors to remember are:
• Data model types become XML Schema types.
• Properties become XML elements and attributes.
• Data model type inheritance becomes XML Schema type inheritance.
• Duplication of entities is avoided by using references
The important concept here is the transition of the underlying data model hierarchy to the representation of objects in the XML schemas (GJXDM and NIEM) as elements and attributes.
The Law Enforcement Information Technology Standards Council (LEITSC), funded through the Office of Justice Programs (OJP), fosters the growth of strategic planning and implementation of integrated justice systems by:
· promoting the merits of information technology standards:
· providing advice to the nation's law enforcement community on technical aspects of IT standards;
· sharing practical solutions; and
· representing the voice of law enforcement in the expansion of justice and public safety information technology standards.
The first year of funding provided by the Bureau of Justice Assistance (BJA) established LEITSC and allowed the group to lay a solid foundation for the project. Accomplishments of the group include the organization and staffing of project; the identification of association staff and membership representatives; creation of project charter; the development and implementation of operational plan; outreach by utilizing association IT initiatives and collaboration with external initiatives; the coordination of quarterly council meetings; and, the development of a strategic plan.
The strategy proposed utilizes committees comprised of law enforcement information integration practitioners, industry representatives and justice standards representatives to review and evaluate existing information technology standards, specifically functional and technical XML standards. They will determine if the standards reviewed fit the needs of law enforcement and make recommendations accordingly. In addition, a detailed communications plan will be designed and implemented to leverage each association’s means to communicate the need and availability of information technology standards to the law enforcement community, and to involve the Council in on-going standards development.
Source: http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=displa…
Since the 1980’s, most VINs are unique combinations of 17 alphanumeric characters identifying each specific vehicle as defined by ISO 3779 and ISO 3780. Within the 17-digit number are codes that indicate the vehicle's make and model, manufacturing location, manufacturer value (the ''world manufacture id'' - WMI, controlled by SAE registration), optional equipment, and a manufacturing sequence number, etc. A vehicle identification number is normally assigned by the original equipment manufacturer (OEM), but can be assigned by titling or registration agencies or by secondary manufacturers or finishers.
It is important to note, that VINs are not unique at times. In early uses, many of the ''fly by night'' finishing firms would assign the same VIN for similar products. There are also rule exceptions for older or more exotic vehicles with less than 500 vehicles that result in duplicate VINs. Most law enforcement CAD systems, if they recognize exceptions will prompt the user when the make/model values encoded in the VIN do not match the information
From: Global XML Structure Task Force (GXSTF)
To answer concerns that the Uniform Crime Reporting (UCR) code schema is incorrectly documented, the Global XML Structure Task Force (GXSTF) is publishing Patch-1 for all versions of the GJXDM (3.0.0, 3.0.2, 3.0.3). This corrects the UCR documentation elements for the UCR codes that are incorrectly labeled. It does NOT disturb type or element definitions. The README.txt file explains how to patch each release without having to move to a new version.
Patch-1 can be downloaded as: https://bja.ojp.gov/program/it/national-initiatives/gjxdm
In addition to posting this patch to the GJXDM Listserv, it will be highlighted and downloadable from the GJXDM main index page (it.ojp.gov/jxdm) as well as each release index page. Patch-1 will be added to the archive file for each release (jxdm-*.zip). However, the user must apply Patch-1 to the archive, if desired.
Only GJXDM 3.0.3 will be patched in the Schema Subset Generation Tool (SSGT) (gjxdmtools.gtri.gatech.edu). Want lists that were previously generated by SSGT from the non-patched 3.0.3 release will be regenerated with the updated UCR schema (i.e. patch applied).
The change logs for the current and previous releases will not be updated. The next full release of GJXDM will correct the UCR code schema and post an entry to that effect in its change log.
The UCR schema errors are semantic in nature, and they are contained in xsd:documentation elements only (within ucr.xsd). They do not impact XML validation.
Therefore, as long as you are not using the documentation within the UCR code schema as an authoritative guide to the semantics of the UCR codes, your schemas, instances, and applications should be unaffected, regardless of whether you apply Patch-1 or not.
Data Format for the Interchange of Fingerprint, Facial, & Scar, Mark, & Tattoo (SMT) Information defines the content, format, and units of measurement for the exchange of information that may be used for the fingerprint, facial, or SMT identification of a subject. It consists of a variety of items (some of which are mandatory), including related record data, digitized fingerprint information, and compressed or uncompressed images of fingerprints, mugshots, or SMTs.
NIST namspace http://release.niem.gov/niem/ansi-nist/2.0/namespace
This utility has been developed as part of the SEARCH project to develop a Reference Information Exchange Package (IEP) for incident reporting. As part of that project, the utility provided a mechanism to test the robustness of the IEP, since one requirement of the IEP was the capability of representing a NIBRS incident report. During the development of this utility, a small number of missing IEP elements were discovered and incorporated into the final version of the IEP.
The utility is also a potentially valuable tool that could be incorporated into NIBRS-compliant law enforcement records management systems (RMSes), should those systems wish to emit XML instance reports that are valid according to the IEP structure.
To download the NIBRS Incident Report to Incident Reference IEP Conversion Utility and related documentation, please click on these links:
http://www.search.org/files/zip/nibrs-iep-converter-src.zip#overview.doc or
Unified Modeling Language Tools
Today, there are a substantial number of tools for enabling model-driven development, both commercial and open-source. Microsoft’s Visio (available through the Microsoft Office suite) has recently been used to support domain modeling by several members of GJXDM Information Exchange Package (IEP) teams.
One of the most popular open source tools for UML design is ArgoUML. This is a full GUI (graphical user interface) desktop application that allows creation of virtually the entire set of UML diagrams, with the ability to save those diagrams in the XMI format, which many modeling tools use as their source for code generation. ArgoUML is hosted at http://argouml.tigris.org/, please go there for all file releases and resources.
There is no single right approach to this issue; the schema designer should ensure conformance to local business and architectural requirements. The following may assist in determining the fit of each approach to requirements.
NIEM 1.0 and GJXDM 3.0.3 contain components that implement many of what could be considered "transactional" or "messaging" attributes. These attributes appear in NIEM 1.0 in the DocumentType type in the universal and common namespaces and the MetadataType type in the structures namespace. In GJXDM 3.0.3, the attributes appear in DocumentType and in the attributes of SuperType. The schema designer should assess the fitness of exchange requirements (represented in the domain model for the exchange) to these NIEM or GJXDM components.
It is important to consider whether the "transactional" or "messaging" requirements are addressed by the standards or technology being used to transport the message between systems. In many cases, such as addressing, the message transport infrastructure will rely on attributes' being represented according to a standard (such as WS-Addressing). Similarly, reliable messaging mechanisms will often assign message identifiers and timestamps (or will rely on their being represented according to a standard in order to function properly.) The schema designer should be aware of these issues when choosing where (and whether) to represent these attributes in an IEPD.
In addition, as a general principle, it is a good idea to satisfy requirements by leveraging standard XML vocabularies rather than inventing new structures. Even if there is no component in NIEM that meets a requirement, there may be other standards that do contain appropriate components.
The Justice Reference Architecture (JRA) consists of two principle sets of information: a reference architecture that defines standard terminology and concepts for understanding a service-oriented approach to information sharing, and a set of documents that evolve JRA concepts into guidelines about how to design and implement information exchanges.
The JRA is a deliverable of the Global Infrastructure/Standards Working Group (GISWG).
The JRA is based on the OASIS Reference Model for Service-Oriented Architecture (SOA-RM). The SOA-RM provides vendor-neutral, standard definitions of concepts involved in information exchange and system integration. (Actually, the SOA-RM is sufficiently general to support exchange between and integration among non-computer entities, but the JRA applies the concepts only to system integration.)
They key innovation of the JRA is to introduce the concept of a service between two systems: one that has a capability (called a "provider system"), and another ("consumer system") that needs to use that capability to achieve some business objective. The capability can be simply providing information, or it can be a complex workflow or business process. The service that sits between these two systems is defined by a formal model that documents clearly and specifically what the service does, as well as what information is needed to interact with the service. In the JRA, the information model of the service is formed from NIEM- and GJXDM-conformant components.
The JRA also includes concepts that support the interaction between consumer systems and services, such as: repositories to store and search service descriptions, infrastructure elements necessary to transmit information between systems, and technical standards for inter-system communication (called "service interaction profiles").
Specific guidelines currently under development include: service interaction profiles for web services, MQ, file transfers, and ebXML; guidelines for modeling/describing services; guidelines for infrastructure capabilities; and guidelines for the identification of services. GISWG is also developing guidelines for the management and governance of a service-oriented architecture.
Finally, the JRA will include a set of "reference services" that represent typical, common services that exist in justice.
There are two key use cases for the JRA.
The first use case involves an actor whose responsibility is to establish an architecture-that is, a set of standards and infrastructure capability requirements-for a justice information sharing initiative. Often (but not always) this actor will be an architect or chief information officer, or equivalent. The actor uses the JRA as a starting point for standardizing the terminology used to describe and understand information sharing in his/her enterprise. The JRA will also provide baseline technical standards for the design and implementation of services, which the actor can modify as necessary to suit local business requirements.
The second use case involves separate jurisdictions using the set of "reference services" to establish interoperability between those jurisdictions.
There are many information sharing and system integration architectures to choose from. Web services (i.e., the use of SOAP over HTTP and standards based on SOAP, such as the WS-I Basic Profile, WS-I Basic Security Profile, WS-Security, WS-Reliable Messaging, WS-Addressing, etc.) is not the only viable approach.
Message Queuing (MQ) approaches offer one alternative. In an MQ approach, the sending system forms a message (in the justice world, this should be a GJXDM-conformant message) and uses a software component to place the message in a queue. Often, this queue is "local" to the sending system-either on the same computer or a "nearby" computer that shares a very reliable network with the sending system. The queue at the sending end identifies the destination of the message and sends it to a second queue at the destination, where the message remains until it is retrieved by the destination system. Often, the message is not deleted from the queue at the sending end until it receives confirmation of receipt at the destination queue, thus implementing "reliable delivery" of the message.
MQ approaches require software and hardware infrastructure to support the message queues. The software infrastructure generally makes available application programming interfaces (APIs) that allow developers to place messages in and retrieve messages from queues. These APIs can be proprietary to the manufacturer of the software infrastructure, or they can follow API standards developed by industry consortia (such as the Java Message Service (JMS) APIs.)
File Transfer is a second alternative approach. A file transfer involves a sending system writing a file (in the justice world, this should be a GJXDM-conformant information exchange package serialized to a file) to a local or remote file system. Writing to a remote file system generally involves a file transfer protocol such as FTP or S/FTP (secure FTP). When the file arrives at the destination, the destination system reads and processes it.
Writing and reading transferred files can be accomplished by developing software or using import/export capabilities of a database platform. When developing software for this purpose, developers often use tools such as the .NET XML serialization libraries or Java libraries such as JAX-B or XML Beans.
Currently there are two SSGTs supported in the community, these are the GJXDM SSGT and the NIEM SSGT.
If the site goes down, bugs should be reported directly to the IJIS Helpdesk (https://www.niem.gov/Pages/contact.aspx).
Email: [email protected]
NIEM SSGT issues must be emailed or called into the IJIS Helpdesk (https://www.niem.gov/Pages/contact.aspx).
Telephone: 1-877-333-5111 or 703-726-1919
Email: [email protected]
Any suggestions for improving the NIEM SSGT must be put through the proper NIEM Governance committees.
The Justice Information Exchange Model (JIEM) Methodology is a structured, formally documented approach for defining and capturing information exchange requirements. The overarching goal of the JIEM Methodology is to build consensus about information exchanges among business partners. The JIEM Methodology provides the steps necessary to capture both the content of the exchange (the information being exchanged) and the context of the exchange (who is involved in the exchange, the factors determining when and where the exchange should occur, and what event will happen next).
The JIEM Methodology is premised on the notion that all information exchanges can be described by identifying five dimensions of requirements. These five dimensions are:
1. Process: A series of logically related events and exchanges that achieve some business purpose or milestone.
2. Event: Decisions or actions that trigger information exchange.
3. Agency: Business partners who exchange information.
4. Condition: Decision points or "gates" that define when information exchange happens.
5. Information: The content of the information exchanged-the "payload."
JIEM documents additional important requirements, including the priority and frequency/urgency of each exchange. In the future, JIEM will capture critical policy requirements such as exchange privacy and security details.
The JIEM Methodology also supports the concept of reference models. A reference model is a set of information exchanges regarding business functions that are common to most jurisdictions based on the models developed by JIEM users. Reference models allow JIEM users to leverage key exchanges of relevance to their site, reducing the time it takes to develop requirements while producing results that are more consistent with those of other jurisdictions. The existing JIEM reference model is based on the Adult Felony judicial process. SEARCH is adding new reference models to define exchanges commonly found in other environments.
The JIEM Modeling Tool applies the JIEM Methodology and allows users to capture requirements using the five JIEM dimensions. The Tool also supports the definition of "as-is" and "to-be" models, aligning with basic enterprise architecture techniques and supporting the ability to identify information sharing capability gaps. This information can in turn feed into a jurisdiction's strategic planning efforts in order to determine specific projects, initiatives and investments necessary to achieve business goals outlined in a strategic plan.
Between 1998 and 2007, the JIEM Tool was a Web application hosted at SEARCH. SEARCH released JIEM 4.0, based on the Eclipse tools platform, in September 2007. This new platform improves usability and opportunity to integrate JIEM with other off-the-shelf modeling tools (such as UML and XML tools) that industry is actively developing on Eclipse.
JIEM plays a key role in the National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) Lifecycle. The second step in the NIEM IEPD Lifecycle is "Analyze Requirements." JIEM provides an effective way to gather the requirements necessary to construct an IEPD. The JIEM Tool is also integrated with NIEM through the use of component libraries. Component libraries allow JIEM users to use NIEM concepts when defining exchange content.
Access to JIEM, including training, is available at no cost from SEARCH through funding from the Bureau of Justice Assistance, U.S. Department of Justice. Use of JIEM is reserved for those who have completed JIEM training and certification. For more information about JIEM training opportunities, please email [email protected].
Further information about JIEM can be found on the official JIEM Web site: http://www.search.org/programs/info/jiem.asp