Production

Info

The production endpoint answers one question: how much of the collection was being made in each period. It is deliberately not a histogram of first years — see Why the weighting for what that would misrepresent.

endpoint:

GET https://data.designmuseumgent.be/v2/id/production

Parameters

Parameter	Type	Default	Description
`bucket`	integer	`10`	Bucket size in years. Clamped to 5–100. `10` is a decade; `25` and `50` stay legible for long ranges
`yearFrom`	integer	`1600`	Start of the axis. Objects whose spans fall entirely before this are excluded
`yearTo`	integer	`2030`	End of the axis. Maximum `2100`
`onDisplay`	boolean	—	Set to `true` to restrict to objects currently in the collection presentation
`q`	string	—	Full text search on titles, descriptions and object numbers. Narrows the density to a subset

GET https://data.designmuseumgent.be/v2/id/production
GET https://data.designmuseumgent.be/v2/id/production?bucket=25&yearFrom=1400
GET https://data.designmuseumgent.be/v2/id/production?onDisplay=true
GET https://data.designmuseumgent.be/v2/id/production?q=affiche&bucket=5&yearFrom=1880

Scope

This describes the objects published through this API — around ten thousand of the twenty-four thousand the museum holds. Which objects have been published, and in what order, is a decision made by people and it shapes every figure here. This is a view of the catalogue, not of the collection.

Why the weighting {#why-the-weighting}

Nearly every published object carries a production date, but only about a quarter carry an exact year. The rest are spans:

Span	Objects
Exact year	2,577
1–5 years	2,326
6–25 years	2,168
26–100 years	2,376
Over a century	362

A histogram of production_year_begin would pin an object dated 1900/2000 to 1900 and draw it as confidently as one dated 1937 — inventing precision for three quarters of the collection.

Instead each object contributes a total weight of exactly 1, spread evenly across every year of its span. An object dated 1937 puts its whole weight on one year; an object dated 1900/2000 puts 1/101 on each of 101 years.

Two consequences worth understanding:

The total area is the number of dated objects, so weight in a bucket is a genuine share of the collection.
Vague dating shows up as flatness, not as a false peak. A period that looks low may simply be one where the museum's objects are loosely dated.

Spans that cross the axis edge

Weight is divided by the span as recorded, not as clamped to the requested range. An object dated 1500/1900 shown on a yearFrom=1700 axis contributes only its visible fifth. Dividing by the clamped span would pull off-axis weight into view and inflate the edge buckets.

Response fields

Field	Description
`bucket_size`	Bucket width in years, as applied
`year_from`, `year_to`	The range covered
`total_weight`	Sum of all bucket weights — the number of dated objects inside the range
`buckets`	One entry per period, ascending

Each bucket:

Field	Description
`year`	First year of the bucket
`weight`	The distributed measure. This is the honest one — a real share of the collection
`share_pct`	`weight` as a percentage of `total_weight`
`object_count`	Objects whose span touches this bucket. Wide spans are counted in full in every bucket they cross, so this sums to far more than the collection. Not a share of anything
`exact_count`	Objects dated to a single year inside this bucket. The subset that needs no interpretation
`spread_factor`	`object_count / weight`. How vaguely this period is dated: `1` means every object here is pinned to a year; `9` means the average object spans nine buckets
`filter`	Ready-to-use URL listing the objects of this period

Reading spread_factor

It declines steadily over time — around 9 in the fifteenth century, around 2 in the twentieth. That is not a fact about the objects but about the records: it measures when dating became precise. exact_count tells the same story from the other direction.

Example response

{
  "@context": {
    "crm": "http://www.cidoc-crm.org/cidoc-crm/",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "hydra": "http://www.w3.org/ns/hydra/core#"
  },
  "@id": "https://data.designmuseumgent.be/v2/id/production",
  "@type": "hydra:Collection",
  "rdfs:label": "Production density",
  "bucket_size": 10,
  "year_from": 1600,
  "year_to": 2030,
  "total_weight": 9684.221,
  "buckets": [
    {
      "year": 1890,
      "weight": 458.048,
      "share_pct": 4.73,
      "object_count": 1539,
      "exact_count": 85,
      "spread_factor": 3.4,
      "filter": "https://data.designmuseumgent.be/v2/id/objects?date=1890/1899"
    },
    {
      "year": 1900,
      "weight": 773.057,
      "share_pct": 7.98,
      "object_count": 1502,
      "exact_count": 236,
      "spread_factor": 1.9,
      "filter": "https://data.designmuseumgent.be/v2/id/objects?date=1900/1909"
    }
  ]
}

The same production years drive the date filters on the objects collection:

GET https://data.designmuseumgent.be/v2/id/objects?date=1950/1969
GET https://data.designmuseumgent.be/v2/id/objects?dateFrom=1900
GET https://data.designmuseumgent.be/v2/id/objects?sortBy=dateBegin&sortOrder=asc

Those filter with overlap logic — an object is returned when its production span overlaps the requested range — so they select the same objects a bucket's object_count counts, not the ones its weight describes. Objects with no recorded date are excluded from all of them.