Frequently Asked Questions

This case study looks at the state of Texas’ adoption of NIEM on the Texas Path to NIEM project.

See attached pdf for full article.

Documents
https://bja.ojp.gov/media/document/30071

This case study highlights the success of E-Verify from a data sharing perspective, between SSA and different systems within DHS.

See attached pdf for full article.

Documents
https://bja.ojp.gov/media/document/30076

The Vermont Judiciary operates with a case management system that is almost 20 years old, and the baseline code has been copied into each county over the years. The Judiciary has a project under way to purchase and convert to a modern, centralized, Web-based case management, document management, and e-filing system to support all courts in the Judiciary.

See attached pdf for full article.

Documents
https://bja.ojp.gov/media/document/30081

The purpose of this case study is to highlight the success of the development of NIEM 2.0-conformant Information Exchange Package Document (IEPD) for Law Enforcement Access to Driver’s License Photos in Washington State.

See attached pdf for full article.

Documents
https://bja.ojp.gov/media/document/30086

Federal Enterprise Architecture (FEA) is constructed through a collection of interrelated “reference models” designed to facilitate cross-agency analysis of services provided to citizens and to identify duplicative investments, gaps, and opportunities for collaboration within and across federal agencies.

Reference Models released by the Federal Enterprise Architecture Planning Management Office (FEAPMO) include:

• The Performance Reference Model (PRM), a standardized framework to characterize the performance of information technology (IT) initiatives and their contribution to program performance. PRM can help produce enhanced IT performance information to improve strategic and daily decision-making; improve the alignment and contribution of IT to outputs and outcomes, thereby creating a clear “line of sight” to results; and identify performance improvement opportunities across traditional agency boundaries.

• The Business Reference Model (BRM), which is a function-driven framework for describing the business operations of the federal government independent of the agencies that perform them. BRM provides an organized, hierarchical construct for describing the federal government’s day-to-day business operations.

• The Data and Information Reference Model (DRM) helps to describe the types of interactions and information exchanges that occur between the federal government and its various constituencies. It will categorize the government’s information along general content areas specific to BRM sub-functions and decompose those content areas into greater levels of detail, ultimately to data components that are common to many business processes or activities. DRM will establish a commonly understood classification for federal data and enable information sharing between agencies. A common data classification model will streamline the processes associated with information exchange, both within the federal government and between the government and its external stakeholders.

• The Service Component Reference Model (SRM) is a business- and performance-driven functional framework that classifies service components with respect to how they support business and/or performance objectives. SRM is intended for use to support the discovery of government-wide business and application service components in IT investments and assets.

• The Technical Reference Model (TRM), which is a component-driven, technical framework used to identify the standards, specifications, and technologies that support and enable the delivery of service components and capabilities. TRM provides a foundation to support the construction, delivery, and exchange of business and application or service components that may be used and leveraged in a Component-based or Service-oriented Architecture.

Taken together, the FEA reference models create a comprehensive government-wide framework to guide agency IT investment activities, identify opportunities to collaborate on and consolidate initiatives, and integrate government activities at the local, state, tribal, and federal levels.

XML elements have different types of relationships between each other. Primary relationships are the common XML relationships that exist between an xsd:complexType and its defining properties (elements and attributes that compose it and make it complex). The properties are generally inherent in the nature of the complexType being defined. For example, PersonNameType has several inherent properties, including PersonFirstName, PersonMiddleName, and PersonLastName. These properties are actually parts of or compose a PersonNameType. Any complexType can be built with all primary relationships. However, sometimes this is not possible, practical, or sensible, depending upon the situation.

Secondary relationships provide an alternate method for representing relationships. Secondary relationships exist between two fully attributed instances. A simple example is a family relationship between two persons. A secondary relationship mechanism enables you to create a FatherOf relationship between two fully attributed PersonType instances without having to define an XML complexType that requires one to be inside the other.

Alias, AKA, is the Name Category metadata being considered for use by the Intel Community Metadata Working Group Person Data Exchange Standard. After several discussions in the XML Structure TAsk Force (XSTF) regarding Alias and AKA, the language in the following example is considered to differentiate the two:

NameCategory Name NameCategory Context Terrorist Watchlist Person of Interest Data Exchange Definition Denotes that the name is a provided name, an alias, an aka, or, for systems that do not support the different meanings of alias and aka, ''aliasoraka'' Reference Reference Authority Identifier Version Draft 12-10-03 Cardinality 1 Representation Representation Category Character representation (ISO/IEC 10646) Form of Representation Code Datatype xs:NMTOKEN Maximum Size 12 Minimum Size 3 Layout of Representation Permissible Values ProvidedName,Alias,AKA,AliasOrAka Usage Examples Comment ProvidedName is the name which is obtained from the source of the record and which is not known to be an alias or aka name.

Alias is an alternative name that is suspected to be in use for deceptive purposes. AKA is an alternative name associated with the individual but not for deceptive purposes (e.g. nickname, street name). Aliasor AKA is used when it is not possible to determine whether the alternative name is an alias or aka.

