NISS Knowledge Base

The process of converting the contents of an XML document to objects, such as a class, is called XML data binding.  A tool called a data binder does this by mapping XML schema components to classes that reside in a computer’s memory.  This process allows applications to access XML data, for a number of reasons, from the object rather that directly from the XML file.

There are several utilities available that can perform the data binding process.  The choice is primarily dependant on the development environment.  Below is a list of utilities that are available for common programming platforms. Please note that this list is not all inclusive.

Java

Castor 

http://www.castor.org/

Eclipse Modeling Framework (EMF)

http://www.eclipse.org/modeling/emf/?project=emf

Java Architecture for XML Binding (JAXB)

http://java.sun.com/developer/technicalArticles/WebServices/jaxb/

XMLBeans

http://xmlbeans.apache.org

C++

            Code Synthesis XSD

http://codesynthesis.com/projects/xsd/

xmlbeansxx

http://www.yolinux.com

.NET

Data binding functionality is built into the .NET platform. The System.Xml.Serialization namespace contains several classes that can be used to bind XML data and access XML data.

Xsd.exe

The XML Schema Definition Tool is included as a part of the .NET framework.  This tool can be used to generate runtime classes from XML schema files. 

http://msdn.microsoft.com/en-us/vstudio/aa496123

NIEM 2.0 Changes (summary)

Over 10,000 changes from NIEM 1.0 to 2.0:

·         >5,000 component changes

·         >5,000 code list value changes

·         Universal + Common = NIEM Core (nc :)

·         NIEM Core tagged/searchable as U or C

Re-modeled the following types:

·         Measure

·         Location: Address, Latitude/Longitude, geographic coordinates

·         Date, Time

·         Facility, Correctional Facility (Structure removed)

·         Entity (Person or Organization)

·         ContactInformation

·         Telephone number

·         Revised many Core definitions

·         Standardized Core definition formats
(type, abstract, augmentation, role, etc.)

New component metadata fields (for search/discovery):

·         Key words - synonyms, slang terms, etc.

·         Usage descriptions - describe specific use cases

·         Examples - typical or sample values

·         Reviewed Core data elements for NDR conformance
and ISO 11179 naming guidelines

Namespace adjustments:

·         Moved components to/from Universal, Common, domains

·         Justice namespace renamed Global Justice XML Data Model (JXDM) 4.0

·         Geospatial namespace prefix replaced by geo:

·         Reviewed and revised Identifiers (IDs) and IdentificationTypes

·         Added new URI representation term and corresponding URIType

·         Integrated Global JXDM 3.1beta

·         Integrated ~30 resolved NBAC/NTAC NCCT issues

·         Inserted ANSI-NIST Biometric standard in new namespace

·         Removed some duplicate components from Core

·         Applied additional 50+ adjustments requested by FBI

·         More thorough integration with Core planned for next release

·         Reintegrated domains to new Core

·         Replaced inappropriate specializations with augmentations

·         Repaired applied augmentations

New code lists and types:

·         Department of Transportation: hazmat

·         Bureau of Alcohol, Tobacco and Firearms: explosives

·         Drug Enforcement Agency: drugs

·         National Geospatial Intelligence Agency (NGA): horizontal datums

Updated existing code lists to most current:

·         Federal Information Processing Standards (FIPS) 10-4 country codes (from latest NGA updates)

·         ISO 639-3 language codes

·         ISO 3166 country codes

·         National Crime Information Center (NCIC) Technical & Operational Update (TOU) 06-2 (latest available)

·         Corrected use of U.N. Economic Commission for Europe (UN/ECE) Rec 20 - now using common codes (not symbols) for units of measure

·         Integrated 26 FBI NDEx issues and components.

·         Remodeled EncounterType for Immigration and People Screening domains.

·         Updated and repaired Immigration and Customs Enforcement ICE component definitions.

·         Fixed a number of technical concerns from the Office of the Director of National Intelligence (ODNI).

·         Added new components and code lists for Suspicious Activity Reporting (SAR) IEPD.

·         Remodeled Passport and integrated with Core for SAR and People Screening IEPDs.

·         Updated NIEM to use Intelligence Community Information Security Markings (IC-ISM) *.
*Current FOUO nature precludes public release.

Other New Features

·         Revised Naming and Design Rules
Draft Version 1.2 (7 Aug 2007).

·         Techniques for Building and Extending NIEM XML Components Version 2.0.1
(7 Aug 2007); includes examples.

·         Improvements to spreadsheet format.

·         URI pages for both NIEM 1.0 and 2.0 rooted at http://reference.niem.gov/niem/
o Limited domain independent versioning.

The NIEM Release history timeline:

Release Candidate (RC) - August 2013
NIEM 3.0 Beta - May 2013
NIEM 3.0 Alpha 2 - March 2013
NIEM 3.0 Alpha 1 - February 2013
NIEM Pre-Alpha - September 2012
NIEM 3.0 Kick-Off - August 29, 2012
NIEM 2.1 Production Release - September 2009
NIEM 2.0 Production Release – July 31, 2007
NIEM 2.0 Release Candidate 2 - June 2007
NIEM 1.0 Production Release – November 1, 2006
NIEM 1.0 Release Candidate 1 – September 30, 2006
NIEM 1.0 Beta 3 – September 11, 2006
NIEM 1.0 Beta 2 – August 8, 2006
NIEM 1.0 Beta 1 – June 30, 2006
NIEM 0.3 – April 12, 2006
NIEM 0.2.1 – February 24, 2006
NIEM 0.2 – December 23, 2005
NIEM 0.1 – October 11, 2005

By default the national community is highly encouraged to develop IEPDs using NIEM 2.0. In the case that the project is critical, under strict time constraints, and staff is well-educated and well-versed in GJXDM but has no exposure to the NIEM it would be a viable choice to instead develop IEPDs using GJXDM 3.0.3.
Although it is difficult to list pros and cons of each model it is worth mentioning that NIEM introduces new concepts that remedy shortcomings identified in the GJXDM. These concepts are called associations, roles, and metadata.

