NISS Knowledge Base

What GJXDM is Not

The is many things. But, for all the ground it covers, there are many things that the GJXDM is not. Here are a few misconceptions about the role of the GJXDM:

The GJXDM is not a database technology.
The GJXDM is not a guideline for designing your internal databases. The GJXDM is only for exchanges between systems. You should not try to make your internal databases mirror the GJXDM.

The GJXDM is not just XML.
The GJXDM is not just XML. It's a set of reusable objects and their definitions. The definitions are not an afterthought. They are a major feature and benefit of the model.

The GJXDM is not Big "J" Justice Specific.
The GJXDM is not limited to the U.S. Department of Justice. (That's Big-J Justice.) The GJXDM includes courts, corrections, juvenile, and other aspects of justice at Federal, state, local, and tribal levels.

The GJXDM is not a programming language.
The GJXDM is a data model. It's not a programming language. It's represented as XML, which isn't a programming language either.

The GJXDM is not a silver bullet.
The GJXDM is a tool for creating exchanges. The model defines pieces and how they fit together. You can use those pieces to build exchanges. But you still need to do the building.

The GJXDM is not a replacement for exchanges and interagency agreements.
Again, the model is a set of objects. Which objects are used and precisely how they will fit together are questions that will still need to be negotiated and decided between and among exchange partners.

The GJXDM is not a definition of interoperability.
The GJXDM helps define the payload of an exchange. Topics like security and messaging layers are beyond the scope of the model.

There is a wide variety of tools available for using the GJXDM.

American Association of Motor Vehicle Administrators (AAMVA)

http://www.aamva.org
The American Association of Motor Vehicle Administrators (AAMVA) is a nonprofit organization striving to develop model programs in motor vehicle administration, police traffic services, and highway safety. AAMVA serves as an information clearinghouse for these same disciplines and acts as an international spokesperson for these interests.

Automated Regional Justice Information System (ARJIS)

http://www.arjis.org/
The Automated Regional Justice Information System (ARJIS) is a complex criminal justice enterprise network utilized by local, state, and federal agencies in the San Diego, California, region. ARJIS is chartered with supporting a regional Web-based enterprise network that utilizes technical and operational standards to build interfaces to all criminal justice systems in the region. The ARJIS secure intranet, ARJISNet, contains data on the region’s crime cases, arrests, citations, field interviews, traffic accidents, fraudulent documents, photographs, gang information, and stolen property.

ARJIS is also utilized for tactical analysis, investigations, statistical information, and crime analysis. Officers and investigators can additionally request electronic notification when information is obtained by another agency or officer concerning an individual, location, or vehicle. The critical success factor for ARJIS is the “single point of entry” to query all regional justice data.

ARJIS is currently collaborating with the National Institute of Justice (NIJ) to build new Web-based technologies to continue the support of the criminal justice community.

Criminal Justice Information Services (CJIS) Division, Federal Bureau of Investigation (FBI)

https://www.fbi.gov/services/cjis
The Criminal Justice Information Services (CJIS) Division was established in February 1992 to serve as the focal point and central repository for criminal justice information services in the Federal Bureau of Investigation (FBI). It is the largest division within the FBI. Programs that were initially consolidated under the CJIS Division include the National Crime Information Center (NCIC), Uniform Crime Reporting (UCR), and Fingerprint Identification. In addition, responsibility for several ongoing technological initiatives was also transferred to the CJIS Division, including the Integrated Automated Fingerprint Identification System (IAFIS), NCIC 2000, and the National Incident-Based Reporting System (NIBRS).

CriMNet

http://www.crimnet.state.mn.us
CriMNet is an enterprise architecture that puts in place a statewide framework of people, processes, data, standards, and technology focused on providing accurate and comprehensive data to the criminal justice community in the state of Minnesota. It provides the means to put “the right data in the hands of the right people at the right time and in the right place.”

The CriMNet integration effort is not one single project but incorporates many projects that are being developed by criminal justice organizations throughout Minnesota. The integration architecture is driven by local operational needs and uses standards that will support the exchange of data across existing and developing systems.

Georgia Tech Research Institute (GTRI)

http://www.gtri.gatech.edu
The Georgia Tech Research Institute (GTRI) is the nonprofit applied research arm of the Georgia Institute of Technology in Atlanta, Georgia. With more than 1,000 employees, GTRI supports approximately $100 million in research yearly, for more than 200 clients in industry and government. GTRI researchers have played a pivotal role in the engineering support and technical guidance of the Global Justice Extensible Markup Language (XML) Data Model (Global JXDM).

GJXDM Training and Technical Assistance Committee (GTTAC)

https://bja.ojp.gov/program/it/policy-implementation/training
The GJXDM Training and Technical Assistance Committee (GTTAC) is a consortium of organizations engaged in technical assistance and training related to technology in the justice field, specifically the Global JXDM. The GTTAC supports the development of training and technical assistance for the Global JXDM. The Committee was established in January 2004 as an outreach effort for the Global JXDM. It is related to, but external from, the Global Justice Information Sharing Initiative (Global) and is an operating entity on behalf of the Global JXDM to assist the justice community’s need to better understand and implement the Global JXDM.

GTTAC’s mission is to coordinate the work of national service providers in providing training and technical assistance on issues related to the implementation of the Global JXDM. Major projects include building Global JXDM Information Exchange Package Descriptions, creating a national virtual help desk centered on the Global JXDM, and coordinating regional large-scale Global JXDM training events.

Global Justice Information Sharing Initiative (Global)

https://bja.ojp.gov/program/it/global 
The Global Justice Information Sharing Initiative (Global) is a “group of groups,” representing more than 30 independent organizations spanning the spectrum of law enforcement, judicial, correctional, and related bodies. Member organizations participate in Global out of shared responsibility and shared belief that together they can bring about positive changes in inter-organizational communication and data sharing.

The Global Advisory Committee (GAC) serves as an advisory committee for the U.S. Department of Justice. Global aids its member organizations and the people they serve through a series of important initiatives. These include the facilitation of the Global Working Groups, development of technology standards, creation of white papers on data sharing issues, and the dissemination of information via the Global Web site.

The work of the GAC has implications of the highest importance and helps to make the GAC the foremost voice for justice information sharing.

Global Infrastructure/Standards Working Group (GISWG)

https://bja.ojp.gov/program/it/giswg
Successful data exchange is greatly facilitated by the development and adoption of standards that enable transparent integration of disparate systems. The Global Justice Information Sharing Initiative (Global) Infrastructure/Standards Working Group (GISWG) is implementing a coordination process to identify information sharing standards within the justice community. This effort includes publishing, cataloging, and sharing these standards to promote collaborative efforts and offer blueprints to those beginning the information exchange planning process.

Global XML Structure Task Force (GXSTF)

https://bja.ojp.gov/program/it/national-initiatives/gjxdm 
The Global Extensible Markup Language (XML) Structure Task Force (GXSTF) is a component of the Global Justice Information Sharing Initiative (Global) Infrastructure/Standards Working Group (GISWG).

The GXSTF addresses the requirements, design, structure, and implementation for the Global Justice XML Data Model (Global JXDM). Their vision is to significantly advance justice information sharing by providing a common language and vocabulary that reduces cost and technical barriers. More specifically, the GXSTF has developed a consistent, extendable, maintainable XML schema reference specification for data elements and types that represent the data requirements of the general justice and public safety communities. The GXSTF is heavily involved in the Global JXDM release process and approves all fixes, additions, deletions, and modifications to each implementation. The GXSTF is also responsible for Global JXDM guidance, review, and issue resolution.

Institute for Telecommunication Sciences (ITS)

http://its.bldrdoc.gov/
The National Telecommunications and Information Administration (NTIA), an agency of the U.S. Department of Commerce, is the Executive Branch’s principal voice on domestic and international telecommunications and information technology issues. NTIA works to spur innovation, encourage competition, help create jobs, and provide consumers with more choices and better quality telecommunications products and services at lower prices.

The Institute for Telecommunication Sciences (ITS) is the chief research and engineering arm of NTIA. ITS supports NTIA telecommunications objectives such as promotion of advanced telecommunications and information infrastructure development in the United States, enhancement of domestic competitiveness, improvement of foreign trade opportunities for U.S. telecommunications firms, and facilitation of more efficient and effective use of the radio spectrum.

ITS also serves as a principal federal resource for solving the telecommunications concerns of other federal agencies, local and state governments, private corporations and associations, and international organizations.

Integrated Criminal Justice Information System (ICJIS)

http://www.Maricopa.gov/ICJIS
ICJIS is a Maricopa County, Arizona sponsored project that provides integration services for sharing information between its internal stakeholders (Sheriff’s Office, County Attorney Office, Clerk of the Superior Court, Superior Court and Indigent Representation Agencies) and to provide these internal stakeholders information sharing capabilities with external agencies that include municipal, state and federal agencies.  ICJIS stakeholders share information between 25 criminal justice systems in addition to all state and federal information sources. 

Integrated Justice Information Systems (IJIS)

http://www.ijis.org/
The mission of the IJIS Institute is to contribute to the implementation of Integrated Justice Information Systems (IJIS) throughout the country by applying the knowledge and experience of the information technology (IT) industry. As IT professionals responsible for the achievement of solution systems, IJIS believes that experience and perspective will improve the quality and reduce the time to market for solutions. IJIS supports the initiative of the Office of Justice Programs to involve industry in its information sharing programs and believes that the program will benefit from its unique and collective experience.

International Organization for Standardization (ISO)

http://www.iso.org
The International Organization for Standardization (ISO) is a network of national standards institutes from 145 countries working in partnership with international organizations, governments, industry, business, and consumer representatives.

Joint Task Force on Rap Sheet Standardization

https://www.nlets.org/sites/default/files/2021-05/chief_fact-sheet.pdf
The Joint Task Force (JTF) on Rap Sheet Standardization is an endeavor by the Federal Bureau of Investigation (FBI) and NLETS – The International Justice and Public Safety Information Sharing Network to bring about a national standard for the exchange of criminal history rap sheets. Sponsored by the FBI, members include staff of the FBI, NLETS, and states that operate criminal history repositories.

In 1995, the National Task Force on Increasing the Utility of the Criminal History Record recommended expanded data content, a presentation format (page layout) for the expanded content, and the creation of a transmission format for the interstate sharing of criminal history information. The National Task Force included representatives from the FBI Criminal Justice Information Services (CJIS) Advisory Policy Board (APB); NLETS; the National Center for State Courts; and SEARCH, The National Consortium for Justice Information and Statistics. Its members were a diverse array of justice practitioners drawn from the judiciary; prosecution; court administration; local, state, and federal law enforcement; juvenile justice pretrial services; and state criminal records repositories.

Justice Information Exchange Model (JIEM)

https://www.search.org/solutions/information-sharing-standards-and-models/jiem/
The Justice Information Exchange Model (JIEM) consists of a framework that defines universal dimensions of information exchange, a research and planning methodology for modeling the operational dynamics of this information exchange, and a Web-based software application - the JIEM Modeling Tool - that enables data collection, analysis, and reporting by users and researchers.

Justice Information Sharing Professionals (JISP)

http://www.jisp.us
The Justice Information Sharing Professionals (JISP) is a national network of local and state justice and public safety integrators responsible for the facilitation, collaboration, and advocacy of information sharing. JISP was created to focus on the need to enhance communication among practitioners. JISP coordinates a member-only Internet mail list at http://groups.yahoo.com/group/JISP/

Law Enforcement Information Technology Standards Council (LEITSC) Technology Center

http://www.leitsc.org/
The Law Enforcement Information Technology Standards Council (LEITSC) is funded through the Office of Justice Programs (OJP), U.S. Department of Justice, to address the issue of information technology standards specific to the law enforcement community. The mission of LEITSC is to foster the growth of strategic planning and implementation of integrated justice systems by promoting the merits of information technology (IT) 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 IT standards.

LEITSC partners include the International Association of Chiefs of Police (IACP), the Police Executive Research Forum (PERF), the National Sheriffs’ Association (NSA), and the National Organization of Black Law Enforcement Executives (NOBLE).

LegalXML Court Filing Standard Initiative

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-courtfiling
Pursuant to discussions at an August 1999 planning meeting, the Conference of State Court Administrators/National Association of Court Managers Joint Technology Committee (JTC) formed an e-filing standards subcommittee to pursue an Internet electronic filing specification for the courts.

To that end, in December 1999, the JTC voted to partner with LegalXML, a nonprofit organization that facilitates development of XML standards for application within the legal community. This coalition produced the LegalXML Court Filing Standard.

LegalXML Integrated Justice Initiative

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-intjustice
The purpose of the Integrated Justice Technical Committee is to support XML specifications for exchanging data among justice system branches and agencies. While its principal focus will be on data pertaining to criminal cases, its scope will include certain data exchanges in civil cases, such as civil protection order, child support enforcement and dependency and neglect cases.  The Committee will also serve as a vehicle for vetting the Global Justice XML Data Dictionary being developed under the auspices of the Infrastructure/Standards Working Group of the Global Justice Information Network Advisory Committee, US Department of Justice.

Los Angeles County Information Systems Advisory Body (ISAB)

http://ccjcc.lacounty.gov/Subcommittees-Task-Forces/Information-Systems-Advisory-Board-ISAB
ISAB is a member of the Countywide Criminal Justice Coordination Committee (CCJCC) and is responsible for overseeing the development and coordination of countywide criminal justice information systems.  ISAB has overall responsibility for the planning, development, implementation and management of countywide criminal justice data and telecommunication system projects and providing related technical assistance to ISAB members which include the Sheriff, District Attorney, Public Defender, Probation Department, Coroner, Superior and Municipal Courts, Chief Administrative Office, Internal Services Department, Los Angeles County Police Chiefs Association, Los Angeles Police Department and the Alternate Public Defender.

Los Angeles County Sheriff’s Department (LASD)

http://www.lasd.org
The Los Angeles Sheriff's Department is the largest Sheriff's Department in the world. The Department serves the entire County of Los Angeles encompassing 4,061 square miles with a population of about 10 million. The Department manages the largest County jail system in the world which averages about 19,000 inmates daily. Additionally, the Department is responsible for police services in the unincorporated areas and 41 incorporated cities for which police and traffic services have been contracted

Mapping Alaska’s Justice InterChanges (MAJIC)

https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/mapping_alaskas_justice_interchanges_majic.pdf
The Mapping Alaska’s Justice InterChanges (MAJIC) program, managed by the state’s Criminal Justice Information Advisory Board, brings together the systems in many organizations statewide, including the Department of Public Safety, the Alaska Court System, the Public Defender Agency, and the National Law Enforcement and Corrections Technology Center-Northwest.

National Center for State Courts (NCSC)

https://www.ncsc.org/
The National Center for State Courts (NCSC) provides up-to-date information and hands-on assistance that help court administrators to better serve the public. Through original research, consulting services, publications, and national educational programs, NCSC offers solutions that enhance court operations with the latest technology, collects and interprets the latest data on court operations nationwide, and provides information on proven “best practices” for improving court operations in areas such as civil case management.

National Crime Information Center (NCIC)

http://www.fas.org/irp/agency/doj/fbi/is/ncic.htm
The National Crime Information Center (NCIC) is a computerized index of criminal justice information (i.e., criminal record history information, fugitives, stolen properties, and missing persons). It is available to local, state, and federal law enforcement and other criminal justice agencies and is operational 24 hours per day, 365 days per year. The purpose for maintaining the NCIC system is to provide a computerized database for ready access by a criminal justice agency making an inquiry and to provide prompt disclosure of information in the system from other criminal justice agencies. This information assists authorized agencies in criminal justice and related law enforcement objectives, such as apprehending fugitives, locating missing persons, and locating and returning stolen property, as well as protecting law enforcement officers.

National Governors Association (NGA)

http://www.nga.org
The National Governors Association (NGA) is the collective voice of the nation's governors and one of Washington, D.C.'s, most respected public policy organizations. NGA provides governors and their senior staff members with services that range from representing states on Capitol Hill and before the Administration on key federal issues to developing policy reports on innovative state programs and hosting networking seminars for state government executive branch officials. The NGA Center for Best Practices focuses on state innovations and best practices on issues that range from education and health to technology, including support for the GJXDM.

National Incident-Based Reporting System (NIBRS)

http://www.ojp.usdoj.gov/bjs/nibrs.htm
The Federal Bureau of Investigation’s (FBI) Uniform Crime Reporting (UCR) Program, which began in 1929, collects information about crimes reported to the police. In 1982, the Bureau of Justice Statistics and the FBI sponsored a study of the UCR Program, with the objective of revising it to meet law enforcement needs into the twenty-first century. A five-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.

National Institute of Justice (NIJ)

http://www.ojp.usdoj.gov/nij
The National Institute of Justice (NIJ) is the research, development, and evaluation agency of the U.S. Department of Justice. NIJ provides objective, independent, nonpartisan, evidence-based knowledge and tools to meet the challenges of crime and justice, particularly at the state and local levels. NIJ’s principal authorities are derived from the Omnibus Crime Control and Safe Streets Act of 1968, as amended (see 42 USC * 3721-3723).

The NIJ director is appointed by the President and confirmed by the Senate. The NIJ director establishes the Institute’s objectives, guided by the priorities of the Office of Justice Programs, the U.S. Department of Justice, and the needs of the field. NIJ actively solicits the views of criminal justice and other professionals and researchers to inform its search for the knowledge and tools to guide policy and practice.

National Telecommunications and Information Administration (NTIA)

http://www.ntia.doc.gov
The National Telecommunications and Information Administration (NTIA), an agency of the U.S. Department of Commerce, is the Executive Branch’s principal voice on domestic and international telecommunications and information technology issues. NTIA works to spur innovation, encourage competition, help create jobs, and provide consumers with more choices and better quality telecommunications products and services at lower prices.

NLETS – The International Justice and Public Safety Information Sharing Network 

http://www.nlets.org
The mission of NLETS – The International Justice and Public Safety Information Sharing Network is to provide, within a secure environment, an international criminal justice telecommunication capability that will benefit, to the highest degree, the safety, security, and preservation of human life and the protection of property. NLETS will assist those national and international governmental agencies and other organizations with similar missions who enforce or aid in enforcing local, state, federal, or international laws or ordinances.

Pennsylvania Justice Network (JNET)

https://www.pajnet.pa.gov/Pages/default.aspx
JNET is a collaboration of municipal, county, state, bordering states, and federal justice agencies that develop and provide a secure, online integrated justice system that allows participating agencies to access driver and offender records and other justice information. Local and state police officers, JNET’s largest users, have immediate access to critical criminal justice information that helps them to perform their jobs more effectively.

Regional Information Sharing Systems® (RISS)

https://www.iir.com/Initiatives/#information
The Regional Information Sharing Systems (RISS) Program is composed of six regional centers that share intelligence and coordinate efforts against criminal networks that operate in many locations across jurisdictional lines. Typical targets of RISS activities are drug trafficking, terrorism, violent crime, cybercrime, gang activity, and organized criminal activities. Each of the centers, however, selects its own target crimes and the range of services provided to member agencies.

SEARCH, The National Consortium for Justice Information and Statistics

http://www.search.org
SEARCH, The National Consortium for Justice Information and Statistics is a nonprofit membership organization created by and for the states, dedicated to improving the criminal justice system and the quality of justice through better information management, the effective application of information and identification technology, and responsible justice information law and policy.

Washington Justice Information Network (JIN)

https://www.courts.wa.gov/committee/?fa=committee.home&committee_id=98
The mission of JIN is to is to improve public safety by providing criminal justice practitioners with complete, timely and accurate information, and to improve operating efficiency by facilitating the integration of disparate systems throughout the state. Its governance Board includes key state and local members of the justice community. Using the principles of services-oriented architecture, JIN is designing and deploying a model for information sharing in the Washington justice community.

The National Information Exchange Model (NIEM) is a Federal, State, Local and Tribal interagency initiative providing a foundation for seamless information exchange. NIEM is a framework to:

• Bring stakeholders and Communities of Interest together to identify information sharing requirements in day-to-day operational and emergency situations;
• Develop standards, a common lexicon and an on-line repository of information exchange package documents to support information sharing;
• Provide technical tools to support development, discovery, dissemination and re-use of exchange documents; and
• Provide training, technical assistance and implementation support services for enterprise-wide information exchange.

NIEM was launched on February 28, 2005, through a partnership agreement between the U.S. Department of Justice (DOJ) and the U.S. Department of Homeland Security (DHS) and signed by Chief Information Officers. It leverages the data exchange standards efforts successfully implemented by the Global Justice Information Sharing Initiative (Global) and extends the Global Justice XML Data Model (GJXDM) to facilitate timely, secure information sharing across the whole of the justice, public safety, emergency and disaster management, intelligence, and homeland security enterprise.

NIEM Website: https://niem.gov 

The NIEM mission is to assist in developing a unified strategy, partnerships, and technical implementations for national information sharing—laying the foundation for local, state, tribal, and federal interoperability by joining together communities of interest. That foundation consists of three parts: core data components, reusable XML exchange packages, and business process models for information sharing.

The goal of the NIEM is to prevent fragmentation and semantic non-interoperability in Extensible Markup Language (XML) standards within and across agencies through a proactive collaborative initiative, to develop and implement common XML information sharing standards that meet critical homeland security data exchange needs.

The NIEM has the following objectives:

• Develop a unified strategy within the U.S. Departments of Homeland Security (DHS) and Justice (DOJ) for an XML-based information sharing capability.
• Develop an initial implementation of the NIEM that satisfies Executive Order (EO) 13356 and Homeland Security Presidential Directive (HSPD)-11.
• Develop an exchange layer for the XML profile implementation of the Federal Enterprise Architecture Data Reference Model (FEA DRM).
• Develop an XML profile of NIEM that implements the FEA DRM.
• Provide technical assistance and training to local, state, tribal, and federal organizations seeking to implement revisions to the GJXDM and support the new national standards emerging from joint efforts under this Memorandum of Understanding (MOU).
• Develop and demonstrate an application of the NIEM for the Bureau of Border and Transportation Security (BTS) operational domain involving customs and border patrol agent data exchange as the first pilot.
• Build out a framework for many pilot use cases under the umbrella of the NIEM.

External components are encapsulated in NIEM-conformant components. This introduces the concept of “external adapter” types. An external adapter type is a NIEM conformant XML Schema complex type that wraps a set of external content.

These adapter types and container elements are XML Schema components, and so are defined within the namespace of the schema currently being defined.

This article specifies two constructs, which contain external content. The first is the external adapter type. This type is a NIEM-conformant type that contains attributes and elements from external namespaces. The second is the external container element. The container element is used when an external namespace provides top-level types for use, but does not provide appropriate top-level elements. In such a case, create a container element of the externally-provided type. Container elements are defined in NIEM conformant namespaces, are named differently than regular NIEM-conformant elements, and are used in a more restricted way.

Consistent with the fundamentals of NIEM, XML elements are used for semantics, and XML Schema types are used to contain necessary structures. Specific rules for definition of adapter components will take this approach, focusing on encapsulating external structures as NIEM-conformant types, within strongly-defined elements with specific semantics.

If an external type needs to be extended for use, such extension should be done outside a NIEM-conformant namespace. These structures are intended to encapsulate external content. They are not indented to introduce extensions and modifications to external content into NIEM-conformant namespaces. If an application schema needs to be constructed to conform to an external standard, the schema should be created in a user defined namespace, outside the NIEM-conformant namespaces. Then, those external components should be referenced by NIEM-conformant external adapter types and external container elements.

The NIEM is a collaborative development initiative with the initial development principally supported by DHS and DOJ. The NIEM development strategy will leverage DOJ’s GJXDM as the principal baseline data model. The pilot project will develop the NIEM as a re-branded version of the GJXDM, extending its scope and aligning its structure and associated processes to include the concept of core data types.

NIEM is an ambitious undertaking that faces numerous technical and logistical challenges and associated risks. The development strategy will mitigate these risks by leveraging the proven technologies and processes of the GJXDM; revising and extending the GJXDM architecture, components, and processes for the NIEM based on an extensive GJXDM knowledge base of successful applications and lessons learned; applying industry best practices; and scoping the initial NIEM release to a small high priority set of core components.

NIEM's strategy will provide core value propositions in several respects:

• Facilitate growth of data model through harmonization of new data components
• Coordinate independent project teams within DOJ and DHS
• Separate core entities and attributes from domain specific components
• Produce multiple modular schemas (universal core, community-of-interest core, and domain specific)
• Facilitate discovery of reusable data components
• Facilitate assembly of reusable exchange packages
• Adopt a standard for assigning context
• Maintain compatibility with GJXDM for future work
• Demonstrate use of core in federated query, and
• Coordinate joint development and joint governance of core entities and exchanges

The NIEM's development strategy revises and extends the GJXDM architecture, components, and processes for the NIEM based on an extensive GJXDM knowledge base of successful applications, lessons learned, and apply industry best practices. NIEM's strategy will provide core value propositions in several respects:

• Facilitate growth of data model through harmonization of new data components
• Coordinate independent project teams within DOJ and DHS
• Separate core entities and attributes from domain specific
• Produce multiple modular schemas (universal core, community-of-interest core, and domain specific)
• Facilitate discovery of reusable data components
• Facilitate assembly of reusable exchange packages
• Adopt a standard for assigning context
• Maintain compatibility with GJXDM for future work
• Demonstrate use of core in federated query
• Coordinate joint development and joint governance of core entities and exchanges

Source: https://www.niem.gov

Rather than nationwide integration of all local, state, tribal, and federal databases, NIEM focuses on cross‑domain information exchanges between communities of interest (COIs), across all levels of government—whether that is between individual local law enforcement agencies, law enforcement and emergency service agencies and other domains, or between local, state, tribal, regional, and federal agencies. As a consequence, not all data needs to be
NIEM‑compliant, only that data that is being shared across domains.

.NIEM is a framework to:

• Bring stakeholders and Communities of Interest together to identify information sharing requirements in day-to-day operational and emergency situations;
• Develop standards, a common lexicon and an on-line repository of information exchange package documents to support information sharing;
• Provide technical tools to support development, discovery, dissemination and re-use of exchange documents; and
• Provide training, technical assistance and implementation support services for enterprise-wide information exchange.

The National Information Exchange Model (NIEM) is identified by the ISE as a standards body, which provides a set of reusable common information standards. To effectively exchange information across domains, there must be a common semantic understanding of data among participating agencies, and the data must be formatted in a semantically consistent manner. For example, two agencies may each gather information about persons charged with committing a crime. If the agencies share information regarding these persons, there must be a common understanding of the terminology each agency uses. One agency, for example, may refer to the person as the "offender," while another refers to them as the "defendant." Agencies do not necessarily need to entirely retool their information systems or adopt standards and coding schemes that impose an artificial uniformity in data collection that fails to meet their operational business needs, but there must be common understanding and semantic consistency in the structure of the data that crosses agency lines if it is to be successfully shared.

Information that is exchanged between agencies can be broken down into individual components—for example, information about people, places, material things, and events. Data components within an information exchange commonly shared and understood among all domains are identified as universal components (e.g., person, address, and organization), while components used in exchanges between multiple domains, but not universally shared, are identified
as common components (e.g., offense, sentence, and disposition). Components managed by a specific COI (e.g., appellate case decision and arrest agency) are considered domain specific.

When working with the National Information Exchange Model (NIEM), information that is exchanged is broken down into the following components:

Universal
Common, and
Domain-specific
Data components within an information exchange commonly shared and understood among all domains are identified as universal components (e.g., person, address, and organization), while components used in exchanges between multiple domains, but not universally shared, are identified as common components (e.g., offense, sentence, and disposition). Components managed by a specific COI (e.g., appellate case decision and arrest agency) are considered domain specific.

NIEM IEPD development steps overview:

Conduct Business Analysis and Requirements Review: This step defines the business requirements associated with an information exchange for which NIEM is used. It incorporates scenario-based planning, which is the
recommended methodology for elaborating the business context of events, incidents, or circumstances in which information exchange takes place.

Complete Information Exchange Mapping and Data Modeling: This uses established methodologies to map and model operational information exchanges. Moreover, it describes the process a COI follows to map its data sources to NIEM and identify IEPDs available for reuse and/or gaps between its data source and NIEM. COIs can use the NIEM repository to search and discover existing data components to decrease the time needed to construct IEPDs.

Build and Validate IEPDs: This step addresses the importance of using common documentation standards, such as IEPDs, to ensure there is consistency in the way information is captured, stored, and exchanged and that uniform methodologies exist to support the generation of the IEPDs. Once the COI validates its IEPD, it may submit the IEPD to its domain specific area (proceed to Step 5) or nominate data components for inclusion into universal or common (proceed to Step 4).

Data Harmonization and Promotion: The appropriate NIEM governance stakeholders form a team to review an IEPD submission and determine whether any of the data components should be included in universal or common. The team evaluates the submission and makes a recommendation regarding which, why, how, and when to integrate the proposed changes into NIEM.

Publish and Implement IEPDs: Once an IEPD is approved, it is stored in the NIEM repository. Other stakeholders or COIs can then search and discover published IEPDs for reuse or extend for a specific instance of the information exchange.

Garner Feedback and Enhance and Expand IEPDs: This step describes how the COIs work with the NIEM Program Management Office (PMO) to ensure existing IEPDs remain up to date and compliant with NIEM.

NIEM includes a set of operational processes and procedures, standards, documentation, tools, training, and technical assistance which support each step in the NIEM IEPD life cycle.

• Documentation includes the NIEM Concept of Operations (CONOPS), User Guide, and NIEM Naming and Design Rules (NDR).
• Standards include IEPDs and other process standards identified in supporting documentation.
• Training and Technical Assistance is facilitated by the NIEM Web site, training materials, in person instruction, executive materials, as well as a help desk.
• Tools include those used for activities such as scenario‑based planning, information exchange mapping and modeling, and IEPD generation.
• Governance and Processes include the structure to manage and maintain NIEM and the processes and procedures behind its operations.

NIEM documentation and standards include a data dictionary, data model, and IEPDs. The data dictionary is a well‑defined vocabulary of data names and structures. The data model is the body of concepts and rules that underlie the structure of the data dictionary, including data components arranged by domain, the type of data being represented (date, integer, Boolean, string, etc.), and a semantically precise, context‑rich definition of each component. Together the data dictionary and model become a database, from which XML schemas are generated. These schemas contain the data components that are reused to construct the IEPDs.

NIEM standardizes the artifacts necessary for interagency information exchange into an IEPD. NIEM makes available reusable IEPD content used in data exchanges; creates and disseminates tools to support rapid IEPD development and deployment; and provides managed processes for the creation, support, dissemination, and implementation of information exchanges. In order to support these exchanges, NIEM provides a:

• Central place that allows for the registration and discovery of IEPDs
• Means to ensure IEPDs are developed using an established, conventional method that results in machine readable, easy‑to‑understand artifacts.
• Place where IEPDs, certified by authoritative sources, can be highlighted and disseminated. 

There are a variety of commonly used standards that are currently represented in XML Schema. There must be a method for NIEM to promote and use these external standards where requirements dictate.

There are two fundamental cases:

• Case 1: NIEM IEPDs reference, import, and use components in an external standard schema or namespace that does not conform to NIEM Naming and Design Rules.
• Case 2: External schemas reference, import, and use NIEM components.

Case 1. Presents a methodology for including non-NIEM components in NIEM-conformant schemas. It enables data modeling efforts to build NIEM-conformant components from non-NIEM data objects.

Case 2. The use of NIEM in external standards will likely involve per-standard recommendations. Use of NIEM should maintain compatibility with those standards, by doing things as the external standards intend. For example, Security Assertion Markup Language (SAML) uses attribute assertions, which each have a name and a value. In such a case, NIEM conformant content should be carried as a set of values, with each name indicating a NIEM-conformant component. Specific rules and guidelines will be developed for each standard.  Overarching guidelines for using NIEM content in external standards will be developed.  Such rules will be overridden by rules for specific standards. General rules will involve (1) focusing on elements as the prime semantic construct in NIEM-conformant data models, and (2) focusing on types as the prime structural entity. These guidelines will help maintain consistency in uses of NIEM content between various architectures.

The term “schema component” is used for any object constructed by XML Schema.

Schema components are specified by the XML Schema specification. They include attribute declarations, type definitions, etc. They include attribute uses (which are distinct from attribute declarations) and use of model groups (distinct from model group definitions).  In the National Information Exchange Model (NIEM) the term “NIEM Component” is used for a schema component from a namespace that is NIEM-Conformant.

From XML Schema Part 1: Structures 2d Ed

W3C Recommendation 28 October 2004

[Definition:] Schema component is the generic term for the building blocks that comprise the abstract data model of the schema. [Definition:] An XML Schema is a set of schema components. There are 13 kinds of component in all, falling into three groups. The primary components, which may (type definitions) or must (element and attribute declarations) have names are as follows: 

• Simple type definitions

• Complex type definitions

• Attribute declarations

• Element declarations

The secondary components, which must have names, are as follows:

• Attribute group definitions

• Identity-constraint definitions

• Model group definitions

• Notation declarations

Finally, the "helper" components provide small parts of other components; they are not independent of their context:

• Annotations

• Model groups

• Particles

• Wildcards

• Attribute Uses

The term “NIEM Component” is used for a schema component from a namespace that is NIEM-conformant, which follows the rules defined by the NIEM Naming and Design Rules (NDR) for NIEM conformance. The NIEM NDR provides a profile of W3C X ML Schema, along with additional constructs to support creating a data model. In order to be NIEM-conformant, a namespace must claim conformance, and must follow specific rules about structure, XML Schema feature usage, naming, and documentation.

NIEM conformance is determined at the namespace level, based on a reference schema for a particular namespace. To determine if a namespace is NIEM-conformant, the reference schema for the namespace is tested against a set of NIEM conformance rules.

These rules include such things as:

1. The schema must claim to be NIEM conformant.

2. The schema must have a target namespace, over which the schema author has dominion.

3. Schema components must be documented.

4. Component documentation must take specific forms, including being supported with XML annotations from a NIEM-specific namespace, to support data modeling concepts.

The term "External Component" is used for a schema component from a namespace that does not follow the rules for NIEM conformance.

Examples of external, non-NIEM standards include:

· GML: Geography Markup Language. GML is a prime candidate for content that may be included in NIEM structures.

· XHTML: Extensible Hypertext Markup Language. This language would likely be used for exchanging simple structured text.

· SAML: Security Assertion Markup Language. This is a likely language into which NIEM content will be embedded. Some SAML assertions will likely need to contain content defined by NIEM.

There are numerous goals in defining and using adapter components:

1. Ensure that content may be carried as defined by external standards, without modification. It would be bad to modify external content standards to make them "fit" NIEM. Instead, we should carry external content exactly as would be expected by external tools.
2. Allow modeling efforts to define the granularity of use of external content as needed.

Different groups require different levels of resolution into external standards. For example, one group may exchange a large block representing the geography of a large urban area, while another group may only exchange a single geographic point.

Both may be using the same external standard, but will need to use different parts, with different sizes, and different semantics.

1. Ensure specific modeling efforts (e.g. NIEM core, domains, or IEPDs) are independent of a centralized process for use of external components. Developers should be able to immediately utilize standards required for their area of expertise.
2. Provide points for harmonization. NIEM-conformant components that use external standards may be integrated into the core of NIEM. By using narrowly defined components with specific semantics, common uses that meet broad requirements may be identified and pulled up into the core of NIEM.
3. Reduce coupling between NIEM schemas and external schemas. This method ensures that any given implementation uses external schemas through specific known points of access, without excessive dependence on deeply nested external components.

Use of external schemas within NIEM should not require that each must be harmonized with components in or placed directly into NIEM. XML Schema provides namespaces to maintain semantic independence or uniqueness.

There are potentially two ways to use components from an external standard within the NIEM framework:

Methods of integrating external components

Profile the standard and insert its components into a NIEM namespace (potentially within Common).

Advantages:

1. The "standard" components will become part of NIEM.
2. The "standard" components will be registered with other NIEM components.
3. The "standard" components will have precise semantics (because they ARE NIEM components).

Disadvantages: 

1. Anytime the standards change, then NIEM must potentially be changed.
2. The "standard" components must be factored to conform to the NIEM NDR.
3. The "standard" components may need to be harmonized with the NIEM components they potentially duplicate in whole or part (from a semantic perspective).
4. The "standard" components may not be used in the same structural representation as the standard intended.
5. Interoperability may require translations back to standard structures. (Tools expecting standard geospatial component structures may not recognize or work with those components if they have been re-structured per the NIEM NDR.).
6. EACH standard that NIEM incorporates in this manner will result in the preceding disadvantages. Thus, insertion will require a lot of unnecessary extra work.

Provide a mechanism to reference and import the standard schemas/namespaces and use the components they contain within IEPDs constructed from NIEM components.

Advantages:

1. Standards components are used within IEPDs in the same structure they were intended without the need to translate -- a potential boost to interoperability.
2. Tools designed to recognize (parse) standard components from other namespaces will recognize these components.
3. No other refactoring, integration, harmonization, or maintenance of these standards is required (even if the standards change).
4. Components in preferred standards can still be registered with and discovered in a repository of NIEM components (requires storage of metadata about the standards).
5. Subset schemas of these standards can be maintained and stored locally as required for use within IEPDs, a registry, etc.

Disadvantages:

1. A NIEM structure (an adapter or container construct) will be required to encapsulate non-conforming components or schemas within an IEPD schema and to identify and preserve the semantics of those components.

A namespace can be labeled as NIEM-conformant. Any namespace that is not NIEM conformant is referred to as an external namespace. A namespace is NIEM-conformant if its reference schema follows NIEM conformance rules. A schema component must be in a NIEM-conformant namespace to be considered NIEM conformant. For any component of a schema to be conformant, the entire schema must be conformant.  A NIEM conformant schema must claim to be conformant. This occurs when the document element, the schema element, has a child annotation with a child appinfo with a child element i:conformant with the character child "true". In other words, the XPath

"/xsd:schema/xsd:annotation/xsd:appinfo/i:conformant" has the value "true".

<xsd:schema ...>

Non-Schema Namespaces

An external namespace may be defined by a non-schema mechanism, such as DTD. In such a case, a placeholder schema would be created to represent the exact constructs referred to from the NIEM-conformant schema. A placeholder schema would not represent the deeper XML content of such namespaces. Instead, it would define placeholder elements and additional required constructs that are further defined by the non-XML Schema standard.

For example, XHTML 1.0, which has no normative XML Schema definition, may be considered an external namespace. XHTML defines a namespace, and numerous elements within that namespace.  Were a NIEM-conformant schema specification to use the element "xhtml:ul" (an unordered list), it would use a reference. In order for schema validation to proceed normally, a schema would have to define that element. However, there is no such schema for Non-XML Schema specifications. The schema that is created to fulfill that role is the placeholder schema. Placeholder schemas should only represent the necessary components directly referred to from NIEM-conformant schemas.

Importing of External Namespaces

When NIEM namespaces are imported, the import statements are documented with a description of how the namespace is relevant to the namespace being defined. External (non-NIEM) namespaces should be documented with additional information, including:

1. An indication that the imported namespace is not NIEM-conformant.

2. The URI for a source of the reference schema for the namespace

3. Version information

4. Information about the body responsible for the standard, including:

      a. Contact information

      b. URI

Additional metadata will be defined, as the NIEM NDR is further defined. For the time being, the metadata should be included as documentation elements.

A NIEM external adapter type is a complex type that has the following qualities:

1. It is a special form of NIEM-conformant type. It may be used as the type of any NIEM-conformant element.
2. An adapter type should compose a single semantic entity. That is, the subparts of the type should appear together because they form the definition for some concept, not simply as a way of wrapping a block of external content.
3. An adapter type should be documented, as should any NIEM-conformant type.
4. It contains content from an external namespace, including:
a. Attributes from an external namespace
b. Attribute groups from an external namespace
c. A single XSD sequence containing zero or more of:
i. Elements from an external namespace
ii. Model Groups from an external namespace. These are named groups of elements defined schemas.
iii. External container elements, from a NIEM-conformant namespace. These are used when an external type must be used.

5. It must extend the "ComplexObjectType" from the NIEM structures namespace
6. It may not directly reference any other complex or simple types. Such types should be accessed via an external container element.
7. It may not directly reference other NIEM content. Apart from the "ComplexObjectType", all content of an external adapter type should be external.
8. The content it references may be from more than one external namespace.
9. Each referenced external component must be individually documented, describing the meaning of the external component

Additional annotations may be introduced as the NDR is developed.

An example of the simple case shows an adapter type directly referring to an external element:

<complexType name="PointType">

<annotation>

<documentation>

SUMMARY OF TYPE GOES HERE

</documentation>

</annotation>

<complexContent>

<extension base="s:ComplexObjectType">

<sequence>

<element ref="gml:Point">

<annotation>

<documentation>

DESCRIPTION OF EXTERNAL ELEMENT GOES HERE

</documentation>

</annotation>

</element>

</sequence>

</extension>

</complexContent>

</complexType>

An alternate case occurs when types from an external standard need to be used, instead of elements.

The term “External” is used as a suffix to element names in the NIEM conformant namespaces. An element with a name that ends in “External” is referred to as an external container element. Such an element is defined when a NIEM standard needs to reference XML Schema types from an external namespace.

If an external namespace defines elements that are appropriate for use, the elements should be referenced by external adapter types, and external container elements are unnecessary. External container elements are needed to create container elements for types from external namespaces.

An external container element has the following characteristics:

Its name ends in "External".
It is not a NIEM-conformant element.
It may only be referred to by external adapter types. It is an error for any other component to refer to an external container element.
The type of the element is a simple or complex type from an external namespace. The element definition may not reference any other external components.
An external container element may not specify a substitution group.

External container elements may not be referenced by standard conformant components.

They may only be referenced by external adapter types.

Here is an example definition of an external container element:

<element name="PointExternal" type="gml:PointType">

<annotation>

<documentation>

DESCRIPTION OF EXTERNAL TYPE GOES HERE

</documentation>

</annotation>

</element>

Note that the definition is very simple: it provides a container for an external type, and is clearly labeled as non-NIEM content by the suffix "External".

The external container element may be used by an adapter type, as the following example shows:

<complexType name="PointType">

<annotation>

<documentation>

SUMMARY OF TYPE GOES HERE

</documentation>

</annotation>

<complexContent>

<extension base="s:ComplexObjectType">

<sequence>

<element ref="this:PointExternal"/>

</sequence>

</extension>

</complexContent>

</complexType>

External container elements are not NIEM-conformant data model components. Instead, they create container for external types. They are clearly identified external by their names (suffixed with "External"). External elements (that come from non-NIEM namespaces) are clearly identified as external by their namespaces.

The syntax for an instance of an association is simple. Take, for example, the marriage of Adam and Barbara Smith:

<MarriageAssociation>
<SpouseRef s:ref="A"/>
<SpouseRef s:ref="B"/>
<MarriageDate>1937-05-12</MarriageDate>
<DivorceDate>1973-06-02</DivorceDate>
</MarriageAssociation>

Interpreting the above XML fragment is straightforward:

There is an association that we call a marriage. You can tell it is an association, and not a thing, because it is named “something association”.
This marriage association has two spouses, a marriage date, and a divorce date.
One spouse is referenced as the object with the identifier A. The other spouse is identified by the ID B.
These objects are specified elsewhere in the same XML instance: Object A is specified as follows:

<Person s:id="A">
<PersonName>
<PersonFullName>Adam Smith</PersonFullName>
</PersonName>
</Person>

Object B is specified as follows:

<Person s:id="B">
<PersonName>
<PersonFullName>Barbara Smith</PersonFullName>
</PersonName>
</Person>

Other elements in the association specify more information about the association:

<MarriageDate>1937-05-12</MarriageDate>
<DivorceDate>1973-06-02</DivorceDate>

The marriage date and divorce date are specific to the relationship between the two spouses, and so is a natural fit for an element of the association.

The definition of an association is composed of several parts:

1. An element that identifies the specific semantics of the association.

For each semantically distinct association, we define an element. Each element will have annotations indicating the specific meaning of the association. Such documentation is not shown in this document, but follows the guidelines established for GJXDM 3.0. The syntax is standard XML Schema. For example, here is the definition for a parent-child element:

<xs:element
name="ParentChildAssociation"
type="ParentChildAssociationType"/>

We may wish to define a more-specific type of parent-child association. For example, an adoptive parent-child association:

<xs:element
name="AdoptiveParentChildAssociation"
type="ParentChildAssociationType"/>

If we wanted to make the type specific to an adoptive parent-child situation, then we define a new type, instead of reusing the general parent-child type.

2. A type for the association. The type may be have precise semantics, or may be a more generally defined type.

The definition of types for associations is done as needed, depending on the content of the types. We do not, as a rule, define a new type for each use or semantic definition of an association. Instead, we define them as necessary, to accommodate the content required. Here is an example definition for a type for the parent-child association:

<xs:complexType name="ParentChildAssociationType">
<xs:complexContent>
<xs:extension base="u:AssociationType">
<xs:sequence>
<xs:element ref="this:ParentRef" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="this:ChildRef" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

The type definition has several parts:

The name of the type is “something AssociationType”. This makes associations between objects distinct from other types of object definitions.

The type is derived from another association type. This allows definition of type hierarchies for associations, and the definition of characteristics that are shared across multiple association types. The content of the association is a sequence of elements. The content of the association could be entirely related objects. The association could also contain characteristics of the associations, such as dates, names, identifiers, etc.

This technique provides a general method for applying metadata and additional content to data objects in NIEM. It enables users to create a block of Metadata in NIEM metadata and apply it to objects in exchanges. An object states what metadata applies to it using the metadata attribute.

In this example, we have a specific reported date for a person object:

<Person s:metadata="MD">

<PersonName>

<PersonGivenName>Adam</PersonGivenName>

<PersonSurName>Brooks</PersonSurName>

</PersonName>

<PersonBirthDate>1960-10-07</PersonBirthDate>

</Person>

<Metadata s:id="MD">

<ReportedDate>2005-08-01</ReportedDate>

</Metadata>

This example has a few interesting features:

• The person object refers to its metadata

– The reference uses the attribute s:metadata

– The reference is to the object with id MD

• The metadata is a separate element

– The element is called Metadata.

– The metadata object has the id ‘MD.

• The ID is conveyed with the attribute s:id

– The metadata object contains an element ReportedDate

Usage of Roles can be demonstrated via the following example:

<Person s:id="P1">
<PersonName>
<PersonFullName>Fred Smith</PersonFullName>
<PersonName>
</Person>

<EnforcementOfficial>
<RoleOfPersonReference s:ref="P1"/>
<EnforcementOfficialBadgeID>
<ID>101101</ID>
</EnforcementOfficialBadgeID>
</EnforcementOfficial>

From the above example, it is clear that Fred Smith has a "Role", and that role is of an EnforcementOfficial.

"Roles" can be defined in a manner similar to that of defining "Associations", that is, by creating a type of "Role" and then creating an element that identifies that type. See below for an example.

<complexType name="EnforcementOfficialType">
<complexContent>
<extension base="this:SuperType">
<sequence>
<element ref="this:RoleOfePersonReference" minOccurs="0" maxOccurs="unbounded"/>
...
... Additional elements defined for enforcement officials ...
...
</sequence>
</extension>
</complexContent>
</complexType>

<element name="EnforcementOfficial" type="EnforcementOfficialType"/>

In the above example, a "Role" is defined for a Person via the RoleOfPersonReference element that indicates the type of the base object (in this case, a person of type PersonType). The type is not enforced by XML Schema validation. It is indicated, and could be enforced by XSLT scripts, but is not enforced by XML Schema validation.

NIEM is many things. But, for all the ground it covers, there are many things that the NIEM is not. Here are a few comments about the role of NIEM:

NIEM is not a database technology.
NIEM is not a guideline for designing your internal databases. NIEM is only for exchanges between systems. You should not try to make your internal databases mirror the NIEM.

NIEM is not just XML.
NIEM is not just XML. It's a set of reusable objects and their definitions. The definitions are not an afterthought. They are a major feature and benefit of the model.

NIEM is not a programming language.
NIEM is a data model. It's not a programming language. It's represented as XML, which isn't a programming language either.

NIEM is not a silver bullet.
NIEM is a tool for creating exchanges. The model defines pieces and how they fit together. You can use those pieces to build exchanges. But you still need to do the building.

NIEM is not a replacement for exchanges and interagency agreements.
Again, the model is a set of objects. Which objects are used and precisely how they will fit together are questions that will still need to be negotiated and decided between and among exchange partners.

NIEM is not a definition of interoperability.
NIEM helps define the payload of an exchange. Topics like security and messaging layers are beyond the scope of the model. 

Associations, roles, and metadata implement the ID and IDREF XML mechanisms. Through the use of ID and IDREF XML data becomes less redundant; ID and IDREF also allow us to take a relational approach for defining data. This results in a less hierarchical and flatter XML file which moves away from using only element inclusion to associate objects.

Although it may not be readily obvious, associations, roles, and metadata do somehow exist in most sets of business requirements. In many cases these may not be easily noticeable in their native form, so the tricky part is being able to pick these out and translate them to NIEM constructs. This underscores the importance of having an experienced and NIEM-cognizant facilitator to assist during the domain modeling phase of the IEPD process. The facilitator's job is to keep in mind the NIEM while considering the input from subject matter experts (SMEs). It should not be assumed that SMEs have previous knowledge of the NIEM so it is up to facilitator to serve as a mediator between business concepts and NIEM concepts. The result should be an agreed upon domain model that represents the business requirements while leveraging concepts set forth by NIEM. A precise and accurately defined domain model will result in more straightforward mapping.

Augmentation is a NIEM-specific methodology that allows for re-use of extensions that occur within a particular domain for use elsewhere. Augmentation does not implement ID and IDREF; instead it relies on element inclusion for associating the augmentation information to the base object, so essentially the augmentation becomes a property of the base object. Mapping to elements that exist in NIEM augmentation structures should not be any different than traditional mapping.

"NIEM provides a standardize set of reusable data components and XML representation for enabling interoperable information sharing for law enforcement at all levels of government. These components, a well-defined architectural framework, and set of tools provide for the consistent and efficient implementation of information exchange specifications. Additionally, the NIEM program and governance structures provide a consensus framework for participation of stakeholders at all levels of government which is essential in the identification of requirements and harmonization of components to support the information sharing mission."

"The concept behind NIEM and its core data exchange standards are proven, since NIEM has been built upon the Global Justice XML Data Model (GJXDM), which has successfully linked justice and public safety systems over the past three years. Many real world information exchanges such as Suspicious Activity Reporting (SAR) span multiple domains. NIEM extends the public safety and justice standards to support the intelligence, immigration, emergency management, international trade, infrastructure protection, and information assurance domains. Additionally, the NIEM 2.0 release significantly improves on its GJXDM predecessor in several areas including improved cross-domain harmonization of data components, better tools to improve efficiency and reuse, and more precise technical documentation such as the NIEM Naming and Design Rules (NDR). However, beginning with the recent NIEM 2.0 release, GJXDM has been incorporated as the "justice domain" of NIEM and as such inherits these benefits as well."

"NIEM was developed from the bottom up based on actual requirements from stakeholders from all levels of government. As such, adoption of the NIEM 2.0 release should not be viewed as pushed down as much as it is voluntary use by the community that participated in its creation. NIEM does not require any agency or project to adopt the latest version on some coordinated NIEM timeline. Each agency or project makes this decision based on what makes sense in their particular situation - nothing breaks just because NIEM publishes a new release. However, to facilitate the migration from GJXDM or a previous version of NIEM to the current version the program provides migration tools, documentation, and training to assist in this regard - See niem.gov."

To edit / delete in NIEM, an IEPD posted on NIEM.gov, the following steps are taken:

- Log into your account in NIEM.gov at http://niem.gtri.gatech.edu/niemtools/iepdt/search/index.iepd

- Click "My IEPDs"

- Click the IEPD to edit / delete

- Next page has 4 menu items at the top

- Click "Edit", edit the IEPD

- Next page, last link allows for deletion of the IEPD

The XML Metadata Interchange (XMI) is an Object Management Group (OMG) standard for exchanging metadata information via the eXtensible Markup Language (XML). The most common use of XMI is as an interchange format for UML models. Several versions of XMI have been created: 1.0, 1.1, 1.2, 1.3, 2.0 and 2.1. It is important to note that the 2.x versions are radically different from the 1.x series.

For NIEM developers, XMI is generally used to exchange metadata between UML-based modeling tools in an effort to share models, as well as to convert UML to a standard format that can be used by other tools in the modeling and development process(s). In the IEPD development process, UML class diagrams are recommended for modeling the content of an information exchange (exchange model). The UML model(s) are then mapped to NIEM during the IEPD mapping process. In general, using a UML class diagram, UML classes align with XML types and UML attributes align XML properties or elements.

A standardized interchange format, such as XMI, is intended to support the interchange of model information between heterogeneous tools. However, multiple versions of XMI as well as UML and various levels of support for these versions have also added to the problems associated with model interchange. NIEM developers are confronted with the task of trying to match UML versions with XMI versions to convert their models into a "standard" format for tool interchange of UML exchange models.

The "Map Information Exchange" tool, which is a member of the NIEM IEPD Development Tool Suite [http://niem.gtri.gatech.edu/niemtools/home.iepd], allows a developer to import their exchange model (UML) via XMI to begin the mapping process from exchange data requirements to NIEM. A common issue with the "Map Information Exchange" tool is that it currently only supports the XMI 1.2 representation of a UML 1.4 metamodel. Practically speaking, this means that the only UML modeling tool currently supported by the NIEM mapping tool is ArgoUML. For NIEM tools go to https://www.niem.gov/tools-catalog. Some organizations have resolved the XMI versioning issue through the development and use of XSLT stylesheets to convert from one XMI version to another. For example, a stylesheet developed to convert from XMI/UML 1.2/1.4 to XMI/UML 2.0/2.0 is a general solution that anyone could use.

The concept of "security" in information exchanges is a concept that requires further expansion. Security requirements can typically be categorized as authentication, authorization, information integrity and confidentiality. In the development of exchanges and/or services, security requirements should be documented during the design process for future implementation.

While NIEM provides structures that address some of these requirements, other national initiatives provide more comprehensive guidance on securing information exchanges. The principal method for addressing security requirements in NIEM is through the use of the metadata mechanism. NIEM provides the metadata mechanism for "attaching" information about NIEM objects. A NIEM object may have an s:metadata attribute, which refers to one or more metadata objects.

With the release of NIEM, all types and elements possess metadata attributes that facilitate the creation and use of metadata container elements that associate (with IDREF and ID type attributes s:metadata and s:id, respectively) any given metadata container to any given NIEM object. This mechanism provides great latitude in the development and use of security markings for any data object in NIEM. One particular use of metadata to establish security markings is the Intelligence Community Information Security Marking (IC-ISM) standard. The IC-ISM is one of the Intelligence Community (IC) Metadata Standards for Information Assurance and is the preferred way to apply information security markings within XML instances. The current approach to using this standard in NIEM (through the use of s:metadata) and its future inclusion in NIEM is provided at www.niem.gov, in an article at http://reference.niem.gov/niem/guidance/using-ic-ism/icism-with-niem.pdf.

…Beyond NIEM Security: Global JRA, Global FIPM Given that NIEM instances are implemented as a message payload, NIEM payloads are typically contained within service, messaging and transport technology standards implemented in XML. A number of security standards are provided at each of these layers that allow for the implementation of a complete broad security profile (e.g., authentication, authorization, information integrity and confidentiality).

The Global Justice Reference Architecture (JRA) initiative has incorporated a Service-Oriented Architecture (SOA) into the activities of all of the Global Working Groups. SOA addresses issues for security, privacy and information quality, and intelligence that have been given explicit attention and treated as part of a broad initiative within Global.

A Service Interaction Profile (SIP) is a concept identified by the Global JRA that defines an approach to meeting the basic requirements necessary for interaction between Service Consumers and Services in an SOA. This approach utilizes a cohesive or "natural" grouping of technologies, standards or techniques in meeting those basic interaction requirements. A SIP also addresses service interaction requirements such as security, reliability and availability. A Web Service description of a SIP has been outlined in the Global JRA Interaction Profile (WS SIP)" at https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/ws_sip_v_1.1_final.pdf. The WS SIP is based on the Web Services family of technology standards. The WS-I Basic Security Profile (WS-I BSP) Version 1.0, WS-Security and the Security Assertion Markup Layer (SAML) security standards are provided in the WS SIP to address security requirements in a SOA implementation of NIEM.

In an effort to extend the Global information sharing concepts and initiatives into a Federated Identity environment, The Global Federated Identity and Privilege Management (GFIPM) initiative was launched. The Global Security Working Group (GSWG) provides oversight for the GFIPM initiative. In a similar fashion to the use of XML schema as the basis for defining a data vocabulary for data interoperability [NIEM], a standard set of XML security attributes about organization/agency and users' identities, privileges and authentication details was developed that could be used as the basis for a common "security" vocabulary across a federation.

This common metadata, in the form of an assertion between systems, allows service providers to make independent data access and data privacy enforcement decisions based on their trust in the security assertions about users who are requesting access to specific data or data system resources. The GFIPM Metadata Package 1.0 defines common semantics and structure for metadata describing federated users and federated entities (hosts, devices, services, etc.) essential to the GFIPM concept of information access across a federation. This metadata can be used in support of security components: identification, authentication, privilege management/access control/authorization, auditing and personalization across a federation.

The encoding and transporting of GFIPM Metadata is accomplished through the use of Security Assertion Language (SAML) assertions, previously mentioned as a component of the JRA Web Service-Service Interaction Profile (SIP). In summary, a host of security capabilities have been identified and can be implemented through the congruent use of the models and architectures developed through Global initiatives.

In ArgoUML:
- Create a project in ArgoUML and save it as XMI compressed project file (.zip) instead of as a zargo or uml output.
- Create a class diagram, adding new classes to it, as well as attributes including the types (depending on your needs).
- Save the entire project as stated above after creating the classes.
- Click on File and select export XMI...
- Save the file as XML Metadata Interchange (*.xmi) type

In NIEM Mapping tool:
- Click on create an exchange to upload the xmi file
- Click on save and map
- Click the name of the exchange model below the label "Exchange Models." The tool will forward you to the next step, where you may select a data element to map. This will pull out the data elements created in the exchange model.
- Click on search, NIEM for a component with a name similar to a data element, or you may make a note about a data element.
- Map the data element to any of the NIEM components listed by clicking on map beside the NIEM component
- Choose the mapping category i.e. equivalent or partial e.t.c., or make notes and click on save.
- After you have mapped a data element, you may generate mapping reports, wantlists, and schemas by following the instructions listed under the label "Additional Help".
- This should generate your needed artifacts and you can make changes to them as well.

NIEM Exchange Mapping Tool:
For NIEM tools, see the https://niem.gov/tools-catalog

JIEM is a modeling tool to help facilitate the definition of information exchanges--getting the stakeholders who initiate the exchange together with those who receive it and then working out the detailed business rules and the data sets needed. The output of the JIEM tool is the documentation of this process that defines the exchange that is needed and what data should be there.

NIEM itself is a data model containing data component definitions and structure to help you build XML schemas to implement an exchange. The output of the NIEM process is an Information Exchange Package Documentation which is really a complete spec that can be given to a programmer to implement. The IEPD includes the XML schema, a sample instance and the business rules for initiating the exchange.

From a workflow perspective, the effort in the process of using the JIEM tool generates a practitioner friendly definition of a specific exchange. The next step is to develop a NIEM conformant IEPD that generates a technology friendly specification that a developer can turn into reality with programming.

It is not necessary to use JIEM for developing a NIEM-conformant exchange. Jurisdictions that have used the JEIM tool have found it very helpful in getting the practitioners on both sides of an exchange to better understand each other, but this can be done in other ways as well.

Since its inception in 2005, the National Information Exchange Model (NIEM) has expanded into many new and exciting areas within the justice and homeland security missions. This new strategic growth is a testament to the usability of NIEM and the many people and agencies involved in making NIEM a success. In 2008, NIEM continued to grow across the federal government through two key relationships—Universal Core (UCore), an interagency information sharing initiative being developed by the Department of Defense (DoD), the Department of Justice (DOJ), the Department of Homeland Security (DHS), and the Intelligence Community (IC), and the Maritime Information Exchange Model (MIEM) 1.0, developed by the MDA Data Sharing Community of Interest.

For more information regarding this, please refer to the attached pdf to this article.

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