GJXDM Users Conference NCIC Schema Challenges

1. GJXDM Users Conference NCIC Schema Challenges Patrice A. Yuh FBI/CJIS pyuh@leo.gov

2. GJXDM Structure • Object Oriented Design There is a significant learning curve to understand the data dictionary • Inheritance Knowledge of inheritance is helpful when representing structures with multiple extended types • Recursive Types Vehicle and VehicleRegistration can be separate or together depending on business requirements • Value Restrictions GJXDM uses true or false for boolean value GJXDM Date Type only accepts a valid date in a specific format

3. GJXDM Elements vs. User Defined Elements • Re-Use of GJXDM Elements and Types Recommendation was to use GJXDM elements of the necessary type instead of creating a more appropriately named element. For instance we represent Activity Approval Date using Activity Result Date because it was an existing date not already being utilized. • Element Naming Contrast The NCIC to GJXDM element mapping wasn’t transparent; we represented elements such as Warrant Number and Protection Order Number with Activity ID and we often reused the same element to represent various NCIC entities such as the reuse of Activity Date • Choice of Element to use GJXDM has multiple structures that NCIC could use to represent the same data; an example is the various Organization structures that could be used for ORIs • User Defined Types User Defined elements and structures were generated and named following GJXDM standards. These elements were loosely based on the GJXDM element based on the ability to represent the data rather than naming conventions.

4. User Defined Structure • Structure Order User Defined elements are appended to the end of existing structure and always after GJXDM elements. • Order of Sequence The order of the user defined elements doesn’t seem consistent because of the fact that the elements are appended after GJXDM elements. For instance the ordering of the elements also makes grouping data impossible. Whereas GJXDM grouped the Activity Dates for Release Type when adding a Probation Expiration Date it falls after the Release Location and not in line with other related Activity Dates. In the example on the next slide you will see that while PropertySerialRangeID may be used in place of PropertySerialID, Property Serial ID is the first element of PropertyAssignedIDDetails and PropertySerialID is the last, Making the model inconsistent.

5. User Defined Structure • Example of User Extension <jxdm:PropertyAssignedIDDetails xsi:type="ncic:PropertyAssignedIDDetailsType"> <jxdm:PropertyFederalID> <!-- UNN   -->   <jxdm:ID>MD6810</jxdm:ID>   </jxdm:PropertyFederalID> <ncic:PropertyLotID> <!-- LOT   -->   <jxdm:ID>Lot456</jxdm:ID>   </ncic:PropertyLotID> <ncic:PropertySerialRangeID> <!-- SER-SER --> <ncic:MinimumRangeID>   <jxdm:ID>SER123</jxdm:ID>   </ncic:MinimumRangeID> <ncic:MaximumRangeID>   <jxdm:ID>SER223</jxdm:ID>   </ncic:MaximumRangeID>   </ncic:PropertySerialRangeID> </jxdm:PropertyAssignedIDDetails>

6. User Defined Structure • Containers GTRI recommended using containers for our message structures; for each GJXDM structure that we were using, we defined an instance of the structure to wrap the structure elements. Structures were often named beginning with a message type (i.e., EnterActivity) in order to best restrict the elements based on the type of message being represented. • Common Structure vs. Specific Structure Common elements/structures are captured under ncic.xsd; for those elements that were file specific, they are captured at the file level.

7. Object Relationships • Structure Association We represented associations between structures that are not offered in version 3.0.3 by generating a wrapper for related files • Customizing structures We altered Incident Subject to fit the required structure for Missing Person because it was the closet structure that could be used although it wasn’t a Missing Person object. • Multiple Files Relationship In NCIC, queries often generate hits from multiple files

8. Using Subclasses • Substitution Groups These constructs are more extensible than a traditional group that uses xsd:choice construct. However they do not allow for restrictions • Added Complexity Based on our design, instead of having one type that all the messages will extend and make them choices, we defined messages as subclasses containing other subclasses • Added extra tags One disadvantage of using substitution groups is the fact that extra tags are introduced in the XML file/input. Following the GJXDM Structure we often had to use several wrappers to represent one field.

9. Multiple Restrictions • Element Constraints/Restrictions They are implemented at the document schema level because they vary from one NCIC file to another. Often restrictions varied by message type meaning we either had to create a restriction for each type or only create a restriction for the message type requiring the most extensive restrictions • Subset Restriction Restriction cannot be applied to the generated subset unless you redefine the structure you want to restrict. Multiple Restrictions are often required in order to restrict to the lowest level. For instance to include only one field for a Person Image in PersonPhysicalDetails we had to first restrict PersonPhysicalDetails and then PersonBiologicalDetials and then PersonDigitalImage. • Multiple Restrictions This approach takes away the readability of the XML structure

10. Business Constraint • Platform Constraint NCIC is running on Mainframe so choices of tools were limited • Multiple schemas for NCIC The FBI approach was to represent schemas per file each capturing a message type. Namespace collaborations were introduced • Element Ordering Elements are entered in NCIC in a specific order different from the order of elements in GJXDM • Multiple Hit Association The type/file combination from a multiple hit looks very complex • Conditional Constraint Conditional data representation has not been captured in the extension schemas

11. Questions?