Frequently Asked Questions

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

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

<Person s:metadata="MD">

<PersonName>

<PersonGivenName>Adam</PersonGivenName>

<PersonSurName>Brooks</PersonSurName>

</PersonName>

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

</Person>

<Metadata s:id="MD">

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

</Metadata>

This example has a few interesting features:

• The person object refers to its metadata

– The reference uses the attribute s:metadata

– The reference is to the object with id MD

• The metadata is a separate element

– The element is called Metadata.

– The metadata object has the id ‘MD.

• The ID is conveyed with the attribute s:id

– The metadata object contains an element ReportedDate

Usage of Roles can be demonstrated via the following example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Click "My IEPDs"

- Click the IEPD to edit / delete

- Next page has 4 menu items at the top

- Click "Edit", edit the IEPD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Real-world situations sometimes yield data that are too irregular to model efficiently via the Unified Modeling Language™ (UML) class diagrams stipulated by the Information Exchange Package Documentation (IEPD) lifecycle process. WIJIS recently encountered such a situation and found an effective and generally applicable solution that is well supported by National Information Exchange Model (NIEM) — external unconstrained Resource Description Framework (RDF) attachments defined at the Instance level, rather than the Class level.

Please refer to the pdf attached for the full article.

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