EU Court Judgments (CJEU/GC) - Per Judgment Work

Judgments of the Court of Justice of the European Union (Court of Justice and General Court) from the EU Publications Office CELLAR as clean, per-judgment records - ECLI, CELEX, court, document date, subject-matter codes, procedure languages and originating country. Identifiers and codes only; no case titles, no party names.

What one record represents

The source is the EU Publications Office CELLAR SPARQL endpoint at publications.europa.eu, queried for works of resource-type JUDG (judgments). Each record is one judgment work, identified structurally by its ECLI and CELEX number, with the court parsed from the ECLI (Court of Justice, General Court, or the historical Civil Service Tribunal), the document date, the CELEX sector and case year, the subject-matter authority codes, the procedure language codes, and - for preliminary rulings - the originating country. It is the case-law-registry view: which judgment, from which court, on what date, about which coded subjects, in which languages.

Coverage and volume

A live COUNT(DISTINCT ?work) over resource-type JUDG returns exactly 34,459 judgment works at the time of writing, and the Actor exposes that on every run's receipt (reported_total). You raise Maximum records to pull the whole corpus or lower it to sample; paging is by a stable ORDER BY ?work with LIMIT/OFFSET over the SPARQL result, so a run is a deterministic sweep. Because CELLAR ingests new judgments as they are published, a scheduled run keeps a downstream case-law table current.

Person data: no title, no party, no judge

On the CJEU a judgment's title is the parties' names ("X v Commission", and for preliminary references the names of the litigants). This cell is built so that no title predicate and no party, judge, advocate-general or agent predicate is ever placed in the SPARQL SELECT. The delivered record carries only structural identifiers (ECLI, CELEX, work URI), the court (derived from the ECLI), dates, and concept codes for subject-matter, language and country. A built-in assertion rejects any record that carried a title or party key. The result is a person-free, citation-grade index of EU case law: you can build a docket, a subject-matter map or a language-availability table without ever touching the names of the people in the cases.

Distinct from eu-regulatory-change

This dataset selects case-law works (resource-type JUDG). The fleet's eu-regulatory-change product uses the same SPARQL door but selects legal acts - regulations, directives and decisions - a different resource-type authority entirely. Judgments interpret and annul acts; acts are what judgments are about. They share the CELLAR endpoint and the CDM ontology but not a single work: a judgment and the regulation it interprets are two different resources with two different CELEX sectors. That is why they are two cells, and joining them (which judgment cites which act) is a real analysis.

Licence

Reuse of EUR-Lex / CELLAR documents is authorised under Commission Decision 2011/833/EU on the reuse of Commission documents - free for any use, including commercial, provided the source is acknowledged (equivalent to CC BY 4.0). No third-party-copyright content is reproduced. The attribution rides on every record.

Who buys this, and how they use it

This cell is bought by teams that need the source's full published set as a typed, keyed table they can hold and refresh, rather than a page they scrape. Market-intelligence and lead-generation teams use it to size a market and track who is active in it; analysts and journalists use it to build a longitudinal series that the source's own portal does not expose; data engineers use it as a clean upstream feed into a warehouse, keyed so it upserts without duplication. The common thread is that the record grain and the stable key are chosen so the output is a building block, not a one-off export: you run it on a schedule, keep the delta, and join it to your other sources on the identifiers it preserves verbatim.

Field-by-field, and why the grain is what it is

Every field in the record is either a source-native identifier, a source-native attribute, or one of the six provenance fields (source, source_dataset, licence, attribution, caveat, observed_at) the fleet attaches to every record. Nothing is derived or inferred beyond the small, documented transforms noted above, and nothing is dropped silently: the person-handling section spells out exactly which fields are excluded and why. The grain - one record per the natural unit of the source - is deliberate: it keeps each row independently meaningful, keeps the key stable across runs so re-running is a cheap upsert rather than a re-import, and lets you aggregate up to whatever unit you need without having to unpick a pre-joined table. If you need a different grain, you compose it downstream from these rows; the cell's job is to deliver the atomic, person-safe, licence-clean records that everything else is built from.

Reconciling counts honestly

Where the live count differs from any previously published figure, the live measure is the honest one and is what this listing quotes; sources re-issue and consolidate their data over time, so a figure drifts. The run receipt always states what was actually delivered and charged and confirms the two agree, so every run is auditable against itself regardless of what any external index expected.

Sibling Actors

Provenance and compliance

Every run reads the door host's robots.txt at runtime; the gate result (URL, status, byte length and, where a policy is served, its SHA-256) is written to the run's RUN_RECEIPT. Where the host serves no applicable robots rule, or redirects its policy to another host, the gate records that (flagged) and proceeds on the licence, which grants re-use. The endpoint is keyless. The Actor never bypasses a block or fetches through a mirror, and it reads only the public listing endpoint - never a per-record detail page.

Data quality and freshness

Numeric columns are delivered as real numbers and every other column as a string or null, so the dataset loads without a cleaning pass. Delivery is keyed on a stable source identifier, so the data is safe to diff, deduplicate or upsert. Every run re-reads the live door, so the data is as fresh as the source publishes, and each record's observed_at stamp dates the snapshot. The run's RUN_RECEIPT records the source URL and how many records were delivered and charged, and confirms charge_equals_delivered.

Billing, delivery and joins

Pricing is per record: you are billed only for records the Actor actually delivers, with the charge raised after each record is pushed (push-then-charge), so a failed or empty run costs nothing. The Maximum records cap bounds every run, so you control spend precisely - sample cheaply, then raise it. Every record is a flat, typed object keyed on a stable id, so the data loads without a cleaning pass, diffs cleanly between runs, and upserts into a table you maintain over time; re-running keeps that table current without re-paying for rows you already hold, and each receipt reconciles delivered against charged. Because the source's own identifiers are preserved verbatim, the dataset joins cleanly onto other sources keyed on the same identifier.

Scaling and scheduling

Set Maximum records low to sample the shape of the data cheaply, then raise it once the cell fits your use. The Actor delivers incrementally and streams its source, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. Because the source republishes on its own cadence, a scheduled run keeps a downstream table current: new and changed records upsert over the old ones on the stable key, and the observed_at stamp on every record tells you when each was last seen live. There is no subscription and no minimum - the per-record price and the record cap together mean the spend on any run is known in advance and matched exactly to the data you receive.