niem / niem-releases Goto Github PK
View Code? Open in Web Editor NEWRepository for releases of the National Information Exchange Model
Home Page: https://niem.github.io/niem-releases/
Repository for releases of the National Information Exchange Model
Home Page: https://niem.github.io/niem-releases/
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.
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)
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 ...
NIEM code sets with duplicate codes:
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
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:
Update the US Census Bureau / US Department of Transportation commodity codes to the 2017 version.
2017 Commodity Flow Survey
Standard Classification of Transported Goods (SCTG)
SCTG COMMODITY CODES
CFS-1200
(10-04-2016)
https://www.bts.gov/surveys/commodity-flow-survey/2017-cfs-commodity-code-sctg-manual
NIEM currently uses the 2012 version.
Part of #35 (Update Core-related code tables).
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.
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."
From email submission:
Links for external standard types give popup errors.
PhysicalFeature elements overlap across Core, Biometrics, and Justice. Harmonize addressable overlap between Core and Biometrics elements for the 4.2 minor release.
Gross Vehicle Weight Rating (GVWR) is represented in NIEM by nc:VehicleMaximumLoadWeightMeasure.
It is hard to find the element. "GVWR" should be added to the elements keyword.
Submitted via NCCT #974.
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.
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:
Is it possible to remove one of the types to get rid of the duplication?
Continue harmonization work on physical feature elements across Core, Biometrics, and Justice.
See #28 for earlier harmonization in this area for NIEM 4.2
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:
Add new element biom:FingerprintPatternSubClassAbstract with substitutions:
Delete the now empty j:FingerprintPatternClassificationAugmentation and its type
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.
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.
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.
Add content submitted by the CDC for the Public Health Emergency Operations Center (PH EOC) Minimum Data Set (MDS) to the Emergency Management domain.
See https://forms.loinc.org/89724-9 for more on the requirements.
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.
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.
Update DNA and pedigree content in the Biometrics domain.
Update the Census county codes to the FIPS 2018 (May 2019) version.
https://www.census.gov/geographies/reference-files/2018/demo/popest/2018-fips.html
Part of #35 (Update Core-related code tables).
Attached is a zip file containing the first QTR of NCIC code tables.
NCIC NIEM 2019 Q1.zip
nc:LocationHeightMeasureType currently extends nc:MeasureType. It should extend nc:LengthMeasureType for access to the relevant unit codes.
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.
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
Recommend adding a new nc:PersonMilitaryIdentification element to nc:PersonType. The closest element available right now is nc:PersonOtherIdentification.
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.
Current:
mo:MGRSUTM100000MeterCoordinateValue ( mo : MGRSUTM10000MeterCoordinateType )
i.e.: 100,000 meter element of 10,000 meter type. The correct 100,000 meter type exists, but it was not used.
Submitted via NCCT #978
The following ndex code sets have been added:
The following ndex code sets have been updated:
The following ndex code sets have been moved to the ucr namespace (#59):
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.
NIEM currently includes code lists from GENC edition 3 update 7. The latest is update 10, published Dec 31 2018.
There is currently no element that uses type ucr:PersonAgeCodeType. Add new element and substitute for nc:TimeUnitAbstract.
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:
U.S. Department of Labor
2018 Standard Occupational Classification (SOC) system
https://www.bls.gov/SOC/
Code spreadsheet: https://www.bls.gov/soc/2018/soc_2018_definitions.xlsx
NIEM currently uses the previous 2010 edition.
Part of #35 (Update Core-related code tables).
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:
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.
Update code tables used by Core in a Core Supplement.
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.
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.
Controlled Substances - by DEA Drug Code Number
03-Aug-19
General info - https://www.deadiversion.usdoj.gov/schedules/
Codes PDF - https://www.deadiversion.usdoj.gov/schedules/orangebook/d_cs_drugcode.pdf
NIEM currently uses the 08-Feb-16 update.
Part of #35 (Update Core-related code tables).
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.
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.
(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:
For Age of a Person:
For Ethnicity of a Person:
For the Sex or Gender of a Person:
For the Race of a Person:
Is the FIPS 5-2 tab still valid?
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.
Review message elements in CBRN and EM for possible harmonization with nc:MessageType.
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.
U.S. Census Bureau
Federal Information Processing System (FIPS) Codes for States
https://www.census.gov/geographies/reference-files/2018/demo/popest/2018-fips.html
Part of #35 (Update Core-related code tables).
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.
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.