National Information Exchange Model (NIEM) 
User Guide 
Volume 1 
www.NIEM.gov 
niem_logo



 U.S. Department of Justice 
Office of Justice Programs 
810 Seventh Street, NW 
Washington, DC 20531 
The Honorable Michael B. Mukasey 
Attorney General 
The Honorable Mark R. Filip 
Deputy Attorney General 
The Honorable Kevin O’Connor 
Associate Attorney General 
The Honorable Jeffrey L. Sedgwick 
Acting Assistant Attorney General 
The Honorable Domingo S. Herraiz 
Director, Bureau of Justice Assistance 
Office of Justice Programs 
World Wide Web Home Page 
www.ojp.usdoj.gov 
Bureau of Justice Assistance 
World Wide Web Home Page 
www.ojp.usdoj.gov/BJA 
For grant and funding information, contact 
U.S. Department of Justice, Office of Justice Programs 
Funding Opportunities 
http://www.ojp.usdoj.gov/funding 
BJA full logo 20070720


This project was supported by Grant No. 2007-RG-CX-K021 awarded by the Bureau of Justice Assistance. 
The Bureau of Justice Assistance is a component of the Office of Justice Programs, which also includes the 
Bureau of Justice Statistics, the National Institute of Justice, the Office of Juvenile Justice and Delinquency 
Prevention, and the Office for Victims of Crime. Points of view or opinions in this document are those of 
the author and do not represent the official position or policies of the United States Department of 
Justice. 


Table of Contents 

Table of Contents ...................................................................................................................... iii 
List of Figures ............................................................................................................................ vi 
List of Tables ............................................................................................................................. ix 
1 Acknowledgements ............................................................................................................. 1 
2 Introduction ......................................................................................................................... 2 
2.1 Typographical Conventions Used in This Document ............................................... 3 
3 The Need for Information Sharing ...................................................................................... 4 
3.1 Challenges to Information Sharing .......................................................................... 4 
3.2 Information Sharing Architectures .......................................................................... 5 
4 NIEM Overview .................................................................................................................... 7 
4.1 Background .............................................................................................................. 8 
4.2 The Evolution of NIEM ............................................................................................. 8 
4.3 NIEM Data Model ..................................................................................................... 9 
4.4 Design Criteria for NIEM ........................................................................................ 11 
5 NIEM Data Model Concepts .............................................................................................. 13 
5.1 An Introduction to Modeling Concepts ................................................................. 13 
5.2 Expressing Object-Oriented Concepts in XML: Types and Properties .................. 14 
5.3 Container Elements ................................................................................................ 16 
5.4 Content Elements and Reference Elements .......................................................... 17 
5.5 Associations ........................................................................................................... 19 
5.6 Roles ....................................................................................................................... 25 
5.7 Abstract Elements and Substitution Groups .......................................................... 28 
5.8 Augmentation ........................................................................................................ 34 
5.9 Metadata ................................................................................................................ 38 
5.10 External Adapter Types .......................................................................................... 41 
6 NIEM Data Model Content ................................................................................................ 44 
6.1 Architecture of NIEM Model .................................................................................. 44 
6.1.1 Relationships Between the Components................................................... 45 
6.2 Namespaces ........................................................................................................... 47 
6.2.1 Structures .................................................................................................. 47 
6.2.2 Domains .................................................................................................... 53 
6.3 Standard Code Lists ................................................................................................ 56 
7 Building NIEM-Conformant Data Exchanges ..................................................................... 58 
7.1 NIEM Information Exchange Package Document (IEPD) Development Lifecycle .. 59 
7.2 Step 1: Scenario Planning ...................................................................................... 60 
7.3 Step 2: Requirements Analysis .............................................................................. 63 
7.3.1 Domain Modeling Options ........................................................................ 64 
7.4 Step 3: Mapping and Modeling ............................................................................. 68 
7.5 Step 4: Building and Validating ............................................................................. 70 
7.5.1 Subset Schema .......................................................................................... 74 
7.5.2 Extension Schema ..................................................................................... 75 
7.5.3 Exchange Schema ..................................................................................... 76 
7.5.4 Constraint Schema .................................................................................... 76 
7.5.5 Validating IEP Schemas ............................................................................. 78 
7.6 Step 5: Assembling and Documenting .................................................................. 78 
7.7 Step 6: Publishing and Implementing ................................................................... 79 
7.8 Data Harmonization and Refactoring .................................................................... 80 
8 IEPD Artifacts ..................................................................................................................... 81 
9 IEPD Metadata ................................................................................................................... 83 
Appendix A: Data Model Conformance Guidelines .............................................................. 85 
Introduction ....................................................................................................................... 85 
Conformance Rules ........................................................................................................... 85 
Assistance in Developing NIEM-Conformant Schemas ..................................................... 86 
Additional Remarks About Conformance .......................................................................... 86 
Grant Recipients ................................................................................................................ 86 
Appendix B: NIEM Tools ....................................................................................................... 88 
Introduction ....................................................................................................................... 88 
Help Documentation on NIEM.gov.................................................................................... 89 
Registering on NIEM.gov ................................................................................................... 89 
Justice Information Exchange Model (JIEM) Tool ............................................................. 89 
Universal Modeling Language (UML) Tools ....................................................................... 90 
Searching and Navigating the NIEM Model ...................................................................... 91 
NIEM Data Model Browser .................................................................................... 91 
Alternate Model Formats ....................................................................................... 92 
NIEM Wayfarer ...................................................................................................... 93 
Subset Schema Generation Tool (SSGT) ................................................................. 94 
Map Information Exchange ............................................................................................... 98 
Creating an Exchange ............................................................................................ 99 
Mapping an Exchange.......................................................................................... 101 
Generating Artifacts ............................................................................................. 103 
Component Mapping Template (CMT) ........................................................................... 105 
Building Schema Subset .................................................................................................. 105 
Generating Documents Page ............................................................................... 107 
SSGT Options Page ............................................................................................... 107 
XML Development Tools ................................................................................................. 109 
Working With IEPDs ........................................................................................................ 109 
Searching the IEPD Repository ............................................................................. 110 
My IEPDs .............................................................................................................. 110 
Creating a NIEM IEPD........................................................................................... 111 
Uploading a NIEM IEPD ........................................................................................ 115 
Generating a Code List Schema ....................................................................................... 115 
Migration Assistance Tool (MAT) .................................................................................... 116 
Best Practices .................................................................................................................. 119 
Appendix C: NIEM Resources ............................................................................................. 120 
NISS Help Desk and Knowledge Base .............................................................................. 120 
NIEM Web Site ................................................................................................................ 121 
IEPD Clearinghouse ......................................................................................................... 121 
IEPD Clearinghouse Benefits and Features .......................................................... 121 
NIEM Training .................................................................................................................. 121 
NIEM Documents ............................................................................................................. 122 
Appendix D: Changes in NIEM Constructs Versus GJXDM 3.0.3 Constructs ...................... 123 
Associations in NIEM Versus Associations in GJXDM ...................................................... 123 
Roles in NIEM Versus Roles in GJXDM............................................................................. 124 
Metadata in NIEM Versus Metadata in GJXDM .............................................................. 125 
Appendix E: Glossary of Terms and Acronyms................................................................... 127 
Glossary of Terms ............................................................................................................ 127 
Glossary of Acronyms ...................................................................................................... 140 
Appendix F: NIEM 2.0 Reference Schemas ........................................................................ 145 

List of Figures 

Figure 1: NIEM at 50,000 Feet. ................................................................................................ 9 
Figure 2: NIEM Core and Domains. ........................................................................................ 10 
Figure 3: XML Schema Fragment Illustrating the Definition of nc:PersonType. .................... 15 
Figure 4: XML Instance Fragment Illustrating the Use of nc:PersonType. ............................. 15 
Figure 5: Diagram Depicting nc:PersonType. ......................................................................... 15 
Figure 6: Diagram Depicting nc:AssessmentPerson. .............................................................. 16 
Figure 7: XML Schema Fragment Illustrating j:DriverLicenseDrivingIncidentAssociationType. 
.............................................................................................................................. 16 
Figure 8: XML Schema Fragment Illustrating the Definition of nc:AssessmentType. ............ 17 
Figure 9: Use of nc:PersonFullName as a Content Element in PersonNameType. ................ 17 
Figure 10: XML Instance Showing the Use of Content Element. ............................................ 18 
Figure 11: Use of Reference Element nc:PersonFullNameReference. ................................... 18 
Figure 12: XML Instance Showing Use of a Reference Element. ........................................... 18 
Figure 13: Diagram Illustrating the Definition of nc:ActivityPersonAssociationType. ........... 19 
Figure 14: XML Schema Fragment Illustrating the Definition of s:ComplexObjectType and 
s:ReferenceType. .................................................................................................. 20 
Figure 15: XML Schema Fragment Illustrating nc:ActivityType and the Element 
nc:ActivityReference. ............................................................................................ 21 
Figure 16: XML Schema Fragment Illustrating nc:PersonType and the Element 
nc:PersonReference. ............................................................................................. 22 
Figure 17: XML Schema Fragment Illustrating nc:AssociationType and 
nc:ActivityPersonAssociationType. ....................................................................... 23 
Figure 18: XML Schema Fragment Illustrating j:IncidentInvestigatorAssociation. ................ 23 
Figure 19: XML Instance Fragment Illustrating the Use of j:IncidentInvestigatorAssociation. 
.............................................................................................................................. 24 
Figure 20: Example of Valid XML Instance Containing Errors. ............................................... 25 
Figure 21: Example of Person Role. ....................................................................................... 25 
Figure 22: j:MissingPersonType as a Role of nc:PersonType. ................................................ 25 
Figure 23: XML Schema Fragment Illustrating j:MissingPersonType. .................................... 26 
Figure 24: XML Schema Fragment Illustrating j:MissingPersonType. .................................... 27 
Figure 25: XML Schema Fragment Illustrating j:MissingPersonType. .................................... 27 
Figure 26: XML Instance Fragment Illustrating the Use of j:MissingPersonType. ................. 28 
Figure 27: Valid XML Instance Fragment With Error. ............................................................ 28 
Figure 28: Abstract Type-Less nc:LocationState Element. ..................................................... 29 
Figure 29: XML Schema Fragment Illustrating s:SimpleObjectAttributeGroup. .................... 30 
Figure 30: XML Schema Fragment Illustrating nc:LocationState. .......................................... 31 
Figure 31: XML Schema Fragment Illustrating can:CanadianProvinceCodeType. ................. 32 
Figure 32: XML Schema Fragment Illustrating fips_5-2:USStateCodeType. .......................... 33 
Figure 33: XML Instance Fragment Illustrating the Use of 
nc:LocationStateCanadianProvinceCode. ............................................................. 33 
Figure 34: XML Instance Fragment Illustrating the Use of nc:LocationStateFIPS5-
2AlphaCode. .......................................................................................................... 34 
Figure 35: Use of j:PersonAugmentationType. ...................................................................... 34 
Figure 36: XML Schema Fragment Illustrating s:AugmentationType. ................................... 35 
Figure 37: XML Schema Fragment Illustrating nc:PersonType. ............................................. 36 
Figure 38: XML Schema Fragment Illustrating j:PersonAugmentationType. ......................... 36 
Figure 39: XML Schema Fragment Illustrating ext:PersonType. ............................................ 37 
Figure 40: XML Instance Fragment Illustrating the Use of ext:Person. ................................. 37 
Figure 41: XML Schema Fragment Illustrating s:MetadataType. ........................................... 39 
Figure 42: XML Schema Fragment Illustrating j:JusticeMetadataType.................................. 40 
Figure 43: XML Instance Fragment Illustrating the Use of j:JusticeMetadata ........................ 40 
Figure 44: Use of j:JusticeMetadataType. .............................................................................. 40 
Figure 45: Use of External Adapter Type geo:SingleSite LandmarkAddressType. ................. 42 
Figure 46: Definition of External Type addr:MunicipalJurisdiction and addr:USPSPlaceName. 
.............................................................................................................................. 42 
Figure 47: XML Instance Showing the Use of an External Adapter Type. .............................. 43 
Figure 48: Use of Elements From Structures in Reference Schema Documents. .................. 46 
Figure 49: NIEM Components. ............................................................................................... 47 
Figure 50: Definition of nc:PersonReference in NIEM. .......................................................... 48 
Figure 51: Definition of the s:ReferenceTypeNIEM Core. ...................................................... 48 
Figure 52: IEPD Lifecycle. ....................................................................................................... 59 
Figure 53: An Example of a Domain Modeling Spreadsheet. ................................................ 65 
Figure 54: Informal Graphical Model. .................................................................................... 66 
Figure 55: Extract From the Amber Alert Domain Model. ..................................................... 67 
Figure 56: Example of an Amber Alert Mapping Document. ................................................. 69 
Figure 57: Example of Schema Development Process. ........................................................... 73 
Figure 58: The Tools Help Feature Has Been Greatly Enhanced With NIEM 2.0. .................. 89 
Figure 59: Data Model Browser. ............................................................................................ 92 
Figure 60: NIEM Wayfarer Tool With Example Graphical Output. ......................................... 94 
Figure 61: The SSGT Is the Primary Entry Point Into Building NIEM Subset Schemas. .......... 95 
Figure 62: The SSGT Includes a Number of User-Selectable Options to Help Refine Your 
Search.................................................................................................................... 97 
Figure 63: Create an Exchange. .............................................................................................. 99 
Figure 64: Change the Default Exchange Name..................................................................... 99 
Figure 65: Uploading Data Model to Exchange. .................................................................. 100 
Figure 66: Process to Begin Mapping Exchange Elements to NIEM. ................................... 100 
Figure 67: Find Equivalent NIEM Terms. .............................................................................. 101 
Figure 68: More Information Regarding Selected Components. ......................................... 101 
Figure 69: Search for Additional Matches............................................................................ 102 
Figure 70: Comments and Mapping Categories. .................................................................. 103 
Figure 71: Generate Artifacts. .............................................................................................. 104 
Figure 72: Select Component for Subset. ............................................................................ 106 
Figure 73: Generate Documents Page. ................................................................................ 107 
Figure 74: Load a Wantlist or Change Release Versions on the SSGT Options Page. .......... 108 
Figure 75: Search, Edit, Create, or Upload an IEPD From the Overview Screen. ................. 110 
Figure 76: Review and Edit Artifacts. ................................................................................... 110 
Figure 77: Code List Template. ............................................................................................. 116 
Figure 78: Code List Generation Tool. .................................................................................. 116 
Figure 79: Select a Wantlist File and Version to Migrate. .................................................... 117 
Figure 80: Migration Summary. ........................................................................................... 118 
Figure 81: Example of GJXDM Property Represented as a Content Element. ..................... 123 
Figure 82: Example of GJXDM Property Represented as a Reference Element. ................. 123 
Figure 83: GJXDM XML Schema Fragment Illustrating the Definition of j:ActivityType. ..... 124 
Figure 84: Definition of j:MissingPersonType. ..................................................................... 124 
Figure 85: GJXDM XML Schema Fragment Illustrating the Definition of j:MissingPersonType. 
............................................................................................................................ 125 
Figure 86: XML Schema Fragment Illustrating the Definition of j:SuperType in GJXDM. .... 126 



