FAQs
"...As the GJXDM became ready for release in production, many developers and administrators realized that very little information was available regarding the real-world performance of properly defined subset schemas. The Office of Justice Programs (OJP) in the U.S. Department of Justice concluded that performance testing of the GJXDM was a high priority. The testing would define the relative impact of using the GJXDM as a basis for creating XML schemas representing documents exchanged.
To carry out the testing program, OJP awarded a grant to the IJIS Institute to conduct performance testing of the initial production release to provide industry and government developers and administrators with insights into the impact of using this important new tool. The IJIS Institute created a partnership with The George Washington University (GWU) to conduct the performance testing under the leadership of a project committee. The committee consisted of developers from IJIS Institute member companies and other organizations having specific interest in the test results (Georgia Tech Research Institute, the engineering arm that designed the GJXDM; the Global XML Structure Task Force, the practitioner group guiding the development process; and OJP)."
Click Here to access the full report.
The definition of an association is composed of several parts:
1. An element that identifies the specific semantics of the association.
For each semantically distinct association, we define an element. Each element will have annotations indicating the specific meaning of the association. Such documentation is not shown in this document, but follows the guidelines established for GJXDM 3.0. The syntax is standard XML Schema. For example, here is the definition for a parent-child element:
<xs:element
name="ParentChildAssociation"
type="ParentChildAssociationType"/>
We may wish to define a more-specific type of parent-child association. For example, an adoptive parent-child association:
<xs:element
name="AdoptiveParentChildAssociation"
type="ParentChildAssociationType"/>
If we wanted to make the type specific to an adoptive parent-child situation, then we define a new type, instead of reusing the general parent-child type.
2. A type for the association. The type may be have precise semantics, or may be a more generally defined type.
The definition of types for associations is done as needed, depending on the content of the types. We do not, as a rule, define a new type for each use or semantic definition of an association. Instead, we define them as necessary, to accommodate the content required. Here is an example definition for a type for the parent-child association:
<xs:complexType name="ParentChildAssociationType">
<xs:complexContent>
<xs:extension base="u:AssociationType">
<xs:sequence>
<xs:element ref="this:ParentRef" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="this:ChildRef" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The type definition has several parts:
The name of the type is “something AssociationType”. This makes associations between objects distinct from other types of object definitions.
The type is derived from another association type. This allows definition of type hierarchies for associations, and the definition of characteristics that are shared across multiple association types. The content of the association is a sequence of elements. The content of the association could be entirely related objects. The association could also contain characteristics of the associations, such as dates, names, identifiers, etc.
A publication by ANSI/NIST may be used as an example for referencing NIEM. This standard was created to support the interchange of biometric data. See http://www.nist.gov/customcf/get_pdf.cfm?pub_id=910136 for more details.
The attached file provides a list of federal agencies and their NIEM adoption plans as of July 2012.
Documents
https://bja.ojp.gov/media/document/29956
The 2011 NIEM National Training Event webcasts are located at this link - http://register.mediasite.com/?nd=login&setsite=39. A login is required.
A Unified Modeling Language (UML) Profile for NIEM which aims to provide a standard for modeling NIEM artifacts (such as Model Package Descriptions, or MPDs) using UML. The UML profile will be an industry standard that will enable the development of NIEM-conformant information sharing and exchange models across systems, agencies, and levels of government.
The development team for this effort consisted of members from the NIEM Program Management Office, the OMG Technical Committee, Program Manager for the Information Sharing Environment, and industry and academic partners. On February 20, 2012, the Revised Submission to the UML Profile for NIEM (NIEM-UML) was delivered to the Object Management Group (OMG).
Final approval is expected in the June 2012 timeframe. You can review the NIEM-UML revised submission by clicking here.
Videos Resources:
NIEM-UML High-Level Introduction
NIEM-UML Specification Overview
This video is a short overview of NIEM and how it can help organizations exchange information. Produced by T. Reinhardt, Canada. 11-2011.
The xsd:appinfo element is used to provide machine-targeted annotations of schema components. In NIEM, there are some specific defined uses. There are some rules constraining use of xsd:appinfo in the NIEM Naming and Design Rules section 6.4.2, and the specifically defined uses are addressed in section 7.2.2 with additional detail in Appendix C.
For a new element created in a NIEM extension, xsd:appinfo is generally only required for the following:
1. Association types and elements, to indicate the base type or element (appinfo:Base)
2. Augmentation and metadata types, to indicate base type to which the augmentation or metadata may be applied (appinfo:AppliesTo)
3. Reference elements, to specify the type to which the reference element may be applied (appinfo:ReferenceTarget)
While xsd:appinfo is required for NIEM conformance in these cases, xsd:appinfo is ignored by XML schema validation so an otherwise valid XML schema will still validate even if the xsd:appinfo elements are not included.
1. What are the reasons for-or-against this effort?
2. Any recommendations on how such an inventory should differ from just a "giant mapping sheet"?
NIEM Model Package Description (MDP) Specification document available on the NIEM web site has the best overview surrounding how the future of NIEM leverages enterprise data models in individual exchange package development.
To answer the specific questions:
The reason for doing this is that this is in line with the future of NIEM as outlined in the MPD Specification. It also a great way to ensure elements are mapped/modeled consistently across various exchanges in the future.
While a simple spreadsheet would work, it may be advantageous to use the new (when that becomes available) instead as it embodies the MPD and also provides tools to graphically depict and textually document the larger enterprise data model.
Service Specifications are similar to National Information Exchange Model ([NIEM]) Information Exchange Package Documentation (IEPD), commonly used within the justice community. They document the conceptual, logical, and physical models of a service in the same way NIEM IEPDs document the conceptual, logical, and physical models of a data exchange. Also, as with IEPDs, Service Specifications are a composite set of documentation, models, policies, contracts, and schemas that together provide a clear view of the service capabilities and business and technical requirements. While both Service Specifications and NIEM IEPDs are sets of artifacts which enable justice agencies to effectively share information and are of similar construction, they are not equivalent concepts. From a GRA perspective, NIEM IEPDs are used to describe the information model of a service and, as such, become a part of the Service Specification.
The National Information Exchange Model (NIEM) is an XML vocabulary that is quickly gaining popularity as a means to support cross-domain information sharing. NIEM is about the semantics of the message, not transportation of that message.
“Web services” is a term for a group of industry standards that collectively provide a mechanism for exchanging XML-based messages, such as NIEM messages. One of these standards is the Web Services Description Language (WSDL), which standardizes the specification and description of a web services interface.
This technical brief (see source below) explains the crucial relationship between NIEM Information Exchange Package Documentation (IEPD) and WSDL. The information that travels between systems is critical to the workings of a web service. A WSDL has the responsibility of specifically defining what that information looks like. Though IEPD is a concept separate from web services, an IEPD can be used in conjunction with WSDL to clearly and unambiguously specify a web services interface, including all the semantics. In other words, web services can be used for exchanging messages defined by NIEM IEPDs. For further reading, please see the source below.
Source - Using NIEM with Web Services
There are many ways to execute the XJC tool on a NIEM IEPD. The IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in JAVA" will deal with three of them:
1. Executing XJC using the Java command;
2. Executing XJC using xjc.sh or xsh.bat; and
3. using an Eclipse plugin.
More details, please see: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in JAVA"; see article ID# 547
The IJIS Institute Technical Advisory Committee (I-TAC) has two new documents available. They are attached to this article and are entitled: 1) NIEM IEPD XML Code Generation in C# with .NET 3.5; and 2) NIEM IEPD XML Code Generation in Java.
NIEM IEPD XML Code Generation in Java:
This document seeks to address generation of Java classes based on the JAXB standard. Initially, it was meant to demonstrate the similarities and differences between Axis and XFire. Since both technologies use the JAXB-XJC tool as one of the ways to generate Java classes for their code generation tools, this paper will address the use of the JAXB-XJC tool.
NIEM IEPD XML Code Generation in C# with .NET 3.5:
Programmatically working with NIEM IEPDs in C# can be challenging due to the overall complexity of working with large XML schema models, and the limitations in Microsoft’s Xsd.exe code generation tool. This document seeks to provide answers to frequently asked practitioner questions that may come up when working with NIEM IEPDs in .NET, and hopefully decrease the effort required to achieve successful NIEM IEPD programming. These questions address using Xsd.exe code generation, and rely on XML object serialization. It is worth noting that there are other viable approaches to working with C#.NET and XML that are available such as LINQ to XML.
Documents
https://bja.ojp.gov/media/document/29946
https://bja.ojp.gov/media/document/29951
An announcement from the National Information Exchange Model (NIEM) LinkedIn Group, by Donna Roy, NIEM Executive Director:
Today marks a pivotal day for the NIEM program and the dedicated government users of the best in government XML based information exchange model. Altova's Mission Kit,according to Forrester Research, boasts over 3 million users across the world. Their lastest release, includes features built to make NIEM easier to implement.
http://ca.sys-con.com/node/1382623
BEVERLY, MA -- (Marketwire) -- 05/05/10 -- Altova® ( http://www.altova.com ), creator of XMLSpy®, the industry leading XML editor today announced the availability of Version 2010 Release 3 (v2010r3) of the Altova MissionKit®, an integrated suite of XML, database, and UML tools. Version 2010 Release 3 adds powerful new functionality including integration with the newly released Visual Studio® 2010, support for working with industry standards iXBRL and National Information Exchange Model (NIEM), support for mapping data based on SAP's IDoc EDI format, and much more.
"The new functionality available in 2010r3 adds to our already robust tool suite and gives users more flexibility to work with a variety of technologies and industry standards," said Alexander Falk, President and CEO for Altova. "By continually adding key features to support technologies such as XML and UML, and standards like XBRL and NIEM, we are helping our users to work as efficiently and cost-effectively as possible."
Each of the tools available in the Altova MissionKit 2010r3 includes several new features:
XMLSpy 2010r3 - With the release of v2010r3, the XMLSpy XML editor adds new usability enhancements to its graphical schema editor, including the ability to validate internal naming and coding conventions. The enhanced XMLSpy graphical schema editor allows schema designers to validate naming and coding conventions outside of the capabilities of the XML Schema standard. This new functionality is of key importance for users working with NIEM, a U.S. Government XML-based standard, when implementing their information sharing exchanges. Another new feature in XMLSpy 2010r3 is support for creating user-defined sample values for XML instance generation. Users can now add arbitrary sample data to their XML instance generations allowing them to control the sample data that is published. XMLSpy 2010r3 also integrates with Visual Studio 2010, adding to its existing support for VS 2005 and VS 2008.
On behalf of the NIEM community, a big thanks for the support of Alexander Falk and Altova!
For more information, please visit, NIEM LinkedIn Group.
There is no formal policy with respect to use of Schematron with NIEM.
Georgia Tech Research Institute (GTRI) uses Schematron (in fact, publishes the Schematron rules) for the NIEM Conformance Tool. Schematron checks that IEPD schemas do not violate the NIEM Naming and Design Rules (NDR). However, Schematron could certainly be used to tighten constraints on schemas or instances for IEPD/IEPs that could not otherwise be checked by an XML Schema validator. As a result, the use of Schematron is be encouraged.
Originally, the concept of a constraint schema with two-pass validation was developed as the way to tighten constraints on XML instances if one cannot, or does not want to, design and apply Schematron rules. A constraint schema does not have to follow the NIEM NDR because it is used for a completely independent 2nd pass validation of an instance. So, as long as an instance passes the conformance validation (1st pass) with the NIEM subset (plus extensions and exchange schema), then it is conforming. A constraint schema can tighten the constraints without impacting conformance (because it's an additional pass with a constraint schema (usually a modified subset schema) that is independent of the first.
The disadvantage of this approach is that it requires a 2nd validation pass with a modified subset. However, Schematron also requires its own pass over the schema or instance being checked. In addition, you must write the Schematron rules - which are not always easy. For example, the Conformance Tool sometimes has to employ a set of as many as 3-4 Schematron rules to check a single NDR rule.
Many business rules can be formally designed and applied in Schematron. Lastly, since Schematron is the means by which NIEM conformance is achieved, the recommendation from a consistency point of view is to use the Schematron approach for complex business rules validation.
This case study highlights the successful utilization of NIEM as part of the MassGangs project to support the exchange of information obtained by local, regional, and state criminal justice agencies regarding members of criminal gangs and illegal organizations in Massachusetts.
See attached pdf or link below for complete article.
Link: https://www.niem.gov/about-niem/success-stories/massachusetts-executive…
Documents
https://bja.ojp.gov/media/document/29941
The first step in working with an IEPD is to create a batch file that will execute Xsd.exe. Because NIEM IEPDs are comprised of multiple xsd files and Xsd.exe will not automatically find imported schemas, we will need to include every xsd in the Xsd.exe input. The batch file will take the format:
> Xsd.exe "<Path to xsd file 1>" "<Path to xsd file 2>" … "<Path to xsd file n>" /c
An example of this is found at: IJIS Technical Advisory Committee NIEM FAQ Series "NIEM IEPD XML Code Generation in C# with .NET 3.5"; see article ID# 547
The following NIEM Presentation was given in October 5-6, 2009 at a "Workshop on Improving Access to Financial Data on the Web". It was co-organized by W3C and XBRL International, Inc, and hosted by FDIC, Arlington, Virginia USA. For more speakers: http://www.w3.org/2009/03/xbrl/minutes.html.
This presentation on "The National Information Exchange Model (NIEM) Program" was provided by Anthony-Hoang (DHS OCIO) and Justin Stekervetz (Deloitte) on behalf of Donna Roy, Director, Enterprise Data Management Office, and Executive Director, for National Information Exchange Model.
Link to presentation slides: http://www.w3.org/2009/03/xbrl/talks/Anthony-Hoang.pdf
In a progressive and unusual collaboration between the judicial system as represented by the National Center for State Courts and the U.S. Department of Health and Human Services, significant improvements have been made in improving outcomes for abused and neglected children, thanks to the use of the National Information Exchange Model (NIEM).
See attached pdf for full article.
Documents
https://bja.ojp.gov/media/document/29936
Donna Roy, executive director of the NIEM Program Management Office and director of the Enterprise Data Management Office with the U.S. Department of Homeland Security, recently noted that "DHS has had a variety of successes with NIEM and at the same grand level that NDEx has been for the Department of Justice. Over 35 percent of the major IT Programs in DHS are working on implemented standardized information exchange using NIEM, with an expected increase to 60 percent by the end of 2009. Major drivers for adoption at DHS include requirements of all new IT programs and modifications to existing programs to use NIEM, based on the DHS-wide System Engineering Lifecycle. NIEM is working for DHS, and we will continue to both use NIEM and support the use of NIEM in federal, state, tribal, and local information sharing initiatives."
Please refer to the pdf attached for the full article.
Also, the Information Sharing Environment (ISE) has four success stories available that provide insight into how various elements of the National Information Exchange Model (NIEM), a key aspect of the Common Information Sharing Standards (CISS), can be applied in different user environments:
NIEM and the HHS Meaningful Use “SPRINT”
UCORE and NIEM: Creating Potent New Cross-Boundary Networks
Suspicious Activity Reporting
The DHS Domestic Nuclear Detection Office Goes NIEM
These success stories are available at http://www.ise.gov and are also attached to this article.
Documents
https://bja.ojp.gov/media/document/29911
https://bja.ojp.gov/media/document/29916
https://bja.ojp.gov/media/document/29921
https://bja.ojp.gov/media/document/29926
https://bja.ojp.gov/media/document/29931
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
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
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.
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
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/bja/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.
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.
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
"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."
"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 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."
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 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.
"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.
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.
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
The NIEM's development strategy revises and extends the GJXDM architecture, components, and processes for the NIEM based on an extensive GJXDM knowledge base of successful applications, lessons learned, and apply industry best practices. NIEM's strategy will provide core value propositions in several respects:
- Facilitate growth of data model through harmonization of new data components
- Coordinate independent project teams within DOJ and DHS
- Separate core entities and attributes from domain specific
- Produce multiple modular schemas (universal core, community-of-interest core, and domain specific)
- Facilitate discovery of reusable data components
- Facilitate assembly of reusable exchange packages
- Adopt a standard for assigning context
- Maintain compatibility with GJXDM for future work
- Demonstrate use of core in federated query
- Coordinate joint development and joint governance of core entities and exchanges
Source: https://www.niem.gov
The goal of the NIEM is to prevent fragmentation and semantic non-interoperability in Extensible Markup Language (XML) standards within and across agencies through a proactive collaborative initiative, to develop and implement common XML information sharing standards that meet critical homeland security data exchange needs.
The NIEM has the following objectives:
- Develop a unified strategy within the U.S. Departments of Homeland Security (DHS) and Justice (DOJ) for an XML-based information sharing capability.
- Develop an initial implementation of the NIEM that satisfies Executive Order (EO) 13356 and Homeland Security Presidential Directive (HSPD)-11.
- Develop an exchange layer for the XML profile implementation of the Federal Enterprise Architecture Data Reference Model (FEA DRM).
- Develop an XML profile of NIEM that implements the FEA DRM.
- Provide technical assistance and training to local, state, tribal, and federal organizations seeking to implement revisions to the GJXDM and support the new national standards emerging from joint efforts under this Memorandum of Understanding (MOU).
- Develop and demonstrate an application of the NIEM for the Bureau of Border and Transportation Security (BTS) operational domain involving customs and border patrol agent data exchange as the first pilot.
- Build out a framework for many pilot use cases under the umbrella of the NIEM.
NIEM webinars are a convenient way to help you learn more about using NIEM, from general concepts and tools to in-depth technical specifications. Whether you're completely new to NIEM or simply want to hone your skills, you'll find the webinar that's right for you.
Webinars contain videos that will show you how to learn about a variety of useful NIEM tools, including:
NIEM Wayfarer
NIEM Extension Wizard
NIEM Conformance Tool
And more!
For more information regarding NIEM Webinars see here - https://www.niem.gov/training/Pages/webinars.aspx.
External components are encapsulated in NIEM-conformant components. This introduces the concept of “external adapter” types. An external adapter type is a NIEM conformant XML Schema complex type that wraps a set of external content.
These adapter types and container elements are XML Schema components, and so are defined within the namespace of the schema currently being defined.
This article specifies two constructs, which contain external content. The first is the external adapter type. This type is a NIEM-conformant type that contains attributes and elements from external namespaces. The second is the external container element. The container element is used when an external namespace provides top-level types for use, but does not provide appropriate top-level elements. In such a case, create a container element of the externally-provided type. Container elements are defined in NIEM conformant namespaces, are named differently than regular NIEM-conformant elements, and are used in a more restricted way.
Consistent with the fundamentals of NIEM, XML elements are used for semantics, and XML Schema types are used to contain necessary structures. Specific rules for definition of adapter components will take this approach, focusing on encapsulating external structures as NIEM-conformant types, within strongly-defined elements with specific semantics.
If an external type needs to be extended for use, such extension should be done outside a NIEM-conformant namespace. These structures are intended to encapsulate external content. They are not indented to introduce extensions and modifications to external content into NIEM-conformant namespaces. If an application schema needs to be constructed to conform to an external standard, the schema should be created in a user defined namespace, outside the NIEM-conformant namespaces. Then, those external components should be referenced by NIEM-conformant external adapter types and external container elements.
The NIEM is a collaborative development initiative with the initial development principally supported by DHS and DOJ. The NIEM development strategy will leverage DOJ’s GJXDM as the principal baseline data model. The pilot project will develop the NIEM as a re-branded version of the GJXDM, extending its scope and aligning its structure and associated processes to include the concept of core data types.
NIEM is an ambitious undertaking that faces numerous technical and logistical challenges and associated risks. The development strategy will mitigate these risks by leveraging the proven technologies and processes of the GJXDM; revising and extending the GJXDM architecture, components, and processes for the NIEM based on an extensive GJXDM knowledge base of successful applications and lessons learned; applying industry best practices; and scoping the initial NIEM release to a small high priority set of core components.
NIEM's strategy will provide core value propositions in several respects:
- Facilitate growth of data model through harmonization of new data components
- Coordinate independent project teams within DOJ and DHS
- Separate core entities and attributes from domain specific components
- Produce multiple modular schemas (universal core, community-of-interest core, and domain specific)
- Facilitate discovery of reusable data components
- Facilitate assembly of reusable exchange packages
- Adopt a standard for assigning context
- Maintain compatibility with GJXDM for future work
- Demonstrate use of core in federated query, and
- Coordinate joint development and joint governance of core entities and exchanges