Associations
GJXDM 3.0.3 relies on element inclusion and referencing for representing relationships between objects. As the GJXDM has become more heavily used it has been determined that there are several issues with these methods of data association. In response NIEM introduced a new mechanism for data object associations, simply coined "associations". The new association concept closely resembles a relational model.  NIEM associations accommodate n-ary associations whereas the GJXDM does not. Also, with the GJXDM it is not possible to apply metadata to a data association; the new NIEM association mechanism makes this possible.
[Reference articles #235 and #236 ]

Roles
GJXDM 3.0.3 was not designed with the concept of "roles" in mind; instead inheritance is used to apply role-specific properties to a base object. NIEM only uses inheritance in the seldom case that an object is truly a specialized type of the base object; therefore roles in the NIEM do not use inheritance. NIEM has adopted the idea that a role represents a certain function of a base object. The NIEM role mechanism allows a base object to take on several roles, the GJXDM does not easily accommodate this.
[Reference article #239]

Metadata
GJXDM 3.0.3 relies on inheritance from the SuperType class for the distribution metadata information throughout the model. Because the NIEM has addressed this as misuse of inheritance it does not rely on inheritance from a base structure for the application of metadata throughout the model. NIEM introduces a new independent structure specifically for the application of metadata.  NIEM makes it very simple to apply metadata to roles, associations, and basic properties.  This structure allows sets of metadata to be extended and applied to only those objects requiring the extended set of metadata.  Metadata properties can also be repeated (cardinality set to 0..*), this was not possible in the GJXDM.  Metadata structures can be created and applied to multiple different objects; also an object may be related to multiple metadata structures. 
[Reference article #238]

NIEM is the National Information Exchange Model. This is an interagency initiative to provide the foundation and building blocks for national-level interoperable information sharing and data exchange. The NIEM project was initiated on 28 February 2005 as a joint venture between the U.S. Department of Homeland Security (DHS) and the U.S. Department of Justice (DOJ) with outreach to other Government departments and agencies. The NIEM leverages both the Global Justice XML Data Model (GJXDM) reference model and the GJXDM XML-based framework and support infrastructure.

This package contains the NIEM reference schemas (Core, code lists, domains, type adapters for external standards, as well as the schemas, schema profiles, or adaptations for those standards.) It also contains a cumulative change log and the spreadsheet. NIEM provides practitioners and developers with a baseline set of XML Schema components for building Information Exchange Package Documentation (IEPDs).

NIEM release 2.1 is based on the NIEM Naming and Design Rules (NDR) 1.3 and the Type Augmentation Supplement to NDR 1.3 (version 1.0, 24 September 2009).

Release Package

NIEM 2.1 - The release package includes all NIEM schemas for this release as well as the changelog, spreadsheet, and schema index.

Documentation

• Catalog - Catalog of files; the file you are viewing now.
• Schemas - A complete list of schemas included in this distribution.
• Spreadsheet - A hyperlinked, textually oriented model and dictionary of the NIEM content.
• Change Log - List of changes since last release.
• Alternative data formats - Alternative to XSD format; contains metadata for all 2.1 data components in three formats: CSV, MS Access, and MS Excel.
• Index to data components by namespace - Links to HTTP URIs and associated documentation pages for each 2.1 data component.

NIEM Core Schemas

• niem-core: NIEM Core includes both Universal (U) and Common (C) components. The identities for U and C components in Core are maintained with metadata.

NIEM Domain Schemas

• cbrn: Chemical, Biological, Radiological, and Nuclear Domain
• emergencyManagement: Emergency Management
• familyServices: Family Services
• immigration: Immigration
• infrastructureProtection: Infrastructure Protection
• intelligence: Intelligence
• internationalTrade: International Trade
• jxdm: Justice
• maritime: Maritime
• screening: The People Screening domain provides harmonized information sharing content within the Screening Portfolio of DHS. The Screening namespace is initially being populated with person screening information for immigrant and non-immigrant person types who have been encountered and identified by the Screening Portfolio Components. Screening expands on encounter-related NIEM elements currently included in the Immigration and Intelligence domains.

NIEM Conformant Schemas (code lists and adaptations of external standards)

• ansi_d20: Motor vehicle administration codes from ANSI D20, the Data Dictionary for Traffic Record Systems, maintained by AAMVA, the American Association of Motor Vehicle Administrators.
• ansi-nist: ANSI/NIST Fingerprint and Biometric standard.
• apco: Association of Public-Safety Communications Officials (APCO) - International, Inc.
• atf: Bureau of Alcohol, Tobacco, and Firearms
• cbrncl: Radiological and Nuclear Code List
• census: Employment codes from the U.S. Census Bureau
• dea: Drug Enforcement Administration
• dod_jcs-pub2.0-misc: Intelligence discipline codes from the U.S. Department of Defense (DoD) Joint Publication 2.01.
• edxl: Emergency Data Exchange Language
• edxl-cap: Common Alerting Protocol
• edxl-de: Distribution Element
• edxl-have: EDXL-HAVE specifies an XML document format that allows the communication of the status of a hospital, its services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital's facility and operations.
• fbi: FBI code lists for National Crime and Information Center (NCIC-2000), National Incident-Based Reporting System (NIBRS), and National Law Enforcement Data Exchange (N-DEx).
• fips_10-4: Countries, dependencies, areas of special sovereignty, and their principal administrative divisions from the Federal Information Processing Standards (FIPS) 10-4.
• fips_5-2: Codes for the identification of the states, the District of Columbia and the outlying areas of the U.S., and associated areas from the Federal Information Processing Standards (FIPS) 5-2.
• fips_6-4: Counties and equivalent entities of the U.S., its possessions, and associated areas from the Federal Information Processing Standards (FIPS) 6-4.
• geospatial: Defines NIEM adapter types for external geospatial components defined by OGC and ISO. It references local copies of unmodified schemas from external standards in local directory tree fragments that mirror the directory structures of the cannonical schema sources on the world wide web, and a profile of the OGC Open Location Services (XLS) schema that is based on GML version 3.2.1.
• have-codes: EDXL Hospital AVailability Exchange (HAVE) code sets
• hazmat: Pipeline and Hazardous Materials Safety Administration - Office of Hazardous Materials Safety
• iso_3166: Codes for the representation of names of countries and their subdivisions from the International Organization for Standardization (ISO) 3166-1:1997.
• iso_4217: Codes for the representation of currencies and funds from the International Organization for Standardization (ISO) 4217:2001.
• iso_639-3: Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages.
• itis: Integrated Transportation Information System
• lasd: Los Angeles County Sheriff's Department
• mmucc_2: Model Minimum Uniform Crash Criteria
• mn_offense: Statute and offense codes from the state of Minnesota.
• nga: National Geospatial Agency
• nlets: NLETS - The International Justice and Public Safety Information Sharing Network
• nonauthoritative-code: Non-authoritative codes for the direction of a person's pose in an image.
• post-canada: Province codes for Canada.
• sar: Suspicious Activity Reporting
• twpdes: Terrorist Watchlist Person Data Exchange Standard
• ucr: Crime reporting codes from Uniform Crime Reporting.
• unece_rec20-misc: Miscellaneous unit of measure codes from the United Nations Economic Commission for Europe Recommendation No. 20, Codes for Units of Measure used in International Trade.
• usps_states: U.S. state and possession abbreviations from the U.S. Postal Service (USPS).
• ut_offender-tracking-misc: Plea and military discharge codes from the Utah Offender Tracking Database, version 2.03.

NIEM Proxy Schemas

• xsd: Proxy types that carry dictionary metadata and have XML data type simple contents.

Special NIEM Schemas

• appinfo: Elements for use within xsd:appinfo to indicate information supporting the data model underlying NIEM.
• appinfo: This appinfo schema provides support for augmented types and augmented elements in NIEM domain schemas. It was written to work in tandem with the NIEM appinfo v2.0 schema.
• structures: Schema constructs for use by NIEM-conformant schemas to provide consistent definitions and functionality.

Source: http://release.niem.gov/niem/2.1/schemas.html

Documents

• https://bja.ojp.gov/media/document/29971

NIEM 3.0 will be a major release, building on the current active release NIEM version 2.1.

Please click on this link to download the NIEM BETA-1 version: http://reference.niem.gov/.3b1/niem-3.0-beta1.zip

NIEM 3.0 changes include model harmonization at both the core and domain levels. See below for specific updates and enhancements.

NIEM Core Updates

Through harmonization and content submission, NIEM Core has been updated as follows:

· Added some elements previously contained in domain content to NIEM Core

· Modified existing definitions for data elements in NIEM Core based on community input

· Added substitution group placeholders for code lists used in core, which makes plugging in updated code sets into information exchanges (i.e., IEPDs) much easier

· Updated 33 code lists in NIEM Core ensuring more timely and relevant data

NIEM Domain Content Updates

The following domains have submitted new and/or updated content for incorporation in NIEM 3.0:

· Biometrics (this domain community content marks their first input into the model)

· Chem Bio Rad Nuc (CBRN)

· Children, Youth, and Family Services (CYFS)

· Justice

· Maritime

· Immigration and Screening.

Technical Architecture Enhancements

· Augmentation: Type Augmentation is a complex concept that is often misunderstood. The NIEM 3.0 design makes type augmentation easier to understand and implement within information exchanges.

· Updating of Code Lists Independent from Releases: This enhancement allows NIEM communities to use and maintain up-to-date code lists without waiting for a future release.

· Intelligence Community Information Security Marking (IC-ISM) standard: NIEM 3.0 includes enhancements that better support the IC-ISM standard and provide the ability to leverage IC-ISM updates based on its rapid version cycle.

· Enhancements to Reference and Content-Bearing Elements: This enhancement significantly reduces complexity and duplication of NIEM elements by allowing a single element declaration to serve as a reference element or a content-bearing element.

NIEM.gov tools will be updated along with the launch of Version 3.0 to reflect architectural changes to the model.

Updated tools include:

· Schema Subset Generation Tool (SSGT): Enables users to search through the NIEM data model and build a NIEM subset.

· Conformance Testing Assistant (ConTesA): Assists developers by automatically identifying potential locations of non-conformance within IEPD artifact using the NIEM NDR 1.3 and IEPD specifications.

· Code List Generator: Provides the ability to build an XML Schema file for code sets from an Excel spreadsheet.

· NIEM-UML for v3.0: The UML Profile for NIEM (NIEM-UML) will be updated to align to 3.0. We will accommodate requests by current and prospective NIEM-UML tool vendors to incorporate NIEM 3.0 capabilities into their services.

Tool Link: http://tools.niem.gov/niemtools/home.iepd

A NIEM release represents a stable, harmonized, and production-ready data model, updated specifications, and potentially enhanced tools. NIEM supports a range of release types that are described in the NIEM High Level Versioning Architecture (HLVA) and categorized by the following release types: Micro, Minor, and Major. NIEM 3.0 will be a major release, building on the current active release NIEM version 2.1. For more information on the HLVA please refer to High-Level Version Architecture.

No. The rationale for elements vs. attributes in NIEM remains the same: The NIEM release will use elements to model NIEM properties, unless this is not possible (usually due to a type having simple content), in which case it will use attributes.

The appinfo.xsd to employ attributes (instead of element properties) was changed for several reasons. The appinfo schema defines metadata about the model, schemas, and terminology, and does not contain payload content components. Appinfo is part of NIEM infrastructure that is designed to be relatively fixed, and does not require the flexibility that users/developers need for IEPD extension and corresponding model semantics. And finally, attributes tend to make appinfo annotations simpler and cleaner.

Yes, the NIEM-UML Profile will be updated to align to 3.0. The NIEM PMO also plans to support requests by current and prospective NIEM-UML tool vendors to incorporate NIEM 3.0 capabilities into their services.

For more information on NIEM-UML, please click on this link: https://www.niem.gov/technical/Pages/niem-uml.aspx

NIEM 3.0 will be a major release, building on the current active release NIEM version 2.1. All the information that relate to the 3.0 can be found in the link below.

Please click on this link to download the NIEM 3.0 that just released: https://www.niem.gov/technical/Pages/current-release.aspx.

Click on the attachment file below to download all the release schemas for NIEM 3.0.

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

NIEM 3.0

Description

The National Information Exchange Model (NIEM) is an interagency initiative that provides the foundation and building blocks for national-level interoperable information sharing and data exchange. Initiated in February 2005, NIEM was originally a joint venture between the U.S. Departments of Justice (DOJ) and Homeland Security (DHS) with outreach to other Government departments and agencies.

This package contains the NIEM 3.0 reference schemas (Core, code lists, domains, type adapters for external standards, as well as the schemas, schema profiles, or adaptations for those standards). It also contains a spreadsheet of the model, a spreadsheet for all code lists, a change log, and an XML catalog. NIEM provides practitioners and developers with a baseline set of reusable XML Schema components for building Information Exchange Package Documentation (IEPDs).

NIEM 3.0 contains significant architectural improvements and content changes over the last NIEM release. This version conforms to NIEM Naming and Design Rules (NDR) v3.0.

Release Package

NIEM 3.0 - The release package includes all NIEM schemas for this release as well as the changelog and spreadsheet.

Documentation

• Index - Index of files; the file you are viewing now.
• Schema list - A complete list of schemas included in this distribution.
• Component spreadsheet - A hyperlinked, textually oriented model and dictionary of the NIEM content.
• Code spreadsheet - A hyperlinked dictionary of codes in NIEM.
• Change log XML - A log identifying components that changed from 2.1 to 3.0 in XML.
• Change log spreadsheet - A log identifying components that changed from 2.1 to 3.0. Also identifies what values changed.
• Alternate data formats - Alternatives to the XSD format; contains content and metadata for all 3.0 data components in three formats: CSV, MS Access, and MS Excel.

NIEM Core Schemas

• niem-core: NIEM Core.

NIEM Domain Schemas

• biom: Biometric Schema Version 1.0
• cbrn: Chemical, Biological, Radiological, and Nuclear Domain
• cyfs: Children, Youth, and Family Services
• emergencyManagement: Emergency Management
• immigration: Immigration
• infrastructureProtection: Infrastructure Protection
• intelligence: Intelligence
• internationalTrade: International Trade
• jxdm: Justice
• maritime: Maritime
• screening: The People Screening domain provides harmonized information sharing content within the Screening Portfolio of DHS. The Screening namespace is initially being populated with person screening information for immigrant and non-immigrant person types who have been encountered and identified by the Screening Portfolio Components. Screening expands on encounter-related NIEM elements currently included in the Immigration and Intelligence domains.

NIEM Conformant Schemas (code lists and adaptations of external standards)

• ansi_d20: Motor vehicle administration codes from ANSI D20, the Data Dictionary for Traffic Record Systems, maintained by AAMVA, the American Association of Motor Vehicle Administrators. Publication: ANSI-D20 Data Dictionary Release 5.0.0; Version: May 2009; http://www.aamva.org/ANSI-D20-Standard-for-Traffic-Records-Systems
• apco_event: Association of Public-Safety Communications Officials (APCO) - International, Inc.Publication: APCO ANS 2.103.1-2012 Public Safety Communications Common Incident Types for Data Exchange; Version: 2012; http://www.apco911.org
• atf: Bureau of Alcohol, Tobacco, and FirearmsDate: 2008
• cbrncl: Radiological and Nuclear Code ListPublication: CBRN domain; Version: 3.0; Date: Oct 2013; http://release.niem.gov/niem/3.0/
• census_commodity: Census and Dept of Transportation.Publication: CFS-1200 - SCTG COMMODITY CODES; Date: 11-15-2011
• census_uscounty: County codes from US Census and ANSI. Publication: INCITS 31:2009; Version: 2009; http://www.census.gov/geo/www/ansi/download.html
• core_misc: Non-authoritative codes for the direction of a person's pose in an image.Source: NIEM 3.0; Publication: NIEM 3.0; Version: 3.0; Date: Oct 2013; http://release.niem.gov/niem/3.0/
• dea: Drug Enforcement Administration (DEA).Publication: Controlled Substances - by DEA Drug Code Number; Date: 6 Sep 2012; http://www.deadiversion.usdoj.gov/schedules/orangebook/d_cs_drugcode.pdf
• dod_jcs-pub2.0: Intelligence discipline codes.Source: DoD Joint Staff; Publication: Joint Publication 2.0 - Joint Intelligence; Date: 22 Jun 2007; http://www.dtic.mil/doctrine/new_pubs/jp2_0.pdf
• dol_soc: US Department of Labor occupation codes.Publication: Standard Occupational Classification (SOC); Version: 2010; http://www.bls.gov/SOC/
• dot_hazmat: Source: US Department of Transportation (DoT)Pipeline and Hazardous Materials Safetey Administration (PHMSA); Publication: Title 49 CFR 172.101 Table (List of Hazardous Materials); Date: 18 Jan 2012; Source Updats: 18 Jan 2012; http://www.phmsa.dot.gov/portal/site/PHMSA/menuitem.ebdc7a8a7e39f2e55cf2031050248a0c/?vgnextoid=d84ddf479bd7d110VgnVCM1000009ed07898RCRD&vgnextchannel=4f347fd9b896b110VgnVCM1000009ed07898RCRD&vgnextfmt=print
• edxl_rm: Source: EDXL Resource Messaging (RM) Standards Working Group (SWG); Publication: Emergency Data Exchange Language Resource Messaging (EDXL-RM) specification; Version: 1.0; Date: 22 Dec 2009; http://docs.oasis-open.org/emerge
• edxl-cap: Common Alerting Protocol
• edxl-de: Distribution Element
• edxl-have: EDXL-HAVE specifies an XML document format that allows the communication of the status of a hospital, its services, and its resources. These include bed capacity and availability, emergency department status, available service coverage, and the status of a hospital's facility and operations.
• fbi_ncic: FBI code lists for the National Crime and Information Center (NCIC-2000).Source: FBI Crminal Justice Information Systems (CJIS) Division; Publication: leo.gov database; https://www.leo.gov
• fbi_ndex: Source: FBI Crminal Justice Information Systems (CJIS) Division; Publication: National Data Exchange (N-Dex) Specification (a NIEM IEPD); Version: 2.2; Date: 2013; http://www.it.ojp.gov/framesets/iepd-clearinghouse-noClose.htm
• fbi_ucr: Crime reporting codes from Uniform Crime Reporting.Source: FBI Crminal Justice Information Systems (CJIS) Division; Publication: CJIS Div UCR Program - NIBRS Technical Specification; Version: 1.0; Date: 16 April 2012; http://www.fbi.gov/about-us/cjis/ucr/nibrs_technical_specification_version_1.0_final_04-16-2012.pdf
• fips_10-4: Countries, dependencies, areas of special sovereignty, and their principal administrative divisions.Source: National Geospatial-Intelligence Agency (NGA); Publication: Geopolitical Entities and Codes (formerly FIPS 10-4); Date: Apr 2010; Source Updates: 14+; http://earth-info.nga.mil/gns/html/GEOPOLITICAL_CODES.pdf
• fips_5-2: Source: National Institute for Standards and Technology (NIST); Publication: Codes for the Identification of the States, the District of Columbia, and the Outlying Areas of the U.S., and Associated Areas; Date: 28 May 1987; Source Updates: 1 Jan 1988; http://www.itl.nist.gov/fipspubs/fip5-2.htm
• fips_6-4: Source: National Institute for Standards and Technology (NIST); Publication: Counties and Equivalent Entities of the U.S., its Possesions, and Associated Areas; Date: 31 Aug 1990; Source Updates: 7 (7 Jul 2001); http://www.itl.nist.gov/fipspubs/fip6-4.htm
• geospatial: Defines NIEM adapter types for external geospatial components defined by OGC and ISO. It references local copies of unmodified schemas from external standards in local directory tree fragments that mirror the directory structures of the cannonical schema sources on the world wide web, and a profile of the OGC Open Location Services (XLS) schema that is based on GML version 3.2.1.
• have-codes: Source: OASIS Emergency Data Exchange Language (EDXL); Publication: Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 1.0; Version: 1.0; Date: 22 Dec 2009; http://docs.oasis-open.org/emergency/edxl-have/v1.0/errata/edxl-have-v1.0-os-errata-os.html
• hl7: Source: Health (HL-7); Publication: Religion-HL7 Table 0006_VD; Date: 19 Jul 2004; http://ushik.ahrq.gov/dr.ui.drConceptualDomain_View?System=mdr&ConceptualDomainID=74288000&ViewDownFile=yes&DownFile=Co
• iso_3166-1: Source: International Standards Organization (ISO); Publication: Codes for the representation of names of countries -- Part 1: Country codes; Date: 2 Aug 2012; Source Updates: VI-13; http://www.iso.org/iso/country_codes.htm
• iso_4217: Source: International Standards Organization (ISO); Publication: Codes for the representation of currencies and funds; Version: ISO 4217:2008; Date: 30 Jun 2008; http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html
• iso_639-3: Source: International Standards Organization (ISO); Publication: Codes for the representation of names of languages -- Part 3: Alpha-3 code for comprehensive coverage of languages; Version: ISO 639-3:2007; Date: 2007; Source Updates: 5 Feb 2007; http://www.sil.org/iso639-3/
• it_codes: IT Codes
• mmucc: Source: Model Minimum Uniform Crash Criteria (MMUCC); Publication: MMUCC Guideline - Model Minimum Uniform Crash Criteria - 3rd Edition; Version: 3.0; Date: 2012; Source Updates: 31 Oct 2006;
• nga_datum: Source: National Geospatial-Intelligence Agency; Publication: Temporal Spatial Positioning Information (TSPI) ; Version: 2.0; Date: 1 Mar 2012; http://metadata.ces.mil/dse/ns/GSIP/tspi/2.0.0/tspi-core.xsd
• nga_genc: The Geopolitical Entities, Names, and Codes (GENC) Standard, the US Government implementation of ISO 3166.Source: NGA; Publication: GENC Standard; Version: Ed 1.0; Date: 27 Nov 2012; https://nsgreg.nga.mil/genc/discovery
• nlets: Source: The International Justice & Public Safety Information Sharing Network; Publication: NLETS User and Technical Guide; Date: 2006; http://www.nlets.org/
• occs_facility: OmniClass; Publication: OCCS Table 11; Date: 30 Oct 2012; http://www.omniclass.org/tables.asp
• post-canada: Province codes for Canada.Publication: Canada Post Addressing Guidelines; Date: 14 Jan 2013; http://www.canadapost.ca/tools/pg/manual/PGaddress-e.asp#1380608
• sar: Source: PM Information Sharing Environment (ISE); Publication: SE-FS-200-version-1.5 Suspicious Activity Reporting (SAR); Version: 1.5; Date: 25 Aug 2009; http://niem.gtri.gatech.edu/niemtools/iepdt/display/container.iepd?ref=ntsXeIX7M6Q%3D
• unece_rec20-misc: Miscellaneous unit of measure codes.Source: UN Economic Commission for Europe (UNECE); Publication: UNECE Recommendation No. 20 Revision 8; Version: Revision 8; Date: 2012; http://www.unece.org/tradewelcome/areas-of-work/un-centre-for-trade-facilitation-and-e-business-uncefact/outputs/cefactrecommendationsrec-index/list-of-trade-facilitation-recommendations-n-16-to-20.html
• usps_states: Source: U.S. Postal Service (USPS); Publication: Official USPS Abbreviations, Appendix B; Date: 2012; http://pe.usps.com/text/pub28/28apb.htm
• xCard: vCard XML representation, IETF RFC 6351

NIEM Proxy Schemas

• xs: Proxy types that carry dictionary metadata and have XML data type simple contents.

Special NIEM Schemas

• appinfo: Elements for use within xsd:appinfo to indicate information supporting the data model underlying NIEM.
• structures: Schema constructs for use by NIEM-conformant schemas to provide consistent definitions and functionality.

The release schemas can be downloaded here:  http://release.niem.gov/niem/3.0/niem-3.0.rel.zip

NIEM 3.0 will be a major release, building on the current active release NIEM version 2.1. For more information on the HLVA please refer to High-Level Version Architecture. In the NIEM 3.0 zip file below, it will included all the new namespaces, schema index, summary for NIEM 3.0, alternated data format, and more....

To download all the NIEM version from 1.0 to 3.0, please click HERE.

To download only the NIEM 3.0 version package, please click on the file below.

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

In September 2013, the Object Management Group (OMG) Board of Directors officially finalized the Unified Modeling Language (UML) Profile for NIEM (or NIEM-UML) as an OMG specification. NIEM-UML for Version 2.1 is now available!

NIEM-UML is an extension of a subset of UML that is specific to NIEM. NIEM-UML, when implemented in a tool, generates 100% NIEM-conformant information exchanges and provides a visual representation of those exchanges that is understandable to both technical and business users. This enables organizations to align their information exchanges with their business requirements.

We invite you to join the submission team as a contributor or reviewer. We expect to have conference calls every other week to discuss updates and items that require a decision. If you'd like to be added to the team distribution list, please reach out to us here.

Final approval is expected in the April 2015 timeframe.

More information, please click on this link: https://github.com/NIEM/NIEM-UML

NIEM 3.1 Alpha-1 Version is a test version of NIEM 3.1. This minor upgrade version will associate with our NIEM NDR 3.0 and MPD 3.0. There will be no changes to NDR 3.0 and MPD 3.0 in this upgrade. The final version of NIEM 3.1 will be released in 2015, and the date is not yet finalized due to the workflows and decision making from NIEM PMO. We recommend all NIEM users who want to stay informed on NIEM updates go to the link below, download the zip file, and test out the new version.

Please click on the link below to download the NIEM 3.1 Alpha-1 version package for test. We welcome any comments or recommendations to our help desk about this version.

NIEM 3.1 Alpha-1 Version: http://release.niem.gov/niem/3.1/

NIEM 3.1 Beta Version is a final test version of NIEM 3.1. This minor upgrade version will associate with our NIEM NDR 3.0 and MPD 3.0.

This NIEM 3.1 Beta Version will available for public review and comment from March 23 to April 6 of 2015. This final version of NIEM 3.1 will expect to be released in May/June 2015. This version will incorporate errors or bugs that users identified in the NIEM 3.0 version last year.

Here are some of the updates that NIEM 3.1 Beta Version includes:

Updated model content in six domains:
1. Justice
2. Millitary Operations (MilOps)
3. Biometrics
4. Maritime
5. Children, Youth, and Family Services (CYFS)
6. International Trade
The addition of the Human Services domain—they are adding content in the model for the first time!
Two core supplements:
1. To correct a code list associated with NIEM 3.0
2. To increase the precision of MGRSCoordinateType (Military Grid Reference System)
The NIEM 3.1 Beta Version Package is available at: https://www.niem.gov/about-niem/news/niem-version-31-now-available
The page for NIEM 3.1 Beta Version comment submissions is: https://www.niem.gov/about-niem/news/niem-31-beta1-available-review

The Geospatial Enhancement for NIEM (Geo4NIEM) initiative is a collaboration of the NIEM Program Management Office (PMO), the Open Geospatial Consortium (OGC), the Department of Homeland Security, and the Program Manager for the Information Sharing Environment (PM-ISE) to enhance NIEM's geospatial exchange capabilities.

The objectives of the Geo4NIEM initiative are to:

Develop recommendations for the inclusion and standard use of embedded geography markup language (GML) with NIEM Information Exchange Package Documentations (IEPDs).
Develop recommendations for the standardized use of Naming and Design Rules and the use of adaptors (e.g., NIEM wrapper for GML).
Test and demonstrate use of a standardized embedded GML and adaptors within NIEM IEPDs.
Develop architecture documentation and a fact sheet for the use of embedded GML and adaptors for use with NIEM IEPDs.
Develop recommendations for the inclusion of a Geospatial Domain within NIEM.
Geospatial information technologies are increasingly a foundation for supporting homeland security, law enforcement, emergency management, and public safety missions in the U.S. While these technologies rely upon much of the same data, they are typically developed in silos within a specific mission area. As a result, data duplication and data exchange delays occur. However, mission partners could benefit from shared access to the common operating data and services used within these geospatial systems if they were exposed and exchanged in open standards. Hence the need for enhancing NIEM’s geospatial exchange capabilities in order to significantly improve inter-government information sharing of this critical data source.

The Geo4NIEM initiative culminated in a demonstration of how enhanced geospatial capabilities enable situational awareness through the ability to identify, process, and comprehend critical information during an incident. More information and videos of the demonstration can be found here.

The Geo4NIEM initiative provided eight recommendations (specific to GML adapters in NIEM) for consideration in the NIEM 3.0 update; seven recommendations were implemented and one recommendation had no impact on the model itself. Overall, no significant changes were recommended to the NIEM technical architecture. The GML adapters are defined in the geospatial.xsd schema, a NIEM reference schema. In general, the standard adapter mechanism should be employed to import valid GML content into NIEM-conformant data structures.

An engineering report summarizing the findings and recommendations of the Geo4NIEM initiative was published in November of 2013. You can read more about the findings and download the engineering report here.
Documents
https://bja.ojp.gov/media/document/29986

The final operational release of NIEM Version 3.1 has been published and is now available. NIEM 3.1 is a minor release that incorporates user needs since NIEM 3.0 was launched in November 2013.

NIEM 3.1 highlights:

One new domain has added content to the model for the first time:

Welcome, Human Services Domain!
Six existing domains have updated their model content:

Biometrics
Children, Youth, and Family Services (CYFS)
International Trade
Justice
Maritime?
Military Operations (MilOps)
Two core supplements that apply to NIEM Core 3.0 are included:

Supplement 3.0.1 - Incorporates all U.S. State codes into U.S. Postal Service (USPS) code list-including Alabama (AL) that was previously omitted.
Supplement 3.0.2 - Incorporates the following updates:
Adds correct constraint for Longitude MGRSCoordinateType (Military Grid Reference System); increases precision.
Adds PersonUnionStatus (for Person associations).
Adds new values added by authoritative sources to the following code lists:
dot_hazmat
dod_jcs-pub2.0
dea_ctlsub
census_uscounty
NIEM 3.1 marks the first time we have exercised the new Version 3.0 architecture that allows:

(1) easy adjustments to code lists and
(2) supplements to core without the need to wait for a major release cycle.
The NIEM 3.1 Final Version Package is available at: https://niem.github.io/niem-releases/

For most information exchange applications, it is preferable not to use the entire schema, but rather a "subset" schema containing only those types and elements needed for that exchange.

When creating a subset, it is important to follow a small set of rules, to ensure that the subset is the functional equivalent (for a particular application) of the full GJXDM or NIEM. The most important subset rule is that an instance that validates against a correct GJXDM or NIEM subset will also validate against the entire GJXDM or NIEM schema. This and other rules for subset schemas have been published online (see link below), so it is certainly possible for schema designers to create subset schemas "by hand" by following these rules.

However, after the idea of subset schemas was introduced, manual creation of subset schemas proved cumbersome, tedious, and error-prone. This was mostly because when selecting a type or element for the subset, there are often other types and elements on which the selected type or element is dependent upon; these dependencies have to be included in the subset for it to be valid. While sometimes difficult to remember, the rules for dependencies are nonetheless consistent and deterministic. Luckily, as a result, the rules lend themselves to implementation in a tool that checks the validity of the subset schema.

GJXDM Validator: https://bja.ojp.gov/program/it/national-initiatives/niem (Note: Currently there is no Validator for NIEM, but it can be validated using third party tools)

Rules for Schema Subsets: https://www.niem.gov/documentsdb/Documents/Technical/NIEM-NDR-1-3.pdf

Key Words are navigational terms to help identify the NIEM name for required components. There are often many ways to name a particular data element. NIEM prohibit the use of synonyms within the XML schema specification. However, the database from which the schema is generated may contain additional navigational terms to help identify the NIEM names for required components. We refer to such navigational terms as key words. Like context data elements, key words do not appear in the schema but do appear in the dictionary database.

Yet, key words differ from context data elements in that they are not represented by inherited properties (which usually have generic names). Instead, they are simply terms or common abbreviations that are near in meaning to, synonymous with, or suggestive of NIEM property names. Key words often come from other data models, dictionaries, or schemas. The following is an example of "Key Words" and the components they might link to:

KEY WORD

LINKS TO

Automobile

Vehicle

Car

Vehicle

ChildFlag

JuvenileIndicator

Fine

DisciplinaryActionFee

Key words capability is available in the NIEM SSGT.

NIEM SSGT: http://niem.gtri.gatech.edu/niemtools/ssgt/index.iepd

The namespace is used for schema version control, in that the contents of GJXDM or NIEM (elements, types, attributes, and attribute groups, as well as the definitions of all of these things) will never change for a given namespace identifier. That is, for example, the contents of the GJXDM namespace at version 3.0.3 will always be the same for that namespace. And any changes to the data model will require a new namespace identifier.

Example of a namespace: https://bja.ojp.gov/program/it/national-initiatives/gjxdm

Directory of all GJXDM namespace releases: https://bja.ojp.gov/program/it/national-initiatives/gjxdm

NIEM namespaces: http://www.niem.gov/niem/namespaces

It is possible to extend GJXDM and NIEM, like any other XML markup language. There are several ways that a local schema might do this. A simple set of examples has been prepared that illustrates various extension methods.

One of these methods is based on the World Wide Web consortium (W3C) rules for extension of XML Schema types. W3C Schema rules for type extension allow many possibilities. However, type extension within the GJXDM and NIEM is intended to maintain a class hierarchy of objects by adhering to a more restrictive set of subclass rules.

To ensure the integrity, consistency, and meaning of the class (inheritance) hierarchy, the following rules for type extension must be followed:

1) A derived type may add (by extension) additional fields (elements/attributes) to its base type.

2) A derived type may restrict one or more fields of its base type, but only so that a derived field is a subset of the field of the base type. For example, a derived type may:

Restrict an enumeration from a large set of options to a smaller set of options, as long as every option in the derived set appears in the base set
Remove a field of the base type only if the field is optional in the base type
Require a field to appear only if the field is optional or required to appear in the base type
3) A derived type may not modify a field of its base type such that it violates the constraints of its base type. For example, a derived type may not:

Add additional enumerations to a field
Remove a field that is required by its base type
Modify the type of a field of its base type
W3C rules for Extension XML Schema Types:http://www.w3.org/tr/xmlschema-0/#derivext

There are several tools available for validation of WSDL that imports a GJXDM or NIEM subset. WSDL stands for Web Services Description Language.

WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes. Both xsdvalid and the built-in schema validator in XMLBeans (where the validator is a part of the schema object model) can be used in validating subsets generated by the SSGT (and the entire GJXDM or NIEM distribution itself). Similar tools work for this purpose in the .NET environment as well.

If one wants to validate the schema that defines the types used by elements in the WSDL document, then a schema validation tool like xsdvalid should work fine. However, if one is looking to validate the WSDL document as well, but can't find a tool that will do it, then one workaround would be to generate client stubs using something like Apache Axis' wsdl2java utility and look for errors in that process. The process is not elegant, and one would wind up with the client stub code. Yet Axis wsdl2java has very high fidelity to the WSDL spec, and it would definitely do the job.

It is not a good idea to workaround the problem by pasting all of the GJXDM or NIEM subset schema elements into a single schema, since that would necessarily mean collapsing everything into a single namespace. Altering the namespace in which schema elements appear is a violation of the rules for GJXDM and NIEM subsets.