List of Tables 

Table 1: About This Document. ................................................................................................ 3 
Table 2: Comparison of Terminology in the NIEM Data Model, XML, and UML. .................. 14 
Table 3: Content Definition Namespace. ............................................................................... 47 
Table 4: NIEM Core Namespace............................................................................................. 49 
Table 5: Emergency Management Domain. ........................................................................... 53 
Table 6: Immigration Domain. ............................................................................................... 53 
Table 7: Intelligence Domain. ................................................................................................ 54 
Table 8: Infrastructure Protection Domain. ........................................................................... 54 
Table 9: International Trade Domain. .................................................................................... 55 
Table 10: Justice Domain. ...................................................................................................... 55 
Table 11: People-Screening Domain. ..................................................................................... 56 
Table 12: Scenario Planning Tasks. ........................................................................................ 63 
Table 13: Requirements Analysis Tasks. ................................................................................ 68 
Table 14: Map and Model Tasks. ............................................................................................ 70 
Table 15: Build and Validate Tasks. ......................................................................................... 78 
Table 16: Assemble and Document Tasks. .............................................................................. 79 
Table 17: Publish and Implement Steps.................................................................................. 80 
Table 18: Data Harmonization and Promotion. ...................................................................... 80 
Table 19: IEPD Artifacts. ......................................................................................................... 82 
Table 20: IEPD Metadata. ...................................................................................................... 84 
Table 21: List of NIEM Tools. .................................................................................................. 88 



1 Acknowledgements 1 

The Bureau of Justice Assistance (BJA) 
and the NIEM Project Management Office 
(PMO) would like to thank the many 
individuals who contributed to the 
development of this document. 
This User Guide would not have been 
possible without the tremendous amount of 
work and assistance of all the authors, editors, 
and volunteer reviewers. BJA and the NIEM 
PMO are especially grateful to members of the 
following committees and organizations for 
their collaborative efforts: 

. 
Georgia Tech Research 
Institute (GTRI) 
. 
Global Justice Information 
Sharing Initiative (Global), 
XML Structure Task Force 
. 
IJIS Institute XML Advisory 
Committee 
. 
National Center for State 
Courts (NCSC) 
. 
NIEM PMO Committee 
Members and Volunteers 
. 
SEARCH, The National 
Consortium for Justice 
Information and Statistics 
. 
U.S. Department of 
Homeland Security (DHS) 


 


NIEM User Guide Development Team 
Mr. Philip Ardire 
Tetrus Consulting 
Ms. Carrie Boyle 
Bearingpoint 
Ms. Andrea Cafarelle 
Tetrus Consulting 
Mr. Tom Carlson 
Tom Carlson Consulting 
Mr. Scott Chontow 
Bearingpoint 
Mr. Donald Gabbin 
IJIS Institute 
Mr. Ashwini Jarral 
IJIS Institute 
Mr. Chandra Jonelagadda 
Tetrus Consulting 
Mr. Vivek Misra 
URL Integration 
Ms. Lisa Neal 
IJIS Institute 
Mr. Prem Neelakanta 
Analyst International 
Mr. Vipul Patel 
IJIS Institute 
Ms. Catherine Plummer 
Information Sharing LLC 
Mr. Sharad Rao 
Tetrus Consulting 
Mr. Dave Usery 
URL Integration 




 2 


2 Introduction 3 

The National Information Exchange Model (NIEM) is a partnership of the U.S. Department 4 
of Justice (DOJ) and the U.S. Department of Homeland Security (DHS). It is designed to develop, 5 
disseminate, and support enterprise-wide information sharing standards and processes, 6 
providing a framework for communities of interest throughout the nation to collaborate and 7 
share critical information effectively. NIEM enables information sharing across all levels of 8 
government, including Federal, state, local, and Tribal governments, and is supportive of both 9 
day-to-day operations and real-time emergency situations.1 10 
The NIEM User Guide Volume I provides detailed guidance about how to develop 11 
information exchanges utilizing this model. It provides a detailed description of the rationale for 12 
the creation of NIEM, an architectural overview, and technical concepts derived from NIEM 13 
Program Management Organization (PMO) documentation. This volume takes the reader 14 
further into a methodology for defining the business requirements of the information exchange, 15 
as well as creating an Information Exchange Package Documentation (IEPD) that fully specifies 16 
the exchange in conformance with NIEM guidelines. Also included is information about tools to 17 
assist development, resources for education and peer assistance, emerging technologies and 18 
how they relate to NIEM, and the national partners that bring it all together. 19 
The primary audience for this document is engineers and developers who intend to use the 20 
NIEM standard to support interagency information sharing. The reader is expected to have an 21 
understanding of the concepts of object oriented design, UML, and XML technologies. 22 
This NIEM User Guide consists of the following sections: 23 

1 http://www.niem.gov/whatIsNiem.php. 

Section 

Description 

1 

Acknowledgements 

This section lists the individuals and agencies that were 
involved in the creation of the NIEM User Guide. 

2 

Introduction 

This section provides an overview of the document and 
describes the notations used throughout. 

3 

The Need for Information Sharing 

This section provides an overview of the need for 
information sharing, some key concepts required for 
information sharing and an overview of NIEM. 

4 

NIEM Overview 

This section provides an overview of the NIEM data model. 

5 

NIEM Data Model Concepts 

NIEM Data Model Concepts 

This section discusses data model concepts of the NIEM 
model. It details types, properties, namespaces, and other 
concepts in NIEM. 

6 

NIEM Data Model Content 

This section describes the content of the NIEM data model. 
It identifies the current domains that the NIEM data model 
covers. 

7 

Building NIEM-Conformant Data 
Exchanges 

This section discusses the suggested methodology for 
building NIEM-conformant data exchanges. 

8 

IEPD Artifacts 

This section identifies the artifacts that may be produced as 
a result of an IEPD development. 

9 

IEPD Metadata 

This section defines the metadata that must be created to 
enable this IEPD to be discovered by other individuals when 
they search the IEPD repository. 




Section 

Description 

Appendix A: Data Model Conformance 
Guidelines 

This appendix discusses the conformance guidelines for 
NIEM. 

Appendix B: NIEM Tools 

This appendix discusses the tools available to the reader to 
develop NIEM-conformant IEPDs. 

Appendix C: NIEM Resources 

This appendix discusses the resources that are available to 
the reader for obtaining additional information about NIEM. 

Appendix D: NIEM Constructs vs. GJXDM 
Constructus 

This appendix briefly demonstrates some differences 
between the NIEM and GJXDM constructs. 

Appendix E: Glossary of Terms and 
Acronyms 

 

This appendix provides definitions for terms and acronyms 
that appear in bold throughout this document. 

Appendix F: NIEM 2.0 Reference Schemas 

This appendix presents the code lists and external schemas 
that are utilized in NIEM. 



Table 1: About This Document. 24 

2.1 Typographical Conventions Used in This Document 25 

Throughout this document, the following typographical conventions provide you with clues 26 
as to the significance or context of the material being discussed. 27 

. This is an alert. When you see information presented in this manner, pay special 28 
attention—information presented in this manner is critical to your understanding of 29 
the concept being discussed. 30 


 31 

. This is a note. Information presented in this manner is important but not critical to your 32 
understanding of the concept being discussed. 33 


 34 
35 
Example code appears in this typeface. 36 
37 
38 


3 The Need for Information Sharing 39 

Information sharing involves the business processes, policies, procedures, architecture, and 40 
governance that support effective decision-making and mission-focused actions by providing 41 
timely, accurate, and relevant information to the appropriate individuals across all levels of 42 
government. Essentially, it is this need that makes the business case for the creation and use of 43 
a standard such as NIEM. 44 
A variety of emergency situations in recent years have demonstrated the potentially tragic 45 
consequences that can result from the inability of jurisdictions and agencies to effectively share 46 
information. Terrorist attacks, natural disasters, and large-scale organized criminal incidents 47 
serve as case studies that reveal weaknesses in our nation’s information sharing capabilities. 48 
Moreover, enterprise-wide information sharing is also required to support the critical day-to-49 
day operations of federal, state, local, and tribal officials. 50 
Current information collection and dissemination practices have not been planned as part 51 
of a unified national strategy but, rather, have evolved incrementally over time to meet specific 52 
one-off challenges as they have surfaced. Agencies are often unable to effectively share 53 
information in a timely, secure manner, and there can be fundamental differences in the nature 54 
and understanding of information that can be shared between agencies. While sharing does 55 
occur today, it often occurs to a limited degree, or within stovepipe information systems. A 56 
tremendous quantity of information that should be shared is still not effectively done, nor is this 57 
information utilized effectively among relevant communities of interest (COIs). 58 

3.1 Challenges to Information Sharing 59 

Previous efforts to improve this situation have been beset by a multitude of challenges. 60 
These challenges include: 61 

. 
Stovepipe information systems leading to inability to connect the dots. 62 
Independent agencies have separate data systems, funding streams, and chains 63 
of command. This separation of data and ownership can obscure relationships 64 
and inhibit the ability of law enforcement, justice and public safety, and 65 
homeland security officials to have the right information at the right time to 66 
assist in proper decision making. By providing these leaders with the 67 
technology framework to share information, the nation’s capacity to combat 68 
crime and terrorism, as well as improve the administration of justice and 69 
homeland security, can be greatly improved. 70 
. 
Large number of organizations at the Federal, State, Local and Tribal levels 71 
including the private section. There are a large number of jurisdictions at the 72 
public level as well the private level with disparate information systems, 73 
governance and activities that need to share information. The sheer number 74 
of organizations and their autonomous nature engender inconsistent policies, 75 
practices, and systems, thereby making coordination more difficult. 76 
. 
Lack of consistent policies and practices. Information sharing practices and 77 
policies often vary from agency to agency with respect to such issues as privacy 78 
protection, security, data quality control, and access. These inconsistent 79 
approaches combined with lack of advised memoranda of understanding 80 



(MOUs) in place make it difficult—and sometimes illegal—to share information 81 
with other agencies. 82 
. 
Lack of common standards for the description and definition of data and 83 
information. Without common standards, data is developed and used within 84 
information systems in a myriad of different ways, causing data duplication, 85 
increasing inaccuracies, and making information usage and alignment across 86 
jurisdictions very difficult. In addition, the consistent definition of the 87 
sensitivity level or classification of data is often lacking across potential 88 
partners, inhibiting confidence in the sharing of secure and protected 89 
information. 90 
. 
Interagency mistrust. As a result of inconsistent policies and practices, those 91 
who do share sensitive information cannot always be sure how it will be used, 92 
whether it will be protected, how it will be disseminated to a third party, and 93 
who will ultimately have access to it. 94 
. 
Categorization of otherwise shareable information into non-shareable 95 
categories. Another barrier to information sharing is created when 96 
information that should be categorized as shareable is categorized in a way 97 
that prevents it from being shared. This is primarily due to the lack of 98 
department-wide training and awareness strategy with regard to information 99 
handling. 100 
. 
Privacy with regard to information sharing. Ethical and legal obligations 101 
compel every professional in the justice system to protect privacy interests 102 
when sharing justice information. Today, increased security needs not only 103 
dictate enhanced justice information sharing but also highlight the need to 104 
balance privacy protection and justice information access. The ease of digital 105 
access now makes analysis of privacy obligations a more complex process. 106 
Nonetheless, the underlying foundations for privacy policy exist in our current 107 
laws and customs. Constitutions, statutes, regulations, policies, procedures, 108 
and common law requirements still control justice entity collection and sharing 109 
of information. What is new is the need for justice practitioners to articulate 110 
the rules that control their information gathering and sharing activities in a 111 
manner that both supports information sharing and protects constitutional 112 
privacy rights. 113 
. 
Lack of coordination on information sharing efforts. In many cases, regional 114 
information sharing initiatives have not been coordinated with one another or 115 
with their federal partners and vice versa. Since the terrorist attacks of 116 
September 11, 2001, the President and Congress have sought to address these 117 
challenges by mandating information sharing through various Executive Orders 118 
and by directing agencies to increase cooperation and sharing, especially as it 119 
relates to critical information that affects the security of the homeland. 120 


3.2 Information Sharing Architectures 121 

The Information sharing architectures that have been developed provide the framework 122 
for coordinating business processes, information exchanges, technology components, and 123 
performance metrics in relation to information sharing. These include the Federal Enterprise 124 
Architecture (FEA), the Justice Reference Architecture (JRA) developed by the Global 125 


Infrastructure and Standards Working Group (GISWG), the ISE Enterprise Architecture 126 
Framework (EAF) developed by the Program Manager for the Information Sharing Environment 127 
(PM-ISE). 128 
These architectures support the sharing of information. NIEM is not a competitor to those 129 
activities, but rather complements them as a method used to implement the data exchange 130 
layer within these architectures. 131 


4 NIEM Overview 132 

NIEM, as a platform for information sharing, is based on eXtensible Markup Language 133 
(XML). XML is a structured language for describing information being sent electronically by one 134 
entity to another. XML schema defines the rules and constraints for the characteristics of the 135 
data, such as structure, relationships, allowable values, and data types. 136 
XML is: 137 

. 
In-text format, readable by both machines and humans 138 
. 
license-free 139 
. 
platform-independent 140 
. 
well-supported by industry 141 


XML specifications2 are guided by the W3C standards. 142 
The NIEM data model is represented in XML but provides specialized XML tag names and 143 
other structure for data that is constrained to meet the specific information exchange 144 
requirements of the justice and homeland security domains. In other words, NIEM utilizes XML 145 
to provide a concise and defined vocabulary for sharing critical information throughout the 146 
nation. This is true regardless of whether the agency sharing the information is local, state, 147 
tribal, or federal and regardless of whether the information is exchanged horizontally or 148 
vertically within existing or emerging systems. 149 

2 http://www.w3.org/XML/. 

