Frequently Asked Questions

The Information Sharing Environment (ISE) broadly refers to the people, projects, systems, and agencies that enable responsible information sharing for national security. This includes many different communities: law enforcement, public safety, homeland security, intelligence, defense, and foreign affairs. The people in these communities may work for federal, state, local, tribal, or territorial governments. The Program Manager for the Information Sharing Environment (PM-ISE) is Kshemendra Paul. The PM-ISE has government-wide authority to plan, oversee the build-out, and manage use of the ISE. He also co-chairs the White House’s Information Sharing and Access Interagency Policy Committee (ISA-IPC).

ISE's mission and vision:

• Advance responsible information sharing to further counterterrorism, homeland security, and cybersecurity missions
• Improve nationwide decision making by transforming from information ownership to stewardship
• Promote partnerships across federal, state, local, and tribal governments, the private sector, and internationally

Resources:
ISE's document libary
ISE's Programs
Video Interview with ISE's Program Manager

NIEM Github is the Sharing Spot is for the community to have access to resources that will help them use NIEM and make NIEM easier for others to use. At its very core, GitHub is a web-based hosting platform for Git repositories. Git is a popular version control system that's widely used among programmers and developers for developing and maintaining code.

For more information on this tool, please click on the links below.

Resources:

http://niem.github.io/

http://www.lynda.com/GitHub-tutorials/What-GitHub/162276/173432-4.html

A description of a subset can be saved as a "wantlist". A NIEM / GJXDM wantlist is an XML instance (based on a schema) for identifying the NIEM / GJXDM components required for a given subset. It is the intermediate format that the SSGT itself uses and edits, and can be persisted (saved to disk, emailed, published online, etc.) to feed the selected types and elements into the SSGT at a later time.

By employing this open XML-based specification, it is possible for other tools (such as editors or schema builders) to interact with the SSGT and to exchange subset definitions between tools.

Wayfarer is an exploration tool for the NIEM and the GJXDM. It provides advanced searching capabilities combined with detailed information about elements and types. It was developed in-house by the NCSC and is freely available to the NIEM and GJXDM communities.

http://www.ncsc.org/Services-and-Experts/Technology-tools/National-stan…

NIEM Wayfarer Tool: http://apps.ncsc.org/niem/

GJXDM Wayfarer Tool: http://apps.ncsc.org/wayfarer/

Wayfarer shows details about various elements and types and the relationships between them. The main interface to Wayfarer is the search box. Users can search element and type names and definitions, as well as code tables. Clicking on an element or type name will bring up details on that element or type.

Element pages give detailed information about the "has-a" relationships, e.g. a Person "has-a" a PersonName.

Type pages give detailed information about the "is-a" relationships, e.g. a Judicial Official "is-a" Person.

The recommended way to access Wayfarer is to go to the online version. This is always the most up-to-date version. There is also a localized version that allows one to use Wayfarer without having access to the Internet. It's based on transforming the database information into a series of static web pages. The end result is nearly 3000 separate pages, one for each element and type. As with the online version, the localized version requires a JavaScript-enabled browser, but it no longer requires any additional software.

Wayfarer Tool Website: http://apps.ncsc.org/niem/

SuperType is the root object in the type inheritance hierarchy. It incorporates attributes such as, @sensitivityText, @reportingOrganizationText, @reportedDate, @effectiveDate, and so forth. SuperType provides a base object with properties that can be associated to any element in the entire GJXDM.

The SuperType is basically any thing. Using a SuperType as a root of the model enables the association of certain attributes common to all of the types. In other words, all types in the model can inherit basic attributes such as “@source Text” (the name or identification of an information resource from which the content came) or “@reportedDate” (the date information was observed, measured, identified, or became known). This is commonly known as metadata.

Derived from the SuperType are other types, such as PersonType or ActivityType. Each of these types has properties of its own, and the important objective of component reuse is achieved by using the OOP concept of inheritance.

The “SuperType” contains properties that are applicable to all components of the GJXDM; therefore, all fields will include the properties of “SuperType”. All GJXDM components are derived from “SuperType”, so that all components inherit all the “SuperType” properties. At the same time, “SuperType” has neither complex nor simple content. In fact, it has no content; it's empty. Thus, objects with simple content can still be derived from “SuperType”, because it cannot contain any subordinate elements. And finally, one can consider “SuperType” properties generic enough to be metadata (such as, “probabilityNumeric”, “distributionText”, “reportedDate”, “expirationDate”, etc.) on all GJXDM components.

