schema
schema copied to clipboard
citation-style-language
European Case Law Identifier (ECLI)
They have DOI for journals, ISBN for books… in Europe we have ECLI for judicial decisions. How can this be integrated in CSL?
(ECLI is supposed to work in the European Union, including in EU Member states jurisdictions, it is not limited to decisions from EU bodies).
ECLI and its companion ELI (European Legislative Identifier) are meant to work like DOI/ISBN, as an ID that resolves to a particular document. Storing it in some way would be useful, but it is Europe-specific, and I'm unclear on whether it is used in formal citations within publications and court documents. If it's not used in citations, it can be left out of CSL. When I've asked folks about this, I've been pointed at the EurLeX resolver site where (of course) the IDs are displayed. No idea what the practice is in courts, though. It's an open question.
Probably the ideal for these various IDs for various domains would be to have a controlled list of recognized domains, similar to what Web-aware clients do with protocols, that is shared with client projects like Zotero etc. An ID field would then be structured in JSON input as an array of objects with a "domain" (or similar) and an "id" field. Like the in-text citations thing, this would require adjustments in several layers managed by separate developers or developer communities, so it would be a heavy lift to introduce. But I think that would be the right way to do it.
Probably the ideal for these various IDs for various domains would be to have a controlled list of recognized domains ...
I started to wonder if a urn would be appropriate, but ECLI isn't registered as one.
And then I stumbled on this, which seems related.
https://en.wikipedia.org/wiki/Lex_(URN) https://datatracker.ietf.org/doc/draft-spinosa-urn-lex/?include_text=1
URN:LEX is what the Jurism jurisdiction/court identifier system is based on. The draft is a perennial proposal that has been circulating in IETF for years. The weakness of it for Jurism purposes is that it specifies a process whereby national governments undertake to cast their own official identifiers. That might happen in Europe if the EU mandated or pushed it (as with ELI and ECLI). As a voluntary join-the-club scheme it's obviously a non-starter, even if it were approved as a standard. Their work on the syntax of identifiers is good stuff, though, so I adopted that for the Jurism ID set housed in the Legal Resource Registry.
As for the two Austrian legal citation styles: they actually do recommend the use of ECLI for citing legal cases and propose a specific format for citations when the ECLI is used. And of course every legal case is assigned an ECLI.
That's useful to know. Would be good to have access to it in some way, as a named variable of some sort.
Probably the ideal for these various IDs for various domains would be to have a controlled list of recognized domains, similar to what Web-aware clients do with protocols, that is shared with client projects like Zotero etc.
In the absence of this more robust and flexible solution, should we just add this now then?
Hi, If I may weight in this, ECLI/ELI is also increasingly used in French scholarly and publishing citations. With an increasing number of court/legislation reports going digital in Europe, I expect that ECLI/ELI will gradually be not only mandatory, but might even replace the report entry in some styles. I currently use a workaround in CSL using the URL and accessed variables: if both are filled, URL is treated as such, if the "accessed" variable is missing, then it is treated as an identifier. It remains a very weak solution. A dedicated identifier variable would already be hugely beneficial for styles.
For a more complete picture:
The majority of the EU member states have implemented or plan to implement the ECLI. In addition, the European Court of Justice, the European Court of Human Rights (Council of Europe) and the Boards of Appeal of the European Patent office assign ECLIs to all pusblished decisions. Many of them have retroactively assigned ECLIs to ancient decisions, Spain and the Netherlands even back to the mid-1800s. All the decisions of the Court of Justice since 1954 are documented in its public database and are assigned an ECLI so some citation styles already have made the ECLI a madatory element in citing these, replacing the reporter element.
The ELI has been implemented by the EU Publications Office, thirteen EU meber states, a former member and three more (https://eur-lex.europa.eu/eli-register/implementation.html). It’s constructed as a URI and promises persistent access to legislation. They also show more or less prominently on the resp. resource site. However, I havent found a juridic style guide yet that recommends its use. Even the recently updated Austrian ones are missing it. I have no idea how this will develop and if introducing an ELI variable makes sense right now.
I havent found a juridic style guide yet that recommends its use
The French publisher's union has a page on the topic (https://reflex.sne.fr/identifiants-uniques-nor-rg-ecli-eli-etc). Their recommendation to their members is to always include both ECLI and ELI either in the citation output or as metadata. It is being implemented poorly, mostly due to a lack of understanding regarding ELI. Thas being said, since ELI behaves as URI, the URL variable can be used instead and a need for a dedicated one is not pressing (perhaps even redundant).
As for ECLI, the acronym is fully integrated into the code ("ECLI:EU:C:1964:66") so a more generic "Identifier" variable could be an option if the euro-centric aspect of an ECLI-specific variable is a problem.
@p-heckler thanks for the link. Interestingly, the only examples that show the identifier are those of the Court of Justice. All the others in the "règles de rédaction des sources officielles" list ELI or ECLI as optional but don’t show an example.
I’d be fine with something like a generic legal-identifier variable, too. This could be used in any of the legal document types and be filled with the appropriate content.
How is the ECLI or ELI actually formatted in citations? Is it always formatted as a URL?
As @georgd noted, ELI is essentially a common URI structure, so it is always formatted as URL in citation: http://data.europa.eu/eli/dec/2020/729/oj https://www.legifrance.gouv.fr/eli/arrete/2020/5/28/JUSK2013194A/jo/texte
ECLI follows quite a different formatting, akin to DOIs: ECLI:EU:C:1964:66 ECLI:CE:ECHR:2001:1212DEC005220799. Inserted in a full citation, it would result in something like this (from OSCOLA): Case C-176/03 Commission v Council EU:C:2005:542, [2005] ECR I-7879. (with report) Case C-542/09 Commission v the Netherlands EU:C:2012:346. (without report)
The latter citation is now the only possible one for EU law cases decided since the report went digital. This is also true of certain national legal orders where publication in a report is either digital or not systematic.
@p-heckler I am not following the connection between the example ECLI's:
ECLI:EU:C:1964:66 ECLI:CE:ECHR:2001:1212DEC005220799.
And the formatted citations:
Case C-176/03 Commission v Council EU:C:2005:542, [2005] ECR I-7879. (with report) Case C-542/09 Commission v the Netherlands EU:C:2012:346. (without report)
Is EU:C:2005:542, [2005] ECR I-7879 an ECLI, or just EU:C:2005:542? Is there some sort of reformatting that is supposed to happen? If not, I think a single legal-identifer variable might be workable?
What do you think @fbennett ?
[2005] ECR I-7879 is the report, EU:C:2005:542 is the ECLI, which I am now realising OSCOLA has used incorrectly: the actual ECLI for the case is ECLI:EU:C:2005:542, sorry about that! A properly formatted citation under OSCOLA should look like this :
Case C-176/03 Commission v Council ECLI:EU:C:2005:542, [2005] ECR I-7879 (with report also cited)
Case C-176/03 Commission v Council ECLI:EU:C:2005:542 (no report)
There should not be any reformatting, ECLI: is an integral part of the identifier (which comprises 5 parts), and I am not sure why the Oxford style drops it.
A single legal-identifier would work for ECLIs while being generic enough to cover similar non-URI case identifiers in non-ECLI legal systems.
Yeah, I'd like to hear from @fbennett about a general versus specific legal identifier variable.
It's good to see this thread. I've been pressed in the past to add ECLIs to Jurism in some way, but hadn't received sample citations that exercised them. This is really useful. Here are some thoughts in light of CSL-M development. This unavoidably gets into the weeds a bit. Please be forgiving.
First, the reference "Case C-176/03 Commission v Council ECLI:EU:C:2005:542, [2005] ECR I-7879" is (logically, and in the Jurism/CSL-M model) a parallel citation consisting of two separate items. In Jurism/CSL-M that's done by setting a relation between the two items in the database, which can be leveraged to suppress matching content in a series of cites. The relation is passed to the CSL JSON input object as a array under a seeAlso key (Zotero no longer passes this value, but I've preserved it in Jurism). The CSL-M code covering both cites might look like this:
<macro name="ecj-ref">
<group delimiter=" " parallel-first="number">
<group delimiter=" ">
<text value="Case"/>
<number variable="number"/>
</group>
<text variable="title"/>
</group>
<choose>
<if variable="container-title">
<group delimiter=" ">
<number variable="collection-number" prefix="[" suffix="]"/>
<text variable="container-title"/>
<number variable="page"/>
</group>
</if>
<else>
<number variable="variable-name-for-case-identifier"/>
</else>
</choose>
</macro>
With this code, the parallel-first block will be printed in the first cite in a related series, but it will be suppressed in a subsequent related cite that has a matching value for the number variable.
I've left the CSL variable name for the ECLI identifier open because legal-identifier seems a little broad. Courts assign numbers to individual filings (complaints, motions, amicus briefs, evidence), which are sometimes referred to as their "docket number." Courts also assign numbers to the case as a whole (in this case, "C-176/03"). Confusingly, this is sometimes referred to as the "docket number," and sometimes as the "case number." Further, the court may assign a number to a decision when it is issued. English courts (which I guess will soon be out of the ECLI system?) do this for their vendor-neutral citation form. Further, journals may also assign a serial number of their own to a case (e.g. "I-7879" in the ECR cite). And finally there is ECLI, applied by courts in coordination with EurLeX aggregation.
All of the numbers listed above are in some sense "legal identifiers." Most we have managed to shoehorn into the existing CSL JSON variables number and page. It's probably worth considering whether the same can be done with ECLI and other umbrella case and legislation IDs.
If the items underlying the example citation are separately stored as described above, the CSL JSON for the first is simply (in Jurism-speak):
{
"id": "this-item-id",
"number": "C-176/03",
"title": "Commission v Council",
"variable-name-for-case-identifier": "ECLI:EU:C:2005:542",
"jurisdiction": "eu.int",
"authority": "ecj",
"seeAlso": [
"other-item-id"
]
}
As EurLeX is an archival service, and ECLI is the location of the case within the EurLeX archive, an alternative might be to ship the value in the existing archive_location variable. Given parallel-cite support, I don't see how a conflict would arise with other identifier schemes that might be applied to a case.
Thanks @fbennett!
I did adopt the convention of using archive and archive_location to store digital archive and locator information (e.g., for ProQuestion Dissertation nubmers) when I was revising apa.csl. @adam3smith has expressed some concerns about using archive and archive_location for digital archives, but I think testing on archive-place handles that distinction. What are your current thoughts @adam3smith?
I think that might be a good place for ECLI if we adopt that as a convention. I agree that legal-identifier is ambiguous vis-a-vis docket numbers, etc., and I would prefer to not to include separate variables for every identifier. The one limitation would be if we wanted to render the ECLI or similar identifier as a resolvable URL (can the ECLI be resolved in a manner similar to a DOI?).
ELI should simply go into the URL field I would think considering it's a URI.
can the ECLI be resolved in a manner similar to a DOI?
Yes, the guideline for ECLI specifies that
A resolver must be available at https://e-justice.europa.eu/ecli/ meaning that an ECLI typed after this address will show the available data on this ECLI via the search interface
If archive_location were to be used, I think the need to test on archive-place would be limited to very specific situations. When a case is archived physically, it is usually compiled in a report (so the report is always cited instead) and even when it is not, archive place and location usually do not appear in citation. I can only think of a few exceptions, such as some ad hoc national jurisdictions after WWII whose works were boxed, or cases under restricted access, where citing archive and archive-place is useful.
As EurLeX is an archival service, and ECLI is the location of the case within the EurLeX archive, an alternative might be to ship the value in the existing
archive_locationvariable
My only worry on this is that ECLI does not, technically, act as an archive number for the EurLex database, but as a cross-database ID. While ECJ cases are primarily stored on EurLex, ECHR and national cases remain on their separate archives. The only requirement is that all jurisdictions log the identifier and corresponding metadata (including a URI) to the ELCI search engine. If we stick to existing fields, could call-number be used instead? After all, the ECLI search engine behaves very much like an OPAC.
@fbennett To facilitate rendering links like citeproc-js does with DOI, URL, PMID, would you be in favor of adding a dedicated ECLI variable? CSL already has quite a few identifiers, do I don't see much issue in adding ECLI.
I wouldn’t compare ECLI to an archival location, it’s much more like a reporter locator – in the case of the European Court of Justice it has become the single official reporter locator.
The UK hasn’t adopted the ECLI yet, AFAIK. But UK lawyers will need the ECLI in the future as well, however loose the relations will be. At least for historical reasons but very likely, ECJ decisions will play a role in the future as well.
legal-identifier is indeed very broad and could be misleading. Perhaps introduce an ecli variable now and consider consolidating identifiers in general in a single document-identifier variable with type="isbn|issn|doi|urn|pmcid|ecli..." in a later iteration? I think transition will be easier from a specific variable to such new structure than from a broad variable where it’s not clear which content is registered with it.
Points taken. If a specific variable is to be used, my own preference would be to give it a descriptive name, rather than binding it to ECLI specifically. Systems like ECLI are limited to the political reach of the jurisdiction that imposes them. That means that other discrete systems will eventually be queuing up for separate inclusion (in fact UN document numbers could be pitched today as such a candidate); and it also means that there is little chance of overlap among systems. If a descriptive name can be found, it would avoid revisiting the issue each time a cross-jurisdiction or institutional ID appears on the horizon. It's a little wordy, but would a name like federated-legal-id be acceptable?
Two points:
- It seems like this variable should be structured like
locatorwith "type" and "value" slots. That will allow new IDs to be added and linked fairly easily. federated-seems overly narrow. What if a single jurisdiction develops an ID system just for itself? Perhapsglobal-legal-idoruniversal-legal-id? Or maybelegal-eid? Or some other word that "id" (ala "handle" but that has a specific meaning)?
Would be happy with legal-eid, if that's generally acceptable. It flags that it's limited to legal materials, and the slightly cryptic eid element would prompt curiosity to look at the docs for the full story, which is hard to cram into a variable name in its entirety.
@fbennett After some discussion with Sebastian, we've decided to instead create an identifier variable that takes a list of identifiers to handle things beyond DOI, PMID, PMCID (e.g., arxivID, WOS id). These can go in there.
Any updates on this? Is it possible to fetch metadata of cases via ECLI yet in any of the current programs? Neither Zotero nor Jursim seem to work.
