Status, artifacts, issues

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.