Amsterdam Schema Specificatie

De meest recente aanpassing aan deze specificatie is:
§ 12.1 [3.0.0] Dataset versionering toegevoegd (2025-03-03)

1. Introductie

Doelstelling
Alle data van gemeente Amsterdam binnen één machine verwerkbaar universeel format beschrijven, zodat het geautomatiseerd verwerkt en ontsloten kan worden. En zo vanuit de tada principes bij dragen aan een transparante, datagedreven organisatie.

Het Amsterdam Schema is een standaard voor het beschrijven van datasets. De structuur van de data kan samen met meta-informatie in een machineverwerkbaar format vastgelegd worden. Zo kunnen datasets automatisch verwerkt en ontsloten worden.

Dit document legt uit hoe een dataset volgens de Amsterdam Schema-standaard beschreven wordt.

Note: Een actueel overzicht van gepubliceerde Amsterdam Schema’s is te vinden op GitHub.

Note: Amsterdam Schema is gebaseerd op JSON Schema’s.

1.1. Overzicht

Binnen deze bestanden bestaan de volgende niveaus:

dataset

Een samenhangende collectie van data met één beheerder of beherende instantie. Zoals bedoeld in DCAT. Op dit niveau wordt voornamelijk meta-informatie over de herkomst en aard van de data meegegeven, zoals de naam, beschrijving, licentie en publicatiedatum. Een dataset bevat minstens één versie.

versie

Beschrijft een versie van een dataset. Bevat een set van velden die beschrijft welke eigenschappen deze versie heeft en bevat minstens één tabel.

tabel

Beschrijft een type object dat in de dataset voorkomt. Bevat een set van velden die beschrijft welke eigenschappen datarijen in deze tabel moeten of mogen bezitten.

veld

Beschrijft de eigenschappen van rijen in een tabel, zoals de naam en het datatype van een eigenschap. Vergelijkbaar met de kolommen van een database.

Note: Binnen Amsterdam Schema wordt de Data Catalog Vocabulary (hierna DCAT) standaard gebruikt. DCAT is een naamgevingsstandaard voor het publiceren van datacatalogi op het web.

2. Dataset

Dataset A collection of data, published or curated by a single agent or identifiable community. The notion of dataset in DCAT is broad and inclusive, with the intention of accommodating resource types arising from all communities. Data comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset. (From Data Catalog Vocabulary (DCAT) - Version 3 § dcat-scope)

2.1. Verplichte attributen

Let op: Zie § 6 Naamgeving voor de eisen waaraan id moet voldoen.

Note: Als een versie van een dataset nog niet klaar is voor publicatie, zet de status dan op "niet_beschikbaar". Zo wordt de dataset nog niet zichtbaar in doelsystemen.

{
  "id": "bekendeAmsterdammers",
  "type": "dataset",
  "title": "Bekende Amsterdammers",
  "description": "Een collectie van bekende Amsterdammers.\n (Een voorbeeld dataset)",
  "publisher": "Team Bekende Amsterdammers",
  "creator": "myBronhouder",
  "auth": "OPENBAAR",
  "authorizationGrantor": "tba@amsterdam.nl",
  "owner": "Gemeente Amsterdam",
  "versions": {
    "v1": {
      "status": "beschikbaar",
      "version": "1.0.0",
      "tables": [
        {
          "$ref": "personen/v1",
          "id": "personen"
        }
      ]
    }
  }
}

Best Practice Zet bij datasets met meer dan één tabel alle tabellen in hun een eigen bestand en gebruik tabelreferenties. Dit komt de leesbaarheid ten goede en maakt versionering mogelijk.

2.2. Optionele attributen

Best Practice Voeg altijd op zijn minst een title en description toe.

2.2.1. DCAT velden

Note: De intentie is dat alle relevante DCAT velden te modelleren zijn. Wanneer velden ontbreken die wel in de DCAT zijn opgenomen, zullen deze worden toegevoegd.

Niet alle DCAT velden zijn gemodelleerd. Daarnaast zijn komt van sommige velden de naamgeving niet overeen met de DCAT spec.

Sommige velden missen een beschrijving

2.3. Tabelreferenties

Een tabelreferentie is een JSON object met in ieder geval de volgende attributen:

Elk tabeldefinitiebestand zou samen met andere versies van dezelfde tabel in een eigen map moeten staan waarvan de naam gelijk is aan de tabel id. De bestandsnaam van een tabeldefinitiebestand zou gelijk moeten zijn aan het major versienummer van de tabel voorafgegaan door 'v' met een '.json' extensie. Het pad gezien vanuit de locatie van het datasetbestand zou dus de volgende vorm moeten hebben:

<tabelid>/v<major>.json

Van deze bestandsnaam en padstructuur moet niet worden afgeweken behalve als daar een zwaarwegende reden voor is.

2.4. Publisherreferenties

Een publisherreferentie is een JSON object met 1 attribuut:

2.5. Scopereferenties

Een scopereferentie is een JSON object met 1 attribuut:

2.6. Versionering

Een dataset kan geversioneerd worden zodat er tegelijkertijd meerdere versies van een dataproduct actief kunnen zijn en er een overgangsperiode kan ontstaan waarin een oudere versie van een dataset ondersteund blijft totdat alle afnemers overgestapt zijn op een nieuwe versie van de dataset. Zie versie voor de implementatie in het Amsterdam Schema.

Note: Deze manier van versioneren is geïntroduceerd in V3 van het Amsterdam schema.

Note: Er kan momenteel slechts één versie van de dataset zijn met de status 'beschikbaar'. Dit dient overeen te komen met de waarde in defaultVersion.

Een versie wordt in het schema aangeduid door middel van een major versie van het versienummer van een dataset. Iedere versie van een dataset bevat een of meerdere tabellen die ook geversioneerd kunnen zijn. De versienummers van een dataset gebruiken semantic versioning. Dit betekend dat de versienummers betekenis hebben. Zo valt met een blik op het versienummer iets te zeggen over de aard van de gedane aanpassing.

Het versie nummer bestaat uit 3 getallen gescheiden door punten MAJOR.MINOR.PATCH:

