This is a one-page introduction to the major NIEM model concepts.
Namespaces act like collections, logically grouping related properties and types together. They also have additional characteristics, like a target namespace URI (a unique ID) and a namespace prefix (used as shorthand for the URI).
Components are often referred to by their qualified names, like nc:Person. Using the namespace prefix in front of the component name helps to identify and distinguish it, especially in cases where the same name may appear in multiple namespaces.
- The
Human Servicesdomain is a namespace.- In the 4.0 release, it uses the namespace prefix
hsand defines components like propertyhs:RequestedServiceand typehs:PlacementType.
NIEM primarily creates namespaces in order to group components together based on governance.
A domain or IEPD may reuse any component from any NIEM release namespace. Reuse is not limited to only Core and the most closely-related domains.
A property represents a concept, idea, or thing. It defines specific semantics and appears in exchanges as the tag or label for a field.
Properties may be more commonly known as as elements, attributes, fields, tags, keys, or keywords.
One of the properties defined in Core is
PersonBirthDate. It represents a person’s birthday and will carry that value in an exchange.
On its own, a property has meaning but no inherent structure.
Without a type, any kind of value could be provided for property
PersonBirthDateabove, like the following:
- 06/30/1950
- 1950-06-30
- June 30th, 1950
- green (without a type, any value is valid)
A property must have an assigned type in order to have both clear semantics and a well-defined structure.
A type defines a structure - an allowable set of values. A type might describe
a simple value (e.g., a string, a number) or a complex object (e.g., PersonType).
- A type for a person’s last name property might be a string.
- A type for an address property might represent an object, with its own set of properties for street, city, state, and zip.
Facets are additional constraints that may be defined on simple types (like strings or numbers) to limit the allowable values.
They can do such things as limit a string to a pre-defined code list, constrain a number to a given range, or create a pattern that must be followed.
- A telephone number type might define a facet that creates the pattern (ddd) ddd-dddd.
- A week-day type might define facets that constrain a string down to the codes MON, TUES, WED, etc.
- A latitude type might define facets that constrain a number to the range -90 to 90.
Adapters are the mechanism NIEM uses to allow content from external standards without causing conformance validation errors.
An adapter is a type that contains an external property. It is marked as an adapter in the schema so that NIEM conformance rules skip over its external (non-conformant) contents instead of throwing errors. Otherwise, an adapter type looks and acts like a standard NIEM type.
geo:SurfaceTypeis an adapter type in NIEM that contains elementSurfacefrom GML, an external standard. It can be used normally by other NIEM components. Because it is an adapter type, NDR conformance tests will not throw errors if the element from the GML external standard does not follow NIEM rules.
Associations are relationships between properties. An association may have additional characteristics that further describe the relationship.
A marriage can be an association between two people, with additional characteristics like marriage date.
Augmentations are NIEM’s mechanism to add additional content to a type defined by another namespace.
Augmentations are done via element substitution (in XML). Almost every type with complex content (sub-properties) in NIEM contains an augmentation point element. These augmentation point elements serve solely as hooks, to be later replaced by additional content defined elsewhere.
If a domain or an IEPD wanted to define additional properties about a person, it would create a new augmentation element and substitute it for
nc:PersonAugmentationPoint(contained bync:PersonType). Any place nc:PersonType is used, the new augmentation may be used as well.
An augmentation may be either the new property to add (e.g., my:PersonCustomCode) or a container (e.g., my:PersonAugmentation) that has a set of sub-properties.
Adding additional content to a type is typically done using type extension, but NIEM abandoned that approach due to its limitations. Type extension is limited to a single parent type; augmentations from several different namespaces can be used together because element substitution allows multiple occurrences.
Local terminology is a word, phrase, acronym, jargon, or other string of characters specially documented in a namespace because it is not defined in a standard dictionary. Literals or definitions are provided.
Because NIEM is designed to be widely reusable, it is important to make sure semantics are clear, even outside of the given subject matter area.
Core defines “GSM” as a local term with literal “Global System for Mobile communication”.
Once defined at the namespace level, local terminology does not need to be redefined each time it is used.
Metadata is data about data. It might describe such things as who provided the content, and when it was last updated.
Because this is data that could potentially be provided about any and every property in the model (e.g., when the person name was last updated, when the address was last updated, when the vehicle tag was last updated, and so on), metadata should be defined separately from other types. This avoids duplication and clutter across the model.
Almost all properties in NIEM (those with complex types) have the ability to reference one or more metadata properties.
Core defines metadata element
nc:Metadata, which contains properties likenc:ReportedDateandnc:SourceText. Any element, likenc:Person,j:PersonEmploymentIndicator, or an element defined in an IEPD, may use this to provide metadata.
References are used in instances or messages to point to content defined elsewhere.
A common reason to use references is to avoid repeating data. In addition to avoiding duplication, it clearly links multiple occurrences to the same object. Just because two properties have the same content (e.g., the same name), they are not necessarily the same.
In order to use references, a unique ID must first be assigned to where the content is defined. That ID can then be references elsewhere. Almost all properties in NIEM (those with complex types) carry attributes that let you define an ID or a reference.
In NIEM, multiple representations of a concept are typically handled via abstract elements and substitution groups. This allows for replacement of the abstract element in an instance with one or more of the substitutions.
Abstract element nc:PersonHairColorAbstract has multiple substitutions, allowing for free-text or code value representations.
In cases where the concept not only has multiple representations but also additional properties describing the concept, a new type is needed to bundle the representations and additional properties together. This is the representation pattern.
The major difference between the two examples is that there are other date-related properties in addition to the multiple date representations; hair color has multiple representations only.
NIEM differentiates between an object and a role of an object. Roles are used to represent a non-exclusive function or part played by an object. An object may have one or more roles. A role may a function of one or more objects.
Things like cars and chairs are items in NIEM. In certain situations, however, they may be used as a weapon and/or function as evidence in a trial or hearing.