FAQs
Yes, there is. The GJXDM User Guide can be located via the following URL:
https://bja.ojp.gov/program/it/national-initiatives/gjxdm/documentation
Another good source of information is the GlJXDM Developer's Workshop Online Training Materials Website that contains all of the presentations, training materials, and recorded audio/video streams from the workshop held at Georgia Tech in Atlanta May 11-12, 2004.
The GJXDM consists primarily of object classes and properties. The Object classes are converted into XML Schema types. They eache represent a specific syntax and structure for a set of values. The properties are converted into XML Schema attributes and elements. They each represent characteristics, or values of things.
The GJXDM is a reference model that is based on a class hierarchy of many specific objects (xsd:type) derived from one very general object (SuperType). Each object contains any number of properties (xsd:element or xsd:attribute). These properties may be simple or complex elements (containing sub-elements). The highest level object classes (under the SuperType) are PersonType, OrganizationType, PropertyType (i.e., things), LocationType, ContactInformationType (i.e., electronic means of contact), ActivityType, DocumentType, and other smaller supporting types.
There is also a special class of RelationshipType used to specify meaning to a link between two object instances. On many of these objects, there are metadata properties (xsd:element or xsd:attribute) that supplement meaning. For example, all properties of MeasureType have a mandatory "units" attribute.
The components were chosen from a variety of legal and technical sources that preceded Global Justice XML Data Model (GJXDM). Data components were built from approximately 35 data dictionaries, XML schema documents, and XML data models under development or in use by various law enforcement and judicial organizations.
These sources yielded approximately 16,000 data components (elements, attributes, and types). Through study and analysis of the similarities and differences among these components, approximately 2,200 properties (xsd:element, xsd:attribute) and 550 types (xsd:type) were synthesized to represent a common set of elements and types, the GJXDM.
It is important to realize that the authors did not invent the content. Instead, the GJXDM tries to capture the requirements of the 35 data sources as completely and accurately as possible. However, compromises were necessary in order to follow the basic design principles and criteria set forth by the XML Structure Task Force (XSTF).
The source data requirements analyzed by the XML Structure Task Force (XSTF) were not consistent in their use of codes. For components with the same meaning, some sources used codes; others used literals. When codes were used, they were not always drawn from the same code table, and some code tables are specific to local jurisdictions.
In order to provide maximum flexibility, the GJXDM usually provides both a code type element and a text type element (that may contain a literal). There are particular code tables that are always common; for example National Criminal Information Center (NCIC)-2000 and the American Association of Motor Vehicle Administrators (AAMVA). Therefore, the XSTF provided a mechanism to use codes from other namespaces. This enables the use of standards without restriction to a single internal set of values.
This also does not require a change to the GJXDM namespace every time external standards change. For example, the XSTF has created an NCIC-2000 schema in its own namespace that contains the NCIC code tables. Temporarily, the XSTF refers to this as the NCIC-2000 proxy schema because it is external to the GJXDM namespace and can be updated without causing the GJXDM to change. The XSTF anticipates that local jurisdictions will want to create their own proxy schemas for their local code tables as well.
NISS Clearinghouse
Reference elements exist to allow schema designs with multiple occurrences of the same information object or instance to reference a single content-filled object rather than to repeat it in different locations.
This ensures that the same information object does not repeat multiple times and mislead the receiver into thinking there are multiple (different) objects. If an object is recorded once and referenced from everywhere else it is used, then there is a lower risk of misunderstanding or inconsistency. This requires one XML element of type ReferenceType for each element in the model. That is, for every element named "X" in GJXDM, there is a second element named "XReference" that is intended to reference, or "point to", an element named X appearing elsewhere in the instance.
While this technique makes the GJXDM somewhat redundant, the use of separate elements for bearing content and content references makes it easier for applications to know immediately if and when they are looking at the information object itself or a reference to it.
A GJXDM or NIEM reference Information Exchange Package Documentation (IEPD) is a specification for a model document or transaction that has been derived from and uses the GJXDM / NIEM. It is currently considered a suggested model for a particular kind of document.
For example, an Arrest Warrant reference Information Exchange Package Documentation (IEPD) uses the GJXDM, is specified in XML Schema, and is a reference for building an Arrest Warrant. This means that it can be used as is, or extended for a more specific or local purpose, or to guide construction of another similar document specification. There also some examples of reference IEPDs that use the NIEM such as, SAR for Local and State Entities IEPD v1.1.
A "reference" is a starting point for a standard, not a rigid, fixed standard. For more information on reference Information Exchange Packages, see Reference Information Exchange Package Schemas.
GJXDM versions are numbered by three integers X, Y, and Z delimited by periods (X.Y.Z).
Each integer represents a particular class of change:
X = Major revisions to the model or representations of the model as rendered in a schema (as XML or other markup)
Y = Minor changes that do not maintain forward compatibility
Z = Minor changes that maintain forward compatibility
A version number should NOT be confused with decimal numbers. X, Y, and Z are integers, not digits, and may become greater than 9. For example, 4.89.113 is a legitimate release number (though not likely to ever be used).
GJXDM version 3.0 is the first operational release. Version 3.0 instances will be forward compatible with and validate using the version 3.0.2 schema or appropriate 3.0.2 schema subsets. See the question on compatibility for more details. Prereleases used four numbers to designate versions. There were only four prereleases: 3.0.0.0, 3.0.0.1, 3.0.0.2, and 3.0.0.3. Except for 3.0.0.2, prereleases are still available, but are no longer maintained or supported.
Note that specific person role types (like CaseOfficialType) extend PersonType, and so automatically inherit all of the properties of PersonType. Since element sequence follows the inheritance hierarchy, in an XML instance, the PersonType information would appear first, followed by the CaseOfficialType information.
The Global Justice XML Data Model (GJXDM) Bugzilla Feedback site will continue to be the primary mechanism for identifying urgent bug fixes and requests for additions, deletions, and modifications. The XML Structure Task Force (XSTF) will continue to authorize all fixes and changes. Thus, all bug reports (feedback) will be reviewed and approved/disapproved by the XSTF. All approved additions, deletions, and modifications will be applied to the next release whenever possible. A cumulative change log will be published with each release to maintain an audit trail. Changes will be linked to appropriate bug reports in the feedback history.
GJXDM Support can be obtained by contacting National Information Sharing Standards Help Desk via:
GJXDM Knowledge Base and Help Desk can be accessed via:
Web: http://it.ojp.gov/gjxdm/helpdesk
GJXDM Help Desk can be contacted via:
Telephone:
1-877-333-5111
703-726-1919
Email: [email protected]
This GJXDM listserv exists to support community-wide announcements, comments, discussions, and exchanges that are relevant to the GJXDM but not directly relevant to the feedback site.
Finally, the organizations utilizing the GJXDM can be contacted directly for further information .
Information Sharing Listserv: https://bja.ojp.gov/program/it/policy-implementation/practitioners
The GJXDM schema is a list of commonly used data elements that were compiled from actual data requirement sources and narrowed down and refined to result in a set of precise and well-defined data components. The GJXDM schema is one functional representation of those components and the product of the GJXDM specification that application developers use for programming.
The GJXDM is also dependent on schemas that represent code tables taken from specifications and publications created by other groups and organizations. The GJXDM base schema references these code tables by importing external schemas in an effort to maintain the independence of the various specifications.
Information in regards to full schemas for GJXDM releases :https://bja.ojp.gov/program/it/national-initiatives/gjxdm
The following design criteria were applied in the development of the Global Justice Extensible Markup Language (XML) Data Model (GJXDM):
Design a common set of reusable, extendable XML data components for the Global Justice XML Data Dictionary (GJXDD) that facilitates standard information exchange.
The GJXDM will be over-inclusive and optional.
Requirements, solutions, and time constraints will be established from rational compromises.
The International Organization for Standardization (ISO) 11179 – Specification and Standardization of Data Elements will be used, as well as other applicable standards.
The GJXDD will evolve, facilitating change and extension.
Extension methods should minimize impact on prior schema and code investments.
Domain relationships will be implemented and represented so that they are globally understood.
Develop reference architecture and namespaces for a standard GJXDM schema specification.
The GJXDM will be an object-oriented model using named types and extensions.
Value constraints will be enabled: codes/enumerations and special semantics. Primary (IS-A, HAS-A) and secondary (domain) relationships will be utilized.
The GJXDM will be built from functional requirements, reference documents, use cases, business context components, and containers.
The GJXDM will provide migration paths for evolving to new technologies.
The GJXDM was designed as a data model to be used as the basis for information exchanges, not as a data model for data warehouses (or databases). A data warehouse is a copy of transaction data specifically structured for querying and reporting. In essence, a data warehouse is designed for the storage of data, not the exchange data with other applications.
On the other hand, GJXDM was inherently designed to allow information exchange. For example, building a GJXDM 'compliant' data warehouse to store the data in a case management system might be problematic and requires adapting the GJXDM schema. In this case, one would want to use GJXDM components to represent the set of data used by an application (the case management system). Yet, since it is unlikely the GJXDM exactly models the business data for this particular application, one should expect to have to use certain GJXDM components, adding your own components, and combining them in additional or different ways than they are in the GJXDM to suit the particular business purpose of the application.
It is possible for a data warehouse modeled after the GJXDM to work; although it may not be optimal for a particular application, it could make it easier to send and receive IEPs. It's just that this use of the GJXDM for data warehouses was not considered in the development of the GJXDM.
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…