• major versie bumps vinden plaats bij veranderingen die niet backwards compatible zijn. Dit zijn alle aanpassingen waarbij het kan voorkomen een afnemer de data volgens het nieuwe schema niet meer kan consumeren.

• minor versies zijn volledig backwards compatible en vereisen dus geen aanpassingen voor een afnemer.

• patch versies bevatten alleen metadata aanpassingen, waarbij de datastructuur gelijk blijft.

Note: We behandelen aanpassingen als breaking changes vanuit het oogpunt van de afnemer. Voorheen was dit vanuit het oogpunt van de leverancier.

Metadata aanpassingen zijn veranderingen aan een of meer van de volgende attributen:

• "title" op dataset, tabel of veld niveau

• "description" op dataset, tabel of veld niveau

• "shortname" op dataset, tabel of veld niveau

• "unit"

• "display"

Backwards compatible veranderingen zijn:

• Een tabel is toegevoegd aan een dataset.

• Een veld is toegevoegd aan een tabel.

Niet backwards compatible zijn alle andere aanpassingen:

• Een tabel is verwijderd of hernoemd in een dataset.

• Een veld is verwijderd of hernoemd.

• Een optioneel veld wordt verplicht gemaakt.

• Inputmogelijkheden van een veld zijn verruimd (zoals wanneer een waarde aan enum is toegevoegd, of een maximum of minimum is verruimd).

Note: Deze semantic versioning standaard is geinspireerd door SchemaVer wat weer is gebaseerd op SemVer.

3. Versie

Een versie definitie beschrijft een versie van de dataset, met daarin de status, versienummer en tabellen die bij deze versie horen.

3.1. Verplichte attributen

{  "id": "bekendeAmsterdammers",  "type": "dataset",  "title": "Bekende Amsterdammers",  "description": "Bekende historische personen die in Amsterdam hebben gewoond.\n (Een voorbeeld dataset)",  "owner": "Gemeente Amsterdam",  "publisher": "myDataTeam",  "creator": "myBronhouder",  "auth": "OPENBAAR",  "authorizationGrantor": "myDataTeam@amsterdam.nl",  "versions": {    "v1": {      "status": "niet_beschikbaar",      "version": "1.3.0",      "tables": [        {          "$ref": "personen/v1",          "id": "personen"        },        {          "$ref": "locaties/v1",          "id": "locaties"        }      ]    },    "v2": {      "status": "beschikbaar",      "version": "2.0.1",      "tables": [        {          "$ref": "personen/v2",          "id": "personen"        },        {          "$ref": "locaties/v1",          "id": "locaties"        }      ]    }  }}

4. Tabel

Een tabel definitie bevat het schema waaraan de er toe behorende datarijen moeten voldoen. Binnen het schema worden velden gedefinieerd die datarijen moeten of mogen bezitten. Daarnaast kan aan een tabel meta informatie en autorisatie instellingen worden meegegeven.

4.1. Verplichte attributen

Let op: Zie § 6 Naamgeving voor de eisen waaraan id moet voldoen.

{  "id": "personen",  "type": "table",  "title": "Personen",  "description": "Bekende Amsterdamse personen",  "version": "1.0.0",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon"      },      "naam": {        "type": "string",        "description": "Volledige naam van de persoon"      }    }  }}

4.2. Optionele attributen

Best Practice Voeg altijd op zijn minst een title en description toe.

4.3. Schema

Het schema object beschrijft de eigenschappen van rijen in de tabel.

Een schema object moet in ieder geval de volgende attributen bezitten:

Daarnaast mag een schema object de volgende attributen bezitten:

Het identifier veld moet string zijn. De array optie wordt binnenkort verwijderd.

{  "id": "personen",  "type": "table",  "title": "Personen",  "description": "Bekende Amsterdamse personen",  "version": "1.0.0",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon"      },      "naam": {        "type": "string",        "description": "Volledige naam van de persoon"      }    }  }}

4.4. Temporaliteit

Als een tabel objecten bevat die slechts beperkte tijd geldig zijn of waarvan over de tijd verschillende versies geldig zijn, wordt dit in de tabel definitie met het temporal object aangegeven.

Een temporal object heeft in ieder geval de volgende attributen.

Note: Momenteel wordt alleen de dimensie "geldigOp" ondersteund. In de toekomst kunnen hier andere dimensies zoals "inWerkingOp" en "beschikbaarOp" aan toegevoegd worden.

De array in temporal.dimensions.geldigOp bevat de namen van twee velden met begin en eind geldigheid van een object. Een object in de tabel is geldig binnen het gesloten interval ["beginGeldigheid", "eindGeldigheid"].

Als een tabel niet temporeel is kan het temporal object worden weggelaten.

"temporal": {
    "identifier": "volgnummer",
    "dimensions": {
        "geldigOp": ["beginGeldigheid", "eindGeldigheid"]
    }
}

4.5. Versionering

Een geversioneerde tabel moet in een eigen bestand staan. De bestandsnaam van de tabel zou gelijk moeten zijn aan het major versienummer van de tabel voorafgegaan door 'v' met een '.json' extensie. Zie § 2.3 Tabelreferenties voor hoe in de dataset naar een tabel bestand moet worden verwezen.

Zie § 2.6 Versionering voor uitleg over semantic versioning.

Zie § 2.3 Tabelreferenties voor het toevoegen van verschillende versies van een tabel.

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "1.2.1",  "description": "Bekende Amsterdamse personen",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon"      },      "naam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "beroep",        "description": "Reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof"        ]      }    }  }}

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "1.3.0",  "description": "Bekende Amsterdamse personen",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon"      },      "naam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "Beroep",        "description": "Reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof",          "beide"        ]      },      "geassocieerdeLocaties": {        "shortname": "locaties",        "title": "Locaties geassocieerd met de Persoon",        "description": "Locaties geassocieerd met de persoon. \nBijvoorbeeld een voormalige woon of verblijfplaats.",        "type": "array",        "relation": "bekendeAmsterdammers:locaties",        "items": {          "type": "string"        }      }    }  }}

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "1.3.0",  "description": "Bekende Amsterdamse personen",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon"      },      "naam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "Beroep",        "description": "Reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof",          "beide"        ]      },      "geassocieerdeLocaties": {        "shortname": "locaties",        "title": "Locaties geassocieerd met de Persoon",        "description": "Locaties geassocieerd met de persoon. \nBijvoorbeeld een voormalige woon of verblijfplaats.",        "type": "array",        "relation": "bekendeAmsterdammers:locaties",        "items": {          "type": "string"        }      }    }  }}

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "2.0.0",  "description": "Bekende Amsterdamse personen",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema",      "geassocieerdeLocaties"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon",        "maxLength": 25      },      "volledigeNaam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "Beroep",        "description": "Reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof",          "zanger",          "schilder",          "wiskundige",          "schrijver"        ]      },      "geassocieerdeLocaties": {        "shortname": "locaties",        "title": "Locaties geassocieerd met de Persoon",        "description": "Locaties geassocieerd met de persoon. \nBijvoorbeeld een voormalige woon of verblijfplaats.",        "type": "array",        "relation": "bekendeAmsterdammers:locaties",        "items": {          "type": "string"        }      }    }  }}

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "2.0.0",  "description": "Bekende Amsterdamse personen",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema",      "geassocieerdeLocaties"    ],    "display": "naam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon",        "maxLength": 25      },      "volledigeNaam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "Beroep",        "description": "Reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof",          "zanger",          "schilder",          "wiskundige",          "schrijver"        ]      },      "geassocieerdeLocaties": {        "shortname": "locaties",        "title": "Locaties geassocieerd met de Persoon",        "description": "Locaties geassocieerd met de persoon. \nBijvoorbeeld een voormalige woon of verblijfplaats.",        "type": "array",        "relation": "bekendeAmsterdammers:locaties",        "items": {          "type": "string"        }      }    }  }}

