Status, artifacts, issues

["Scott Came" <scott@justiceintegration.com>]

As you've all seen, I just posted a new baseline of the domain model and mapping to the main TC KAVI area.

The consolidation work and cleanup raised a number of issues, in the attached.  Also attached is a list of changes
that were made to the criminal and traffic models, to improve consistency and reuse of structures across the message
models.  (John and I had a conversation about this yesterday and decided some refactoring would be worth the effort.) 
I have saved baselines along the way, so none of the changes are set in stone.  I believe they do make the models (and
mappings) clearer, more consistent, and less error-prone.

Our biggest remaining gaps are:

*
Finishing up the juvenile model and mapping (still some gaps there...Jim, I have highlighted some issues for you in
the attached issues file, at the top)
* Modeling and mapping GetCaseQuery
* Domain expert review of the
consolidated models and all of the mappings (esp criminal, traffic, and juvenile)

I have not begun creating
schemas.  I've flat run out of time this weekend, and also do not want to spend time on them if there are additional
changes to the mappings.  I would guess it will take 6-8 hours to create the schemas from the mappings.

I
also agreed with John that I would produce a short (1-2 page) description of the ECF 3.0 architecture, for inclusion
in the IEPD overview document.  Look for that mid-week.

Thanks everyone.
--Scott

Issues for Jim:

--Associations in Juvenile not mapped; I took a stab at this (see more below)
--(Payment mapping) Classes Branch and FinancialInstitution are mapped out in spreadsheet, but do not appear in domain model...need to reconcile
--CardAccount.accountOwnerAddress is in domain model, but not mapped
--On GetServiceInformationQuery...
  --shouldn't ServiceInformationResponseMessage have 1..* ServiceRecipients
  --shouldn't each ServiceRecipient have either an Organization or Person?
  --if so, then can we use the abstract class technique used elsewhere (e.g., case type-specific stuff) to model this, and map to a schema choice compositor?
--We need UBL schemas

Other domain model issues:

--suggest refactoring of message classes, to simplify mappings and reduce potential errors:
  --move filingID from BaseMessage to ElectronicFilingMessage
  --have BlueQueryMessage and BlueResponseMessage extend BaseMessage
  --remove everything from BlueQueryMessage and BlueResponseMessage except queryID (the rest would now be covered by inheritance from BaseMessage)
--suggest removing "Blue" everywhere it appears in the model

Mapping issues:

--CallbackMessages: map ReviewedDocument.documentDocketID to DocumentDescriptiveMetadata/DocumentFileControlID?

--CourtPolicy: still need to identify an open standard vocabulary for describing PublicKeyInformation (Scott will do over the next week)

--CriminalFiling:
  --Note that supplied spreadsheets do not map associations between classes (just attributes).  Best judgement was used for associations.
      The whole mapping, in my view, needs to be reviewed by domain experts.
  --Defendant.defendantNumber and Defendant.localAgencyIDNumber are both mapped (in supplied spreadsheet) to PersonOtherID.  How are they
      to be distinguished?  Also, we need this element for the personIdentifier attribute (which links the criminal filing person to the
      Person in the ReviewFilingMessage).  **Mapping currently uses IDTypeText for this; should be confirmed by domain experts.**
  --Charge.amendedCharge is really another association between CriminalFiling and Charge (changed model and mapping to this effect)

--ExtendedPersonInformation: mapping done inconsistently between criminal and traffic.  Since we need much of the info in DriverAuthorizationType,
   mapped driversLicenseNumber and ...State to that structure as well.