. NIEM provides a common language with which federal, state, local, and tribal agencies 150 
can describe, structure, and share critical information in both emergency and routine 151 
situations. NIEM is designed to facilitate information exchange among different 152 
domains, such as justice, public safety, emergency and disaster management, 153 
intelligence, and homeland security. NIEM makes this possible by providing the data 154 
standards and exchange development methods for defining these cross-domain 155 
exchanges. 156 


 157 

158 


4.1 Background 159 

DOJ and DHS launched the NIEM program on February 28, 2005. Among other 160 
requirements, NIEM complies with Homeland Security Presidential Directive-5 (HSPD-5),3 which 161 
assigns the Secretary of Homeland Security the role of principal federal official for domestic 162 
incident management. The Homeland Security Act of 20024 charges the Secretary with the 163 
responsibility for coordinating federal operations within the United States to prepare for, 164 
respond to, and recover from terrorist attacks, major disasters, and other emergencies. The 165 
Intelligence Reform and Terrorism Prevention Act of 2004 (IRTPA)5 was signed into law in 166 
December 2004, and in 2005, Executive Order 133886 was issued by the President. These acts 167 
and the administrative direction require U.S. government organizations to strengthen the 168 
sharing of terrorism information between organizations and appropriate authorities of local and 169 
state governments and protect the ability of organizations to acquire this additional 170 
information. 171 

3 http://www.fas.org/irp/offdocs/nspd/hspd-5.html. 
4 http://www.dhs.gov/xlibrary/assets/hr_5005_enr.pdf. 
5 http://travel.state.gov/pdf/irtpa2004.pdf. 
6 http://www.fas.org/irp/offdocs/eo/eo-13388.htm. 

4.2 The Evolution of NIEM 172 

In the late 1990s, the state and local criminal justice community began to focus on sharing 173 
information rapidly and effectively to serve a variety of public safety needs. The advent of XML 174 
provided the technology with which information could be exchanged more efficiently and cost 175 
effectively. The Global Justice XML Data Model (GJXDM) vocabulary was derived from user 176 
requirements and was driven from the “bottom up” by active practitioners in the justice and 177 
public safety fields. The unique development approach taken with GJXDM provided an 178 
opportunity for national organizations to assist and support the process of sharing critical justice 179 
information where that information originates—at the state, local, and tribal levels. 180 
GJXDM demonstrated the value of information sharing and helped promote the business 181 
case for NIEM, which now extends that concept on a national level. NIEM includes not only the 182 
Justice (JXDM) domain but also represents others, such as intelligence, emergency 183 
management, immigration, infrastructure protection, international trade, and screening. NIEM 184 
actively encourages federal agency participation while continuing to support state and local 185 
requirements and interoperability standards. NIEM provides component-based resources that 186 
are reusable and portable to any organization or platform. 187 
Today, the stated objectives of the NIEM PMO are to: 188 

. 
Bring stakeholders together to identify information sharing requirements for 189 
operational and emergency situations. 190 
. 
Maintain a National Data Model and Reference Vocabulary containing common 191 
and domain-specific data components that pertain to agency information 192 
needs to facilitate development of discrete information exchanges. 193 



. 
Develop standards, a common vocabulary, and an online repository of 194 
exchange standards to support information sharing. 195 


Developing and implementing NIEM-based exchanges allows agencies to leverage existing 196 
investments in information systems by building the bridges to connect them. NIEM standards 197 
enable different information systems to share and exchange information, irrespective of the 198 
particular technologies in use in those information systems. Moreover, creating and adopting 199 
NIEM standards means that local, state, tribal, and federal organizations can reap significant 200 
cost benefits through adoption and reuse, rather than building proprietary, single-use software 201 
from scratch. The fact that NIEM requirements are driven from the user community rather than 202 
a Federal mandate paves the way for faster adoption, and more closely aligned outcomes 203 
between the NIEM PMO and its constituents. 204 

4.3 NIEM Data Model 205 

The NIEM data model provides the reference vocabulary for consistent and reusable intra- 206 
and interdomain information exchanges. The structure and meaning of NIEM data are defined 207 
by the model and dictionary and are represented as XML schema, thereby providing a common 208 
framework for information exchange. As part of the NIEM 2.0 release, the model can also be 209 
viewed as a spreadsheet7 or in a database format. 210 
The fundamental building block of NIEM is a data component. Data components are the 211 
basic business data items that describe common concepts used in general business activities. 212 
213 

7 http://www.niem.gov/topicIndex.php?topic=spreadsheet. 

Figure 1: NIEM at 50,000 Feet. 214 

Figure 1 illustrates that NIEM is modeled to be able to describe people, places, things, and 215 
events and the relationships between all of them at different points in time. 216 
By far, activity makes up the bulk of the model, with person information coming in second. 217 
While each of these categories represents a stand-alone entity, each is structured such that it 218 
can also be associated with other categories. 219 

220 


The NIEM architecture consists of two sets of vocabularies—NIEM Core and the individual 221 
NIEM domains. NIEM Core includes Universal (U) and Common (C) components. The identities 222 
for U and C components in NIEM Core are maintained with metadata. Universal data 223 
components are concepts that are commonly understood across all business domains, such as 224 
dates, times, and locations. They do not have to appear in every exchange and do not have to 225 
apply all the time—they simply have to be well-defined and well-known enough to be 226 
understood by all (or the majority of) domains. Common data components, on the other hand, 227 
are used in exchanges between two or more domains but not universally shared. 228 

By contrast, the individual NIEM domains contain domain-specific data components. As 229 
illustrated in Figure 2, the domains of Emergency Management, Justice, Infrastructure 230 
Protection, Intelligence, International Trade, and Immigration are currently participating in 231 
NIEM. Additional domains will be added as policy evolves and operational requirements 232 
emerge. 233 
234 
235 

 236 

Domain-Specific 
Items with semantic 
meaning relevant primarily 
to their own domain. 

NIEM Core and Structures 
Items that exist and have same 
semantic meaning across all or 
several domains. 

Figure 2: NIEM Core and Domains. 237 
As of version 2.0, NIEM consists of 3,985 data elements and 777 data types. The elements 238 
are grouped into namespaces—NIEM Core or one of the seven domains. 239 


These core components are commonly understood and their meanings are agreed to by 240 
many, if not all, domains. The standardization of these core components provides significant 241 
potential for increased interoperability among and between justice and public safety 242 
information systems. Standardization in this manner provides each of us with functionally 243 
equivalent or interchangeable components of the system or process in which they are used, 244 
regardless of our individual system differences. 245 
The data model and dictionary are combined into one database—a component 246 
repository—which allows the consistent generation of several products that can be consumed 247 
by the sharing community: 248 

. 
The NIEM schema 249 
. 
Numerous external code table schemas 250 
. 
A NIEM documentation spreadsheet 251 


It is recommended that new users acquaint themselves with the NIEM Component 252 
Mapping Tool (CMT) spreadsheet,8 which is provided as a Microsoft Excel file for easy 253 
navigation. The NIEM CMT spreadsheet provides all the element names organized hierarchically 254 
under the domains (NIEM Core, Emergency Management, Justice, etc.) with hyperlinks to 255 
related elements. The spreadsheet also provides information as to the type of data being 256 
represented (date, integer, Boolean, string, etc.) and a precise definition of each dictionary 257 
component. The definitions represent a commitment to provide reusable components that 258 
mean the same thing to all domains. 259 

 8 http://www.niem.gov/topicIndex.php?topic=spreadsheet. 

 9 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=1758. 

4.4 Design Criteria for NIEM 260 

The primary goal for NIEM has been to develop a common set of reusable, extensible XML 261 
data components that could be combined in documents, transactions, and messages that are 262 
consistently structured to support interoperability between systems. The following design 263 
criteria were used in the development of NIEM: 264 

. 
NIEM should be constructed from actual functional requirements, reference 265 
documents, use cases, and business-context components. 266 
. 
An object-oriented data model, named types, and extensions are best suited to 267 
the goals of interagency information exchange. 268 
. 
The composition of the data dictionary should be over-inclusive and optional to 269 
allow users to pick and choose appropriate building blocks for their data 270 
exchanges. 271 
. 
NIEM element and attribute tag names should be based on relevant 272 
international standards for electronic data exchange, especially ISO/IEC 11179-273 
5:1995—Specification and Standardization of Data Elements9, as discussed in 274 
the NIEM Naming and Design Rules (NDR). Additional source standards 275 
include, but are not limited to: 276 



. 
W3C XML Schema Specification and RDF and RDF Schema Specification.10 277 
. 
The Federal CIO Council Draft Federal XML Schema Developer’s Guide.11 278 
. 
UN/CEFACT ebXML Core Components Technical Specification 2.01.12 279 
. 
Dublin Core Metadata for Documents.13 280 
. 
U.S. Department of Defense 5015.02-STD Design Criteria Standard for 281 
E-RMS Applications.14 282 
. 
The OASIS XML Common Biometrics Format.15 283 
. 
The ASC X12 Reference Model for XML Design.16 284 
. 
NIEM continues to evolve, so the data model must facilitate change and 285 
extension as required. 286 
. 
Extension methods should comply with NIEM Naming and Design Rules 287 
(NDR)17 to minimize the impact on prior schema and code investments by 288 
practitioners and developers. 289 
. 
NIEM must provide migration paths for evolution to new technologies, such as 290 
Resource Description Framework (RDF) and Web Ontology Language (OWL).18 291 


10 http://www.w3.org/XML/Schema#dev. 

11 http://www.xml.gov/documents/in_progress/developersguide.pdf. 

12 http://www.unece.org/cefact/ebxml/CCTS_V2-01_Final.pdf. 

13 http://dublincore.org/documents/. 

14 http://www.dtic.mil/whs/directives/corres/pdf/501502std.pdf. 

15 http://www.oasis-open.org/committees/download.php/3353/oasis-200305-xcbf-specification-1.1.doc. 

16 http://www.x12.org/x12org/xmldesign/X12Reference_Model_For_XML_Design.pdf. 

17 http://niem.gov/topicIndex.php?topic=file-NDR-withoutLineNum. 
18 RDF and OWL are semantic Web standards that provide a framework for asset management, enterprise 
integration, and the sharing and reuse of data on the Web. 

NIEM provides a mechanism through which standards for information exchange can be 292 
defined with a high degree of granularity. 293 


5 NIEM Data Model Concepts 294 

5.1 An Introduction to Modeling Concepts 295 

NIEM is a standardized data model and a reference vocabulary implemented in XML 296 
schema. The NIEM data model states exactly and explicitly the meaning of a given concept or 297 
relationship. Accordingly, an XML instance that conforms to the NIEM XML schema also has 298 
specific meaning. The purpose of NIEM is to provide a standard—but extensible—format for 299 
use in the exchange of information between information systems. 300 
NIEM employs several constructs that address common concerns in the design of data 301 
models that represent information being exchanged between software systems. 302 

. 
Types and Properties: Representations of the physical and conceptual things 303 
being communicated. 304 
. 
Container Elements: Elements whose presence in types represents 305 
semantically weak relationships. 306 
. 
Content Elements and Reference Elements: Two semantically equivalent ways 307 
to represent the properties of a type. 308 
. 
Associations: Representations of the relationships that a type 309 
(e.g., “PersonType”) has with other types (e.g., “VehicleType,” “ActivityType”) 310 
that do not create duplicate copies of the type in question (“PersonType”). 311 
. 
Roles: Representations of the different roles (e.g., “VictimType,” 312 
“WitnessType”) that a type (e.g., “PersonType”) plays in its relationships with 313 
other types (e.g., “IncidentType,” “CaseType”) that do not create multiple, and 314 
possibly conflicting, specializations of the type in question (“PersonType”). 315 
. 
Code Lists: Generic representations of enumerated code values of a type. 316 
. 
Augmentation: Representation of a reusable bundle of properties 317 
(e.g., “PersonAugmentationType” containing properties “DriverLicense,” 318 
“PersonFootPrint,” etc.) for the purpose of augmenting the definition of an 319 
existing type (e.g., “PersonType”) that does not create multiple, and possibly 320 
conflicting, specializations of the type in question (“PersonType”). 321 
. 
Metadata: Representation of metadata of types in a flexible and extensible 322 
manner. 323 
. 
External Adapter Types: Usage of non-NIEM types in a NIEM-conformant 324 
schema. 325 


Each of the above-mentioned constructs comes with a prescribed mechanism to follow 326 
when designing NIEM-conformant XML schema types and when using elements of those types 327 
in XML instances. This chapter describes and exemplifies these constructs and mechanisms. 328 

329 


5.2 Expressing Object-Oriented Concepts in XML: Types and Properties 330 

The NIEM data model consists of “types” (of things) that have “properties” and that 331 
participate in “relationships” with other “types” (of things). 332 
A type is a description of a set of things that share the same properties, relationships, and 333 
semantics. For example in NIEM, “PersonType” and “VehicleType” represent persons and 334 
vehicles—kinds of things. 335 
A property is a named characteristic of a type. For example, “PersonBirthDate” is a 336 
property of “PersonType.” Furthermore, the property is of a specific type itself. For example, 337 
”PersonBirthDate” is itself of type “DateType.” 338 
A relationship may be modeled as either a type or a property. For example in NIEM, a 339 
relationship between persons and vehicles is represented by the type 340 
“PersonVehicleAssociationType.” 341 
An object is an instance of a type and is an abstraction of a specific physical thing or a 342 
conceptual thing. Also, in an object, the properties have values. For example, John Smith, a 343 
specific person, would be an object of type “PersonType” with the property “PersonBirthDate.” 344 
Also, for John Smith, the property “PersonBirthDate” may have a value of “1970-01-01.” 345 
An object may have a unique ID within an XML instance, but it is not required to have a 346 
globally unique identifier. The presence of specific objects in an exchange makes the assertions 347 
that: 348 

. 
Objects exist. 349 
. 
Objects have properties. 350 
. 
Objects participate in relationships. 351 


The NIEM data model is explicit, not implicit. If the data says a person’s name is John Smith, 352 
it is not implying that he does not have other names or that John Smith is his legal name or that 353 
he is different from a person known as Bob Jones. The only assertion being made is that one of 354 
the names by which this person is known is John Smith. 355 

As shown in Table 2, types, properties, and objects in the NIEM data model have equivalent 356 
concepts in XML Schema and Unified Modeling Language (UML). 357 

NIEM Data Model 

XML Schema/XML Instance 

UML 

Type 
e.g., “PersonType” 

Complex Type or Simple Type 
e.g., nc:PersonType 

Class 

Property 
e.g., “PersonBirthDate” of type 
“DateType” 

Element or Attribute 
e.g., nc:PersonBirthDate of type nc:DateType 

Attribute 

Object 
e.g., “Person” 

Element or Attribute 
e.g., nc:Person 

Instance/Object 