{  "id": "personen",  "type": "table",  "title": "Personen",  "version": "2.0.1",  "description": "Bekende historische Amsterdammers",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema",      "geassocieerdeLocaties"    ],    "display": "volledigeNaam",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v1.1.1#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding persoon",        "maxLength": 25      },      "volledigeNaam": {        "type": "string",        "description": "Volledige naam van de persoon"      },      "beroep": {        "title": "Beroep",        "description": "Primaire reden, dat de persoon bekend is.",        "type": "string",        "enum": [          "voetballer",          "filosoof",          "zanger",          "schilder",          "wiskundige",          "schrijver"        ]      },      "geassocieerdeLocaties": {        "shortname": "locaties",        "title": "Geassocieerde locaties",        "description": "Locaties geassocieerd met de persoon. \nBijvoorbeeld een voormalige woon of verblijfplaats.",        "type": "array",        "relation": "bekendeAmsterdammers:locaties",        "items": {          "type": "string"        }      }    }  }}

{  "id": "bekendeAmsterdammers",  "type": "dataset",  "title": "Bekende Amsterdammers",  "description": "Bekende historische personen die in Amsterdam hebben gewoond.\n (Een voorbeeld dataset)",  "owner": "Gemeente Amsterdam",  "publisher": "myDataTeam",  "creator": "myBronhouder",  "auth": "OPENBAAR",  "authorizationGrantor": "myDataTeam@amsterdam.nl",  "versions": {    "v1": {      "status": "niet_beschikbaar",      "version": "1.3.0",      "tables": [        {          "$ref": "personen/v1",          "id": "personen"        },        {          "$ref": "locaties/v1",          "id": "locaties"        }      ]    },    "v2": {      "status": "beschikbaar",      "version": "2.0.1",      "tables": [        {          "$ref": "personen/v2",          "id": "personen"        },        {          "$ref": "locaties/v1",          "id": "locaties"        }      ]    }  }}

5. Veld

Zie § 5.3 Data types voor een overzicht van modelleerbare typen en hoe deze binnen Amsterdam Schema uitgedrukt kunnen worden.

Note: veld gebruikt een subset van [json-schema-validation]. Een aantal JSON Schema features waaronder union types wordt niet ondersteund.

Let op: Zie § 6 Naamgeving voor de eisen waaraan de namen van velden moeten voldoen.

5.1. Verplichte attributen

Note: Let op, een veld moet dus een type of een $ref attribuut hebben, beide is niet toegestaan.

5.2. Toegestane attributen

Best Practice Voeg altijd op zijn minst een 'title' en 'description' toe.