To find a component (type or element), it is helpful to understand how they are named and be aware of the challenges for searching introduced by the inheritance relationships in GJXDM and NIEM.

One design criteria for GJXDM and NIEM is to provide a set of data element names that are relatively complete, semantically precise, and globally understood. The meaning of any given tagname should be determinable within a variety of circumstances, ranging from well-structured documents with rich context to transaction- or message-oriented formats that may be weak in context. To accomplish this goal, GJXDM and NIEM prohibit synonyms and use ISO/IEC Standard 11179 (Specification and Standardization of Data Elements) syntax for naming elements consistently and precisely.

As a result, GJXDM and NIEM have wide applicability and a larger scope, but also longer tagnames. However, it is not difficult to codify the tagnames for transmission efficiency or to apply compression techniques. The Federal XML Developer's Guide requires that XML data element names (tagnames) be specified using the syntax rules of ISO/IEC Standard 11179 (Specification and Standardization of Data Elements). Therefore, all XML data element names contain three basic parts: object class term, property term, and a representation term. Each of these terms may be further supplemented with optional qualifier terms (essentially adjectives), as required to clarify or focus semantic meaning.

Each component lists the ways in which it may be required , and other components which it may require.

A component is any of the following:

• Namespace prefix declaration: A namespace prefix declaration is required when the declared prefix is used anywhere within the schema file. For example, if an entity from the 'http://xyz.com/ns' namespace is used within the schema, then a namespace declaration must be included for that namespace.
• Import of a schema: Each schema defines the contents of a single namespace (the target Namespace of the schema). If Schema B refers to an entity of Schema A (an entity in the namespace defined by Schema A), then Schema B must import Schema A. If Schema B does not refer to an entity of Schema A, then Schema A need not import Schema B. An import is required when any component from the namespace which it imports is used within the schema file.
• Type definition: A type definition is required when: 

1. The type is used by the consumer of the schema (either in an instance or an outside schema)
2. It is used as the type of an element or attribute
3. It is the base type of another type definition This requirement should not be ignored. When defining a type, it is important that all base types of that type be included in the schema. Even if they are empty (i.e. have no attributes or elements), they should be included. A base type may be empty if there are no requirements for elements or attributes of that type to appear in instances or outside schemas . Even in such a case, the type should still be included, preserving the type hierarchy.

A type definition may require other components: 

• The base type of the type. This type may be simple or complex. Also required are the base type of that type, and the base type of that type, etc.
• The SuperTypeMetadata attribute group
• Occurrences of attributes in the SuperTypeMetadata
• Occurrences of attributes in the type
• Occurrences of elements in the type

Global element definition Every element that represents a data model entity has a single definition in the schema. A global element definition is required when: 

• It is referenced in a type definition, as an occurrence of an element in a type 
• It is referenced by a non-data model schema, such as a schema for local extensions. A global element definition requires:

The type definition for its data type. -Global attribute definition Every attribute in the schema that represents a data model property is given a single definition. Each use of the attribute references that definition (using ref=)

A global attribute definition is required when:

• It is referenced in a type definition, as an occurrence of an attribute in a type 
• It is referenced in the SuperTypeMetadata attribute group

A global attribute definition requires:  The type definition for its data type -Occurrence of an element in a type

An occurrence of an element in a type is required when: 

•  An instance of a type uses the element. For example, if an instance of PersonType contains PersonName, then the element PersonName is required to occur in the type PersonType.
• An instance of a subclass of the type uses the element. For example, an instance of EnforcementOfficialType requires PersonName, then the element PersonName is required to occur in the type PersonType, since EnforcementOfficialType inherits PersonName from PersonType.

An occurrence of an element in a type definition requires:  The global definition of the element -Occurrence of an attribute in a type definition

An occurrence of an attribute in a type is required when: 

• An instance of a type uses the attribute
• An instance of a subclass of the type uses the attribute
• It requires: * The global definition of the attribute -Occurrence of an attribute in the SuperTypeMetadata

An occurrence of an attribute in the SuperTypeMetadata is required when:

• An instance of the SuperType uses the attribute
• An instance of any subtype of SuperType uses the attribute -Enumeration

An enumeration is required when: An instance may include the enumeration as a data value.