Table 2: Comparison of Terminology in the NIEM Data Model, XML, and UML. 358 

359 


In XML schema, a type is represented by a Simple Type or a Complex Type. A property is 360 
represented by an attribute or an element. An object is represented by an element in an XML 361 
instance fragment that conforms to the Simple Type or the Complex Type definition. 362 
Consider the following fragment from the NIEM XML schema. The XML schema type 363 
nc:PersonType represents the NIEM Data Model type “PersonType.” The element 364 
nc:PersonBirthDate represents the property “PersonBirthDate.” Finally, the element 365 
nc:AssessmentPerson of nc:PersonType represents an object of “PersonType.” 366 
367 
368 
<xsd:element name="PersonBirthDate" type="nc:DateType" nillable="true"/> 369 
370 
<xsd:complexType name="PersonType"> 371 
… 372 
<xsd:complexContent> 373 
<xsd:extension base="s:ComplexObjectType"> 374 
<xsd:sequence> 375 
… 376 
<xsd:element ref="nc:PersonBirthDate" minOccurs="0" maxOccurs="unbounded"/> 377 
… 378 
</xsd:sequence> 379 
</xsd:extension> 380 
</xsd:complexContent> 381 
</xsd:complexType> 382 
383 
<xsd:element name="AssessmentPerson" type="nc:PersonType" nillable="true"/> 384 
385 

Figure 3: XML Schema Fragment Illustrating the Definition of nc:PersonType. 386 
Next, consider the fragment below, which shows an XML instance containing 387 
nc:AssessmentPerson, where the element nc:PersonBirthDate has a value of “1970-01-01.” 388 
389 
390 
<nc:AssessmentPerson> 391 
… 392 
<nc:PersonBirthDate>1970-01-01</nc:PersonBirthDate> 393 
… 394 
</nc:AssessmentPerson> 395 
396 

Figure 4: XML Instance Fragment Illustrating the Use of nc:PersonType. 397 
In UML, a NIEM Data Model type can be represented by a UML class, a NIEM Data Model 398 
property by a UML attribute, and a NIEM Data Model object by a UML instance. For example, 399 
the NIEM Data Model type “PersonType” can be depicted as follows: 400 
401 
. . .
nc:PersonBirthDate. . .
nc:PersonType

Figure 5: Diagram Depicting nc:PersonType. 402 

403 


In another example, the NIEM data model object “AssessmentPerson” containing the 404 
property “PersonBirthDate” with a value of “1970-01-01” could be depicted as in Figure 6. 405 
406 
. . .
nc:PersonBirthDate = 1970-01-01. . .
nc:AssessmentPerson : nc:PersonType

Figure 6: Diagram Depicting nc:AssessmentPerson. 407 

5.3 Container Elements 408 

There are two levels of semantics that can be associated with the presence of an element 409 
in a type—weak semantics and strong semantics. Consider for example, 410 
j:DriverLicenseDrivingIncidentAssociationType, which represents an association between a 411 
driver’s license and a driving incident and contains an element nc:Person of nc:PersonType. The 412 
presence of the nc:Person element does not establish what kind of relationship exists between 413 
j:DriverLicenseDrivingIncidentAssociationType and nc:PersonType, only that there is a 414 
relationship. This is an example of a semantically weak relationship. In such a case, the element 415 
nc:Person is called a “container element” because it only serves the purpose of containing an 416 
object of nc:PersonType, while leaving the exact meaning unstated. 417 
418 
419 
<xsd:complexType name="DriverLicenseDrivingIncidentAssociationType"> 420 
<xsd:annotation> 421 
<xsd:appinfo> 422 
<i:Base i:namespace="http://niem.gov/niem/niem-core/2.0" 423 
i:name="AssociationType"/> 424 
</xsd:appinfo> 425 
</xsd:annotation> 426 
<xsd:complexContent> 427 
<xsd:extension base="nc:AssociationType"> 428 
<xsd:sequence> 429 
<xsd:element ref="nc:Person" minOccurs="0" maxOccurs="unbounded"/> 430 
<xsd:element ref="nc:DriverLicense" minOccurs="0" maxOccurs="unbounded"/> 431 
<xsd:element ref="j:DrivingIncident" minOccurs="0" maxOccurs="unbounded"/> 432 
… 433 
</xsd:sequence> 434 
</xsd:extension> 435 
</xsd:complexContent> 436 
</xsd:complexType> 437 
438 

Figure 7: XML Schema Fragment Illustrating j:DriverLicenseDrivingIncidentAssociationType. 439 
If you contrast this situation with that of nc:AssessmentType, which represents an 440 
evaluation, appraisal, or assessment of something or someone and contains the element 441 
nc:AssessmentPerson of nc:PersonType, it is clear that the person referenced by the element 442 
nc:AssessentPerson was responsible for an assessment of some type, relevant to the exchange 443 
being modeled. The more descriptive name, nc:AssessmentPerson, makes the relationship 444 
between it and nc:AssessmentType a semantically strong relationship. 445 
446 
<xsd:complexType name="AssessmentType"> 447 


 <xsd:annotation> 448 
<xsd:appinfo> 449 
<i:Base i:name="ActivityType"/> 450 
</xsd:appinfo> 451 
</xsd:annotation> <xsd:complexContent> 452 
<xsd:extension base="nc:ActivityType"> 453 
<xsd:sequence> 454 
… 455 
<xsd:element ref="nc:AssessmentPerson" minOccurs="0" maxOccurs="unbounded"/> 456 
</xsd:sequence> 457 
</xsd:extension> 458 
</xsd:complexContent> 459 
</xsd:complexType> 460 
461 

Figure 8: XML Schema Fragment Illustrating the Definition of nc:AssessmentType. 462 
Note that the concept of “container element” is only notional. There are no formalized 463 
rules about what makes an element a container element. The distinction, however, between 464 
container and noncontainer elements is still useful in identifying the meaning that can be 465 
explicitly associated with the presence of the element in a type. 466 

. One caveat when working with NIEM—When looking for something, do not forget to 467 
look upward through all the parent elements for inherited properties. 468 


5.4 Content Elements and Reference Elements 469 

There are two forms in which an element may be present in a type—as a content element 470 
or as a reference element. A content element occurs in the definition of its containing type. For 471 
example, nc:PersonFullName element occurs as a content element in its containing element 472 
nc:PersonNameType in the following XML schema fragment. 473 
474 
475 
<!-- targetNamespace=”http://niem.gov/niem/niem-core/2.0” . 476 
477 
<xsd:element name="PersonFullName" type="nc:PersonNameTextType" nillable="true"/> 478 
479 
<xsd:complexType name="PersonNameType"> 480 
<xsd:complexContent> 481 
<xsd:extension base="s:ComplexObjectType"> 482 
<xsd:sequence> 483 
… 484 
<xsd:element ref="nc:PersonFullName" minOccurs="0" maxOccurs="unbounded"/> 485 
</xsd:sequence> 486 
… 487 
</xsd:extension> 488 
</xsd:complexContent> 489 
</xsd:complexType> 490 
491 
<xsd:element name="PersonName" type="nc:PersonNameType" nillable="true"/> 492 
493 

Figure 9: Use of nc:PersonFullName as a Content Element in PersonNameType. 494 


The value (“John Smith”) of a content element (nc:PersonFullName) also occurs in-line in its 495 
containing element (nc:PersonName) in an XML instance. The following XML instance fragment 496 
shows this. 497 
498 
499 
<nc:PersonName> 500 
… 501 
<nc:PersonFullName>John Smith</nc:PersonFullName> 502 
</nc:PersonName> 503 
504 

Figure 10: XML Instance Showing the Use of Content Element. 505 
A reference element, on the other hand, is an element that is defined to be of the type 506 
s:ReferenceType. For example, nc:PersonFullNameReference element occurs as a reference 507 
element in its containing type ext:AlternativePersonNameType in the following XML Schema 508 
fragment. 509 
510 
511 
<!-- targetNamespace=”http://cjis.gov/extension/1.0” . 512 
513 
<xsd:element name="PersonFullNameReference" type="s:ReferenceType"/> 514 
515 
<xsd:complexType name="AlternativePersonNameType"> 516 
<xsd:complexContent> 517 
<xsd:extension base="s:ComplexObjectType"> 518 
<xsd:sequence> 519 
… 520 
<xsd:element ref="nc:PersonFullNameReference " minOccurs="0" 521 
maxOccurs="unbounded"/> 522 
</xsd:sequence> 523 
… 524 
</xsd:extension> 525 
</xsd:complexContent> 526 
</xsd:complexType> 527 
528 
<xsd:element name="PersonName" type="ext:AlternativePersonNameType" nillable="true"/> 529 
530 

Figure 11: Use of Reference Element nc:PersonFullNameReference. 531 
The value (“N1”) of the reference element (nc:PersonFullNameReference) in an XML 532 
instance identifies the ID (s:id=”N1”) of the element (nc:PersonFullName) that contains the 533 
desired value (“John Smith”). The following XML instance fragment shows this. 534 
535 
536 
<nc:PersonFullName s:id=”N1”>John Smith</nc:PersonFullName> 537 
538 
<ext:PersonName> 539 
… 540 
<ext:PersonFullNameReference s:ref=”N1”/> 541 
</ext:PersonName> 542 
543 

Figure 12: XML Instance Showing Use of a Reference Element. 544 


In the NIEM data model, content elements and reference elements are semantically 545 
equivalent. 546 

5.5 Associations 547 

An association is a kind of relationship between two or more objects. The objects and the 548 
relationship must have the following characteristics for the relationship to be an association: 549 

. 
The objects must be “peers” of one another. This means that no object is 550 
logically a part of another. In other words, each object can exist independently 551 
of others, and none of the objects lose meaning if separated from one another. 552 
This also means that each object has its own set of properties, which are 553 
independent of the properties of the other objects. 554 
. 
The relationship between the objects may exist only if all the participating 555 
objects exist and it has its own set of properties separate from the properties 556 
of the participating objects. 557 


For example in NIEM, a single or a set of related actions, events, or process steps is 558 
represented by an “ActivityType” and a person is represented by a “PersonType.” Further, the 559 
relationship between an activity and a person, signifying the involvement of the person in the 560 
activity, is represented by “ActivityPersonAssociationType.” 561 

This can be depicted as shown in Figure 13. 562 
563 
s:idnc:ActivityTypes:idnc:PersonTypenc:ActivityReference 
nc:PersonReference 
nc:ActivityPersonAssociationTypenc:AssociationBeginDate 
nc:AssociationEndDate 
nc:AssociationType

Figure 13: Diagram Illustrating the Definition of nc:ActivityPersonAssociationType. 564 
The NIEM XML Schema represents an association as a type that extends 565 
nc:AssociationType. For example, the relationship “ActivityPersonAssociationType” is 566 
represented by nc:ActivityPersonAssociationType, which extends nc:AssociationType. 567 
To demonstrate the definition and use of nc:ActivtyPersonAssociationType, you can 568 
examine the NIEM XML Schema fragments below, which include: 569 

. 
The common components from the Structures namespace 570 
. 
The “Activity”-related components from the NIEM Core namespace 571 



. 
The “Person”-related components from the NIEM Core namespace 572 
. 
The “ActivityPersonAssociation”-related components from the NIEM Core 573 
namespace 574 
. 
The “IncidentInvestigatorAssociation” element from the Justice namespace 575 


Following these is a fragment of an XML instance containing the 576 
j:IncidentInvestigatorAssociation element. 577 
The first XML schema fragment shows the common components that are used directly or 578 
indirectly in the definition of nc:ActivityPersonAssociationType. Most complex types in NIEM 579 
are based on the abstract type s:ComplexObjectType, which contains three attributes. 580 

1. The first attribute, s:id, enables an element to identify itself uniquely within an 581 
XML instance. 582 
2. The second attribute, s:metadata, enables an element to point to metadata 583 
that affects itself. 584 
3. The third attribute, s:linkMetadata, enables an element to point to metadata 585 
that affects the relationship between itself and its context. 586 


 587 
All reference elements within NIEM-conformant schemas are of the type s:ReferenceType. 588 
The s:ref attribute of s:ReferenceType enables an element of s:ReferenceType to point to 589 
another element of a different type. 590 
591 
<!-- Subset schema (Structures namespace) . 592 
<xsd:schema 593 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 594 
xmlns:s="http://niem.gov/niem/structures/2.0" 595 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 596 
targetNamespace=”http://niem.gov/niem/structures/2.0” 597 
…> 598 
… 599 
<xsd:attribute name="id" type="xsd:ID"/> 600 
<xsd:attribute name="ref" type="xsd:IDREF"/> 601 
602 
<xsd:complexType name="ComplexObjectType" abstract="true"> 603 
<xsd:attribute ref="s:id"/> 604 
<xsd:attribute ref="s:metadata"/> 605 
<xsd:attribute ref="s:linkMetadata"/> 606 
</xsd:complexType> 607 
608 
<xsd:complexType name="ReferenceType" final="#all"> 609 
<xsd:attribute ref="s:id"/> 610 
<xsd:attribute ref="s:ref"/> 611 
<xsd:attribute ref="s:linkMetadata"/> 612 
</xsd:complexType> 613 
… 614 
</xsd:schema> 615 
616 

Figure 14: XML Schema Fragment Illustrating the Definition of 617 
s:ComplexObjectType and s:ReferenceType. 618 

The next XML schema fragment shows the definition of the type nc:ActivityType and the 619 
element nc:Activity. It also contains the definition of the element nc:ActivityReference, which 620 


will be used later by the type nc:ActivityPersonAssociationType to refer to the element 621 
nc:Activity. 622 
623 
<!-- Subset schema (NIEM Core namespace) . 624 
<xsd:schema 625 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 626 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 627 
xmlns:s="http://niem.gov/niem/structures/2.0" 628 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 629 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 630 
…> 631 
… 632 
<xsd:complexType name="ActivityType"> 633 
<xsd:annotation> 634 
<xsd:appinfo> 635 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 636 
</xsd:appinfo> 637 
</xsd:annotation> 638 
<xsd:complexContent> 639 
<xsd:extension base="s:ComplexObjectType"> 640 
<xsd:sequence> 641 
… 642 
<xsd:element ref="nc:ActivityName" minOccurs="0" maxOccurs="unbounded"/> 643 
… 644 
</xsd:sequence> 645 
</xsd:extension> 646 
</xsd:complexContent> 647 
</xsd:complexType> 648 
649 
<xsd:element name="Activity" type="nc:ActivityType" nillable="true"/> 650 
651 
<xsd:element name="ActivityReference" type="s:ReferenceType"> 652 
<xsd:annotation> 653 
<xsd:appinfo> 654 
<i:ReferenceTarget i:name="ActivityType"/>v 655 
</xsd:appinfo> 656 
</xsd:annotation> 657 
</xsd:element> 658 
… 659 
</xsd:schema> 660 
661 