Naast bovenstaande attributen mag een veld uitsluitend de volgende subset van attributen uit JSON Schema bevatten:

        "type": "string",
        "description": "Volledige naam van de persoon"
      },
      "beroep": {
        "title": "beroep",
        "description": "Reden, dat de persoon bekend is.",

"locatie": {
    "title": "Locatie",
    "description": "Coordinaten van het middelpunt van het plein",
    "$ref" : "https://geojson.org/schema/Point.json"
}

5.3. Data types

Velden worden allemaal gemodelleerd als concrete JSON Schema type definieringen, deze moeten in doel-systemen naar de juiste veld/kolom-types getransformeerd worden. (Zie ook Type-specific keywords in de JSON Schema specificatie).

Deze sectie bevat een overzicht van de door Amsterdam Schema ondersteunde JSON Schema typen, voorbeelden van gebruik en welke (SQL) data typen gebruikt zouden moeten worden om de JSON Schema typen te interpreteren.

Note: UNION types worden niet ondersteund: een kolom kan niet meerdere typen waardes bevatten, behalve null. De anyOf operater is dus niet toegestaan
{"anyOf": [{ "type": "integer" }, { "type": "string"}]}

Note: Elk veld is nullable tenzij het als required property is opgegeven, zie required.

5.3.1. integer

"aantalDuivenOpDeDam": {
    "title": "aantal duiven op de Dam",
    "description": "Het gemeten aantal duiven op de de Dam",
    "type": "integer"
}

"zandkorrelsOpBlijburg": {
    "title": "zandkorrels op Blijburg",
    "description": "Het aantal aantal zandkorrels op het strand van Blijburg.",
    "type": "integer",
    "maximum": 1E19
}

Daar waar een kleiner bereik is gegeven door middel van een of meer van de attributen maximum, minimum of exclusiveMaximum kan een native datatype met een geschikt bereik worden toegepast. Zo kan een integer met een exclusiveMaximum < 2^(N-1) en minimum >= 2^(N-1) altijd worden geinterpreteerd als een N-bits signed integer.

"hoogteTenOpzichteVanNormaalAmsterdamsPijl": {
    "title": "Hoogte ten opzichte van NAP",
    "shortname": "hoogteNAP"
    "description": "Hoogte van de locatie ten opzichte van NAP in cm.",
    "type": "integer",
    "exclusiveMaximum": 2147483648,
    "minimum": -2147483648,
    "unit": "cm"
}

Een integer met een minimum >= 0 en een exclusiveMaximum < 2^N kan altijd worden geinterpreteerd als een N-bits unsigned integer.

"weeknummer": {
    "title": "weeknummer",
    "description": "weeknummer",
    "type": "integer",
    "exclusiveMaximum": 256,
    "minimum": 0,
}

Het wordt aangeraden om de toegestane waarden in een veld altijd te beperken tot realistische waarden om fouten te voorkomen.

"decennium": {
    "title": "decennium",
    "description": "Een decennium in het bestaan van de stad.",
    "type": "integer",
    "exclusiveMaximum": 2121,
    "minimum": 1300,
    "multipleOf": 10
}

5.3.2. number

"gevelHoek": {
    "title": "gevel hoek",
    "description": "Hoek van de gevel met de verticaal in graden",
    "type": "number"
}

Wanneer aan een number veld een multipleOf attribuut is meegegeven moet dit veld worden geinterpreteerd als fixed-point type met schaal=log(multipleOf)/log(0.1) (zodat multipleOf=0.1^schaal).

"gevelHoek": {
    "title": "gevel hoek",
    "description": "Hoek van de gevel met de verticaal in graden",
    "type": "number",
    "multipleOf": 0.01
}

Als een maximum attribuut is meegegeven kan een native type met een geschikte precisie worden gebruikt. precisie = log(maximum + 1)/log(10) + schaal (zodat maximum=10^(precisie-schaal) -1).

"gevelHoek": {
    "title": "gevel hoek",
    "description": "Hoek van de gevel met de verticaal in graden",
    "type": "number",
    "multipleOf": 0.01
    "maximum": 90
    "minimum": -90
}

Best Practice Beperk numerieke velden altijd tot realistische waarden met maximum, minimum of exclusiveMaximum om fouten te voorkomen, en doelsystemen de juiste datatypen te laten gebruiken.

5.3.3. boolean

"isGepubliceerd": {
    "title": "Is gepubliceerd",
    "description": "Dit artikel is gepubliceerd.",
    "type": "boolean",
}

5.3.4. string

"beschrijving": {
    "title": "Beschrijving",
    "description": "Beschrijving van het pand.",
    "type": "string",
}

Waar een maxLength attribuut is meegegeven aan een string veld kan een geschikt limited width string type zoals een SQL VARCHAR worden gebruikt.

"bekendeUitspraak": {
    "title": "Bekende uitspraak",
    "description": "Bekende uitspraak van de persoon.",
    "type": "string",
    "maxLength": 50
}

Als een string veld een minLength en een maxLength attribuut van gelijke waarde heeft kan het veld worden geinterpreteerd als een fixed width string zoals een SQL CHAR.

"taalcode": {
    "title": "taalcode",
    "description": "Taalcode volgens de ISO639-2 standaard.",
    "type": "string",
    "maxLength": 3
    "minLength": 3
}

Wanneer in een text veld een beperkte set waarden is toegestaan door middel van het enum attribuut, zou het veld moeten worden geinterpreteerd als een enumerator type zoals een SQL ENUM.

"beroep": {
    "title": "beroep",
    "description": "Beroep van de persoon.",
    "type": "string",
    "enum": ["voetballer", "filosoof", "beide"]
}

Een text veld met contentEncoding gelijk aan "base64" zou moeten worden geinterpreteerd als binary data.

"hash": {
    "title": "hash",
    "description": "SHA512 hash",
    "type": "string",
    "contentEncoding": "base64"
}

Wanneer een maxLength attribuut is meegegeven aan een string veld zou het veld moeten worden geinterpreteerd als een fixed width binary type zoals een SQL BINARY, met maxLength=4*ceil(bytes/3).

"hash": {
    "title": "hash",
    "description": "SHA512 hash",
    "type": "string",
    "contentEncoding": "base64",
    "maxLength": 88
}

5.3.5. tijd

Note: De maximale precisie van de tijdseenheden is microseconde.

Note: Bij een "date-time" wordt aangeraden om een tijdszone op te geven. Wanneer de tijdszone ontbreekt wordt een data-kwaliteit waarschuwing gegeven.

"publicatieDatum": {
    "title": "publicatie datum",
    "description": "Datum van publicatie",
    "type": "string",
    "format": "date"
}

"publicatieTijd": {
    "title": "publicatie tijd",
    "description": "Tijd van publicatie",
    "type": "string",
    "format": "time"
}

"tijdEnDatumVanPublicatie": {
    "title": "Tijd en datum van publicatie",
    "description": "Tijd en datum van publicatie",
    "type": "string",
    "format": "date-time"
}

"duur": {
    "title": "Evenements duur",
    "description": "Tijdsduur dat het evenement open is voor publiek.",
    "type": "string",
    "format": "duration"
}

5.3.6. geometrie

      "lokatie": {
        "title": "Lokatie",
        "description": "Coordinaten van het middelpunt van het plein",
        "$ref": "https://geojson.org/schema/Point.json"
      },

Een tabel schema mag meerdere geometrie velden bezitten. Bijvoorbeeld de contour van een object in een Polygon en de centrale coordinaten van het object in een Point.

Doelsystemen die slechts één geometrie veld per object ondersteunen moeten gebruik maken van het veld waarnaar wordt verwezen in het mainGeometry attribuut van de tabel. Als de tabel geen expliciet mainGeometry attribuut heeft is dit de default waarde: "Geometry".

Note: Als een tabel één of meerdere geometrie velden heeft, maar geen van deze velden "Geometry" heet, moet één van de velden als primaire geometrie worden aangegeven in mainGeometry.

Note: Als een tabel een geometrie veld bevat, moet op dataset niveau het coordinaat referentie systeem worden aangegeven in het crs attribuut.

{  "id": "pleinen",  "type": "table",  "title": "Pleinen",  "version": "1.0.0",  "description": "Pleinen van amsterdam. (Een voorbeeld tabel met geometrie velden)",  "mainGeometry": "lokatie",  "schema": {    "$schema": "http://json-schema.org/draft-07/schema#",    "type": "object",    "required": [      "id",      "schema"    ],    "display": "id",    "properties": {      "schema": {        "$ref": "https://schemas.data.amsterdam.nl/schema@v3#/definitions/schema"      },      "id": {        "type": "string",        "description": "Unieke aanduiding van het plein"      },      "naam": {        "type": "string",        "description": "Naam van het plein"      },      "lokatie": {        "title": "Lokatie",        "description": "Coordinaten van het middelpunt van het plein",        "$ref": "https://geojson.org/schema/Point.json"      },      "contour": {        "title": "Contour",        "description": "Polygoon van de contour van het plein.",        "$ref": "https://geojson.org/schema/Polygon.json"      }    }  }}

5.3.7. object

Note: Het properties attribuut moet geen object of array velden bevatten. Geneste data is in een gestructureerd object veld niet toegestaan.

"adres": {
    "title": "Adres",
    "description": "Het adres.",
    "type": "object",
    "properties": {
        "functieAdres": {
            "type": "string",
            "title": "Functie adres",
            "description": "Aanduiding van het soort adres. Mogelijke waarden: W (woonadres), B (briefadres).",
            "enum": ["W", "B"]
        },
        "huisnummer": {
            "type": "integer",
            "exclusiveMaximum": 2147483648,
            "minimum": 0

        },
        "toevoeging": {
            "type": "string"
        },
        "postcode": {
            "description": "Volledige postcode zonder spaties.",
            "type": "string"
            "minLength": 6,
            "maxLength": 6
        },
        "straatnaam": {
            "type": "string"
        }
    }
}

Note: De velden in properties zijn altijd nullable.

Als een object veld een properties attribuut bevat (gestructureerd is), moet het in doelsystemen geinterpreteerd worden als een SQL STRUCT type. Als een object veld geen properties attribuut heeft (ongestructureerd is) kan het in doelsystemen slechts ongeindexeerd worden opgeslagen in bijvoorbeeld een JSON string.

Daarom moet het gebruik van object velden zonder properties attribuut waar mogelijk worden vermeden. Een config/properties veld van string keys naar string waarden is een voorbeeld van acceptabel gebruik van een ongestructureerd object veld.

5.3.8. array

Note: De optie van een items array uit de JSON Schema specificatie wordt niet ondersteund. Een array kan dus slechts één type waarde bevatten (geen UNION types).

Het items attribuut is een veld object, maar de meta-data attributen title, description, auth, provenance, shortname en relation hebben in items geen effect en zouden moeten worden weggelaten.

Note: Een array van arrays is niet toegestaan. Dus items mag zelf niet het type array hebben.

"weeknummers": {
    "title": "weeknummers",
    "description": "Weeknummers.",
    "type": "array",
    "items": {
        "type": "integer",
        "exclusiveMaximum": 256,
        "minimum": 0,
    }
}

"metingen": {
    "title": "metingen",
    "description": "Uitgevoerde metingen.",
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "meetonzekerheid": {
                "title": "Meetonzekerheid",
                "description": "Onzekerheid van de meting.",
                "type": "number",
                "minimum": 0
            },
            "waarde": {
                "title": "Waarde",
                "description": "De gemeten waarde.",
                "type": "number"
            }
        }
    }
}