--Traffic Citation
  --In supplied spreadsheets, "category" is called "CitationIssuedLocation", but all of the attributes start with "LocationOfViolation..."
    --Assume this means we're tracking where the violation occurred, since that's what all the definitions refer to
    --So we changed the name of the class to ViolationLocation in the domain model
    --So seems we should map to TrafficCitation/TrafficCitationViolation/IncidentLocation/... (which is what I've done...domain experts need to confirm)
  --Assuming subunit/unit distinction in supplied mapping spreadsheet is a typo (see element definitions to distinguish)
  --Supplied spreadsheets map violationNotCommittedInMyPresenceIndicator to IncidentType/IncidentOfficialPresentIndicator.  This indicates that
      this attribute should be on Citation.  Moved it there.

--GetServiceInformationQuery
  --If we make the suggested changes to the model noted above (in "issues for Jim"), then this becomes a lot easier and clearer to map

--Juvenile
  --Consider moving ArrestAgencyRecordID from JuvenileCase to JuvenileArrest (would make mapping easier, with no loss of fidelity)
  --Juvenile.sexOffenderRegistrationID is perfect illustration of role/relationship inadequacy in GJXDM...person is both a juvenile, subject,
      and registered offender all at the same time, but these go down separate inheritance hierarchies in GJXDM.  Since schema only supports
      single inheritance, it forces an extension to include information from one hierarchy in another.
  --Is it really appropriate to map Act/DelinquentAct to ChargeType?  The definition seems to fit IncidentType better...  For instance, what
      is the association between Act and Location?  Where the act took place, or where the charge is filed?  If the former, then it will be
      natural to map the Act-Location association to Incident/IncidentLocation.  You can get to Charge via Incident/IncidentResponse/IncidentArrest/ArrestCharge,
      or if the subject was never arrested, use an extension (this is what was done on the Incident Report IEPD.)
  --Jim/John/Christoph: I needed to finish up the mapping tab for Juvenile (associations were not even in there, so I put them in and
      took a stab at mapping); no mappings of classes to GJXDM types were present, which was leading to mappings that didn't fit in the same
      structure.  I made an attempt at these, which required reworking a few things.  If you need the former spreadsheet so you can tell exactly
      what changed, let me know.
** CRIMINAL FILING MODEL CHANGES **

Additional changes that seemed to make sense in addition to John's:

--CaseDefenseAttorney has only personIdentifier left, so deleted it (it's responding party attorney in the RFM)
--CaseParticipants has only personIdentifier left, so deleted it
--AlternateCaseNumber class only has prosecutionCaseNumber attribute now, so include it (0..1) in CriminalFiling
--CaseProsecutionAttorney has only personIdentifier left, so deleted it (it's the initiating party attorney in the RFM)
--Added Person.interpreterLanguageCode to RFM (0..1)
--per John's red item at bottom of spreadsheet...adding custodyStatusCode of type Text, and so removing defendantCustodyStatusIndicator
--added Defendant.driversLicenseCountryCode

Changes per my email reviewing merge results:

--per definition, defendantWarrantStatus is an indicator, so changed name to ...Indicator, and of type boolean
--made CriminalFiling the root of the structure
--per decision on DefendantNumber, assume CriminalFiling-Defendant association could be 1..*, so changed it
--changed navigability of CriminalFiling-Arrest assn, and made it 0..1 (filings can be made w/o defendant being arrested)
--removed personIdentifier from ArrestInformation, since that can be obtained from Defendant via assn
--reversed nav on CaseCharges-Defendant, since that will make GJXDM mapping easier (ChargeSubjectReference)
--changed cardinality on CriminalFiling-CaseCharges to 1..* (filing can include several charges...JG confirm)
--changed cardinality on ArrestInformation-CaseCharges to 1..* (subject can be arrested for multiple charges...JG confirm)
--changed Defendant.driversLicenseNo to .driversLicenseNumber, and changed type to IDType
--changed Defendant.localAgencyIDNumberForDefendant to .localAgencyIDNumber (who else would it be for, since it's an attribue of Defendant?)
--changed type of CriminalFiling.prosecutionCaseNumber from Text to IDType (consistent w/ other models)
--changed type of ArrestInformation.arrestingAgencyID from Text to IDType (consistent w/ other models)
--changed type of ArrestInformation.bookingAgencyID from Text to IDType (consistent w/ other models)
--changed ArrestInformation to Arrest
--changed Arrest to JuvenileArrest in the juvenile filing model, to avoid class name conflict
--changed Defendant.driversLicenseState to ...Code
--changed CaseCharges to Charge (consistency in naming classes singular, no need for "Case" preceding)

** CRIMINAL FILING MODEL REMAINING ISSUES **

--search for "JG confirm" in the above
--do we really need Arrest-Defendant association now that Arrest-Charge and Charge-Defendant are 1..* and 1..1?
--we need a definition for custodyStatusCode (which we're now using in Juvenile and Criminal)

** TRAFFIC MODEL CHANGES **

Changes for consistency etc:

--changed CitationIssuedLocation to ViolationLocation, to be consistent with names of attributes
--associate ViolationLocation with Citation, not Offender
--changed Statute to ViolatedStatute
--associate ViolatedStatute with Citation, not Offender
--associate CitationAgency with Citation, not Offender
--reverse Citation-Offender navigability
--remove Citation-Vehicle association, since that connection can be made via Offender
--associate DrivingIncident with Citation, not Offender
--make Citation the root, not Offender
--deleted definitions on CitationAgency and CitationIssuingOfficial (referred to attributes or otherwise didn't make sense)
--changed type of Citation.timeOfViolation from int to Time
--changed DrivingIncident.speedLimit and .offendersSpeed to associations to a new SpeedRate class (idea borrowed from GJXDM, cleaner, allows for units)
--changed DrivingIncident.laserIndicator, .radarIndicator, .accidentInvolvedIndicator from Text to boolean
--changed CitationAgency.lawEnforcementAgencyORIID from Text to IDType
--changed CitationIssuingOfficial attribute names to be consistent in format with all other attributes
--changed type of CitationIssuingOfficial.violationNotCommittedInMyPresenceIndicator from Text to boolean
--changed type of Insurance.ownerProofOfInsuranceIndicator from Text to boolean
--changed type of Insurance.operatorProofOfInsuranceIndicator from Text to boolean
--added Offender.offenderOperatorLicenseCountryCode
--changed Offender.offenderOperatorLicenseStateText to ...Code
--changed CitationCourt to CitationCourtAppearance (that's all the court information left)
--removed CitationCourtAppearance.yearOfCourtAppearance (contained within the date)
--changed type of CitationCourtAppearance.dateOfCourtAppearance from Text to Date
--changed type of CitationCourtAppearance.timeOfCourtAppearance from Time to Date
--changed cardinality of Citation-CitationCourtAppearance from 1..1 to 0..1 (sometimes no court appearance is scheduled...JG confirm)
--changed OffenderInformation to Offender
--changed type of Offender.socialSecurityNumber from int to Text (consistent w/ Criminal)
--added Offender.weightUnitCode and .heightUnitCode (consistent w/ Criminal)
--renamed Offender.ethnicCode and .ethnicText to .ethnicityCode and .ethnicityText
--changed Offender.dateOfLicenseExpiration to .licenseExpirationDate (consistent with other attribute names)
--associate CitationIssuingOfficial directly with Citation, then associate to CitationAgency (this is how GJXDM does it, via PersonAssignmentUnit.Organization)
--moved CitationIssuingOfficial.violationNotCommittedInMyPresenceIndicator to Citation (see mapping notes)
--moved narrativeSummaryOfViolation from ViolatedStatute to Citation (it's not a property of the statute, but of the incident itself)
--moved correctableOffenseIndicator and correctableOffenseText from ViolatedStatute to Citation (not property of statute, but incident)
--factored Insurance out as associations between vehicle and insurance (seems to be how supplied mapping spreadsheets want it to be)
--associate Vehicle with DrivingIncident rather than Offender (that's how supplied mapping spreadsheets do it)

** TRAFFIC FILING MODEL REMAINING ISSUES **

--why is there Citation.dateOfCitationIssue but no .timeOfCitationIssue?
--ViolatedStatute.offenseLevel seems to be a code.  Should we change it?
--Do we still need Offender.heightDescriptionText and weightDescriptionText?
--Confirm cardinality of attributes and associations
--Is the Offender-Vehicle association owner? operator? something else?  does it matter (hint: it will for mapping)?
--search for "JG confirm" in the above

** CHANGES PUT IN TO CONSOLIDATE "EXTENDED" PERSON INFO ACROSS CRIMINAL, TRAFFIC, AND JUVENILE **

--create ExtendedPersonInformation model, and consolidated all information there

--removed dateOfBirth, height, weight, raceText, sexCode, ssn, hairColorCode, eyeColorCode, ethnicityText from Juvenile
   (now in ExtendedPersonInformation)
--removed associations to DriversLicense and ScarsMarksTattoos from Juvenile (now in ExtendedPersonInformation)
--remove FingerPrint from the Juvenile model, since that's now covered by new ExtendedPersonInformation structure
--removed similar elements from Defendant (CriminalFiling diagram)...these are now in ExtendedPersonInformation
--removed similar elements from Offender (TrafficCitation diagram)...these are now in ExtendedPersonInformation
--factored remaining Offender drivers license information into separate class to isolate it
--remove Juvenile.languageNeededCode, since it is now in the core (ReviewFiling) model (Person.interpreterLanguageCode)

** GENERAL ISSUES / TODOs **

--still need to take a cardinality pass at all of the attributes
--make sure datatypes and names are consistent across models
  --zipcode
--should CitationIssuingOfficial.violationNotCommittedInMyPresenceIndicator be moved to ViolatedStatute or Citation?  Shouldn't have the word "My" in an attribute name...
--Do we want to reuse the Drivers License structure from Juvenile in Criminal and Traffic?