If I have a long list of citations, how would I find them in CL?

[mlissner]

I have a spreadsheet of citations that I want to marry to CourtListener IDs. How do I do that?

[mlissner]

I think my go-to tool is our citation finder:

https://www.courtlistener.com/c/

The great thing about it is that it is very robust against weird citations. No matter if you have a historical citation, one with a typo or some other messy thing, it should work, if we have the citation.

You can, of course, just do this by hand, but that's no fun. To do it programmatically, it has a basic API we hope to document in #2714, but haven't yet gotten to.

Here's how it works. Say I have the citation for Roe v. Wade, 410 U.S. 113.

I can do a GET to this endpoint like this:

curl -v 'https://www.courtlistener.com/c/U.S./410/113/'

That'll return a 302 that takes you do:

↪ curl -v 'https://www.courtlistener.com/c/U.S./410/113/'
> GET /c/U.S./410/113/ HTTP/2
> Host: www.courtlistener.com
< location: /c/us/410/113/

You can see that your reporter (the U.S. part of it) is now corrected to a lowercased version, OK. So let's try that URL:

↪ curl -v 'https://www.courtlistener.com/c/us/410/113/'
> GET /c/us/410/113/ HTTP/2
> Host: www.courtlistener.com
< location: /opinion/108713/roe-v-wade/

And now you have the URL of the case, which has the cluster ID of 108713.

From there you can get the docket ID or the opinion ID. The docket ID you can get with:

↪ curl --silent 'https://www.courtlistener.com/api/rest/v3/clusters/108713/' | jq '.docket_id'
"https://www.courtlistener.com/api/rest/v3/dockets/488071/"

The opinion ID you can get with:

↪ curl --silent 'https://www.courtlistener.com/api/rest/v3/opinions/?cluster=108713&fields=id'
{
  "count": 4,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 9425159
    },
    {
      "id": 9425158
    },
    {
      "id": 9425157
    },
    {
      "id": 108713
    }
  ]
}

I hope that helps. Let me know what other questions come up or remain!

[flooie]

@tribblelabs -

1. you are correct that the search endpoint does provide different information
2. You should familiarize yourself with the cluster/opinion relationship. The opinion endpoint represents individual judicial thoughts (ie. majority/dissent/concurrence etc). So if you have a cluster - you need to look at the sub opinions or opinion_ids to obtain the text.
3. Inside each opinion object there are multiple text fields all or just one of which could contain the opinion content. it depends on where the original opinion content was sourced from.

[mlissner]

Thanks all! A few responses...

1. you are correct that the search endpoint does provide different information

@tribblelabs, can you say which fields are in /search that you're looking for? Everything should be somewhere.

3. Inside each opinion object there are multiple text fields all or just one of which could contain the opinion content. it depends on where the original opinion content was sourced from.

You can see more about which one to choose here:

https://www.courtlistener.com/help/api/rest/#opinion-endpoint

---

I'll comment on the other issue to get that ball rolling. Thanks for volunteering to help with it. It's something we're hearing a lot of demand for.

[tribblelabs]

@flooie when i go to an opinion endpoint, should I be grabbing the text via the html? For example at https://www.courtlistener.com/api/rest/v3/opinions/108713/ - I'm sure it varies by case but for that one specifically should I just key into ['html'] and grab that string and parse it? Thanks in advance

[flooie]

html_with_citaitons or xml_harvard are probably your best bets. But it varies on a case by case basis depending on where the data or multiple data sources come from.

It's also very important to understand the data structure from opinion cluster to opinion if you are trying to build the full opinion back

[purplefloyd14]

@flooie thats very helpful thank you. Yes I am wrapping my head around that structure, seems to be very useful.

I have a question: I noticed that there are some cases that have tabs separating the sub-opinions (I'm talking about the UI). Sometimes the default/main tab is 'combined', most of the time it seems, but sometimes its "lead".

here is my question: are there cases without tabs, where multiple sub opinions exist? In that scenario, are all sub-opinions (like dissent and concurrences) all present in that main text content (I assume they are), and are they represented in the api as a single sub-opinion or are they subdivided in the api?

I know some such cases must exist but I am having trouble finding one now to inspect its api cluster endpoint. Thanks