Het is onduidelijk of unit in een array moet worden meegegeven in het items attribuut als veld.items.unit of in het hoofd object als veld.unit.

5.4. Relaties

Het attribuut relation moet altijd een string bevatten van de vorm "<dataset-id>:<tabel-id>". Van de waarden in een relation veld wordt verwacht dat ze gelijk zijn aan de unieke identifier van een rij in de tabel waaraan gerefereerd wordt.

Note: Dit is niet verplicht, referentiële integriteit wordt niet afgedwongen. Het kan dus voorkomen dat relaties naar niet (meer) bestaande entiteiten verwijzen.

In het geval dat gerefereerd wordt aan een tabel zonder temporaliteit, moet het type van het verwijzende veld overeenkomen met het type van de identifier van de andere tabel.

"hoortBijMeetbout": {
    "title": "hoort bij meetbout",
    "description": "De meetbout waarop de meting is gedaan."
    "type": "string",
    "relation": "meetbouten:meetbouten"
}

Als gerefereerd wordt aan een tabel met temporaliteit, bestaat de unieke identifier van een object in die tabel uit twee velden; de tabel identifier en de temporele identifier (zie § 4.4 Temporaliteit). In dit geval moet het verwijzende veld van het type object zijn en twee properties bevatten, met namen en types die overeenkomen met de identifier en de temporal van het object waarnaar verwezen wordt.

"ligtInWijk": {
    "title": "ligt in wijk",
    "description": "De wijk waar de buurt in ligt.",
    "type": "object",
    "relation": "gebieden:wijken",
    "properties": {
        "identifier": {
            "type": "string"
        },
        "volgnummer": {
            "type": "string"
        }
    }
}

Voor meervoudige (Many-To-Many) relaties wordt een array veld gebruikt met een relation attibuut.

"refereertAanReferentiepunten": {
    "shortname": "referentiepunten",
    "title": "refereert aan referentiepunten",
    "description": "De referentiepunten waar aan de meetbout refereert.",
    "type": "array",
    "relation": "meetbouten:referentiepunten",
    "items": {
        "type": "string"
    }
}

"ligtInPanden": {
    "title": "ligt in panden",
    "relation": "bag:panden",
    "description": "De unieke landelijke aanduidingen van de panden waarvan het verblijfsobject onderdeel uitmaakt.",
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "identificatie": {
                "type": "string"
            },
            "volgnummer": {
                "type": "integer"
            }
        }
    }
}

5.5. Eenheden