Figure 15: XML Schema Fragment Illustrating nc:ActivityType 662 
and the Element nc:ActivityReference. 663 
The following XML schema fragment shows the definitions of the type nc:PersonType and 664 
the element nc:Person of that type. It also contains the definition of the element 665 
nc:PersonReference of s:ReferenceType. This element will be used later by 666 
nc:ActivityPersonAssociationType to refer to the nc:Person element. 667 
668 
669 
<!-- Subset schema (NIEM Core namespace) . 670 
<xsd:schema 671 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 672 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 673 
xmlns:s="http://niem.gov/niem/structures/2.0" 674 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 675 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 676 
…> 677 
… 678 
<xsd:complexType name="PersonType"> 679 


 <xsd:annotation> 680 
<xsd:appinfo> 681 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 682 
</xsd:appinfo> 683 
</xsd:annotation> 684 
<xsd:complexContent> 685 
<xsd:extension base="s:ComplexObjectType"> 686 
<xsd:sequence> 687 
… 688 
<xsd:element ref="nc:PersonName" minOccurs="0" maxOccurs="unbounded"/> 689 
… 690 
</xsd:sequence> 691 
</xsd:extension> 692 
</xsd:complexContent> 693 
</xsd:complexType> 694 
695 
<xsd:element name="Person" type="nc:PersonType" nillable="true"/> 696 
<xsd:element name="PersonReference" type="s:ReferenceType"> 697 
<xsd:annotation> 698 
<xsd:appinfo> 699 
<i:ReferenceTarget i:name="PersonType"/> 700 
</xsd:appinfo> 701 
</xsd:annotation> 702 
</xsd:element> 703 
… 704 
</xsd:schema> 705 
706 

Figure 16: XML Schema Fragment Illustrating nc:PersonType 707 
and the Element nc:PersonReference. 708 
The next XML schema fragment shows the definitions of nc:AssociationType and 709 
nc:ActivityPersonAssociationType. The type nc:ActivityPersonAssociationType has properties—710 
nc:AssociationBeginDate and nc:AssociationEndDate inherited from nc:AssociationType—711 
independently of the participating objects activity and person. In addition to these two 712 
properties, the association also has references—nc:ActivityReference and nc:PersonReference—713 
to the activity and person objects participating in the relationship. 714 
715 
716 
<!-- Subset schema (NIEM Core namespace) . 717 
<xsd:schema 718 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 719 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 720 
xmlns:s="http://niem.gov/niem/structures/2.0" 721 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 722 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 723 
…> 724 
… 725 
<xsd:complexType name="AssociationType"> 726 
<xsd:annotation> 727 
<xsd:appinfo> 728 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Association"/> 729 
</xsd:appinfo> 730 
</xsd:annotation> 731 
<xsd:complexContent> 732 
<xsd:extension base="s:ComplexObjectType"> 733 
<xsd:sequence> 734 
<xsd:element ref="nc:AssociationBeginDate" minOccurs="0" 735 
maxOccurs="unbounded"/> 736 
<xsd:element ref="nc:AssociationEndDate" minOccurs="0" maxOccurs="unbounded"/> 737 
</xsd:sequence> 738 


 </xsd:extension> 739 
</xsd:complexContent> 740 
</xsd:complexType> 741 
742 
<xsd:complexType name="ActivityPersonAssociationType"> 743 
<xsd:annotation> 744 
<xsd:appinfo> 745 
<i:Base i:name="AssociationType"/> 746 
</xsd:appinfo> 747 
</xsd:annotation> 748 
<xsd:complexContent> 749 
<xsd:extension base="nc:AssociationType"> 750 
<xsd:sequence> 751 
<xsd:element ref="nc:ActivityReference" minOccurs="0" maxOccurs="unbounded"/> 752 
<xsd:element ref="nc:PersonReference" minOccurs="0" maxOccurs="unbounded"/> 753 
</xsd:sequence> 754 
</xsd:extension> 755 
</xsd:complexContent> 756 
</xsd:complexType> 757 
… 758 
</xsd:schema> 759 
760 

Figure 17: XML Schema Fragment Illustrating nc:AssociationType and 761 
nc:ActivityPersonAssociationType. 762 
The following fragment from the Justice domain namespace shows the definition of the 763 
element j:IncidentInvestigatorAssociation of type nc:ActivityPersonAssociationType. 764 
765 
<!— Extension schema . 766 
<xsd:schema 767 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 768 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 769 
xmlns:s="http://niem.gov/niem/structures/2.0" 770 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 771 
xmlns:j=”http://niem.gov/niem/domains/jxdm/4.0” 772 
targetNamespace=”http://niem.gov/niem/domains/jxdm/4.0” 773 
…> 774 
… 775 
<xsd:element name="IncidentInvestigatorAssociation" 776 
type="nc:ActivityPersonAssociationType" 777 
nillable="true"/> … 778 
</xsd:schema> 779 
780 

Figure 18: XML Schema Fragment Illustrating j:IncidentInvestigatorAssociation. 781 
Finally, the following fragment shows an XML instance that conforms to the definition of 782 
j:IncidentInvestigatorAssociation element. 783 
784 
<nc:Activity id="A1" >Some activity name</nc:Activity> 785 
786 
<nc:Activity id="A2" >Some other activity name</nc:Activity> 787 
788 
<nc:Person id="P1" > 789 
<nc:PersonName> 790 
<nc:PersonGivenName>John</nc:PersonGivenName> 791 
<nc:PersonSurName>Smith</nc:PersonSurName> 792 
</nc:PersonName> 793 
</nc:Person> 794 
795 


<nc:Person id="P2" > 796 
<nc:PersonName> 797 
<nc:PersonGivenName>Jane</nc:PersonGivenName> 798 
<nc:PersonSurName>Doe</nc:PersonSurName> 799 
</nc:PersonName> 800 
</nc:Person> 801 
802 
<j:IncidentInvestigatorAssociation> 803 
<nc:AssociationBeginDate>2007-12-28</nc:AssociationBeginDate> 804 
<nc:ActivityReference s:ref="A1"/> 805 
<nc:PersonReference s:ref="P1"/> 806 
</j:IncidentInvestigatorAssociation> 807 
808 
<j:IncidentInvestigatorAssociation> 809 
<nc:AssociationBeginDate>2007-12-29</nc:AssociationBeginDate> 810 
<nc:ActivityReference s:ref="A1"/> 811 
<nc:PersonReference s:ref="P2"/> 812 
</j:IncidentInvestigatorAssociation> 813 
814 
<j:IncidentInvestigatorAssociation> 815 
<nc:AssociationBeginDate>2007-12-30</nc:AssociationBeginDate> 816 
<nc:ActivityReference s:ref="A2"/> 817 
<nc:PersonReference s:ref="P2"/> 818 
</j:IncidentInvestigatorAssociation> 819 
820 

Figure 19: XML Instance Fragment Illustrating the Use of j:IncidentInvestigatorAssociation. 821 
Since the association is represented by a NIEM type, it (the association) may itself 822 
participate in another association with an object. 823 
The nc:AssociationType and types derived directly or indirectly from it are collectively and 824 
generally referred to as association types. 825 
Note that when associations are used, XML schema validation cannot guarantee a “valid” 826 
XML instance. This is because XML schema can neither ensure that an object reference is valid 827 
nor that it is the correct type. For example, the following XML instance is valid even though it 828 
contains two errors: 829 
The nc:ActivityReference element in the j:IncidentInvestigatorAssociation element points 830 
to a nonexistent nc:Activity element. 831 
The nc:PersonReference element points to an nc:Activity element instead of an nc:Person 832 
element. 833 
XML schema validation can only ensure that s:ref attributes of nc:ActivityReference and 834 
nc:PersonReference elements contain valid XML ID values, not that they are the correct XML ID 835 
values. 836 
837 
<nc:Activity id="A1" >Some activity name</nc:Activity> 838 
839 
<nc:Person id="P1" > 840 
<nc:PersonName> 841 
<nc:PersonGivenName>John</nc:PersonGivenName> 842 
<nc:PersonSurName>Smith</nc:PersonSurName> 843 
</nc:PersonName> 844 
</nc:Person> 845 
846 
<j:IncidentInvestigatorAssociation> 847 
<nc:AssociationBeginDate>2007-12-28</nc:AssociationBeginDate> 848 

 <nc:ActivityReference s:ref="A2"/> <!-- Valid but incorrect: Referencing a non-existent 849 
ID!! . 850 


 <nc:PersonReference s:ref="A1"/> <!—Valid but incorrect: Referencing the ID of a wrong 851 
type of element !! . 852 
</j:IncidentInvestigatorAssociation> 853 
854 

Figure 20: Example of Valid XML Instance Containing Errors. 855 

5.6 Roles 856 

A role is a particular function, purpose, or use of an object. It may be specific to time, 857 
incident, employment, or other aspects of an activity or context. The object to which the role 858 
applies is called the “base object.” 859 
If the base object is referenced only by the role in the NIEM data model, and there are no 860 
additional properties of the role to be modeled, the simplest way to represent the role is to use 861 
an element. The following example represents the role of a person who performs an 862 
assessment. 863 
864 
<xsd:element name="AssessmentPerson" type="nc:PersonType" nillable="true"/> 865 
866 

Figure 21: Example of Person Role. 867 
In many cases, however, there is a need to capture additional information about the role. 868 
In such cases, a new type is created to represent the role and its properties. For example in 869 
NIEM, a person whose whereabouts are unknown is modeled as j:MissingPersonType, which 870 
represents a particular role of nc:PersonType. Additional information about the person specific 871 
to his/her role as a missing person is modeled as the properties of j:MissingPersonType. Such 872 
information may include the date on which and the location at which the person was last seen, 873 
represented as the properties j:MissingPersonLastSeenDate and 874 
j:MissingPersonLastSeenLocation. 875 

Figure 22 illustrates this. 876 
877 
s:idnc:PersonTypenc:RoleOfPersonReference 
j:MissingPersonLastSeenDate 
j:MissingPersonLastSeenLocationj:MissingPersonType

Figure 22: j:MissingPersonType as a Role of nc:PersonType. 878 
To demonstrate the definition and use of j:MissingPersonType, review the NIEM XML 879 
Schema fragments below, which include: 880 

. 
The common components from the Structures namespace 881 
. 
The “Person”-related components from the NIEM Core namespace 882 
. 
The “MissingPerson”-related components from the Justice domain namespace 883 


Following these is a fragment of an XML instance containing the j:MissingPerson element. 884 
The first XML schema fragment shows the common components that are used directly or 885 
indirectly in the definition of j:MissingPersonType. 886 


 887 
<!-- Subset schema (Structures namespace) . 888 
<xsd:schema 889 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 890 
xmlns:s="http://niem.gov/niem/structures/2.0" 891 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 892 
targetNamespace=”http://niem.gov/niem/structures/2.0” 893 
…> 894 
… 895 
<xsd:attribute name="id" type="xsd:ID"/> 896 
<xsd:attribute name="ref" type="xsd:IDREF"/> 897 
898 
<xsd:complexType name="ComplexObjectType" abstract="true"> 899 
<xsd:attribute ref="s:id"/> 900 
<xsd:attribute ref="s:metadata"/> 901 
<xsd:attribute ref="s:linkMetadata"/> 902 
</xsd:complexType> 903 
904 
<xsd:complexType name="ReferenceType" final="#all"> 905 
<xsd:attribute ref="s:id"/> 906 
<xsd:attribute ref="s:ref"/> 907 
<xsd:attribute ref="s:linkMetadata"/> 908 
</xsd:complexType> 909 
… 910 
</xsd:schema> 911 
912 

Figure 23: XML Schema Fragment Illustrating j:MissingPersonType. 913 
The next XML schema fragment shows the definitions of the type nc:PersonType and the 914 
element nc:Person. It also contains the definition of the element nc:RoleOfPersonReference, 915 
which will be used later by the type j:MissingPersonType to refer to the element nc:Person. 916 
917 
<!-- Subset schema (NIEM Core namespace) . 918 
<xsd:schema 919 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 920 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 921 
xmlns:s="http://niem.gov/niem/structures/2.0" 922 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 923 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 924 
…> 925 
… 926 
<xsd:complexType name="PersonType"> 927 
<xsd:annotation> 928 
<xsd:appinfo> 929 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 930 
</xsd:appinfo> 931 
</xsd:annotation> 932 
<xsd:complexContent> 933 
<xsd:extension base="s:ComplexObjectType"> 934 
<xsd:sequence> 935 
… 936 
<xsd:element ref="nc:PersonName" minOccurs="0" maxOccurs="unbounded"/> 937 
… 938 
</xsd:sequence> 939 
</xsd:extension> 940 
</xsd:complexContent> 941 
</xsd:complexType> 942 
943 
<xsd:element name="Person" type="nc:PersonType" nillable="true"/> 944 
945 
<xsd:element name="RoleOf" abstract="true"/> 946 

 947 


 <xsd:element substitutionGroup="nc:RoleOf" name="RoleOfPersonReference" 948 
type="s:ReferenceType"> 949 
<xsd:annotation> 950 
<xsd:appinfo> 951 
<i:ReferenceTarget i:name="PersonType"/> 952 
<i:Base i:name="RoleOf"/> 953 
</xsd:appinfo> 954 
</xsd:annotation> 955 
</xsd:element> 956 
… 957 
</xsd:schema> 958 
959 

Figure 24: XML Schema Fragment Illustrating j:MissingPersonType. 960 
The following fragment from the Justice domain namespace shows the definition of the 961 
element j:MissingPerson of type j:MissingPersonType. 962 
963 
<!-- Subset schema (Justice Domain namespace) . 964 
<xsd:schema 965 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 966 
xmlns:j=”http://niem.gov/niem/domains/jxdm/4.0” 967 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 968 
xmlns:s="http://niem.gov/niem/structures/2.0" 969 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 970 
targetNamespace=”http://niem.gov/niem/domains/jxdm/4.0” 971 
…> 972 
… 973 
<xsd:complexType name="MissingPersonType"> 974 
<xsd:annotation> 975 
<xsd:appinfo> 976 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 977 
</xsd:appinfo> 978 
</xsd:annotation> 979 
<xsd:complexContent> 980 
<xsd:extension base="s:ComplexObjectType"> 981 
<xsd:sequence> 982 
<xsd:element ref="nc:RoleOfPersonReference" minOccurs="0" 983 
maxOccurs="unbounded"/> 984 
… 985 
<xsd:element ref="j:MissingPersonLastSeenDate" minOccurs="0" 986 
maxOccurs="unbounded"/> 987 
<xsd:element ref="j:MissingPersonLastSeenLocation" minOccurs="0" 988 
maxOccurs="unbounded"/> 989 
… 990 
</xsd:sequence> 991 
</xsd:extension> 992 
</xsd:complexContent> 993 
</xsd:complexType> 994 
995 
<xsd:element name="MissingPerson" type="j:MissingPersonType" nillable="true"/> 996 
… 997 
</xsd:schema> 998 
999 

