johnhawkinson
commented
7 years ago footnote: it's also possible to run "combined docket reports" for multiple cases. I have not tried, but I assume these do the wrong thing in RECAP (I cannot imagine them possibly doing the right thing, given the lack of subdoc support).
For instance, in Cadden, checking subcases -1 and -2 from the iquery.pl form leads you to a docket page like this: https://ecf.mad.uscourts.gov/cgi-bin/DktRpt.pl?166118;166117
which, if run, gives you either both docket reports consecutively, or if you check the "Combined docket report" checkbox, merges the two reports together. Sorted by the specified sort order.
Even more frightfully from the RECAP perspective, this combined report feature is not limited to subcases. You can enter arbitrary unrelated caseids seperated by semicolons in the URL parameter string for DktRpt.pl and other queries.
Although probably nobody does this, so it's not a big worry. But the data model should accommodate it. And I think it screws up receipts (that is, they are not reliable indicators of the case to which the document belongs, if indeed the document belongs to a single case in the combined report).
mlissner
danieldjewell
bishwashere
hughbe
GammaGames
vwkd
flooie
Overview
This is a long-standing issue but lately it comes up more and more for me.
• In CMECF, there is a many-to-one mapping between docket numbers and documents. A single document can belong to multiple docket numbers, as when an order is filed in two related cases.
• In CMECF, there is a many-to-one mapping between docket numbers and internal caseids (
de_caseid). This is extremely common in criminal cases, where the numbers are generally contiguous. This is so when there are multiple defendants who each get a sub-case, but it is also so when there is a single defendant: there is a main case and a single subcase.This throws a wrench in RECAP because different people will get to the same docket number via different caseid paths. Depending on what one searches for in PACER's
iquery.pland whether you choose All Defendants or single defendant or a combination thereof, you may get different (or multiple) caseids.For instance, take 1:14-cr-10363-RGS USA v. Cadden et al in ecf.mad:
Or in XML form, query https://ecf.mad.uscourts.gov/cgi-bin/possible_case_numbers.pl?1410363 (free) to get:
All caseids from 166116-166130 refer to the same docket number. Many (most?) documents in the case belong to multiple (all?) subcases.
But RECAP and CL treat them like differenet dockets with identical docket numbers, and don't show the subcase suffix number either.
For instance the main case is https://www.courtlistener.com/docket/4275782/united-states-v-cadden/ which has through docket entries through DE514 (Jan. 2016), and was last updated 2 months ago.
But the
-1case is https://www.courtlistener.com/docket/5135835/united-states-v-cadden/ which has through DE1260 (Oct. 24), 2017, and was last updated 12 days ago,.But the
-2case is https://www.courtlistener.com/docket/6145187/united-states-v-cadden/ has through DE1281, but was also updated 12 days ago.Although the
-2case is more recent, it doesn't actually have the PDF for DE1260.So this is like a huge mess.
Single-defendant criminal cases, too
The problem even occurs for single defendant criminal cases, although the path to pain is less obvious. Let's take our friend George Papadopoulos, in ecf.dcd. He's the sole defendant and it looks like there's only one case:
https://ecf.dcd.uscourts.gov/cgi-bin/possible_case_numbers.pl?17182
So it looks like it's just 189898. But, surprise:
https://ecf.dcd.uscourts.gov/cgi-bin/DktRpt.pl?189897 1:17-cr-00182-RDM USA v. PAPADOPOULOS https://ecf.dcd.uscourts.gov/cgi-bin/DktRpt.pl?189898 1:17-cr-00182-RDM-1 - PAPADOPOULOS, GEORGE
The '898 is easily found in the PACER UI, but unfortunately we can't ignore the '897, because it appears in other places. For instance, the email NEF sent to parties and "interested party" ECF users yesterday:
Of course, this problem is more likely to effect people who use NEFs, which is lawyers and journalists, and not too many members of the general public. But those are important RECAP constituencies.
Upshot
CL needs to track the docket number and caseid for each document independently, recognizing there can be more than one of each. For sanity's sake, CL docket pages should make the caseid visible somewhere (IA docket pages had it in the URL), even if it's small and at the bottom. Makes debugging your brain much simpler.
CL should acknowledge the concept of subdockets. I'm not sure all of what this entails. This is a nice-to-have, but not critical. If all the searches for 1:14-cr-10363 returned an amalgamation of the main docket and 14 subdockets, that would not be so bad
Maybe
Perhaps the RECAP extension should query docket number against
possible_case_numbers.pl, and report to the server associated caseids. I think this is a bad idea, because it means the extension is no longer passive, it can be identified (and blocked) by the courts, and it is using a nonpublic API. Furthermore, it would not return the second caseid in the case of a single-defendant case.Perhaps the RECAP extension should query adjacent caseids against
DktRpt.pluntil it runs into a different docket number on either side. Again, for the same reasons as above, I think that's bad. Also it could be many queries. I ran into a 60-defendant case last night.Perhaps the CL server should do these queries, maybe on a one-time basis.
Mitigation
It should be straightforward to identify, in the CL database, where there are multiple caseids for a given docket number, and then take some action to combine them. This is separate but related to from what the server and extension should do about this going forward.
Discuss!