Het is mogelijk om bij een veld de eenheid mee te geven in het unit attribuut als meta-informatie voor user interfaces. Dit is slechts bedoeld ter informatie van de eindgebruiker, er worden dus geen automatische bewerkingen (zoals bijvoorbeeld eenheid conversies) uitgevoerd op basis van dit veld.

Voor het definieren van een eenheid wordt standaard een string met de eenheid volgens de The Unified Code for Units of Measure codering gebruikt.

"unit": "mm/h"

Note: Zie deze link voor een overzicht van veelgebruikte eenheden in UCUM-format.

Voor valuta’s wordt de drieletterige codering ISO 4217 gebruikt binnen een UCUM 2.1§6 unitannotatie.

"unit": "{EUR}/h"

De eenheidscodering kan ook expliciet meegegeven worden door unit een object mee te geven. Een unit object moet de volgende attributen bevatten.

"unit": {"type": "ucum", "value": "{EUR}/h"}

Zo kunnen ook andere eenheidscoderingen gebruikt worden.

"unit": {"type": "pint", "value": "meter"}

Best Practice Gebruik de UCUM-standaard om eenheden te coderen. Niet-standaard-coderingssystemen worden afgeraden.

6. Naamgeving

Namen van datasets, tabellen en velden moeten:

• 1. gebruik maken van camelCase.
• 2. geen afkortingen of afbrekingen bevatten.
• 3. bestaan uit zelfstandige naamwoorden (met uitzondering van de namen van relatievelden).
• 4. uniek zijn binnen hun scope. (respectievelijk: De hele catalogus, de dataset of de tabel)

5. Namen van tabellen moeten in meervoudsvorm zijn, behalve als sprake is van een enkelvoudige entiteit. Conform REST-API Design Rules § api-54.

6. Namen van velden moeten geen herhaling van de tabel naam bevatten. (Dus niet container.containerNummmer, maar container.nummer.)

Note: Gebruik duidelijke en begrijpelijke namen voor zowel datasets, tabellen als velden. De data wordt onsloten op een publieke API, dus de naamgeving moet zonder veel uitleg duidelijk zijn voor externe afnemers.

6.1. Shortname

Op zowel tabel als veld niveau is het mogelijk om een alternatieve verkorte naam op te geven met het attribuut shortname. Het shortname attribuut mag wel afkortingen bevatten (regel 2 geldt niet) maar moet verder aan dezelfde eisen voldoen als de naam die erdoor wordt afgekort.

{
    "id": "maatschappelijkeActiviteiten",
    "shortname": "activiteiten",
    "type": "table"
    ...
}

"registratieTijdstipMaatschappelijkeActiviteit": {
    "shortname": "registratieTijdstip",
    "type": "string",
    "format": "date-time"
}

7. Publisher

Een publisher definitie bevat een publisher object. Deze word onder andere gebruikt voor billing en tagging van resources die via het amsterdam schema worden aangevraagd.

{
  "id": "NOBODY",
  "type": "publisher"
  "name": "Datateam Nobody",
  "shortname": "nobody",
  "tags": {
    "costcenter": "00000000.0000"
    "team": "nobody",
  },
}

7.1. Verplichte attributen

8. Scope

Een scope is een groep gebruikers (medewerkers) met gedeelde rechten. Een gebruiker kan meerdere scopes hebben. Een scope is een string bestaande uit een reeks lower of uppercase letters eventueel gescheiden door een forward slash (/), bijvoorbeeld "BRP/RO".

In versie 2.1.0 van het metaschema is de mogelijkheid toegevoegd om een scope in een apart bestand te definieren. Dit is in versie 2.2.0 uitgebreid met velden waar een Azure access package kan worden gespecificeerd voor de verschillende omgevingen. Deze bestanden bevinden zich in de scopes/ folders.

{
    "type": "scope",
    "id": "LEVEL/X",
    "naam": "Toegang tot level X",
    "accessPackages": {
        "production": "EM4W-DATA-schemascope-p-scope_level_x",
        "nonProduction": "EM4W-DATA-schemascope-ot-scope_level_x"
    },
    "owner": {
        "$ref": "publishers/BENK
    }
}

8.1. Verplichte attributen

9. Autorisatie

Confirm the Wet Open Overheid (Woo) zijn gegevens standaard openbaar. Er zijn twee mechanismen om de toegang te beperken en authorisatie in te regelen:

1. De "auth"-attributen in het Amsterdam-schema beperken de toegang. zie § 9.1 Auth-attributen.

2. De profielen geven granulair toegang op basis van een gebruikersprofiel. zie § 9.2 Profielen.

Beide mechanismen gebruiken doorvoor scopes om te koppelen met gebruikersgroepen in de bestaande architectuur. Deze scopes worden bijvoorbeeld verkregen vanuit een bestaande OAuth-flow die een JSON Web Token (JWT) aanbiedt.

9.1. Auth-attributen

Op zowel dataset, tabel als veld niveau kan een "auth"-attribuut worden meegegeven om toegang tot een entitieit te beperken.

Het "auth"-attribuut bevat één of meer scopes, die leesrechten hebben op de entiteit waarop "auth" is gedefinieerd.