XMLBeans:http://xmlbeans.apache.org/

One key concept is that GJXDM and NIEM were designed for information exchange, and have no direct bearing on how one would implement a database that is part of a sending or receiving system; the database should be designed to hold the data required for the system's business purpose. At this time there are no web services that have been identified or documented for use with the GJXDM and NIEM surrounding the DB implementation, although work is being done in that area.

However, a number of organizations have had success deploying web services to exchange information using the GJXDM. Some have used web services conformant with the WS-I Basic Profile. XML messaging standards (depending on what you mean by ''messaging standards'') for the GJXDM are emerging but are not complete, although again, work is being done in that area. Organizations are developing Information Exchange Package Documentation to specify information exchange packages such and Incident Report, Court Filing, etc.

Organizations such as NLETS have released GJXDM-conformant message specifications for the information exchanges they support. An example with SQL is the data exchange project WENET, where a couple of the service points use the MS SQL server XML services to directly extract GJXDM data from SQL. Currently it is only in the early stages of development.

The hardest part seems to be creating a GJXDM or NIEM complaint sub-schema that SQL will like. The sub-sets strip out all of the imports and make them local, redesign some of the global element model and generally look different from the GJXDM or NIEM but still validate. Then they are marked up with SQL-XML tags/attributes specifying tables/fields and relationships. This is demonstrated with simple elements and is working towards it with Person, Warrant, and some others.