When dealing with types that are derived from other types, the order is important in validating. For instance, if the schema has PersonGivenName before PersonSurName, it would not validate if the sequence is switched. How does a derived type get affected by this? For example, CaseOfficial is a CaseOfficialType. CaseOfficialType is derived from SuperType, PersonType, and JudicialOfficialType.

What should be the order of tags from any of the Base types should be so that the xml file still validates? The rule is that parent properties (in sequence) always come first. So, since CaseOfficialType extends JudicialOfficialType extends PersonType extends SuperType, then a CaseOfficial will have element properties defined in SuperType PersonType JudicialOfficialType CaseOfficialType, in that order, and sequenced as in each respective type. Attribute properties can be used in any order. T here has been much discussion and no resolution other than a recommendation to use sequence as the GJXDM suggests on where reference PersonGivenName is before PersonSurName .

There are several groups and individuals who believe that element sequence within a type is an unnecessary restriction. However, it depends upon how the instance is processed. If the program/parser traverses the hierarchy looking for each element in the hierarchy in sequence (PersonName, PersonSurName, PersonGivenName) then one must retain the sequence in your instances or the program/parser breaks. Those in favor of not validating based upon sequence consider this an antiquated restriction and a processing problem, not an XML problem. If the program/parser looks for Subject and then looks for PersonName and PersonSurName and PersonGivenName are unique within PersonName there does not have to be any particular sequence. As one goes up the hierarchy, PersonName should not have to appear in any particular order within Subject (a PersonType) but it must appear within Subject or it loses context.

XML Schema provides two constructs for tagging data in XML instances – elements and attributes. Which construct to employ is not always clear. While data can often be stored as attributes or elements, there are a number of constraints on attributes that generally impact one's decision:

· XML does not support specification of structure in attribute values; attribute values are just strings. Elements may contain additional structure as sub-elements or attributes.

·Attributes are not easily extended (for future changes). However, you can add additional sub-elements and attributes to an element through type subclassing and type substitution.

·Mixed content (mixing simple values and elements together) is hard to work with, and harder to specify. This means that properties of a simple data type must be included as attributes (in order to avoid having to use mixed content).

For this reason, GJXDM and NIEM take the approach of tagging most data in elements. Attributes are reserved generally for metadata.

Each external code table has a proxy schema whose only purpose is to add the metadata attributes on the SuperType so that they can be used with the properties that use those code values. The "base" contains the code values and the "base proxy" hooks (or adds) the SuperType metadata to the code (enumerated) elements. jxdm.xsd imports the base proxy (and adds the SuperType metadata) and the base proxy imports the base (and adds the values).

Here is an example that illustrates the concept of proxy schema. Suppose we want to specify the color of a person's eyes using the NCIC code for eye colors. The XML would look like

<Person></Person>

...

<PersonEyeColorCode>BLU</PersonEyeColorCode>

<Person>Person</Person>

<PersonEyeColorCode reporteddate="2004-01-01">BLU</PersonEyeColorCode>

It would have been easier if we could have directly added the metadata reference to the external type rather than creating a proxy type, but we are not the owners of the external types and namespaces and cannot change their data to suit our needs.

The Information Sharing Listserv is an electronic forum created for the purpose of developing and broadening the community of Justice XML expertise and support for the application of the National Information Exchange Model (NIEM) and consistent standards and practices in the information sharing industry. The Listserv promotes the exchange of ideas and experiences associated with information sharing projects and provides an opportunity to discuss lessons learned and implementation tips.

Who Should Join?

Justice and public safety practitioners, managers and policy makers; developers and programmers involved with building applications using NIEM; and local, tribal, state, federal, and private sector communities of practice who are involved in data integration efforts using XML can all find benefit in discussing information sharing in an open environment. Industry journalists and interested parties should also feel free to subscribe to the Listserv; however, topics are limited to industry-specific issues and may be moderated.

For more information on the Listserv membership and rules, please see https://bja.ojp.gov/program/it/policy-implementation/practitioners

The change log is a list of all the changes made in the current GJXDM release versus the old GJXDM release. It lists all the change and the associated bug number which have been entered in bugzilla. To find more information about the change user can click on the hyperlink associated to the bug number.

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

Namespaces are the solution to naming conflicts (also known as collisions) in XML. Using XML namespaces can help alleviate issues that arise where XML elements and attributes use identical names.

XML namespaces help to identify and resolve conflicts between elements that have the same name but mean different things. An XML namespace is a domain that contains a set of element declarations and type definitions.

An analogy is women's clothing sizes. A size eight is not always the same size eight, because women's clothing is designed in junior, misses, and petites. These various size eights, which may represent different specifications, can exist in several domains. To solve this issue, each domain will need to be identified with a different namespace.

Each XML schema provides a unique identification (ID) in the form of a Uniform Resource Identifier (URI), which can point to an external file that defines the namespace.

The URI may either be a Universal Resource Locator (URL), which points to a web server, or a Universal Resource Name (URN), which names a resource but does not specify a network object that can be de-referenced.

The URI is defined in the format illustrated below.

• The protocol part either specifies a real network transfer protocol, such as HTTP or FTP for a URL, or the string “urn:” for a URN.
• The host part specifies a registered host name, resolvable through Domain Name Service (DNS).
• The path part specifies a unique ID on that host, and its meaning is under the control of the parties that control the host.