FAQs
The GJXDM Instance Validation Tool is a simple tool built on top of the Apache Xerces parser, and can be used to test whether an XML instance is valid against a GJXDM-conformant schema.
GJXDM Validator: https://bja.ojp.gov/program/it/national-initiatives/niem
Currently, there are four methods to define a relationship (or a ''link'') between two components that do not already have a relationship with each other in the Global Justice XML Data Model (GJXDM). (To demonstrate the methods, as an example the component Citation will be linked to Charge. A citation ID is represented in the GJXDM as j:Citation/j:ActivityID (j:ActivityID is inherited from j:ActivityType, the parent of j:CitationType). However, j:ChargeType does not contain j:Citation or a parent of j:Citation, and there is no relationship between the two in the GJXDM. So one has to define that relationship.
The first method, referred to as inclusion, is to simply define a new type that extends the type of one component (which is a complex type) to include the other component (which can be either a complex type or a simple type). To use the first method, one would define their own charge type that is an extension of j:ChargeType. Then one would have to add j:Citation to the sequence. If there were any other GJXDM properties not in j:ChargeType that one wants, those could be added as well. If one only wants the citation ID (and not the whole citation), since it is so trivial, one could consider defining their own CitationID element of type IDType. This method might be most appropriate, since extending j:ChargeType to include j:Citation (or your:CitationID) is analogous to including the citation ID in your charge table.
The second method, referred to as reference, is to include in one component a reference to the other component using ID/IDREF . For this method, one would define a new type that extends j:ChargeType to add j:CitationReference to the sequence (instead of j:Citation). This can be used if the citation information is already represented elsewhere as j:Citation and the purpose is to just reference that existing citation information instead of duplicating it in the charge information.
The third method, referred to as association, is to use the j:Relationship element. It has the attributes name, subject, and object. For our example, one would give it the name attribute -- say ''ChargeCitationID''. The subject attribute would be j:ChargeReference and the object attribute would be j:CitationReference. This method is used to define some relationship between two properties without extending one to include the other (as in the first method) or a reference to the other (as in the second method).
The fourth method is to define your own association type and element, similar to the third method, but enabling additional relationship content beyond the name, subject, and object.
The GJXDM schema itself does NOT provide query capabilities. The two alternatives are to build queries that return GJXDM compliant ''types'' or to use web services. There is anobject model with method names to provide such query: IMHO, it is very academic in nature with minimal business analysis for practical usage; i.e., it is more of a ''controlled vocabulary'' than a real model for implementation with modern tools.
It is possible to build queries that return GJXDM compliant ''types''. One should use a naming convention for SOAP queries that follow standard camel case, using the actionTypeConstraintType convention: getPersonByID; returns Person getCourtAppearanceActorPersonByPersonName; return CourtAppearanceActorPerson (drop the dot notation), etc. Regarding the source of the input parameters, it is not possible to directly use the GJXDM naming as input parameters due to the contextual nature of the typing (complexTypes). Specifically, some of the names used in the attributes and elements are TOO GENERIC to be able to pass them as SOAP parameters. You need the entire XPATH notation to be able to define the full context / semantic definition of the parameter. Therefore, the requests are often home spun.
The second option is to use web services (WS-I conformant SOAP and WSDL) to implement the exchange. To use GJXDM in a web services context with WSDL, your schemas (subset/constraint and extension) become a source of types for the input and output parameters for each operation, as well as for faults (errors). This tends to provide a lot of flexibility in reusing these structures in the input (request) and output (reply) messages. That way, one does not need to try to figure out how to fit this all into one document schema, since the WSDL really takes on that role. The other advantage of web services and WSDL is that in most cases one can generate both requestor and service endpoint stub/skeleton code, which invokes an interface that you implement to wire up the endpoints to business logic on each end. It is also possible to choose to parse the XML, or have it de-serialized into an object graph. (This is well-supported on both the Java 2 and .NET platforms.)
The JXDM-Query-Options file in the attachment contains recommendations, best practices and lessons about query generation for the model.
Documents
https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/JXDM-q…
When considering the Global Justice Extensible Markup Language (XML) Data Model (GJXDM), the government and industry experts, technical managers, and engineers responsible for its development formed the following assumptions that guided them in their design of the GJXDM.
The GJXDM:
Be reusable, with extensible data components that facilitate standard information exchange in XML within the justice, courts, public safety, and homeland security communities.
Generalize for the community at large, rather than specific document instances.
Provide referenceable schema components for schema developers.
Have a Global Justice XML Data Dictionary (GJXDD) and Global Justice XML Data Dictionary Schema (JXDDS) that will evolve, change, and require extensions, using extension methods that minimize the impact on prior investments.
Represent and implement domain relationships.
Have time, technical, and requirement constraints that mandate rational trade-offs—no silver bullets! The design criteria discussed above were developed in accordance with the following goals:
To enable forms-based maintenance/reconfiguration of the GJXDM.
To automatically generate XML schema for the GJXDD schema specification.
To automatically generate equivalent Resource Description Framework (RDF) schema.
To store and map data element requirements from any data source (schema, Document Type Definition [DTD], data table, or data dictionary) to GJXDM components.
To enable measurement by source of the number of data requirements covered and the number of data left to implement.
To provide search filters, forms, and tools to quickly analyze data requirements and build initial draft object models for vetting.
NLETS, which serves as the International Justice and Public Safety Information Sharing Network for state owned system connecting all 50 states, territories along with every federal agency with a justice component, has found great success in its embrace of the Global Justice XML Data Model (GJXDM) standard. As a result there are over 500,000 access points.
The network has for 38 years provided sharing of data – the hub for interstate exchange. NLETS has always “dictated” the data format for use of the system. And until recently the format was proprietary, but fortunately a decision was made to adapt GJXDM as the standard. In the past, NLETS did not hold any data. Proprietary data formats were used to connect disparate state and federal systems. This forced extensive custom programming for each NLETS interface user. NLETS -FBI and the states all have the same "customers." Yet the proprietary format and the different specifications all made the different users design different applications for the different interfaces. This severely drove up costs and maintenance issues.
GJXDM offered a chance for NLETS to simply exchange of information. They are still supporting proprietary data formats, but no new services will be offered in legacy. All NLETS transactions and responses were transitioned to GJXDM 3.0.x. Currently, NLETS are accepting nearly 1 million FBI-CJIS-III CCH transactions per month in XML. They are doing hundreds of thousands of bidirectional transformations (Legacy – XML – Legacy) daily. The success of the transformation to GJXDM has expanded the role of NLETS. Kentucky, Maine and Wisconsin are sending and receiving XML rap sheets across NLETS. And there is a pilot to standardize driver's license records across state lines over NLETS is underway using GJXDM XML. The Amber Alert Consortium for interstate Amber notification for justice enterprise also uses GJXDM.
There are over 40 projects that are using or are committed to using the Global Justice XML Data Model (GJXDM) for their data exchange applications.
The organizations include:
1. Administrative Office of the Courts, Georgia (Georgia Judicial Exchange)
2. Arizona Supreme Court, Administrative Office of the Courts (Justice Integration-Electronic Citations Import)
3. Arizona Supreme Court, Administrative Office of the Courts/Arizona Criminal Justice Information System (ICJIS) (Adult Probation Data Exchange)
4. Arkansas Integrated Justice Information Systems Program (Arkansas IJIS Pilot Project)
5. Association of Motor Vehicle Administrators (AAMVA) (CANDLE : Standardization of Driver's License records across NLETS – The International Justice & Public Safety Information Sharing Network)
6. California Administrative Office of the Courts (Data Exchange Standards Initiative)
7. California Department of Justice (DOJ) (Statewide Investigative Networking System (SINS))
8. Coconino County, Arizona (Criminal Justice Integration Project)
9. Colorado Integrated Criminal Justice Information System (CICJIS) (CICJIS Online Presentation System (COPS))
10. CriMNet - Minnesota Department of Public Safety (CriMNet EAI Backbone)
11. Criminal Information Sharing Alliance, Incorporated (CISAnet: Sharing, organizing, and analyzing of criminal information (intelligence, CJIS, investigative, etc.) across local, state, and federal boundaries for investigative and analytical purposes)
12. Florida Law Enforcement Data Sharing Consortium (FINDER – Florida Integrated Network for Data Exchange and Retrieval)
13. Maine State Police (Bureau of Motor Vehicles Interface)
14. Maine State Police (Criminal History Record System - Justice Data Broker)
15. Maine State Police (Criminal History Record System - Provision of Criminal History Records (RAP Sheets))
16. Maine State Police (Violations Bureau Interface)
17. Missouri Office of State Courts Administrator (OSCA) (Missouri Court Automation Project)
18. NLETS (Standardized XML Transactions)
19. North Carolina Criminal Justice Network (CJIN) (DOJ, SBI, DCI Batch Updates to ACIS)
20. North Carolina Criminal Justice Network (CJIN) (Driver License Photo Transmission)
21. North Carolina Criminal Justice Network (CJIN) (Facial Image Transmission)
22. North Carolina Criminal Justice Network (CJIN) (Sex Offender Data Sharing)
23. Ohio Association of Chiefs of Police (OLLEISN - Ohio Local Law Enforcement Information Sharing Network)
24. Orange County Florida (Integrated Criminal Justice Information Systems)
25. Pennsylvania Justice Network (JNET) (GJXDD 3.0-Based Driver History Record)
26. Pennsylvania Justice Network (JNET) (Criminal History Records Disposition System Update Project)
27. Pennsylvania Justice Network (JNET) (Warrants Project)
28. Pennsylvania Justice Network (JNET) (Sentencing Guidelines Project)
29. Pennsylvania Justice Network (JNET) (Electronic Citation Filing Project)
30. RISS Application Development Group (RISSApps)
31. Seattle, Washington (Seattle Justice Information System (SeaJIS))
32. Southwest Alabama Integrated Criminal-Justice System (Law Enforcement Tactical System (LETS))
33. State of New Hampshire - Department of Safety (J-ONE (One Network Environment for Justice) - Bail Conditions)
34. State of New Hampshire - Department of Safety (J-ONE (One Network Environment for Justice) - Warrant Requests)
35. State of New Hampshire - Department of Safety (J-ONE (One Network Environment for Justice)- Criminal Complaints)
36. State of New Hampshire - Department of Safety (J-ONE (One Network Environment for Justice)- Dispositions)
37. State of New Hampshire - Department of Safety (J-ONE (One Network Environment for Justice)- Protection Orders)
38. Supreme Court of Georgia (Supreme Court E-filing Project)
39. Syracuse Police Department (CNYLEADS: Electronic reporting with RMS.)
40. United States Department of Justice (DOJ), Executive Office for United States Attorneys (EOUSA) and United States Postal Inspection Service (USPIS) (Victim Notification System (VNS)
41. University of Maryland Center for Advanced Transportation Technology (UMD-CATT) (Capital Wireless Integrated Network (CapWIN))
42. University of Southern Mississippi (Automated System Project)
43. State of Vermont Agency of Digital Services - formerly Department of Innovation and Information (Vermont Criminal Justice Integration Services)
44. Washington State Administrative Office for the Courts (Data Exchanges)
45. Whatcom County, Washington (Whatcom Exchange Network (WENET))
46. Wisconsin Department of Justice (eTIME Server to Server)
47. Wisconsin's Justice Information Sharing Program (WIJIS) (The Justice Gateway)
Organizations Using GJXDM: http://it.ojp.gov/default.aspx?area=nationalInitiatives&page=1227
How GJXDM is being used: http://www.idealliance.org/proceedings/xml04/papers/150/How-US-Govt-Using-XML-1YL.html#S7.9
GJXDM prereleases have four integers in their version numbering schemes, and include 3.0.0.0, 3.0.0.1, 3.0.0.2, and 3.0.0.3. All were released in 2003. For transitional reasons, prereleases 3.0.0.0, 3.0.0.1, and 3.0.0.3 will remain available in their respective namespaces for an undetermined period of time. GJXDM prereleases are no longer updated or supported.
The XML Structure Task Force (XSTF) found a bug in XMLSpy that prevented refinement of the simple content of a complex type by restricting an existing complex type with simple content. It was decided that, in deference to XMLSpy users, schemas that use this capacity of XML Schema will be avoided.
The common principles for using GJXDM are as follows:
* Design and synthesize common, reusable, extensible data components that facilitate standard information exchange in Extensible Markup Language (XML).
* Requirements-based: Build content from existing data models, dictionaries, and specifications.
* Object-oriented: Maximize efficiency through extension and consistent reuse of properties and types.
* Generalize the Global JXDM for the justice community at-large. Do NOT target specific applications or systems.
* Provide referenceable schema components primarily for schema developers.
* Facilitate the evolution of the Global JXDM and its schema by providing change management and extension.
* Extendable: Enable local additions of data components, but preserve the semantic relationships when they exist, and minimize the impact on prior schema and code investments.
* Implement and represent domain relationships so they are globally understood.
* Preserve global semantics.
* Build to evolve with emerging technologies (e.g. OWL, Web Services, etc.).
* In view of time constraints, national priorities, requirements conflicts, and technical limitations, apply rational compromises to these criteria to achieve solutions.
The following sequence describes compatibility within the GJXDM 3.0 release series: 3.0(.0) instances validate with 3.0.2, 3.0.3, ..., 3.0.n schemas 3.0.2 instances validate with 3.0.3, 3.0.4, ..., 3.0.n schemas 3.0.3 instances validate with 3.0.4, 3.0.5, ..., 3.0.n schemas ... (Note: 3.0.1 was removed from service.) We say that within the 3.0 series, forward compatibility is maintained.
However, when 3.1.0 (a new series) is released, 3.0.n instances are NOT guaranteed to validate against 3.1.m schemas. However, 3.1.0 instances will validate with 3.1.1, 3.1.2, ..., 3.1.n schemas, etc. (if/when they are released). In other words, forward compatibility within the 3.1 series will be maintained.
Caveats:
If you want a 3.0.0 instance to validate against the 3.0.2 GJXDM schema, then you must change the namespace reference in the instance to 3.0.2 (and in your schema, as well if you are using one between the instance and the GJXDM schema).
Depending on which GJXDM components you are using, you may find that a 3.0.0 instance validates against the 3.1.0 GJXDM schema (when available). DO NOT assume that every 3.0.0 instance will validate. NO guarantees of validation will exist between 3.0 and 3.1.
Not at the moment. However, the ultimate intent of the XML Structure Task Force (XSTF) is to establish a Global Justice Data Registry capability. This would provide a single logical point of access to all GJXDM artifacts, including the GJXDM content, the schema releases, reference document schemas, tools, and additional capabilities.
These may be stored in a local repository or in multiple distributed networked repositories. The registry would be standards-based and present multiple interfaces (e.g. browser, Web services) to enable both users and other servers to access, navigate, view, and retrieve metadata from the GJXDM. The data registry may be implemented with commercial registry software, depending upon requirements and cost-effectiveness. The XSTF and the Office of Justice Programs (OJP) are evaluating requirements and alternatives
OJP Website: http://www.ojp.usdoj.gov/
There is a draft mapping of the 53 data elements of the National Incident Based Reporting System (NIBRS) to the GJXDM, Version 3.0, release. While many of the elements have a direct mapping, some elements are not a one-to-one match. Furthermore, in a few cases a mapping is either too complex or does not exist, and was therefore omitted.
NIBRS was created by the FBI's Uniform Crime Reporting (UCR) program, which began in 1929, collects information about crimes reported to the police. In 1982, BJS and the FBI sponsored a study of the UCR Program with the objective of revising it to meet law enforcement needs into the 21st century. A 5-year redesign effort to provide more comprehensive and detailed crime statistics resulted in the National Incident-Based Reporting System (NIBRS) which collects data on each reported crime incident.
The UCR Program is currently being expanded to NIBRS. Currently under the Summary system, law enforcement authorities aggregate the number of incidents by offense type monthly and report these totals to the FBI. Under incident-based reporting, agencies will provide an individual record for each crime reported. The Summary UCR Program collects offense information on the 8 Part I crimes of homicide, forcible rape, robbery, aggravated assault, burglary, larceny-theft, motor vehicle theft, and arson. It provides limited information about offenses, victims and offenders, and includes reported arrests for 21 additional crime categories.
Under NIBRS, law enforcement authorities provide information to the FBI on each criminal incident involving 46 specific offenses, including the 8 Part I crimes, which occur in their jurisdiction. Details about each incident include information about multiple victims and offenders. Arrest information on the 46 offenses plus 11 lesser offenses is also provided in NIBRS. Since NIBRS place such a crucial role in the activities of FBI, it is very important that the link between the NIBRS elements and GJXDM elements are clearly defined.
Spreadsheet of Mapping: https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/NIBRS-…
Note that the Incident Reporting Reference IEPD, created by SEARCH, has been validated to map all 53 NIBRS elements.
Ultimately, XML and the Global Justice XML Data Model can help to make criminal justice information sharing easier, quicker, and less expensive for agencies by offering standard tools, techniques, and data structures.
With the help of XML and the Global Justice XML Data Model, the opportunity for proactive justice information sharing is enhanced, arming everyone across the justice and public safety communities with the most accurate and up-to-date data to make the very best decisions possible—increasing law enforcement and criminal justice agency efficiency, public safety, and national security.
Refer to the article "Extensible Markup Language (XML) and Its Role in Supporting the Global Justice XML Data Model": https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/What_i…
The Global Justice Extensible Markup Language (XML) Data Model (GJXDM) is an XML standard designed specifically for criminal justice information exchanges, providing law enforcement, public safety agencies, prosecutors, public defenders, and the judicial branch with a tool to effectively share data and information in a timely manner. The GJXDM removes the burden from agencies to independently create exchange standards, and because of its extensibility, there is more flexibility to deal with unique agency requirements and changes.
A long long-term goal is to provide a baseline model for the data dictionary that can be represented in advanced technologies beyond XML Schema.
The first step to getting started with GJXDM is learning about XML (Extensible Markup Language).The next major step is familiarizing one self with all the tags in the data model that are expected to be used with the GJXDM standard.
The tags are presented in an easy to navigate schema, in the format of an Excel Document.All the tags represented in the schema are easy to understand because their purpose is clearly and fully defined in their name. The Excel Document also provides information about what type of data is a tag, including inheritance links, and a brief description.
For Example (using the tag name "Biometric ID") : The tag BiometricID clearly refers to "an identifier used to uniquely refer to a biometric." Therefore it is under the Biometric heading. Biometric is in the part of the file under the person tab, because Biometric clearly defines property of a person. The type of BiometricId is provided as inheritance of IDType. And a quick link to IDtype is provided to allow the user to know what sub-tags one should use within the BiometricID tag. An identifier used to uniquely refer to a biometric.
Some useful links:
XML Tutorial: http://www.w3schools.com/xml/xml_whatis.asp
GJXDM Website: https://bja.ojp.gov/program/it/national-initiatives/gjxdm
GJXDM Version 3.0.3 Schema: https://bja.ojp.gov/program/it/national-initiatives/gjxdm
GJXDM User's Guide: https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/GJXDMU…