Create `Docket` merger for Florida

[MorganBennetDev]

Implement docket merging logic for Florida scraper output. This issue is only for Docket and possibly OriginatingCourtInformation objects; other data will be handled in different issues.

Also should compose the first phase of experimentation for #6878

[MorganBennetDev]

Similarly to Texas, it appears we will also need to include logic to disaggregate existing Dockets under the aggregate "District Court of Appeal Florida".

[MorganBennetDev]

Proposed mapping for Docket objects. Mappings for other objects will live in the associated issues.

Docket Field	Scraped Field	Notes
court	court_id	Minimal remapping required; dependent on Sixth COA being added to DB.
appeal_from	originating_cases	Florida can have multiple originating cases. We can either populate this field using some deterministic selection from that list, or we can combine all of the entries in appeal_from_str and track the appeals data using CaseTransfers
appeal_from_str		See above
originating_court_information		See above
assigned_to		Florida does not give us access to the names of judges presiding over cases so this will have to be blank.
parties	parties
date_argued		We could probably populate this by scraping the hearings endpoint, but I don't know if that's something we want.
date_filed	date_filed
date_last_filing	entries or date_filed	Use the max filing date of the docket entries or, if there are no entries, the filing date of the case. Filling this field may help with setting the frequency to rescrape cases.
case_name_short	case_name
case_name	case_name
case_name_full	case_name_full	Currently case_name and case_name_full have the same value in the Florida scraper.
docket_number	docket_number	From a cursory inspection, Florida docket numbers seem to be standardized (yay!) with S<Year>-<N> for SC dockets and <District>A<Year>-<N> for COA dockets so there should be minimal cleaning/rewriting needed.
docket_number_core	docket_number	See above
docket_number_raw	docket_number
docket_number_source	DocketNumberSources.ORIGINAL in (most likely) all cases.

Extras

Florida has a type field for dockets, which we are currently scraping but doesn't have a nice mapping into the Docket model. We could discard this field, we could add a case_type field to Docket, or we could do something else to capture that data but not add more fields to Docket (something similar to SCOTUSDocketMetadata maybe?).

[albertisfu]

Thanks @MorganBennetDev I have a couple of questions:

Florida can have multiple originating cases. We can either populate this field using some deterministic selection from that list, or we can combine all of the entries in appeal_from_str and track the appeals data using CaseTransfers

Do you know if the multiple originating cases can belong to different courts, or if all of them belong to the same originating court?

parties
Do Florida parties match exactly the fields and structure we currently merge, or are there additional or missing fields?

date_argued
We could probably populate this by scraping the hearings endpoint, but I don't know if that's something we want.

A case can have multiple hearings, right? If we take this approach, which date would we choose: the oldest or the newest one?

Use the max filing date of the docket entries or, if there are no entries, the filing date of the case. Filling this field may help with setting the frequency to rescrape cases.

Sounds good.

• Additionally, from the fields described above, we need to fill out Source, which in this case should be SCRAPER.

• Could you please provide some examples of the multiple values that exist for the type field? To see whether we care about this field or if we can ignore it.

• From the Juriscraper examples I’m seeing:
  case_uuid: Would it be helpful to store this in the pacer_case_id field? We could use it during the merge process as well.

  There are also other fields. Could you explain what these fields are about so we can determine whether we care about them?

  • class_group_type
  • class_group_type_id
  • classification_id
  • closed_flag
  • case_group_flag
  • location
  • location_id

[MorganBennetDev]

Do you know if the multiple originating cases can belong to different courts, or if all of them belong to the same originating court?

I was not able to find an example of this. Examples I did find that we'll need to handle:

• SC2026-0781 with different originating courts, but that appears to just be the appellate chain.
• SC2026-0077 with one originating court but multiple docket numbers in the DN field separated by semicolons and SC2025-0848 with comma separators (this will need to be handled). It appears to be inconsistent whether multiple originating cases from the same court are returned as separate entries.
• SC2021-0910, SC2021-0911, SC2021-0925, and SC2021-0870 all have the same case name and an originating case from the Fifth Judicial Circuit with docket number "352011CF000105AXXXXX". I assume this is actually multiple different originating docket numbers being redacted, but I can't know that for sure. There are other cases with X's in the originating docket number but this was the most notable one.

A case can have multiple hearings, right? If we take this approach, which date would we choose: the oldest or the newest one?

I can see tradeoffs to either approach, but I think the most recent date is the most useful information for someone viewing the docket to have. If we're open to DB changes, I'm partial towards something like date_first_argued and date_most_recently_argued to capture both. There's also the option of adding a modified version of the model I proposed in my interview (#6401) to capture all hearings since we now have (at least) two states where that data is available: Florida and (some of) California.

Could you please provide some examples of the multiple values that exist for the type field?

The types seem to be three "-" separated components. Examples of the last component are at florida/cases.py#L33, which normalizes them to a variant of the DocketType model.

From the Juriscraper examples I’m seeing: case_uuid: Would it be helpful to store this in the pacer_case_id field?

I don't like it having the same name as pacer_case_id, but I think that storing this would let us unambiguously merge dockets (yay) but we would still need a find_docket_object lookup for cases we already have. We could log an error if we find something with case_uuid and find_docket_object but they don't match.

There are also other fields. Could you explain what these fields are about so we can determine whether we care about them?

class_group_type	I can only find cases where the value of this field is "Appeal" so we should probably ignore it for now but log an error if we encounter a different value so we can review.
class_group_type_id	Numerical ID for class_group_type
classification_id	This varies between courts for the same value of caseClassification, so we normalize the caseClassification value into docket_type and also keep this value.
closed_flag	Whether or not the case is closed. This would be good to store to let us stop polling closed cases, but I don't think there's a good mapping to existing Docket fields. Maybe FloridaDocketMetadata?
case_group_flag	I can't seem to find a case where this field is true so I don't know what it does.
location	Appears to be the name of the court or courthouse the case is heard in. I think it's mostly redundant with courtID.
location_id	Numerical ID for location