Global Justice XML Data Model (GJXDM) schema designers should become familiar with the tools available to search GJXDM for desired types and elements. These tools include the National Center for State Courts (NCSC) Wayfarer, the Schema Subset Generation Tool (which subsumed the functionality of the GJXDM Model Viewer), and the GJXDM spreadsheet that is part of the distribution for each release.

Regardless of which finding aid utilized, it is important to remember that each type in GJXDM inherits properties from types higher in the inheritance hierarchy; it is often the case that the property being sought is actually in a base type, and so may have an unexpected name. This concept, called contextual data elements (article #4), can frustrate some search attempts, but is beneficial because it fosters reuse within the model, represents important semantic relationships between general and specialized types, and makes the data model smaller. The XSTF is investigating a set of techniques and mechanisms that could be used to improve searches with contextual data elements.

The GJXDM and NIEM contain DocumentType components from which standard XML document schemas can be derived. The DocumentTypes include commonly used properties such as control and records management metadata, security and classification metadata, and general document descriptive metadata.

Within its own target namespace, each reference document schema will import the GJXDM or NIEM namespace (or a subset of them) and extend DocumentType for its root element. For example, a CitationDocument schema would import the GJXDM or NIEM namespace and create

(1) a CitationDocumentType that extends DocumentType and
(2) a complex root element CitationDocument of type CitationDocumentType. Consequently, CitationDocumentType inherits all of the standard metadata properties of DocumentType, however, each document designates its own target namespace, enabling local document customization and preventing name conflicts.

The Service Component Reference Model (SRM) is a business- and performance-driven functional framework that classifies service components with respect to how they support business and/or performance objectives. SRM is intended for use to support the discovery of government-wide business and application service components in IT investments and assets.

The SRM serves to identify and classify horizontal and vertical service components that support Federal agencies and their IT investments and assets. The model will aid in recommending service capabilities to support the reuse of business components and services across the Federal Government.

Source:

http://sites.google.com/site/consolidatedreferencemodelv23/Home/service…

The main components are the Service Description and one or more Service Interface Descriptions. A Service Description describes all aspects of a service that are not directly tied to the physical implementation or service interface while a Service Interface Description is a description of the physical implementation or service interface used in a specific implementation of a service. Since a service can implement multiple Service Interfaces, the Service Specification might contain more than one Service Interface Description.

NIEM 2.0 Changes (summary)

Over 10,000 changes from NIEM 1.0 to 2.0:

·         >5,000 component changes

·         >5,000 code list value changes

·         Universal + Common = NIEM Core (nc :)

·         NIEM Core tagged/searchable as U or C

Re-modeled the following types:

·         Measure

·         Location: Address, Latitude/Longitude, geographic coordinates

·         Date, Time

·         Facility, Correctional Facility (Structure removed)

·         Entity (Person or Organization)

·         ContactInformation

·         Telephone number

·         Revised many Core definitions

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

New component metadata fields (for search/discovery):

·         Key words - synonyms, slang terms, etc.

·         Usage descriptions - describe specific use cases

·         Examples - typical or sample values

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

Namespace adjustments:

·         Moved components to/from Universal, Common, domains

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

·         Geospatial namespace prefix replaced by geo:

·         Reviewed and revised Identifiers (IDs) and IdentificationTypes

·         Added new URI representation term and corresponding URIType

·         Integrated Global JXDM 3.1beta

·         Integrated ~30 resolved NBAC/NTAC NCCT issues

·         Inserted ANSI-NIST Biometric standard in new namespace

·         Removed some duplicate components from Core

·         Applied additional 50+ adjustments requested by FBI

·         More thorough integration with Core planned for next release

·         Reintegrated domains to new Core

·         Replaced inappropriate specializations with augmentations

·         Repaired applied augmentations

New code lists and types:

·         Department of Transportation: hazmat

·         Bureau of Alcohol, Tobacco and Firearms: explosives

·         Drug Enforcement Agency: drugs

·         National Geospatial Intelligence Agency (NGA): horizontal datums

Updated existing code lists to most current:

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

·         ISO 639-3 language codes

·         ISO 3166 country codes

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

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

·         Integrated 26 FBI NDEx issues and components.

·         Remodeled EncounterType for Immigration and People Screening domains.

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

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

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

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

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

Other New Features

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

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

·         Improvements to spreadsheet format.

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