9.1.1. Meerdere scopes {#auth-multiple-scopes}

Als het "auth"-attribuut een array bevat is elke scope in de array afzonderlijk geautoriseerd. Dus een gebruiker heeft slechts één van de scopes in een array nodig voor toegang.

"aantalDuivenOpDeDam": {
    "title": "aantal duiven op de Dam",
    "description": "Het gemeten aantal duiven op de de Dam",
    "auth": ["LEVEL/X", "LEVEL/Y"]
    "type": "integer"
}

Een scope kan op deze manier in een auth veld worden gebruikt:

"aantalDuivenOpDeDam": {
    "title": "aantal duiven op de Dam",
    "description": "Het gemeten aantal duiven op de de Dam",
    "auth": {
        "$ref": "scopes/BENK/LEVEL-X
    },
    "type": "integer"
}

Het is ook mogelijk om een array van scopes mee te geven:

"aantalDuivenOpDeDam": {
    "title": "aantal duiven op de Dam",
    "description": "Het gemeten aantal duiven op de de Dam",
    "auth": [
        {
            "$ref": "scopes/BENK/LEVEL-X
        },
        {
            "$ref": "scopes/BOR/LEVEL-Y
        }
    ],
    "type": "integer"
}

9.1.2. Meerdere niveau’s {#auth-multiple-levels}

Op dataset niveau is het auth attribuut verplicht. Bij een openbare dataset krijgt het auth attribuut de waarde "OPENBAAR".

Als een tabel geen "auth" attribuut heeft, is de scope van de tabel gelijk aan die van de dataset.

Als een veld geen "auth" attribuut heeft, is de scope van het veld gelijk aan die van de tabel.

Om toegang tot een veld te krijgen, moet de gebruiker op alle niveau’s toegang krijgen; op veld-, tabel- en datasetniveau.

Op het eerste niveau waarop data niet openbaar wordt gemaakt moet een "reasonsNonPublic"-attribuut bestaan. Dus als een dataset openbaar is, maar deze een tabel bevat waarop een auth attribuut met een andere waarde dan "OPENBAAR" bestaat. Moet in de betreffende tabel of tabellen een reasonsNonPublic attribuut bestaan.

{    "type": "dataset",    "id": "gebieden",    "title": "gebieden",    "auth": "LEVEL/A",    "reasonsNonPublic": [        "5.1 1b: Gevaar voor staatsveiligheid"    ],    "status": "beschikbaar",    "crs": "EPSG:28992",    "tables": [        {            "id": "bouwblokken",            "mainGeometry": "geometrie",            "type": "table",            "version": "1.0.0",            "auth": "LEVEL/B",            "schema": {                "$id": "https://github.com/Amsterdam/schemas/gebieden/bouwblokken.json",                "$schema": "http://json-schema.org/draft-07/schema#",                "type": "object",                "additionalProperties": false,                "identifier": ["id"],                "required": ["schema", "id"],                "display": "id",                "properties": {                    "schema": {                        "$ref": "https://schemas.data.amsterdam.nl/schema@v1.1.1#/definitions/schema"                    },                    "id": {                        "type": "string",                        "description": "Unieke identificatie voor dit object, inclusief volgnummer"                    },                    "beginGeldigheid": {                        "type": "string",                        "format": "date",                        "title": "Begin geldigheid",                        "description": "De datum waarop het object is gecreëerd.",                        "auth": "LEVEL/C"                    },                    "eindGeldigheid": {                        "type": "string",                        "format": "date",                        "title": "Eind geldigheid",                        "description": "De datum waarop het object is komen te vervallen.",                        "provenance": "eindgeldigheid"                    },                    "ligtInBuurt": {                        "type": "string",                        "relation": "gebieden:buurten",                        "provenance": "ligtinbuurt",                        "title": "Ligt in buurt",                        "description": "De buurt waar het bouwblok in ligt."                    }                }            }        }    ]}

9.2. Profielen

Waar een "auth"-attribuut de toegang ontzegt, geeft een profiel granulair toegang onder voorwaarden. Een profiel wordt alleen toegepast als er geen authorisatie verkregen is via de "auth"-attributen.

{
    "id": "parkeerwachter",
    "type": "profile",
    "name": "Parkeerwacht toegang",
    "scopes": ["FP/PARKEERWACHTER"],
    "datasets": {
        "parkeervakken": {
            "tables": {
                "parkeervakken": {
                    "permissions": "read",
                }
            }
        }
    }
}

Een profiel kan toegang geven op dataset-, tabel- en veldniveau. Daarbij kan ook een zoekvraag ("mandatoryFilterSets") verplicht zijn om toegang te krijgen.

{
    "id": "parkeerwachter",
    "type": "profile",
    "name": "Parkeerwacht toegang beperkt",
    "scopes": ["FP/PARKEERWACHTER-B"],
    "datasets": {
        "parkeervakken": {
            "tables": {
                "parkeervakken": {
                    "fields": {
                        "type": "read",
                        "grootte": "read",
                        "opmerking": "letters:10",
                    },
                    "mandatoryFilterSets": [
                        ["id", "volgnummer"],
                        ["buurtcode", "type"],
                    ],
                }
            }
        }
    }
}

9.3. Verplichte attributen

Iedere dataset in een profiel kan de volgende waarden bevatten:

Iedere tabel in een profiel kan over de volgende waarden bevatten:

Ieder veld in een profiel kan over de volgende waarden bevatten:

9.3.1. Verplichte zoekvragen {#mandatory-filter-sets}

De mandatoryFilterSets verplicht het gebruik van een zoekvraag om de tabel te raadplegen. De waarde bevat een lijst van mogelijke toegestane vragen. Operatoren zijn alleen toegestaan als deze letterlijk opgegeven worden, bijvoorbeeld "regimes.aantal[gte]".

"mandatoryFilterSets": [
    ["id", "volgnummer"],
    ["buurtcode", "type"]
]

9.3.2. Toegangsregels {#access-rules}

Een gebruiker heeft toegang tot een dataset indien deze:

• Toegang krijgt via de "auth" regel.

• Of een profiel heeft met "permissions": "read" op dataset niveau.

Een gebruiker heeft toegang tot een tabel indien deze:

• Toegang krijgt via "auth" regels op de tabel én dataset.

• Of volledige toegang heeft tot de dataset door middel van een profiel met "permissions": "read" op dataset niveau.

• Of een profiel heeft met "permissions": "read" op tabel niveau, én voldoet aan de mandatoryFilterSets indien deze aanwezig zijn. Toegang tot het openen van dataset wordt daarmee impliciet verkregen.

Een gebruiker heeft toegang tot een veld indien deze:

• Toegang krijgt via "auth" regels op de dataset, tabel én het veld.

• Of volledige toegang heeft tot de dataset door middel van een profiel met "permissions": "read" op dataset niveau.

• Of volledige toegang heeft tot een tabel door middel van een profiel heeft met "permissions": "read" op het tabel niveau, waarbij de de mandatoryFilterSets voldaan zijn indien deze aanwezig zijn.

• Of een profiel heeft met "permissions" op het veld niveau, én voldoet aan de mandatoryFilterSets vam de tabel indien deze aanwezig zijn. Toegang tot het openen van de dataset en tabel wordt daarmee impliciet verkregen.

10. Generieke attributen

10.1. Omschrijving

Op elk niveau kan een semantische omschrijving toegevoegd worden d.m.v. de attributen title en description.

De title kan bijvoorbeeld in frontendapplicaties worden gebruikt als label voor een invoerveld. Het description veld is bedoeld voor bijvoorbeeld contextmenu’s (mouseover) bij een invoerveld of voor informatievelden.

  "title": "Bekende Amsterdammers",
  "description": "Bekende historische personen die in Amsterdam hebben gewoond.\n (Een voorbeeld dataset)",

  "title": "Locaties",
  "description": "Adressen in Amsterdam geassocieerd met een bekende Amsterdammer. \nBijvoorbeeld een voormalige woon of verblijfplaats",

          "Geboorteadres",
          "Werkplaats",

Note: Als een veld geen title-attibuut heeft, wordt de naam van het veld gebruikt.

10.2. Provenance

Provenance als veld wordt gebruikt om programmatisch informatie op te slaan over de oorsprong van bepaalde data.

In beperkte vorm kan provenance ook gebruikt worden om automatisch verwerking van brongegevens in andere formaten te bewerkstelligen.

Provenance is beschikbaar op zowel dataset-, tabel- als veld-niveau. Het is een vrij veld maar door een object met 'type' te specificeren kunnen specifieke machine readable profielen geactiveerd worden t.b.v. automatische bronverwerking

10.2.1. Vrije invoer

Dataset: "provenance": "Deze dataset wordt handmatig verwerkt door ..."

Tabel: "provenance": "Deze tabel is gebaseerd op een CSV bestand aangeleverd door ..."

Veld: "provenance": "Ontbrekende IDs zijn m.b.v TextEdit vervangen door UUID hashes van de naam in UTF-8."

10.2.2. Postgres

Dataset: "provenance": { "type": "postgres", "schema": "ruimte" }

Tabel: "provenance": { "table": "verhardingen" }

Veld: "provenance": { "field": "lengte_m", "type": "NUMERIC(10,2)"}

10.2.3. Shapefile

Dataset: "provenance": { "type": "shapefile"}

Tabel: "provenance": { "file": "asbestdaken_daken.zip" }

Veld: "provenance": { "field": "perceel_id"}

11. Attribuuttypen

12. Changelog

12.1. [3.0.0] Dataset versionering toegevoegd (2025-03-03)

Doelstelling
Toevoegen van versionering van datasets aan V3 van het Amsterdam Schema.

• § 2.6 Versionering van datasets gedocumenteerd.

• § 3 Versie toegevoegd.

• § 4.5 Versionering van tabellen aangepast naar de nieuwe situatie

12.2. [2.4.0] Scopes documentatie toegevoegd (2025-02-04)

Doelstelling
Aparte scopes objecten die de authorisatie van datasets, tabellen en velden bepalen.

• § 8 Scope gedocumenteerd.

• auth velden kunnen nu verwijzen naar een of meer scope files.

12.3. [2.3.0] filterAuth attribuut toegevoegd (2025-01-12)

Doelstelling
Betere afscherming van velden bij speciale zoekacties.

• Het filterAuth attribuut is toegevoegd.

• De § 9.2 Profielen zijn gedocumenteerd.

12.4. [2.2.0] dataclass attribuut toegevoegd (2023-01-12)

Doelstelling
Uitzonderingsgronden WOO in lijn gebracht met versie van WOO die nu van kracht is.

• Het dataclass attribuut is toegevoegd.

12.5. [2.1.5] dataclass attribuut toegevoegd (2023-01-10)

Doelstelling
Beschrijving en relatering van ongestructureerde data mogelijk maken.

• De opties in attribuut reasonsNonPublic aangepast.

• Verwijzing Wet Open Overheid geupdate.

12.6. [2.1.4] Publishers zijn zelfstandige objecten geworden (2022-12-21)

Doelstelling
Publishers zijn zelfstandige objecten geworden.

• Het publisher attribuut is een ref geworden.

• Het publisher object is toegevoegd.

12.7. [2.1.3] Auth attribuut verplicht op dataset niveau (2022-04-13)

Doelstelling
Alle datasets zijn openbaar tenzij obv de Wet Open Overheid. Maar om onbedoelde openbaarmaking te voorkomen, moet dit altijd expliciet ingevuld worden. Voor data die niet publiek is moet de uitzonderingsgrond worden vermeld.

• Het auth attribuut is verplicht gemaakt.

• Het dataset attribuut reasonsNonPublic is toegevoegd.

• Het tabel attribuut reasonsNonPublic is toegevoegd.

• Het veld attribuut reasonsNonPublic is toegevoegd.

12.8. [2.1.2] Auth attribuut niet toegestaan bij identifier en display velden (2022-04-13)

Doelstelling
De velden waar naar verwezen wordt in identifier en display moeten zichtbaar zijn voor iedereen die toegang heeft tot de tabel. Deze velden mogen dus geen auth bevatten.

• De velden waar naar verwezen wordt in de identifier en display attributen mogen geen auth attribuut bevatten.

12.9. [2.1.1] Crs attribuut verplicht bij geometrie velden (2022-03-23)

Doelstelling
Het coordinaat referentie systeem van een dataset met geo data moet bekend zijn voor correct functioneren van doelsystemen.

• Het crs veld is verplicht geworden wanneer één of meerdere tabellen een § 5.3.6 geometrie veld bevatten.

12.10. [2.1.0] Dataset contact gegevens (2022-03-17)

Doelstelling
Meerdere aanpassingen aan dataset velden voor contactgegevens. Met als doel om alle teams en organisaties die een rol hebben bij het ontsluiten van een dataset te vermelden. Zodat vragen over de dataset aan de juiste personen gericht kunnen worden.

• Nieuw optioneel veld creator toegevoegd.

• Het veld publisher heeft geen constant waarde meer. En bevat nu de naam van het datateam dat de dataset ontsluit.

• Het veld contactPoint is nu optioneel en bevat een standaard waarde.