Search:
View  Edit  Attributes  History  Attach  Print  Search
Menu Main / MistakesInTheModel

HomePage

Documentation Index

Recent Changes RSS Feed

edit SideBar

Mistakes in the Model

Nothing the size of the NIEM is going to be perfect. There are a number of potential mistakes in the model. Here are a few:


Duplicate Elements

Sometimes, a domain contains an element that already exists in the core. Such Duplicate Elements are not necessarily mistakes, but bear close inspection.


Naming Convention Violations

There are times when the NIEM doesn't follow its own naming rules. Sometimes, it's something trivial. Sometimes not.

nc:PersonSurName

Should nc:PersonSurName really be nc:PersonSurnameName? Turns out the answer is "no." The naming standard specifies to delete subsequent repeat occurrences of words. But that does create another potential point of confusion. We have things like nc:PersonSurName, which hold data and have "Name" as their representational term, due to deleted word repetitions. But we also have nc:PersonName, which is of a complex type and holds other objects. And it also ends in "Name." It all complies with the naming standard, but effectively overloads the term "name," which is potentially confusing.

nc:PersonBloodType

Should really be nc:PersonBloodCategory, but people are familiar with the term "Blood Type". So maybe it should be nc:PersonBloodTypeCategory.

IDs not of IDType

The GJXDM created confusion when it used the same abbreviation, "ID", to replace both an identification and an identifier. An identification is an actual structure, while an identifier is just an alpha-numeric string that identifies something. So, for example, a Driver License is, itself, an identification. It's more than just the string. The concept includes an issuing authority, an expiration date, and other information. The Driver License number is the identifier.

The NIEM dealt with that confusion by using "ID" only as a replacement for an identifier. However, a few examples of IDs that are full identification structures remain in the model:

  • im:AlienIncidentSequenceID
  • j:ArrestSequenceID
  • im:ChainOfCustodySequenceID
  • j:ChargeSequenceID
  • j:CourtEventSequenceID

These are all pretty much just identifiers. So, it's less that the name is wrong and more that they're of the wrong type.


Association holding real elements instead of references

Associations are supposed to link objects together and only contain information about the association itself. Here are a few exceptions:

Associations containing an nc:Person object instead of a reference:

  • j:DriverLicenseDrivingIncidentAssociationType (e.g. j:DriverLicenseDrivingIncidentAssociation)
  • scr:PersonBiographicAssociationType (e.g. scr:PersonBiographicAssociation)
  • scr:PersonLeadAssociationType (e.g. scr:PersonLeadAssociation)

Associations containing an nc:Biometric object instead of a reference:

  • scr:PersonBiometricAssociationType (e.g. scr:PersonBiometricAssociation)

Odd Ducks

There are no elements of type nc:IdentityType, nor are any types derived from it. So why is it there? There's an IdentityReference, but to what would it point?



The niem-o-rama.org wiki is hosted and maintained by Tom Carlson Consulting LLC.