search

INTERPOL-Innovation-Centre / ANSI-NIST-XML-ITL-Implementation

INTERPOL's implementation for ANSI/NIST ITL
GNU General Public License v3.0
15 stars 4 forks source link

Multiple Type 13 (Latents) #4

Open Jeremy-M-Int opened 3 years ago

Jeremy-M-Int commented 3 years ago

Can we have multiple Type 13 (Latents) in a NIST file? NIST authorizes it, the v5.03 also, but the new v6.00 only authorizes 1 Type 13 per file.

Jeremy-M-Int commented 3 years ago

What would be the impact on Type 2? Would there be multiple Type 2 records and how to link Type 2 and Type 13 records.

epcondon commented 2 years ago

The Interpol Standards 6.0 Working Group (WG) discussed this issue and the restriction to limit one mark per NIST transaction was a deliberate position. The rational was that this made the alignment of records within the transaction much simpler, easier to implement and more consistent with existing binary implementation. Where you have multiple marks in the same NIST transaction you would need a mechanism: a) to align the template(s) (Type 9 and Type 99) to mark images, and specific marks images to any other images, within the case construct. b) to align any search response to a specific mark; you could not rely just on the TCN/TCR but also need to reference the specific mark (increasing complexity in any system processing the transaction). It also means the one to one cardinality of TCN to TCR for search responses does not hold (making auditing and monitoring of outstanding responses more challenging). Given that this is anticipated as being a system to system interaction sending multiple NIST transactions (with the same case reference to tie them in the receiving system) was not seen as an undue overhead, helped the automation of search initiation upon receipt and also protected against very large sized NIST files which could have detrimental impacts on transmission mechanisms.

If the next revision of the standard wants to remove this limitation, a description of the mechanism to tie the record types together will be required and a decision if this new construct is mandatory for all transactions or just where there is more than one mark within a case. (The NIST standard appears to have such a mechanism)

Having multiple Type 2 records with in the same NIST transaction, whilst not prohibited by the NIST standard, would be a step change from the current and historic usage. I believe it was introduced (2013) to cater for where you may have multiple individuals/ identities associated with another record e.g. voice recording of a conversation. It would make implementation more challenging and also require definition of how to tie to the relevant other records in the transaction (assumed that same as for other record types). Ensuring that you did not have one mark associated with multiple type 2 would be challenging to enforce (and beyond the ability of schema / MRT files to validate)

Jeremy-M-Int commented 3 months ago

As discussed with the INSIWG: