Giter Site home page Giter Site logo

niem-releases's People

Contributors

cb2 avatar cdmgtri avatar webb avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

niem-releases's Issues

Move j:ChargeNCICText to substitution group

There is an existing substitution group under j:ChargeType called ncic:ChargeNCICAbstract. Recommend removing j:ChargeNCICText from j:ChargeType and adding it to this substitution group.

Also consider renaming the substitution group to something more generic, so that other kinds of charge codes could also be substituted here as well - j:ChargeCodeAbstract.

changelog suggestion: use git!

I like that the detailed changelog is included in this repo. Would it also be possible to upload each release as a CSV on GitHub to view the changes via GitHub's version control? (see this example)

Review how to handle non-unique codes

NIEM includes several code sets that do not have unique code values, like Hazmat codes and county codes. For example, there are currently 50 county "001" codes in NIEM, one for each state.

Review if there are better options for representing these kinds of codes, like ...

  • Use the NIEM Code Lists specification to represent these codes in a CSV format, along with additional columns. For the county code example, adding the state code column would be useful.
  • Look for alternate code sets with unique values that might be a better fit for an XML schema representation.
  • Use a hybrid approach - create unique enumerations for the schemas and instances. Provide a link between the new enums and the original codes and definitions in a Code Lists CSV file.

NIEM code sets with duplicate codes:

  • fips:USCountyCodeNumericSimpleType, including
    • 001 - Adair County
    • 001 - Adams County
    • 001 - Albany County
  • hazmat:HazmatUNCodeSimpleType, including
    • NA1760 - Compounds, tree killing, liquid or Compounds, weed killing, liquid
    • NA1760 - Compounds, cleaning liquid
    • NA1760 - Chemical kit
    • NA1760 - Ferrous chloride, solution
  • dea:DrugCodeSimpleType, including
    • 2100 - Talbutal
    • 2100 - Butalbital
    • 2100 - Butabarbital (secbutabarbital)
    • 2100 - Vinbarbital
  • ncic:VMOCodeSimpleType, including
    • 100 - 100
    • 100 - 100 SERIES
    • 100 - 100 E SERIES
    • 100 - 1000
    • 100 - 1000 & 1000GL

NCIC 4th Qtr Code Tables Update for NIEM 4.2

Provided is the updated NCIC codes for the 4th quarter. One of the biggest changes between what is currently in NIEM and the attached updates is the “0” vs “O” (zero vs O). In the current postings all codes that should have contained “O”. An example would be the code for the color brown. The code uses zero in place of the letter “o”. The tables attached have the “O” were it should be.

Attached is the NEIM/NCIC mapping spreadsheet you requested help with.

NCIC NIEM 2018 Q4.zip
ncic-niem-mapping_20181106_MissingCorrespondingElements.xlsx

Update Justice elements of type ncic:CountryCodeType

Type ncic:CountryCodeType (country codes) replaced ncic:CTZCodeType (country codes and a set of North American state/province/tribe codes). Need to update the elements that now use this type to reflect the changes.

Recommendations are to:

  1. Delete the following elements since the code set no longer includes states:
  • j:LocationStateNCICLISCode
  • j:LocationStateNCICLSTACode
  • j:LocationStateNCICRESCode
  1. Update the element definition to remove "state or":
  • j:PersonBirthplaceCode - A state or country of a person's birth.
  1. Add a new element and substitute it for abstract element nc:CountryRepresentation. This will make the NCIC country code set available anywhere the Core nc:CountryType is used in the model or an IEPD:
  • j:LocationCountryCode - A country, territory, dependency, or other such geopolitical subdivision of a location.

nc:AssociationType should extend structures:ObjectType instead of structures:AssociationType

structures:ObjectType and structures:AssociationType are similar - except for name of AugmentationPoint

When nc:AssociationType is instantiated, it has two elements/properties with the same name:
nc:AssociationAugmentationPoint and structures:AssociationAugmentationPoint

When object types are used in other tools (e.g. Java) to implement the interface - the two properties with the same name are not allowed.

If nc:AssociationType was extending structures:ObjectType then nc:AssociationAugmentationPoint provides a place to augment nc:AssociationType, there would be no duplicate properties with the same name and structures:AssociationType could be deprecated.

Rename nc:Entity as LegalEntity

From email submission:

The NIEM definition of a nc:Entity is "A data concept for a person, organization, or thing capable of bearing legal rights and responsibilities." This would be better named LegalEntity instead of Entity. As it is now, it is confusing with the typical IT definition of an Object Type. The typical IT definition of an Entity is just the first 3 words of the NIEM definition: "A data concept."

Harmonize physical feature elements

PhysicalFeature elements overlap across Core, Biometrics, and Justice. Harmonize addressable overlap between Core and Biometrics elements for the 4.2 minor release.

Harmonize em:OrganizationName

Element em:OrganizationName is used in type em:RosterType.

This could be replaced by element nc:OrganizationName (both have very similar definitions) and the EM element could be removed as a duplicate.

Harmonize nibrs and ucr CriminalActivityCategoryCodeType

The NIBRS and UCR namespaces both contain a code set for CriminalActivityCategoryCodeType.

The code values are identical. The definitions have some formatting differences (mainly capitalization) but are semantically the same, with one exception:

  • ucr:CriminalActivityCategoryCodeSimpleType: T - transport/ transmitting
  • nibrs:CriminalActivityCategoryCodeSimpleType: T - Transporting/Transmitting/Importing

Is it possible to remove one of the types to get rid of the duplication?

Harmonize physical feature elements

Continue harmonization work on physical feature elements across Core, Biometrics, and Justice.

See #28 for earlier harmonization in this area for NIEM 4.2

Add substitution groups for fingerprint classification codes

Both Biometrics and Justice have elements for fingerprint classification codes.

Justice currently creates an augmentation to make their codes accessible with element biom:FingerprintPatternClassification.

Creating abstract substitution groups in the Biometrics domain would group these related codes together and remove the need for the augmentation.

Recommendations:

Add new element biom:FingerprintPatternGeneralClassAbstract with substitutions:

  • biom:FingerprintPatternGeneralClassCode
  • j:FingerprintPatternCode

Add new element biom:FingerprintPatternSubClassAbstract with substitutions:

  • biom:FingerprintPatternSubClassCode
  • j:FingerprintClassificationCode

Delete the now empty j:FingerprintPatternClassificationAugmentation and its type

Reword three Immigration domain element definitions

The following elements definitions were submitted for review:

im:BookOutOfficer (im:ICEEmployeeType)

A date on which the alien was booked out by Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE) Employee.

im:SearchOfficer (im:ICEEmployeeType)

A date on which an alien was searched by Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE) Employee during booking.

im:BookInOfficer (im:ICEEmployeeType)

A date on which the alien was booked in by Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE) Employee.

Review measure value representations and types

From email submission:

When we need to declare the nc:MeasureValueAbstract component of the nc:MeasureType in a nc:PersonAgeMeasure, we use nc:MeasureValueText for our string values, and we use nc:MeasureIntegerValue for our integer values.

However, nc:MeasureValueText is of type nc:TextType whereas nc:MeasureIntegerValue is of type niem-xs:integer. So at the equivalent stage in the processing of the string and integer ages, the string ages are decoupled from XML using the nc:TextType, but the integer age is still coupled to XML using the niem-xs wrapper type on the xs:integer.

So perhaps we need something like nc:IntegerType which, like nc:QuantityType, extends nc:NumericType but restricts allowable values to integers. Similarly, it seems like nc:MeasureDecimalValue should be of type nc:NumericType instead of being of type niem-xs:decimal.

Recommend renaming files

The files in the root should not include the version name. This way, different releases can be checked out using the branches/tags, and all the references to the files will remain the same.

Update GENC

GENC Standard, Edition 3.0 Update 7

This update to the content of the GENC Standard is a consequence of one ISO notification, dated 17 March 2017, as well as the 13 June 2017 meeting of the U.S. Board on Geographic Names' (BGN) Foreign Names Committee, where a number of naming determinations were made.

Harmonize angles, courses, headings, and related components

A lot of custom angular measurement types exist for properties with related but slightly different semantics. It may be better to create some generic types that could be reused. These types would need to support multiple representations.

This would be similar to how NIEM uses nc:DateType as the generic type for date properties. This one basic type provides consistency and reusability, and also allows for users to choose the individual representation (date, datetime, time, year, etc.) that meets their requirements.

MilOps is moving ahead with some solutions for their domain in 4.1, but recommends harmonization in Core.

Interpretation of percent values is underspecified

In NIEM 4.0 (1a0ec9e), elements nc:ProbabilityPercent and nc:Percent, and attribute nc:confidencePercent each have a type based in xs:decimal. However, documentation of these elements aren't clear in how to interpret their values. nc:Percent is clear (100% = value 100), but the others are vague. Suggest adding a PercentType that has a clear interpretation as "0" means 0%, "100" means 100%, etc.

Note that there are many values across NIEM that are percents, and there's no clear way to interpret them all.

cyfs references in human services namespace

In commit 0324336

Definition of element hs:BiologicalParentDeterminationMethodText contains reference to cyfs.

A narrative alternative to cyfs:BiologicalParentDeterminationMethodCode to describe the method by which a biological relationship between a parent and child is legally determined.

Definition of element hs:SchoolResourceOfficerEducationOrganizationAssociationAugmentationPoint contains reference to cyfs.

An augmentation point for type cyfs:SchoolResourceOfficerEducationOrganizationAssociationType

Add a Biometrics person augmentation for biometric information

Suggest creating a new biom:PersonAugmentation to include element biom:Biometric. This would make biometric info easily accessible wherever nc:PersonType is used.

Also suggest removing biom:PersonBiometricAssociation. It's type extends nc:AssociationType but doesn't add anything other than its augmentation point.

Update FBI NDEx codes

Code sets added

The following ndex code sets have been added:

  • ActivityOrganizationDescriptionCodeType
  • ActivityPersonDescriptionCodeType
  • LightingCodeType
  • PersonOrganizationDescriptionCodeType
  • PersonRelationshipCodeType
  • WarrantCategoryCodeType
  • WarrantStatusCodeType

Code sets updated

The following ndex code sets have been updated:

  • DispositionCodeType
  • ItemCategoryCodeType
  • OffenseCodeType
  • VSTCategoryCodeType

Code sets moved

The following ndex code sets have been moved to the ucr namespace (#59):

  • JudicialDistrictCodeType
  • NIBRSReportCategoryCodeType

Staged for removal in NIEM 5.0

The following ndex code sets are no longer being used and are scheduled to be removed in NIEM 5.0.

See issue #61 for 5.0 status.

  • ApprovalStatusCodeType
  • ChargeCategoryCodeType
  • ConveyanceFuelCategoryCodeType
  • GrainCategoryCodeType
  • ItemGenderUseCodeType
  • ItemValueCategoryCodeType
  • KeepsakeCategoryCodeType
  • PretrialReleaseStatusCodeType
  • RiskLevelCodeType
  • SecuritySystemStatusCodeType
  • ServiceUtilityCategoryCodeType
  • SubjectAttitudeCodeType

Move nc:PleaCategoryCodeType to the Justice domain

Code type nc:PleaCategoryCodeType is defined in Core but is only used by Justice element j:PleaCategoryCode.

Recommend moving the type to the Justice domain with the rest of the plea-related components:

  • j:PleaType
    • j:PleaDescriptionText (nc:TextType)
    • j:PleaGuiltyIndicator (niem-xs:boolean)
    • j:PleaNegotiatedIndicator (niem-xs:boolean)
    • j:PleaNoContestIndicator (niem-xs-boolean)
    • j:PleaRecommendationText (nc:TextType)
    • j:PleaCategoryAbstract
      • j:PleaCategoryCode (nc:PleaCategoryCodeType) (j:PleaCategoryCodeType)
    • j:PleaAugmentationPoint

Fix special characters in definitions

Some of the definitions include unintentional smart quotes, long dashes, or other characters that appear in the schemas as entity numbers (e.g.,  ). Replaced these with their standard character counterparts.

Special characters have been maintained for country names, language names, and other cases where they serve a purpose.

Special characters replaced in definitions for:

  • j:DevelopmentalDisabilityType
  • j:DevelopmentDisability
  • biom:ImpressionCaptureCodeSimpleType - enumeration 42
  • biom:ImpressionCaptureCodeSimpleType - enumeration 41
  • mmucc:NonMotoristLocationCodeSimpleType - enumeration 11
  • mmucc:NonMotoristLocationCodeSimpleType - enumeration 10
  • mmucc:NonMotoristActionBeforeCrashCodeSimpleType - enumeration 8
  • mmucc:OccupantProtectionSystemUseCodeSimpleType - enumeration 7
  • mmucc:DriverLicenseClassCodeSimpleType - enumeration R
  • mmucc:DrivingRestrictionCodeSimpleType - enumeration 8
  • nibrs:LocationCategoryCodeSimpleType - enumeration 09
  • st:TrafficAccessControlCodeSimpleType - enumeration 1
  • st:SurfaceCodeSimpleType - enumeration 3
  • st:SurfaceCodeSimpleType - enumeration 4
  • st:SurfaceCodeSimpleType - enumeration 5

The files below show more information about the definitions fixes, definitions valid and unchanged, and definitions that need to be fixed but are locked in the minor release.

chars-fixed.txt
chars-locked.txt
chars-valid.txt

Rename j:SupervisionFineAmount as j:SentenceFineAmount

Element j:SupervisionFineAmount is contained by type j:SentenceType and has definition

"A pecuniary criminal punishment or penalty payable to the public treasury"

Changing the element name to j:SentenceFineAmount might be a better fit.


j:SentenceType also contains element j:CourtCostAmount (element only appears in this type). "Sentence" might also be used as the class term here. Current definition:

An amount of expenses of prosecuting the case that a convicted subject may be ordered to pay as reimbursement.

Review street name elements

Sometimes NIEM fields use the term "StreetName", but the definition does not indicate whether or not this includes the street number component of the address. Is it more of an Address Line 1 field, or is it purely the StreetName? An example is the m:PortStreetName.

Add new nc:PersonContactInformation element to nc:PersonType

nc:PersonType has ways to represent home, work, and emergency contact information. Need to add a generic element for contact info in case the type isn't known. Suggest adding this to a Core Supplement for the 4.2 release.


Current:

nc:PersonHomeContactInformation (nc:ContactInformationType)

A means of contacting a person at home.

nc:PersonEmergencyContactInformation (nc:ContactInformationType)

A means of contacting someone in the event of an emergency.

nc:EmploymentContactInformation (nc:ContactInformationType)

A means of contacting a person at work.


Proposed addition:

nc:PersonContactInformation (nc:ContactInformationType)

A means of contacting a person.

Review date part representation terms

From email submission:

I disagree that the Date Component fields should be represented as Date fields. They are "Date Part" fields which are usually represented by an integer value. Example: nc:DayOfMonth is a Value, not a Date.

NIEM 4.2 code list feedback question

(from an email submitted to [email protected])

Some of the code sets are still different across domains and I am wondering if they will be addressed?

Here are just a couple examples.

For States of the United States of America:

  • NCIC has UnitedStatesCodeSimpleType NB for Nebraska
  • USPS has USStateCodeSimpleType NE for Nebraska
  • This forces transformations to occur when we believe there shouldn't be any required.

For Age of a Person:

  • UCR has descriptive codes such as BABY, NEONATAL, NEWBORN and UNKNOWN
  • According to the NIBRS Technical Specifications Manual, NIBRS is expecting to receive a 2-digit code such as BB, NB, NN or 00 and I am unable to find any equivalent codes in NIEM.

For Ethnicity of a Person:

  • NCIC has ETNCodeSimpleType with H and N
  • UCR has EthnicityCodeSimpleType with H, N and U
  • J has PersonEthnicityCodeSimpleType that has 34 options to choose from
  • When we are required to submit information to NCIC, how can we submit Unknown when NIEM does not recognize it as a valid NCIC Code, when it fact, it is.

For the Sex or Gender of a Person:

  • NDEX has SEXCodeSimpleType with F, G, M, N, X, Y and Z
  • NCIC has SEXCodeSimpleType with F, M and U
  • J as PersonSexCodeSimpleType with Female, Male, Other and Unknown

For the Race of a Person:

  • NDEX has RACCodeSimpleType with A, B, I, P, U and W
  • NCIC has RACECodeSimpleType with A, B, I, U and W
  • J has PersonRaceCodeSimpleType with Asian, Black, Native American, Unknown and White

Is the FIPS 5-2 tab still valid?

  • I thought most of the FIPS code lists were withdrawn and replaced by either NIST or ANSI standard code lists?

Change nc:PolygonCoordinate to use nc:LocationType instead

Currently, nc:PolygonRegionType contains nc:PolygonCoordinate (nc:Location2DGeospatialCoordinateType).

MilOps requested that the lat/long coordinate representation be generalized to a location. This would provide more flexibility, allowing for other representations like grid coordinates. It would also still allow for the current lat/long coordinate representation since nc:LocationType contains an element for a lat/long coordinate.

Potential solution:
Change nc:PolygonCoordinate to nc:PolygonNodeLocation (nc:LocationType).

Other terms to consider for the name instead of "Node": Point, Vertex.

Release 3.2 Alternative Format Version Issue

Taking it up here.

Several attributes seem to be incorrect or out of date.

For example, in the edxl-cap.xsd document, the imported namespace for 'cap' is version 1.1, and in the reference documents the path is correct 'external/cap/1.1', however in the .xslx tab Namespace, cap has a Version Release Number of 1.0, making it impossible to programmatically access the correct external schema.

Host Alternative Formats

Please host the alternative formats in the NIEM/NIEM-Releases repo as well, would be very helpful for developers.

The alternative formats are tools to allow developers to programmatically understand and utilize the complex schema relationships within NIEM.

For example, understanding that a message is an external schema (appinfo:externalAdapterTypeIndicator) corresponds to 'true' in the NamespaceIsExternallyGenerated column in the Namespace worksheet, as well as a lack of a VersionURI.

Harmonize nibrs and ucr LocationCategoryCodeType

The NIBRS and UCR namespaces both contain a code set for LocationCategoryCodeType.

The code values are identical. The definitions have some formatting differences (capitalization and spacing) but are semantically the same.

Is it possible to remove one of the types to get rid of the duplication?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.