The most popular RDBMS and IDE tools, including those from Microsoft and Oracle, can support DB implementations based on GJXDM or NIEM. These tools provide capabilities for parsing XML and moving XML data in and out of databases. However, depending on ones particular database, it may be necessary to use XSLT to transform between a GJXDM- or NIEM-conformant XML schema and an XML schema that works with your database.

WENET Data Exchange Project: http://www.whatcomcounty.us/515/Whatcom-Exchange-Network-WENET-Project

There are a large number of transformations which could be performed on the GJXDM and NIEM to create a subset, and many of those possible transformations are not recommended. It is important that the generated schema subset adhere to the rules for schema subsets.

The following transformations should not be performed:

Do not omit any components that are required.
Do not rearrange or change the order of elements appearing in schemas.
Do not change the base type of any type
Do not change the type of any element or attribute
Do not make global components local
Do not change the namespace of elements, attributes, types, etc.
Do not rename components
Do not flatten structures
Do not change any namespace URI
Do not change the relative file path location of files (i.e. .../3.0/jxdm.xsd)
Do not do anything not specified by this document

There is no perfect strategy for handling incomplete or partial dates within the GJXDM and NIEM. However, different options do exist for different circumstances. Most of the date fields are of type ''xsd:date'' whereas for example a number of our entities can include only the year. As an example, consider the case where a license plate registration year is stored only as a year. In GJXDM and NIEM there is VehicleRegistration/RegistrationEffectiveDate. For this example there are two options:

1. Just use 01-01-XXXX and let the receiver know out of band that the month and day are unreliable. An advantage of this approach is that it doesn't require any schema changes and thus the data are more easily exchanged. Disadvantage is that it's rather inelegant and confusing.

2.  Extend the schema to add a field of type ''gYear'' in the appropriate spot. This would require creating a local extension of PropertyRegistration, then a local extension of VehicleRegistration to use the PropertyRegistration base type. (VehicleRegistration could be extended directly but just for the sake of argument I'll put it in exactly the same hierarchy.) Then if VehicleRegistration is encapsulated in a Vehicle, type substitution must be used in the appropriate Vehicle entity. The advantage is that this way is more exact; disadvantage is that it requires much more work and has local extensions which harm interoperability.

NLETS dealt with a similar problem in which the dates only included the year, but because of the legacy data there was also the possibility of receiving several other textual values, as well as an inability to know the data while creating XML. Therefore they created an element in our namespace of type TextType and implemented using cascading extension. If properly documented as a business rule, the full date element can probably be used in the Registration situation.

However, one should be wary of implications if more exact data could be provided in the future. One runs the risk of having some exact dates, and some with 01-01 as a space holder. Then it is impossible to know if the registration was actually as of January 1, or if the Month/Day were unknown. Keep in mind that type substitution may not be appropriate here because one can only substitute with a type derived from the expected type.

Another option which would allow avoiding extension but more clearly communicating the data in the element is to leverage the comment Text metadata attribute to communicate that the month/day is unknown. The choice depends largely on the implementation circumstances. It's generally better to ensure that the content of the element will be unambiguous and err on the side of an additional extension rather than risk misinterpretation. 

A GJXDM or NIEM component is any type or property defined in the models. Types translate to XML Schema types and properties translate to XML schema elements or attributes from core, domains, code list schemas, and external standard adapters. There are currently over 4000 components in NIEM 2.0 and over 2000 components in GJXDM 3.03. There will be more components to be add in the new version NIEM 2.1 that pulished in October 2009.

GJXDM and NIEM follow the Federal XML Developer's Guidelines, ebXML, ISO/IEC Standard 11179, and best practices. Abbreviations and acronyms are highly discouraged within data element names, except when commonly understood, rarely confused, widely accepted, agreed upon, and documented. Authorized abbreviations are listed and defined in the glossary of the documentation.

Federal XML Developer's Guide: http://xml.fido.gov/documents/in_progress/developersguide.pdf

GJXDM and NIEM do not contain elements for enforcing security requirements for information exchanges. Enforcing these requirements necessitates leveraging other standards, which will differ depending on the overall architecture of the exchange. For example, in web services, many exchange security requirements are addressed by the Web Services Security (WS-Security) standard from OASIS, and the Web Services Interoperability Organization (WS-I) Basic Security Profile.

The OASIS LegalXML Court Filing technical committee has addressed many of these information security requirements in its standards development work. This work is recommended as an example of how to leverage open security standards in GJXDM- and NIEM-conformant exchanges.

In accordance with ISO 11179, each GJXDM and NIEM tag name consists of several parts:

• Object class term: The object class term represents the specific real-world object to which the property is applicable.
• Property term: The property term is a plain-language summary of the quality that the property represents. Example property terms would include Hair Color, Hair Appearance, and Tax Identifier.
• Representation term: The representation term describes, from a very high level, the form of the data represented. This term is taken from a list of “ebXML” representation terms. Representation terms not on the list are not valid. The point of the representation term is not to specify the exact type of the represented value; It is instead intended to give the person reading the property name a clue as to what the property is for and what it might mean.

The Global JXDM is unique within government as an XML vocabulary that has truly been created from the ground up. Practitioners from a variety of organizations came together to create a data dictionary that would allow the entire justice enterprise to share information with a common structure. This enables exchanges to be built that serve many purposes and eliminates the point-to-point inefficiencies of the past. The success of Global JXDM has standardized many disparate systems across the criminal justice domain and the concept is now being extended on a national level. Global JXDM will continue to operate under the guidance of DOJ Bureau of Justice Affairs (BJA), and NIEM will serve as an umbrella organization with a much larger scope. DOJ Office of the CIO is responsible for NIEM, in partnership with the DHS Office of the CIO.

In NIEM, the Global JXDM is represented in the justice domain. NIEM not only includes the justice domain, but also represents others, such as intelligence and emergency and disaster management. NIEM provides the organizations involved in these domains with the data model needed to create their information exchanges, to create and share information, and to get a head start in implementing its own exchanges. NIEM actively encourages Federal agencies while equally focusing on state and local contributors. This is possible through an emphasis on component-based resources that are reusable and portable to any organization or platform. NIEM will serve as an umbrella for existing domains, such as justice and homeland security, to work side by side in developing information exchange capabilities and ensure that technology will never again be a barrier to the public's safety and well being.

http://www.niem.gov

Conceptually, the IEPD lifecycle in NIEM (as defined in the NIEM Concept of Operations) is very similar to the IEPD lifecycle followed by many IEPD developers in GJXDM. The GJXDM lifecycle is documented in the GJXDM Users Guide.
Both lifecycles call for the basic steps of understanding the contextual business scenarios or context of exchange, documenting exchange requirements, modeling the information being exchanged, mapping the information model to GJXDM or NIEM, and building schemas from the mapping. Both lifecycles suggest (the NIEM lifecycle does so explicitly) that IEPDs should be published and registered so that others may find and reuse them.
The NIEM lifecycle references supporting tools that were not available in the GJXDM lifecycle, such as the NIEM Naming and Design Rules (NDR) and the NIEM Component Mapping Template (CMT).
The GJXDM lifecycle makes more explicit reference to the benefit of logical domain modeling as a way of capturing information requirements that are independent of the XML vocabulary. The domain model represents the requirements that are mapped to GJXDM (or NIEM).

Does private industry mean private professionals in the Justice domain, as differentiated from public ones.

For your specific question, adoption and use by private industry at this time is by service providers and vendors that service the Justice and Public Safety Government marketplace. However, this does include lawyers and law firms that have a requirement to make filings with the Courts. We do expect to do more with private industry. both from the perspective of vendor adoption, and based on NIEM mission stakeholders and their requirements to exchange information with players in the private sector.

Most of these items are current programs, initiatives, and/or groups which are providing support to increase information exchange within the Law Enforcement Community. I've provided a little text to give you some information about each item, there are many documents and additional information that is accessible within each website.

" Information Sharing Environment (www.ise.gov): Information Sharing is a large focus of the Department's Architecture.

" DOJ Office of Justice Programs IT Initiatives (http://www.it.ojp.gov/index.jsp): This website outlines some of the major IT Initiatives of the Department's Office of Justice Programs. There are a number of links to related websites and details on each of these IT Initiatives.

" National Information Exchange Model (www.niem.gov): NIEM is the outgrowth of efforts that took root inside the U.S. Department of Justice (DOJ) to standardize the Extensible Markup Language (XML) schema used to describe the information commonly used by and exchanged among local, state, and federal enforcement agencies. NIEM represents the current approach to cross domain and cross levels of government information sharing (data standards).

" Global Justice XML Data Model (http://www.it.ojp.gov/topic.jsp?topic_id=43): GJXDM is the precursor to NIEM. The Global JXDM is an XML standard designed specifically for criminal justice information exchanges, providing law enforcement, public safety agencies, prosecutors, public defenders, and the judicial branch with a tool to effectively share data and information in a timely manner. What used to be GJXDM is now the Justice Domain within NIEM.
o GJXDM Success Stories https://bja.ojp.gov/program/it/global/groups/outreach/success-stories

" The Eurojust Project (http://eurojust.europa.eu/): Eurojust project which adopted the GJXDM as a way to speed development of warrant and other exchanges among EU member countries, resulting in a 50% reduction in cost and time to get operational.

" The Law Enforcement Information Technology Standards Council (http://www.leitsc.org/): The mission of LEITSC is to foster the growth of strategic planning and implementation of integrated justice systems. Together, participants from these organizations represent the law enforcement community as a whole on information technology standards related issues. LEITSC provides functional standards for CAD and RMS.

" Global Justice Information Sharing Initiative (http://www.iir.com/GLOBAL/): The Institute for Intergovernmental Research receives grant funding from the Office of Justice Programs, Bureau of Justice Assistance, U.S. Department of Justice, to provide coordination and management support to the Global Justice Information Sharing Initiative (Global).
o Global Products (https://bja.ojp.gov/program/it/global)

" Regional Information Sharing Systems (http://www.iir.com/riss/): RISS is a national program of regionally oriented services designed to enhance the ability of local, state, federal, and tribal criminal justice agencies to Identify, target, and remove criminal conspiracies and activities spanning multi-jurisdictional, multi-state, and sometimes international boundaries. Facilitate rapid exchange and sharing of information among the agencies pertaining to known suspected criminals or criminal activity. Enhance coordination and communication among agencies that are in pursuit of criminal conspiracies determined to be interjurisdictional in nature. Currently both Interpol and Europol are members of RISS.

To support government-wide information sharing, all recipients of grants for projects implementing information exchange capabilities using XML technology are required to use the National Information Exchange Model (NIEM) / Global Justice XML Data Model (GJXDM) in accordance with these Implementation Guidelines. Grantees are further required to assemble, register and make available without restriction all IEPDs and related artifacts generated as a result of the grant to the component registry. Assembly of NIEM IEPDs within the NIEM IEPD Tool is optional. However, NIEM IEPDs must be assembled in accordance with IEPD Requirements as specified by the NIEM Program Management Office, and must be registered in the Information Exchange Package Documentation (IEPD) Clearinghouse.

Organizations not receiving federal funding to use NIEM / GJXDM are also encouraged to register their IEPDs in the IEPD Clearinghouse. This will facilitate interoperability of information systems and will enhance effective sharing of critical information.

Specific grant program requirements are stated in the grant solicitation or program guidelines and also may be included in the special conditions of the grant award. This information and more on this topic regarding eligibility and requirements can be obtained from your Grant Manager due to the fact that each grant is different and the grant managers have the documentation regarding these grants and the terms stated on them.

Many vendors offer specific tools for this purpose, and many databases now have the capability to read an XML document and insert the contents into the appropriate tables. Implementers should beware that this approach carries some risk of tightly coupling the business logic of the exchange to a particular database and particular database structure. Implementers should consider the benefits and potential pitfalls of the approach before applying it.
This article will focus on options, standards, and tools that are either offered under an open source license, developed by a standards body or industry consortium, or freely available to the general public.
One approach is to write software that parses the XML stream (the IEP) and processes the resulting structure or tokens to interact with a database or system. This approach is usually programming-intensive and can be error-prone. It typically involves using an XML parser, such as the .NET runtime's parser or the Crimson or Xerces parsers on the Java platform.
A second approach is to use a software library and application programming interface (API) that represents an XML stream as a graph of objects automatically, based on code generated from an XML schema. The .NET framework contains this capability natively; the Java 2 platform offers several approaches to this, including the Java API for XML Binding (JAX-B) and XML Beans.

Click on this link: http://www.it.ojp.gov/framesets/iepd-clearinghouse-noClose.htm and click on the word "My Stuff", and click on "Create a New Account" button to create a user account.

1. 1. Once the user account has been created, follow the steps below to submit the IEPD Metadata Information.
Click on this link: http://www.it.ojp.gov/framesets/iepd-clearinghouse-noClose.htm

2. 2. On the left hand side, click on the word "download" to get the IEPD Form Template, and after that, please read the procedure on the page 2, and completely fill out the information on page 1.

3 3. Then, go back to the web page, on the right hand side, click on the "Submit IEPD Information" link.

4. 4. At the "Title", provide the name of the IEPD, then give a brief description about your IEPD at the "Summary".

5. 5. Click on the "Browse..." button to attach the IEPD Form Template that you just filled out. (REMEMBER: Please attach the page 1 only). After that, click on the "Continue…" button, then the system will send you a message to your email to confirm that it has been submitted.

NOTE: Clearinghouse will upload your article in 24-72 hours.

If you still cannot submit the information, please contact the NISS Help Desk to help you submit your IEPD Metadata Template at:

E-mail: [email protected] (recommended)
Telephone: 1-877-333-5111 or 703-726-1919

VehicleID is a unique combination of alphanumeric characters that identifies a specific vehicle. A vehicle identification number is normally imprinted by the manufacturer and attached to the vehicle in specific locations, but is occasionally assigned by titling or registration agencies. Sometimes referred to as a VIN, VIN number.