Figure 25: XML Schema Fragment Illustrating j:MissingPersonType. 1000 
Finally, the following fragment shows an XML instance that conforms to the definition of 1001 
j:MissingPerson element. 1002 


 1003 
<nc:Person id="P1" > 1004 
<nc:PersonName> 1005 
<nc:PersonGivenName>John</nc:PersonGivenName> 1006 
<nc:PersonSurName>Smith</nc:PersonSurName> 1007 
</nc:PersonName> 1008 
</nc:Person> 1009 
1010 
<j:MissingPerson> 1011 
<nc:RoleOfPersonReference ref="P1"/> 1012 
<j:MissingPersonLastSeenDate>2007-12-31</j:MissingPersonLastSeenDate> 1013 
… 1014 
</j:MissingPerson> 1015 
1016 

Figure 26: XML Instance Fragment Illustrating the Use of j:MissingPersonType. 1017 
As with associations, it should be noted that when roles are used, XML schema validation 1018 
cannot guarantee a “valid” XML instance. This is because XML schema can neither ensure that 1019 
an object reference is valid nor that it is the correct type. For example, the following XML 1020 
instance is valid even though it contains an error, specifically, the nc:RoleOfPersonReference 1021 
element in j:MissingPerson element points to a nonexistent nc:Person element. XML schema 1022 
validation can only ensure that s:ref attributes of the nc:RoleOfPersonReference element 1023 
contains a valid XML ID value, not that it is the correct XML ID value. 1024 
1025 
<nc:Person id="P1" > 1026 
<nc:PersonName> 1027 
<nc:PersonGivenName>John</nc:PersonGivenName> 1028 
<nc:PersonSurName>Smith</nc:PersonSurName> 1029 
</nc:PersonName> 1030 
</nc:Person> 1031 
1032 
<j:MissingPerson> 1033 
<nc:RoleOfPersonReference ref="A2"/> 1034 
<j:MissingPersonLastSeenDate>2007-12-31</j:MissingPersonLastSeenDate> 1035 
… 1036 
</j:MissingPerson> 1037 
1038 

Figure 27: Valid XML Instance Fragment With Error. 1039 

5.7 Abstract Elements and Substitution Groups 1040 

Substitution groups, abstract elements, and element substitution are XML schema features 1041 
that can be used as means to create an XML schema type that is extensible by an XML instance 1042 
author. 1043 
A substitution group consists of two parts—a single group head element and one or more 1044 
group member elements. In an XML instance, the group head element can be replaced by one 1045 
of the group member elements. If the group head element has a type, then the group member 1046 
elements must be of the same type or of a type derived from that same type. 1047 
When an element is declared to be abstract in XML schema, it cannot be used in an XML 1048 
instance. Instead, a member of that element's substitution group must appear in the XML 1049 
instance. 1050 

NIEM relies on the XML schema feature of element substitution for representing different 1051 
kinds of enumerated code values for a type and for using those code values in an XML instance. 1052 


For example, consider the different kinds of representations and uses of code values 1053 
denoting states or provinces such as Alberta or Minnesota. The NIEM XML Schema identifies a 1054 
province through a value of nc:CanadianProvinceCodeType and a state through a value of 1055 
nc:USStateCodeType. NIEM also defines the abstract type-less element nc:LocationState to 1056 
represent the concept of a province or a state. Because it is abstract, the nc:LocationState 1057 
element cannot appear in an XML instance. Rather, it heads a substitution group, which 1058 
contains elements of eight different types, including the elements 1059 
nc:LocationStateCanadianProvinceCode of the type nc:CanadianProvinceCodeType, and 1060 
nc:LocationStateFIPS5-2AlphaCode of the type nc:USStateCodeType. In the XML instance, the 1061 
nc:LocationState element can be replaced by the nc:LocationStateCanadianProvinceCode 1062 
element or the nc:LocationStateFIPS5-2AlphaCode element. Finally, NIEM also defines the 1063 
element nc:Jurisdiction of the type nc:JurisdictionType. The type nc:JurisdictionType contains 1064 
the element nc:LocationState and represents a geopolitical area in which an organization, a 1065 
person, or an object has a specific range of authority. 1066 

Figure 28 (below) illustrates this example. 1067 

 1068 
Substitution GroupHeadMemberscan:CanadianProvinceCodeSimpleTypefips_5-2:USStateCodeTypefips_5-2:USStateCodeSimpleTypecan:CanadianProvinceCodeTypenc:LocationStateCanadianProvinceCode : can:CanadianProvinceCodeTypenc:LocationStateFIPS5-2AlphaCode : fips_5-2:USStateCodeTypenc:LocationState : <<abstract type-less>>«instance»
«instance»
nc:Jurisdiction : nc:JurisdictionType

Figure 28: Abstract Type-Less nc:LocationState Element. 1069 
To demonstrate the definition and use of nc:CanadianProvinceCodeType and 1070 
nc:USStateCodeType, consider the NIEM XML Schema fragments below, which include: 1071 

. 
The common components from the Structures namespace 1072 
. 
The “Jurisdiction”-related components from the NIEM Core namespace 1073 
. 
The “Province”-related components from the Post Canada namespace 1074 
. 
The “State”-related components from the FIPS 5.2 namespace 1075 


Following these are two fragments of XML instances containing the nc:Jurisdiction element. 1076 


The first XML schema fragment shows the common components that are used directly or 1077 
indirectly in the definition of nc:CanadianProvinceCodeType and nc:USStateCodeType. These 1078 
code types contain the attribute group s:SimpleObjectAttributeGroup, which, in turn, contains 1079 
the attribute s:id. The attribute s:id enables an element to identify itself uniquely within an XML 1080 
instance. 1081 
1082 
<!-- Subset schema (Structures namespace) . 1083 
<xsd:schema 1084 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1085 
xmlns:s="http://niem.gov/niem/structures/2.0" 1086 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1087 
targetNamespace=”http://niem.gov/niem/structures/2.0” 1088 
…> 1089 
… 1090 
<xsd:attribute name="id" type="xsd:ID"/> 1091 
<xsd:attribute name="linkMetadata" type="xsd:IDREFS"/> 1092 
<xsd:attribute name="metadata" type="xsd:IDREFS"/> 1093 
1094 
<xsd:attributeGroup name="SimpleObjectAttributeGroup"> 1095 
<xsd:attribute ref="s:id"/> 1096 
<xsd:attribute ref="s:metadata"/> 1097 
<xsd:attribute ref="s:linkMetadata"/> 1098 
</xsd:attributeGroup> … 1099 
</xsd:schema> 1100 
1101 

Figure 29: XML Schema Fragment Illustrating s:SimpleObjectAttributeGroup. 1102 
The next XML schema fragment shows the definition of the abstract type-less element 1103 
nc:LocatonState. Because it is abstract, nc:LocationState element cannot appear in an XML 1104 
instance. Rather, it heads a substitution group, which contains the elements 1105 
nc:LocationStateCanadianProvinceCode and nc:LocationStateFIPS5-2AlphaCode. The fragment 1106 
also shows the definitions of the type nc:JurisdictionType and the element nc:Jurisdiction. The 1107 
type nc:JurisdictionType contains the element nc:LocationState. 1108 
1109 
1110 
<!-- Subset schema (NIEM Core namespace) . 1111 
<xsd:schema 1112 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1113 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 1114 
xmlns:s="http://niem.gov/niem/structures/2.0" 1115 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1116 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 1117 
…> 1118 
… 1119 
<xsd:element name="LocationState" abstract="true"/> 1120 
<xsd:element substitutionGroup="nc:LocationState" 1121 
name="LocationStateCanadianProvinceCode" 1122 
type="can:CanadianProvinceCodeType" nillable="true"/> 1123 
<xsd:element substitutionGroup="nc:LocationState" name="LocationStateFIPS5-2AlphaCode" 1124 
type="fips_5-2:USStateCodeType" nillable="true"/> 1125 
… 1126 
<xsd:complexType name="JurisdictionType"> 1127 
<xsd:annotation> 1128 
<xsd:appinfo> 1129 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1130 
</xsd:appinfo> 1131 
</xsd:annotation> 1132 
<xsd:complexContent> 1133 


 <xsd:extension base="s:ComplexObjectType"> 1134 
<xsd:sequence> 1135 
<xsd:element ref="nc:LocationCityName" minOccurs="0" maxOccurs="unbounded"/> 1136 
… 1137 
<xsd:element ref="nc:LocationState" minOccurs="0" maxOccurs="unbounded"/> 1138 
… 1139 
</xsd:sequence> 1140 
</xsd:extension> 1141 
</xsd:complexContent> 1142 
</xsd:complexType> 1143 
<xsd:element name="Jurisdiction" type="nc:JurisdictionType" nillable="true"/> 1144 
… 1145 
</xsd:schema> 1146 
1147 

Figure 30: XML Schema Fragment Illustrating nc:LocationState. 1148 
The following fragment from the Post Canada namespace shows the definition of the type 1149 
can:CanadianProvinceCodeType. 1150 
1151 
<!-- Subset schema (NIEM Post Canada namespace) . 1152 
<xsd:schema 1153 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1154 
xmlns:can="http://niem.gov/niem/post-canada/2.0" 1155 
xmlns:s="http://niem.gov/niem/structures/2.0" 1156 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1157 
targetNamespace=”http://niem.gov/niem/post-canada/2.0” 1158 
…> 1159 
… 1160 
<xsd:simpleType name="CanadianProvinceCodeSimpleType"> 1161 
<xsd:annotation> 1162 
<xsd:appinfo> 1163 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1164 
</xsd:appinfo> 1165 
</xsd:annotation> 1166 
<xsd:restriction base="xsd:token"> 1167 
<xsd:enumeration value="AB"/> 1168 
… 1169 
<xsd:enumeration value="YT"/> 1170 
</xsd:restriction> 1171 
</xsd:simpleType> 1172 

1173 


 1174 
<xsd:complexType name="CanadianProvinceCodeType"> 1175 
<xsd:annotation> 1176 
<xsd:appinfo> 1177 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1178 
</xsd:appinfo> 1179 
</xsd:annotation> 1180 
<xsd:simpleContent> 1181 
<xsd:extension base="can:CanadianProvinceCodeSimpleType"> 1182 
<xsd:attributeGroup ref="s:SimpleObjectAttributeGroup"/> 1183 
</xsd:extension> 1184 
</xsd:simpleContent> 1185 
</xsd:complexType> 1186 
… 1187 
</xsd:schema> 1188 
1189 

Figure 31: XML Schema Fragment Illustrating can:CanadianProvinceCodeType. 1190 

1191 


The next fragment from the FIPS 5.2 namespace shows the definition of the type 1192 
fips_5-2:USStateCodeType. 1193 
1194 
<!-- Subset schema (NIEM FIPS 5.2 namespace) . 1195 
<xsd:schema 1196 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1197 
xmlns:fips_5-2="http://niem.gov/niem/fips_5-2/2.0" 1198 
xmlns:s="http://niem.gov/niem/structures/2.0" 1199 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1200 
targetNamespace=”http://niem.gov/niem/fips_5-2/2.0” 1201 
…> 1202 
… 1203 
<xsd:simpleType name="USStateCodeSimpleType"> 1204 
<xsd:annotation> 1205 
<xsd:appinfo> 1206 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1207 
</xsd:appinfo> 1208 
</xsd:annotation> 1209 
<xsd:restriction base="xsd:token"> 1210 
<xsd:enumeration value="AK"> 1211 
… 1212 
<xsd:enumeration value="WY"> 1213 
</xsd:restriction> 1214 
</xsd:simpleType> 1215 
1216 
<xsd:complexType name="USStateCodeType"> 1217 
<xsd:annotation> 1218 
<xsd:appinfo> 1219 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1220 
</xsd:appinfo> 1221 
</xsd:annotation> 1222 
<xsd:simpleContent> 1223 
<xsd:extension base="fips_5-2:USStateCodeSimpleType"> 1224 
<xsd:attributeGroup ref="s:SimpleObjectAttributeGroup"/> 1225 
</xsd:extension> 1226 
</xsd:simpleContent> 1227 
</xsd:complexType> 1228 
… 1229 
</xsd:schema> 1230 
1231 

Figure 32: XML Schema Fragment Illustrating fips_5-2:USStateCodeType. 1232 
Finally, the following fragments show XML instances that conform to the definition of the 1233 
nc:Jurisdiction element. In the first XML instance, the nc:LocationState element has been 1234 
replaced by the nc:LocationStateCanadianProvinceCode element—a member of the substitution 1235 
group headed by nc:LocationState. 1236 
1237 
<nc:Jurisdiction> 1238 
… 1239 
<nc:LocationStateCanadianProvinceCode >AB</nc:LocationStateCanadianProvinceCode > 1240 
… 1241 
</nc:Jurisdiction> 1242 
1243 

Figure 33: XML Instance Fragment Illustrating the Use of nc:LocationStateCanadianProvinceCode. 1244 

1245 


In the second XML instance, the nc:LocationState element has been replaced by the 1246 
nc:LocationStateFIPS5-2AlphaCode element—also a member of the substitution group headed 1247 
by nc:LocationState. 1248 
1249 
<nc:Jurisdiction> 1250 
… 1251 
<nc:LocationStateFIPS5-2AlphaCode>MN</nc:LocationStateFIPS5-2AlphaCode> 1252 
… 1253 
</nc:Jurisdiction> 1254 
1255 

Figure 34: XML Instance Fragment Illustrating the Use of nc:LocationStateFIPS5-2AlphaCode. 1256 

5.8 Augmentation 1257 

Augmentation is a mechanism prescribed by NIEM to create a new NIEM-derived type, via 1258 
the extension of an existing NIEM type, by adding a block of elements bundled together in 1259 
another type called an “augmentation type.” The practice of bundling the additional elements 1260 
in an augmentation type is preferable to directly placing the elements in the new NIEM-derived 1261 
type because it provides a reusable bundle of properties. The mechanism also prescribes that 1262 
the augmentation type also extend the s:AugmentationType and that the element of the new 1263 
augmentation type be made a member of the substitution group headed by the element 1264 
s:Augmentation. 1265 
To illustrate the mechanism of augmentation, consider the following example. Suppose we 1266 
wish to use an element of nc:PersonType in our schema, but that we also need to capture 1267 
additional properties, such as the person’s driver’s license and place of birth, which 1268 
nc:PersonType does not provide. NIEM provides several person-related properties in 1269 
j:PersonAugmentationType, including nc:DriverLicense and j:PersonBirthPlaceCode, which 1270 
match the two additional properties we want. Therefore, we create a new NIEM-derived type, 1271 
ext:PersonType, which extends nc:PersonType by adding an element of 1272 
j:PersonAugmentationType to nc:PersonType. 1273 

Figure 35 illustrates this. 1274 
1275 
s:AugmentationTypenc:PersonTypej:PersonAugmentationTypeext:PersonType

Figure 35: Use of j:PersonAugmentationType. 1276 
To illustrate the definition and use of j:PersonAugmentationType, consider the NIEM XML 1277 
Schema fragments below, which include: 1278 

. 
The common components from the Structures namespace. 1279 
. 
The relevant components from the NIEM Core namespace. 1280 
. 
The relevant components from the Justice namespace. 1281 



. 
The relevant components from the Local Extension namespace. 1282 


Figure 36 is an XML instance fragment containing the ext:Person element. 1283 
We first show the relevant XML schema components from the NIEM Structures namespace 1284 
that are used directly or indirectly in the definition of s:AugmentationType. 1285 
1286 
<!-- Subset schema (Structures namespace) . 1287 
<xsd:schema 1288 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1289 
xmlns:s="http://niem.gov/niem/structures/2.0" 1290 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1291 
targetNamespace=”http://niem.gov/niem/structures/2.0” 1292 
…> 1293 
… 1294 
<xsd:attribute name="id" type="xsd:ID"/> 1295 
<xsd:attribute name="ref" type="xsd:IDREF"/> 1296 
1297 
<xsd:complexType name="ComplexObjectType" abstract="true"> 1298 
<xsd:attribute ref="s:id"/> 1299 
<xsd:attribute ref="s:metadata"/> 1300 
<xsd:attribute ref="s:linkMetadata"/> 1301 
</xsd:complexType> 1302 
1303 
<xsd:complexType name="AugmentationType" abstract="true"> 1304 
<xsd:attribute ref="s:id"/> 1305 
<xsd:attribute ref="s:metadata"/> 1306 
</xsd:complexType> 1307 
1308 
<xsd:element name="Augmentation" type="s:AugmentationType" abstract="true"/> 1309 
… 1310 
</xsd:schema> 1311 
1312 

Figure 36: XML Schema Fragment Illustrating s:AugmentationType. 1313 
The following fragment shows the relevant XML schema components from the NIEM Core 1314 
namespace. 1315 
1316 
<!-- Subset schema (NIEM Core namespace) . 1317 
<xsd:schema 1318 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1319 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 1320 
xmlns:s="http://niem.gov/niem/structures/2.0" 1321 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1322 
targetNamespace=”http://niem.gov/niem/niem-core/2.0” 1323 
…> 1324 
… 1325 
<xsd:complexType name="PersonType"> 1326 
<xsd:annotation> 1327 
<xsd:appinfo> 1328 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1329 
</xsd:appinfo> 1330 
</xsd:annotation> 1331 
<xsd:complexContent> 1332 
<xsd:extension base="s:ComplexObjectType"> 1333 
<xsd:sequence> 1334 
… 1335 
<xsd:element ref="nc:PersonName" minOccurs="0" maxOccurs="unbounded"/> 1336 
… 1337 
</xsd:sequence> 1338 


 </xsd:extension> 1339 
</xsd:complexContent> 1340 
</xsd:complexType> 1341 
1342 
<xsd:element name="Person" type="nc:PersonType" nillable="true"/> 1343 
… 1344 
</xsd:schema> 1345 

Figure 37: XML Schema Fragment Illustrating nc:PersonType. 1346 
The following fragment shows the relevant XML schema components from the Justice 1347 
domain namespace. 1348 
1349 
<!-- Subset schema (Justice Domain namespace) . 1350 
<xsd:schema 1351 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1352 
xmlns:j=”http://niem.gov/niem/domains/jxdm/4.0” 1353 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 1354 
xmlns:s="http://niem.gov/niem/structures/2.0" 1355 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1356 
targetNamespace=”http://niem.gov/niem/domains/jxdm/4.0” 1357 
…> 1358 
… 1359 
<xsd:complexType name="PersonAugmentationType"> 1360 
<xsd:annotation> 1361 
<xsd:appinfo> 1362 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" 1363 
i:name="AugmentationType"/> 1364 
</xsd:appinfo> 1365 
</xsd:annotation> 1366 
<xsd:complexContent> 1367 
<xsd:extension base="s:AugmentationType"> 1368 
<xsd:sequence> 1369 
<xsd:element ref="nc:DriverLicense" minOccurs="0" maxOccurs="unbounded"/> 1370 
… 1371 
<xsd:element ref="j:PersonBirthPlaceCode" minOccurs="0" maxOccurs="unbounded"/> 1372 
… 1373 
</xsd:sequence> 1374 
</xsd:extension> 1375 
</xsd:complexContent> 1376 
</xsd:complexType> <xsd:element name="PersonAugmentation" 1377 
type="j:PersonAugmentationType" 1378 
substitutionGroup="s:Augmentation"> 1379 
<xsd:annotation> 1380 
<xsd:appinfo> 1381 
<i:AppliesTo i:namespace="http://niem.gov/niem/niem-core/2.0" 1382 
i:name="PersonType"/> 1383 
</xsd:appinfo> 1384 
</xsd:annotation> 1385 
</xsd:element> 1386 
… 1387 
</xsd:schema> 1388 

Figure 38: XML Schema Fragment Illustrating j:PersonAugmentationType. 1389 

1390 


The following fragment shows the definition of ext:PersonType in the local extension 1391 
namespace. 1392 
1393 
<!— Extension schema . 1394 
<xsd:schema 1395 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1396 
xmlns:j=”http://niem.gov/niem/domains/jxdm/4.0” 1397 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 1398 
xmlns:s="http://niem.gov/niem/structures/2.0" 1399 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1400 
xmlns:ext=”http://cjis.gov/extension/1.0” 1401 
targetNamespace=”http://cjis.gov/extension/1.0” 1402 
…> 1403 
… 1404 
<xsd:complexType name="PersonType"> 1405 
<xsd:complexContent> 1406 
<xsd:extension base="nc:PersonType"> 1407 
<xsd:sequence> 1408 
<xsd:element ref="nc:PersonAugmentation" minOccurs="0" maxOccurs="unbounded"/> 1409 
</xsd:sequence> 1410 
</xsd:extension> 1411 
</xsd:complexContent> 1412 
</xsd:complexType> 1413 
1414 
<xsd:element name="Person" type="ext:PersonType" substitutionGroup=”nc:Person"> 1415 
</xsd:element> 1416 
… 1417 
</xsd:schema> 1418 
1419 

Figure 39: XML Schema Fragment Illustrating ext:PersonType. 1420 
Finally, the following fragment shows an XML instance that conforms to the definition of 1421 
ext:Person element. 1422 
1423 
<ext:Person> 1424 
… 1425 
<nc:PersonName> 1426 
<nc:PersonGivenName>John</nc:PersonGivenName> 1427 
<nc:PersonSurName>Smith</nc:PersonSurName> 1428 
</nc:PersonName> 1429 
… 1430 
<nc:PersonAugmentation> 1431 
<nc:DriverLicense>VA 1234</nc:DriverLicense> 1432 
… 1433 
<j:PersonBirthPlaceCode>VA</j:PersonBirthPlaceCode> 1434 
1435 
… 1436 
</nc:PersonAugmentation> 1437 
… 1438 
</ext:Person> 1439 
1440 

Figure 40: XML Instance Fragment Illustrating the Use of ext:Person. 1441 

1442 


5.9 Metadata 1443 

Meta is generally used as a prefix to mean “one level of description higher.” If X is a given 1444 
concept, then meta-X is information about or processes operating on X. For example, a meta-1445 
syntax is syntax for specifying syntax, meta-language is a language used to discuss language, and 1446 
meta-reasoning is reasoning about reasoning. 1447 
Likewise, metadata is data about data. It is information that is not descriptive of objects 1448 
and their relationships but is descriptive of data itself. For example, NIEM provides 1449 
j:EvidenceType, which represents an item received by or submitted to an agency for use in 1450 
ascertaining the truth of a matter. It contains elements such as j:EvidenceAmount, which is an 1451 
estimated or actual monetary value of a piece of evidence, j:EvidenceCollector, which is a 1452 
person who collected a particular piece of evidence, and so on. In the case of a specific object of 1453 
j:EvidenceType, these elements have values. These values constitute what is understood as 1454 
data of the j:EvidenceType object. However, there is information such as whether or not 1455 
j:EvidenceType object may be regarded as criminal or intelligence information (as may be the 1456 
case if j:EvidenceType object was a document of some kind). Such information is considered to 1457 
be metadata about the j:EvidenceType object. 1458 

. Note that whether information is considered to be “metadata” or “data” is subjective or 1459 
relative. It can be difficult to draw a clear dividing line between metadata and data. 1460 


NIEM prescribes a specific method for representing metadata. A type that represents 1461 
metadata is called a metadata type. NIEM defines an abstract s:MetadataType to serve as the 1462 
base type for all metadata types. The s:MetadataType contains a single attribute, s:id, the value 1463 
of which uniquely identifies a metadata type element within an exchange. NIEM also defines an 1464 
abstract element, s:Metadata, to serve as the head element of the substitution group in which 1465 
all concrete metadata type elements should be placed. 1466 
The following XML schema fragment from the NIEM Structures namespace shows these 1467 
definitions. 1468 
1469 
1470 
<!-- Subset schema (Structures namespace) . 1471 
<xsd:schema 1472 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1473 
xmlns:s="http://niem.gov/niem/structures/2.0" 1474 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1475 
targetNamespace=”http://niem.gov/niem/structures/2.0” 1476 
…> 1477 
… 1478 
<xsd:attribute name="id" type="xsd:ID"/> 1479 
<xsd:attribute name="ref" type="xsd:IDREF"/> 1480 
<xsd:attribute name="linkMetadata" type="xsd:IDREFS"/> 1481 
<xsd:attribute name="metadata" type="xsd:IDREFS"/> 1482 
1483 
<xsd:complexType name="MetadataType" abstract="true"> 1484 
<xsd:attribute ref="s:id"/> 1485 
</xsd:complexType> 1486 
1487 

 <xsd:element name="Metadata" type="s:MetadataType" abstract="true"/>1488 


 1489 
<xsd:attributeGroup name="SimpleObjectAttributeGroup"> 1490 
<xsd:attribute ref="s:id"/> 1491 
<xsd:attribute ref="s:metadata"/> 1492 
<xsd:attribute ref="s:linkMetadata"/> 1493 
</xsd:attributeGroup> … 1494 
</xsd:schema> 1495 
1496 

Figure 41: XML Schema Fragment Illustrating s:MetadataType. 1497 
As shown in the following fragment from the Justice domain namespace, 1498 
j:JusticeMetadataType extends s:MetadataType and adds two additional elements, 1499 
j:CriminalInformationIndicator and j:IntelligenceInformationIndicator. The namespace also 1500 
defines j:EvidenceType, which can use the j:JusticeMetadataType element to capture its 1501 
metadata information. 1502 
1503 
<!-- Subset schema (Justice Domain namespace) . 1504 
<xsd:schema 1505 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 1506 
xmlns:j=”http://niem.gov/niem/domains/jxdm/4.0” 1507 
xmlns:nc="http://niem.gov/niem/niem-core/2.0" 1508 
xmlns:s="http://niem.gov/niem/structures/2.0" 1509 
xmlns:i="http://niem.gov/niem/appinfo/2.0" 1510 
targetNamespace=”http://niem.gov/niem/domains/jxdm/4.0” 1511 
…> 1512 
… 1513 
<xsd:complexType name="JusticeMetadataType"> 1514 
<xsd:annotation> 1515 
<xsd:appinfo> 1516 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="MetadataType"/> 1517 
<i:AppliesTo i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1518 
<i:AppliesTo i:namespace="http://niem.gov/niem/structures/2.0" 1519 
i:name="Association"/> 1520 
</xsd:appinfo> 1521 
</xsd:annotation> 1522 
<xsd:complexContent> 1523 
<xsd:extension base="s:MetadataType"> 1524 
<xsd:sequence> 1525 
<xsd:element ref="j:CriminalInformationIndicator" minOccurs="0" 1526 
maxOccurs="unbounded"/> 1527 
<xsd:element ref="j:IntelligenceInformationIndicator" minOccurs="0" 1528 
maxOccurs="unbounded"/> 1529 
</xsd:sequence> 1530 
</xsd:extension> 1531 
</xsd:complexContent> 1532 
</xsd:complexType> 1533 
1534 
<xsd:element name="JusticeMetadata" type="j:JusticeMetadataType" nillable="true"/> 1535 
1536 
<xsd:complexType name="EvidenceType"> 1537 
<xsd:annotation> 1538 
<xsd:appinfo> 1539 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" i:name="Object"/> 1540 
</xsd:appinfo> 1541 
</xsd:annotation> 1542 
<xsd:complexContent> 1543 
<xsd:extension base="s:ComplexObjectType"> 1544 
<xsd:sequence> 1545 
<xsd:element ref="j:EvidenceAmount" minOccurs="0" maxOccurs="unbounded"/> 1546 
<xsd:element ref="j:EvidenceCollector" minOccurs="0" maxOccurs="unbounded"/> 1547 
… 1548 


 </xsd:sequence> 1549 
</xsd:extension> 1550 
</xsd:complexContent> 1551 
</xsd:complexType> 1552 
1553 
<xsd:element name="Evidence" type="j:EvidenceType" nillable="true"/> 1554 
… 1555 
</xsd:schema> 1556 
1557 

Figure 42: XML Schema Fragment Illustrating j:JusticeMetadataType. 1558 
Finally, the following fragment shows an XML instance containing a j:Evidence element that 1559 
uses the element j:JusticeMetadata to represent its metadata information. 1560 
1561 
<j:JusticeMetadata s:id=”M1”> 1562 
<j:CriminalInformationIndicator>true</j:CriminalInformationIndicator> 1563 
<j:IntelligenceInformationIndicator>false</j:IntelligenceInformationIndicator> 1564 
</j:JusticeMetadata> 1565 
1566 
<j:Evidence s:metadata=”M1”> 1567 
<j:EvidenceAmount>…</j: EvidenceAmount > 1568 
<j:EvidenceCollector>… </j: EvidenceCollector > 1569 
… 1570 
</j:Evidence> 1571 
1572 

Figure 43: XML Instance Fragment Illustrating the Use of j:JusticeMetadata 1573 

Figure 44 illustrates this example in a class diagram. 1574 
1575 
s:ids:MetadataTypej:CriminalInformationIndicatorj:IntelligenceInformationIndicatorj:JusticeMetadataTypes:metadataj:EvidenceType

Figure 44: Use of j:JusticeMetadataType. 1576 
A metadata type can be defined to apply to specific types only. To do this, you can add an 1577 
xsd:annotation/xsd:appinfo/i:AppliesTo element to the xsd:complexType definition of the 1578 
metadata type. For example, j:JusticeMetadataType specifies that it can only be applied to 1579 
types derived from Object and Association. This requirement is not enforced by XML schema, of 1580 
course, and is the responsibility of the user’s application. 1581 

1582 


5.10 External Adapter Types 1583 

While NIEM is a far-reaching standard, there are other information exchange standards 1584 
used in other communities. To share information with these other communities, NIEM includes 1585 
support for external standards. NIEM prescribes that the XML schema types from non-NIEM 1586 
namespaces should be wrapped in NIEM-conformant types so they may be used in a NIEM-1587 
conformant schema. The main construct available in NIEM 2.0 for wrapping non-NIEM-1588 
conforming types is the external adapter type. 1589 
The external adapter type is a NIEM-conformant type that can contain: 1590 

. 
Attributes from external namespaces. 1591 
. 
Elements from external namespaces. 1592 


The subparts of that adapter type should correspond to a semantically meaningful concept. 1593 
The adapter type may reference content from more than one external namespace, but all 1594 
content must be from external namespaces. 1595 
There are some special importing and packaging requirements for an IEPD that accesses 1596 
external adapter types. An IEPD that uses an external namespace through adapter components 1597 
will require the import of both a schema that contains the NIEM-conformant components 1598 
(adapter types) and the non-NIEM conformant external schemas. All the relevant schemas must 1599 
be included in the IEPD. Aside from these requirements, however, external adapter types can 1600 
be used in an IEPD just like standard NIEM types. Nothing special is required for designing 1601 
schemas or instances that use external adapter types. 1602 
In the following examples, the schema import statements are removed for the sake of 1603 
brevity. The Geospatial standard uses the prefix “geo:,” while the external content itself uses 1604 
the prefix “addr:.” 1605 

1606 


First is an example of an external adapter type from the Geospatial external standard in 1607 
NIEM 2.0 (geo:). The adapter type wrapping the nonconformant elements is 1608 
geo:SingleSiteLandmarkAddressType. 1609 
1610 
<xsd:complexType name="SingleSiteLandmarkAddressType"> 1611 
<xsd:annotation> 1612 
<xsd:appinfo> 1613 
<i:Base i:namespace="http://niem.gov/niem/structures/2.0" 1614 
i:name="Object"/> 1615 
<i:ExternalAdapterTypeIndicator> 1616 
true 1617 
</i:ExternalAdapterTypeIndicator> 1618 
</xsd:appinfo> 1619 
</xsd:annotation> 1620 
<xsd:complexContent> 1621 
<xsd:extension base="s:ComplexObjectType"> 1622 
<xsd:sequence> 1623 
<xsd:element ref="addr:SingleSiteLandmarkAddress" 1624 
maxOccurs="unbounded"/> 1625 
</xsd:sequence> 1626 
</xsd:extension> 1627 
</xsd:complexContent> 1628 
</xsd:complexType> 1629 
1630 

Figure 45: Use of External Adapter Type geo:SingleSite LandmarkAddressType. 1631 
Note that the appinfo information states that this is an external adapter type. Other than 1632 
this indicator, the XML schema for this type is much like any NIEM-conformant type. This 1633 
external adapter type wraps the following external content from the URISA Street address 1634 
namespace (addr:) but is simplified for this example: 1635 
1636 
<xsd:complexType name="PlaceName_type"> 1637 
<xsd:choice> 1638 
<xsd:element name="MunicipalJurisdiction" 1639 
type="addr:MunicipalJurisdiction_type"/> 1640 
<xsd:element name="USPSPlaceName" 1641 
type="addr:USPSPlaceName_type"/> 1642 
</xsd:choice> 1643 
</xsd:complexType> 1644 
<xsd:complexType name="SingleSiteLandmarkAddress_type"> 1645 
<xsd:sequence> 1646 
<xsd:element name="LandmarkName" 1647 
type="addr:LandmarkName_type"/> 1648 
<xsd:element name="PlaceName" type="addr:PlaceName_type"/> 1649 
<xsd:element name="StateName" type="addr:StateName_type"/> 1650 
<xsd:element name="ZipCode" type="addr:ZipCode_type"/> 1651 
</xsd:sequence> 1652 
<xsd:attribute name="action" type="addr:Action_type" use="optional"/> 1653 
</xsd:complexType> 1654 
1655 
<xsd:element name="SingleSiteLandmarkAddress" 1656 
type="addr:SingleSiteLandmarkAddress_type"/> 1657 

Figure 46: Definition of External Type addr:MunicipalJurisdiction and addr:USPSPlaceName. 1658 

. Note that this external content is not NIEM-conformant. 1659 


Finally, the resulting instance document pulls the two together, allowing for the use of the 1660 
external standard elements within a NIEM-conformant exchange: 1661 


 1662 
<geo:SingleSiteLandmarkAddress> 1663 
<addr:SingleSiteLandmarkAddress> 1664 
<addr:LandmarkName>Statue of Liberty</addr:LandmarkName> 1665 
<addr:PlaceName> 1666 
<addr:MunicipalJurisdiction> 1667 
New York 1668 
</addr:MunicipalJurisdiction> 1669 
</addr:PlaceName> 1670 
<addr:StateName>NY</addr:StateName> 1671 
<addr:ZipCode>10004</addr:ZipCode> 1672 
</addr:SingleSiteLandmarkAddress> 1673 
</geo:SingleSiteLandmarkAddress> 1674 
1675 

Figure 47: XML Instance Showing the Use of an External Adapter Type. 1676 
Using external adapter types to wrap non-NIEM-conformant standards is a powerful 1677 
method to leverage other standards from within NIEM without requiring those external 1678 
standards to be made NIEM-conformant. 1679 


6 NIEM Data Model Content 1680 

6.1 Architecture of NIEM Model 1681 

NIEM contains many XML data types and properties. To ensure that the information being 1682 
sent is understood clearly, it is important to avoid creating new data types and properties when 1683 
similar ones exist within the data model. It is therefore important to develop an understanding 1684 
of the content of NIEM. It is also important to develop a sense of how to go about navigating 1685 
through the data model. This chapter presents an overview of NIEM with an eye towards aiding 1686 
better navigation through the data model. 1687 
As mentioned previously, NIEM is a collection of data elements and data types, grouped 1688 
logically into several kinds of XML schemas. The data elements and types can be classified into 1689 
several broad categories: 1690 

. 
Appinfo: This schema provides support for high-level data model concepts and 1691 
additional syntax to support the NIEM conceptual model and validation of 1692 
NIEM-conformant instances. 1693 
. 
Structures: These elements enable consistent linking and description of 1694 
information in NIEM. These elements are also used to connect metadata to 1695 
objects. 1696 
. 
NIEM Core components: Basic NIEM objects—these describe core entities like 1697 
Activity, Person, Document, etc. In addition, the NIEM Core components also 1698 
describe more complex entities—such as drugs, vehicles, locations—that are 1699 
useful across multiple domains. 1700 
. 
Domains: These represent specialized information models that represent 1701 
information in verticals such as emergency management, justice, immigration, 1702 
etc. 1703 
. 
Standard Code Lists: These data elements and types are not really a part of 1704 
NIEM, but they are extremely useful in ensuring that information is described 1705 
in a consistent manner. 1706 


In addition to the XML objects mentioned above, NIEM also provides mechanism to 1707 
annotate individual data elements with metadata. 1708 

. 
In some cases, the metadata can be created as an entire XML object and be 1709 
associated with the appropriate piece of information whose characteristics are 1710 
being described. This is made possible by the XML object s:MetadataType. 1711 
. 
In other cases, annotating individual elements of data is preferable. In these 1712 
cases, you should use XML attributes provided by NIEM. 1713 
. 
For example, when dealing with monetary information, a useful annotation 1714 
would be the currency that the data represents. 1715 
. 
Similarly, it might be desirable to explicitly specify the language of a piece 1716 
of text. 1717 


A closer look at the XML Attributes in NIEM is presented towards the end of this section. 1718 


6.1.1 Relationships Between the Components 1719 

The data elements and types defined in each of the groups are interrelated in a specific 1720 
manner. For instance, elements in the Structures depend only on basic XML constructs. 1721 
Elements in NIEM Core depend only on each other and the elements in structures. As such, 1722 
elements in the Structure groups can be considered to be primordial, while the data elements in 1723 
the NIEM Core and the various domains represent increased specialization of information. 1724 
Components in the domains depend on components in NIEM Core, Structures, and, in some 1725 
cases, on each other. 1726 
For instance: 1727 

. 
NIEM Core defines an Activity—this is the object nc:ActivityType. 1728 
. 
Justice domain models an Arrest as an Activity, i.e., extends nc:ActivityType, 1729 
and adds elements that are specific to the arrest of an individual—this is the 1730 
object j:ArrestType. 1731 
. 
Immigration domain extends the Justice domain’s Arrest, j:ArrestType, to 1732 
describe the arrest of an alien—this is the object im:ImmigrationArrestType. 1733 
. 
A reference schema could model the relationship between an illegal alien and a 1734 
traffic stop, using constructs defined in the Structures namespace by simply 1735 
connecting activities and persons. 1736 


Consider the following scenario in which a reference schema defines a traffic stop as an 1737 
activity (see Figure 48, below). The schema also defines an association between a traffic stop 1738 
and an illegal alien as an ActivityPersonAssociation. The definitions for IllegalAlien, TrafficStop, 1739 
and TrafficStopIllegalAlienAssociation are contained within the reference schema. The object 1740 
IllegalAlien is shown to be of type im:IllegalAlien (which, in turn, points to a person in NIEM 1741 
Core). The object TrafficStop is modeled as an Activity (again in NIEM Core). Both Person and 1742 
Activity objects are tagged with the s:id attribute discussed above. The 1743 
TrafficStopIllegalAlienAssociation object, which in reality is an object of type 1744 
ActivityPersonAssociation, contains two references—s:ref attributes discussed above with the 1745 
ActivityReference containing the Activity object’s s:id attribute and the PersonReference 1746 
containing the Person object’s s:id attribute. 1747 


 1748 NIEM Architecture


Figure 48: Use of Elements From Structures in Reference Schema Documents. 1749 

When you construct a reference schema that reflects a particular information exchange, 1750 
you could use or extend the element from all of the namespaces. These relationships are 1751 
illustrated in Figure 49. The components in the domains are shown to be dependent on the 1752 
components in NIEM Core. Components in the external code sets are independent of the 1753 
components in NIEM. Components in reference schemas can utilize components in the domains 1754 
as well as in NIEM Core. External code sets are also available to the applications. 1755 

1756 


 1757 

Figure 49: NIEM Components. 1758 

6.2 Namespaces 1759 

This section takes a closer look at the namespaces that constitute NIEM and provides a 1760 
roadmap for navigating through the data model. The NIEM Web site (www.NIEM.gov) provides 1761 
online tools for navigating the data model. In addition, the Web site provides the data model in 1762 
the form of a spreadsheet. For some uses, the spreadsheet is easier to navigate. Refer to the 1763 
online tools and the spreadsheet for a comprehensive listing of various components of NIEM. 1764 
The following subsections present an overview of the namespaces that comprise NIEM. 1765 
Where appropriate, a few illustrative components are discussed individually. 1766 

6.2.1 Structures 1767 

The Structures namespace provides support for fundamental NIEM linking mechanisms, as 1768 
well as provides base types for the definition of NIEM-conformant types. The namespace and 1769 
the prefix are defined as follows. 1770 

Prefix: s 

http://niem.gov/niem/structures/2.0 

Schema constructs for use by NIEM-conformant schemas to provide consistent definitions and 
functionality. 



Table 3: Content Definition Namespace. 1771 
Some of the key components in this namespace are as follows: 1772 


. 
id: The id attribute is used to define XML IDs for objects in NIEM and NIEM-1773 
conformant data models. These IDs could be associated with any data 1774 
elements or even metadata elements. 1775 
. 
ref: The ref attribute is used to refer to XML elements that have XML IDs, id 1776 
attribute referenced above. The combined use of id and ref attributes makes it 1777 
possible to refer to data elements/objects without having to contain them 1778 
within objects. 1779 
. 
AugmentationType: The AugmentationType type is a base type for all 1780 
augmentations. An augmentation may have metadata and an ID. Typically, 1781 
domains use domain-specific augmentations to extend the information 1782 
contained in the base types. The use of augmentation has been covered in the 1783 
previous sections. 1784 
. 
ReferenceType: The ReferenceType type is the type of all reference elements 1785 
within NIEM-conformant schemas. This type provides only a reference 1786 
attribute to reference an object defined elsewhere. It includes an id, as the link 1787 
established by a reference element may need to be identified, and it includes 1788 
link metadata, as an element of this type establishes a relationship between its 1789 
context and the referenced object. It does not contain metadata because it 1790 
does not itself establish the existence of an object; it relies on a definition 1791 
located elsewhere. This object is used when any object is to be referenced. For 1792 
example, consider the following XML segment. This snippet is from the niem-1793 
core.xsd schema document and illustrates how a reference is created to an 1794 
nc:Person object. It should be noted that the reference to the person is really 1795 
of the type nc:ReferenceType. The following XML snippet shows the definition 1796 
of the nc:PersonReference from NIEM. 1797 


 1798 
<xsd:element name="PersonReference" type="s:ReferenceType"> 1799 
<xsd:annotation> 1800 
<xsd:documentation>A human being.</xsd:documentation> 1801 
<xsd:appinfo> 1802 
<i:ReferenceTarget i:name="PersonType"/> 1803 
</xsd:appinfo> 1804 
</xsd:annotation> 1805 
</xsd:element> 1806 
1807 

Figure 50: Definition of nc:PersonReference in NIEM. 1808 
The following XML code segment shows the definition of the ReferenceType object. As can 1809 
be seen, the Referen