Giter Site home page Giter Site logo

tweedekamerderstaten-generaal / opendataportaal Goto Github PK

View Code? Open in Web Editor NEW
46.0 46.0 3.0 12 KB

GitHub van het officiële Open Data Portaal van de Tweede Kamer der Staten-Generaal.

Home Page: https://opendata.tweedekamer.nl

open-data parliamentary-data

opendataportaal's People

Contributors

opendataportaal avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

opendataportaal's Issues

Niet mogelijk om referentiedocument terug te vinden dmv '$expand=*'

Hieronder is een opgehaald document zichtbaar, specifieke url: https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Document/ec9315bf-e1d1-422e-a8fb-0000932ed927

image

Hierin staat onder footnote 2 een verwijzing naar een ander document (dmv een documentnummer).
Met het gebruik van $expand=* op de overkoepelende "Zaak" krijg ik het volgende terug als JSON:

image

Dan zien we bovenin metadata en onderin de gerelateerde data van de expand: ('Activiteit' tot en met 'Document').
'ZaakActor' bevat de betrokken mensen bij deze zaak.
'Document' bevat:
[0]: Antwoord schriftelijke vragen
[1]: Mededeling (uitstel antwoord)
[2]: Schriftelijke vragen

Geen van deze documenten betreffen "uw antwoorden op eerdere vragen over dit onderwerp?" zoals we zien bij footnote 2.
Mij is het dus niet gelukt om de gerelateerde referentie terug te vinden.

Is dit wel mogelijk? Zoja hoe dan?

Problemen met de SyncFeed

Er zijn op dit moment helaas weer problemen met de werking van de SyncFeed. Er wordt hard gewerkt aan een oplossing.

Data: inconsistent taalgebruik omschrijving in PersoonLoopbanen

Soms eindigt omschrijving met punt, soms niet. Soms kleine letter aan begin, soms niet. Koppelwoorden soms wel, soms niet. Linefeeds in de tekst.

Query:

select persoon_id
,      omschrijvingnl
from   PersoonLoopbanen@twk
where false
--
-- Inconsistent zin/zinsnede. Onduidelijk wat standaard is, hoofdletter begin? punt einde? Varieert breed.
--
or    ( omschrijvingnl like '%.' and omschrijvingnl not like '%V.' )
--
-- Begint met kleine letter.
--
or    upper(substr(omschrijvingnl, 1, 1)) != substr(omschrijvingnl, 1, 1)
--
-- Koppelwoord naar functie lijkt het.
--
or    ( upper(omschrijvingnl) like 'van %' or upper(omschrijvingnl) like 'vanaf %' or upper(omschrijvingnl) like 'aan %' or upper(omschrijvingnl) like 'voor %' or upper(omschrijvingnl) like 'waarin %')
--
-- Linefeeds in tekst.
--
or    omschrijvingnl like '%_' || chr(10) || '_%'

Zoals:

image

Layout documentatie pagina

De documentatie pagina schaalt wel, maar er wordt niet echt goed gebruik gemaakt van de beschikbare scherm grote.

Heel veel wit ruimte rondom de tekst.

Screenshot_20220623-075021.png

Inconsistentie datums

Ik weet (nog) niet of dit op meerdere plekken speelt, maar bij deze een voorbeeld:

Persoon -> Geboortedatum: 1821-06-09T00:00:00+02:00
Persoon -> Overlijdensdatum: 1906-09-15

Documentatie zegt voor beide velden 'datetime2 | 8'

Ik vind het vreemd dat een geboortedatum/overlijdensdatum datetime moet zijn, maar de eerste lijkt in ieder geval te kloppen met wat de documentatie voorschrijft. Overlijdensdatum is alleen een datum en klopt dus niet met de documentatie.

Inhoud verslag zoals gepubliceerd op officiele bekendmakingen

Ik probeer uit te vinden of ik via de OData API ook de volledige handelingen van debatten kan opvragen zoals te vinden op officiele bekendmakingen (of in ieder geval de voorlopige versie daarvan). Zie https://zoek.officielebekendmakingen.nl/h-tk-20222023-14-11.xml als voorbeeld.

Ik zie dat ik via de Verslag entiteit in ieder geval de spreekmomenten van iedere deelnemer kan krijgen, maar deze lijkt niet de transcriptie van wat er gezegd is te bevatten. Zie ik deze nu over het hoofd of is deze nog niet beschikbaar in de OData API? Zo ja, zou het wat mij betreft een zeer wenselijke feature zijn!

Syncfeed API: filteren op attribuut werkt niet

Volgens de de documentatie van de SyncFeed API is het mogelijk om argumenten te gebruiken om het verzoek te filteren op hun onderliggende attributen. Ik lees dat buiten category en skiptoken het ook mogelijk is om als URL parameter <attribuut>=<waarde> mee te sturen, hierbij staat vermeld:

Geeft een feed waarin iedere entiteit een attribuut met een specifieke waarde heeft

Echter, wanneer ik entiteiten van de categorie "Document" probeer op te halen, en hierbij probeer te filteren op Documenten waarvan het <vergaderjaar> attribuut "2021-2022" bevat, krijg ik nog steeds alle Documenten terug.


Voorbeeld:

URL
https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Feed?category=Document&vergaderjaar=2021-2022

Verwachting
Een resultaat met Documenten uit vergaderjaar 2021-2022.

Resultaat
Alle Documenten, ongeacht de waarde van het vergaderjaar attribuut.


Het probleem lijkt niet Document-specifiek, zo geven de onderliggende queries ook niet het verwachte resultaat:


Kunnen jullie er voor zorgen dat het mogelijk is om entiteiten te filteren op hun attributen, zoals vermeld staat in de documentatie? Alvast bedankt!

Open API TweedeKamer beschikbaar via Cross Domain

De Tweedekamer API is niet cross-domain bereikbaar. Ik krijg met een Javascript fetch nog steeds de error CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Ik heb de Tweedekamer API cross-domain beschikbaar gemaakt via tweedekamer.aliconnect.nl/api. Daar is tevens een OAS / Open API Specificatie te downloaden. Deze is te bekijken met editor.swagger.io. Je kan gebruik maken van de [Try it out] button. De POST, PATCH en DELETE methoden zijn niet beschikbaar, deze API is alleen lezen. De demo applicatie is te bekijken op tweedekamer.aliconnect.nl.

Datafout reis Ernst Cramer

De reis naar Werkbezoek vaste commissie voor Verkeer en Waterstaat. omstreeks mei 2008 heeft als startdatum:

5008-05-05

Dit moet vermoedelijk 2008-05-05 zijn.

Verwachting is dat start datum <= tot/met datum is.

image

Enkele portretten/afbeeldingen kamerleden hebben afwijkende ratio & zijn >1,5MB groot

De volgende ID's hebben een afbeelding die sterk afwijkt van de rest van alleafbeeldingen in formaat & grootte.

4253b5a0-daa6-470d-bc6c-004707a1079b
d847851a-777b-43c6-83b3-392672659edc
f067f702-8e06-491a-9498-462205d1aaec
990b2d9b-0b83-4dde-ab04-5cd5d8c5c4d3
beb41c8f-0433-418c-ba75-617240b3baa3
a4993263-317a-4c92-b844-6521aa1eaaba
a824c21d-055a-49ed-a060-a1c7af3262df
36ed934d-56c7-4903-a0a8-a9f186d5a96f
efd89dff-2cde-4afc-ab14-e4f9795d1407

Kunnen deze worden gelijkgetrokken met de rest?

Foute zetel persoon datums bij Henk Kamp

Lid Henk Kamp heeft een aantal vreemde regels in fractie / zetel / personen:

select id
,      functie
,      van
,      totenmet
from   fractiezetelpersonen@twk
where  persoon_id = '106805cc-d387-4481-b068-825dc0d6de44'

image

Verwachting is dat de totenmet-datum sowieso niet lager kan zijn dan de van-datum voor het bezet houden van een zetel.

Toestaan van Cross-Origin Resource Sharing bij OData API

Het is momenteel niet mogelijk om de OData API aan te roepen op een ander domein dan https://gegevensmagazijn.tweedekamer.nl

Voorbeeld

Gegeven het volgende stukje Javascript

var xhttp = new XMLHttpRequest();
xhttp.open("GET", "https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Document(7a9b77f1-d230-4a00-9856-2f0f8e967e62)");
xhttp.send();

Dan laat de browser weten dat dit niet mogelijk
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Document(7a9b77f1-d230-4a00-9856-2f0f8e967e62). (Reason: CORS request did not succeed). Status code: (null).

Oplossing

De volgende HTTP header kan worden toegevoegd aan de response van de OData API
Access-Control-Allow-Origin: *
Dit staat toe dat de browser vanuit elke website een verzoek aan https://gegevensmagazijn.tweedekamer.nl/OData/ mag doen. Dit maakt het mogelijk om applicaties te maken die direct gebruik maken van de OData API, zonder dat daar een extra back-end server tussen hoeft te staan.

Meer informatie over CORS is te vinden op https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Verbeteren status response codes

Voorbeeld

Betreffend : OData API
Het lijk zo te zijn dat invalide invoer altijd wordt afgehandeld met HTTP-statuscodes 500

Zo geven bijvoorbeeld :
I ) https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Willekeur
II ) https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Fractie/Willekeur

Allebei

500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.

Terwijl in feiten de resource niet gevonden kan worden (404)


Apart is dat wanneer we een space achter het verzoek plaatsen wordt er wel een 404 error afgegeven. Echter; net zoals bij de bovenstaande voorbeelden. In de vorm van een html pagina.
I ) https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Willekeur%20
II ) https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Fractie/Willekeur%20

 The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable.  Please review the following URL and make sure that it is spelled correctly.

Requested URL: /OData/v4/2.0/Willekeur

Wat ik zelf nog vreemder vind, is dat wanneer een anderen methode wordt meegegeven bij een juiste query verzoek er wel een 404 status code wordt afgegeven
I) https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Stemming?$top=2 (POST)

{
    "error": {
        "code": "",
        "message": "No HTTP resource was found that matches the request URI 'https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Stemming?$top=2'."
    }
}

Hier zou je eerder 405: Method not allowed verwachten

Wens

Het zou fijn zijn voor debuggen en netheid en toepasbaarheid dat

  1. Er een uniforme error format wordt teruggegeven
    (bij het eerste voorbeeld wordt een html pagina teruggegeven en de tweede een json response met een lege code)
  2. Er juiste (verwachtbare) http codes worden teruggeven

Syncfeed Besluit 500

Interesante data! Ik ben nieuw met deze API, maar ik krijg een fout als ik alle besluiten wil ophalen via Syncfeed (Is dat hetzelfde als Feedsync trouwens?):

➜  tmp git:(main) ✗ wget https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Feed\?category\=Besluit
--2022-10-26 20:45:10--  https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Feed?category=Besluit
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving gegevensmagazijn.tweedekamer.nl (gegevensmagazijn.tweedekamer.nl)... 20.82.52.30
Connecting to gegevensmagazijn.tweedekamer.nl (gegevensmagazijn.tweedekamer.nl)|20.82.52.30|:443... connected.
HTTP request sent, awaiting response... 500 Internal Server Error
2022-10-26 20:45:41 ERROR 500: Internal Server Error.

Moet ik misschien de resultatenset limiet meegeven?

@odata.nextLink ook toepassen bij aanwezigheid $top parameter

Momenteel wordt “Wanneer een query meer dan 250 resultaten geeft (…) onderaan de pagina een query die leidt naar de volgende pagina.” Toegevoegd; dit is fijn aangezien dit aangeeft dat er meer resultaten beschikbaar zijn.

Echter is bij het plaatsen van de $top functionaliteit dit niet het geval
(staat ook niet beschreven in de documentatie dus in die zin logisch)

Maar nu zou het naar mijn mening een toegevoegde waarde zijn als deze bovengenoemde query (@odata.nextLink) ook weergeven wordt wanneer er een $top functionaliteit/parameter aanwezig is. Dit omdat :

I ) Het consistentie met zich meebrengt; als er meer resultaten zijn buiten de huidige weergaven wordt de @odata.nextLink geplaatst en niet alleen als dit het geval is is bij 250+ items. Dus bij elke overflow usecase is het resultaat hetzelfde

II ) Het handig is voor bijvoorbeeld pagination. Waar het resource technisch niet logisch is om 250 items in te laden maar bijvoorbeeld 25. Maar het wel handig is om te weten of er nog meer resultaten voor de zoekopdracht beschikbaar zijn.

Veel-op-veel relaties zichtbaar maken

Voor zover ik kan zien is het in het huidige data model niet mogelijk om een connectie te maken met een veel-op-veel relatie. Je kan bijvoorbeeld niet zien over welke Zaken een Besluit gaat (of andersom).
Zoiets zou mogelijk moeten zijn met bijvoorbeeld een lijst van Id's en het zou het mogelijk maken om verbanden te leggen tussen verschillende entiteitsoorten.

Ontbrekende Verslagen in vergaderjaren 2016-2017 en 2017-2018

Bij een analyse van de datakwaliteit is geconstateerd dat in https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Verslag? in totaal 21 Verslagen in xml-formaat ontbreken in de vergaderjaren 2016-2017 en 2017-2018. Deze Verslagen – allen van commissie-activiteiten – zijn dus momenteel helaas niet beschikbaar in xml-formaat. Wel zijn deze verslagen beschikbaar als Document, zie bijvoorbeeld: https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Document(a83d7807-6719-4c99-861a-cd00d396cdd4)/Resource.

We werken eraan om deze Verslagen met terugwerkende kracht beschikbaar te maken als Verslag.

Dubbele punt in content-disposition van xml verslagen

Als ik een resource opvraag van een verslag dan krijg ik een filenaam terug met twee punten voor de extensie.
Ik had verwacht een enkele punt te krijgen tussen filenaam en extensie.

Een voorbeeld request is de resource cdc70ea8-279d-457b-b0ea-bff9bb5797ed.

curl -sD - -o /dev/null 'https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Resources/cdc70ea8-279d-457b-b0ea-bff9bb5797ed'

Deze hoort bij verslag cdc70ea8-279d-457b-b0ea-bff9bb5797ed, bij vergadering df6522e0-3290-41a3-8fe8-ff2d70762a00. Als ik kijk naar de http response dan zie ik een dubbele punt (..) bij het veld Content-Disposition. Hierdoor krijgt de file een naam met een dubbele punt in plaats van een enkele. Dit kan men reproduceren met bijvoorbeeld het commando wget --content-disposition 'https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Resources/cdc70ea8-279d-457b-b0ea-bff9bb5797ed'.

De volledige header is:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 258587
Content-Type: text/xml
Expires: -1
Content-Disposition: inline; filename=cdc70ea8-279d-457b-b0ea-bff9bb5797ed..xml
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'
Date: Sat, 12 Aug 2023 12:14:14 GMT
Set-Cookie: XXX; Path=/; Domain=.gegevensmagazijn.tweedekamer.nl

De incorrecte filenaam is:
filename=cdc70ea8-279d-457b-b0ea-bff9bb5797ed..xml
Ik had hier verwacht:
filename=cdc70ea8-279d-457b-b0ea-bff9bb5797ed.xml

Ik zie dit probleem ook bij andere resources, bijvoorbeeld https://gegevensmagazijn.tweedekamer.nl/SyncFeed/2.0/Resources/98a7aceb-516b-4a89-a29e-446db0e64e90 van dezelfde vergadering.

Kunt u de dubbele punt vervangen door een enkele punt?

Alvast bedankt!

Inhoud tabel Fracties: alle velden behalve Id leeg bij ruim meer dan de helft.

De volgende query gaf wat vreemde resultaten omdat data lijkt te ontbreken in de kolommen:

set log-native-calls-to-disk@twk true

set use-http-disk-cache@twk false

set use-http-memory-cache@twk false

select *
from fractie@twk
where nummer is null

Er zijn blijkbaar 87 fracties die geen naam hebben, maar wel een ID. Er zijn er 53 die een ID en een naam hebben.

Het OData verzoek is:

{ "Url":"https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Fractie/"
, "Success":true
, "CallDirection":0
, "Id":1
, "DateRegisteredUtc":"2022-06-23T06:44:07.690449Z"
, "RequestBodyAsString":""
, "ResponseBodyAsString":"{\"@odata.context":"https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/$metadata#Fractie\"...
}

In het OData antwoord staat inderdaad wel een ID maar geen waarde bij overige velden:

{"Id":"e133cd98-1b5c-47e0-ac4d-031f34199767","Nummer":2783,"Afkorting":"BRINK","NaamNL":"Brinkman","NaamEN":"Brinkman","AantalZetels":null,"AantalStemmen":null,"DatumActief":"2012-03-20T00:00:00+01:00","DatumInactief":"2012-09-19T00:00:00+02:00","ContentType":null,"ContentLength"
:null,"GewijzigdOp":"2022-02-11T13:57:54+01:00","ApiGewijzigdOp":"2022-02-11T12:59:33.0796783Z","Verwijderd":false}
,{"Id":"bb5b3750-7152-4120-8116-064c77d9748d","Nummer":null,"Afkorting":null,"NaamNL":null,"NaamEN":null,"AantalZetels":null,"AantalStemmen":
null,"DatumActief":null,"DatumInactief":null,"ContentType":null,"ContentLength":null,"GewijzigdOp":null,"ApiGewijzigdOp":null,"Verwijderd":null
}

Verzoek is om ongeldige rijen weg te laten of tenminste de natuurlijke sleutel Nummer te vullen.

SyncFeed "updated" veld

Hi all,

Allereerst wil ik even melden dat ik erg blij ben dat het Open Data Portaal sinds kort beschikbaar is voor iedereen!

Ik heb wel een vraag betreft het <updated> veld in de SyncFeed API. Zoals de documentatie voorstelt bevraag ik deze API nu periodiek om te synchroniseren met mijn eigen database, en gebruik ik de DateTime-waarde uit dit veld om te bepalen of er een update uitgevoerd moet worden in mijn database.

Echter, in de documentatie zie ik bij meerdere modellen de volgende twee attributen staan:

ApiGewijzigdOp
Datum waarop een Persoon zichtbaar is geworden in de OData API. In de SyncFeed API is dit het element 'updated'.

GewijzigdOp
Datum wanneer het bronsysteem een Persoon heeft aangemaakt of aangepast. In de SyncFeed API is dit het attribuut 'tk:bijgewerkt' van het element 'persoon'.

Aan de hand van deze informatie lijkt het zo dat het <updated> veld dus niet aangeeft of de entry geüpdatet is in jullie bronsysteem, maar alleen aangeeft sinds wanneer hij toegevoegd is in de XML result, en is het tk:bijgewerkt veld het daadwerkelijke veld waaruit blijkt of een entry geüpdatet is. Klopt dit?

En zo ja: kunnen jullie er voor zorgen dat het <updated> veld wél daadwerkelijk aangeeft wanneer de informatie binnen de entry aangepast is? Dit zou de uitwisseling een stuk schoner houden omdat er dan niet gekeken hoeft te worden naar de content in een entry. Deze content is namelijk "category-specific", en dat zou voor ieder model betekenen dat ik dieper moet graven om te bepalen of ik mijn record moet updaten, terwijl wat mij betreft het <updated> veld hier de logische plek voor is.

Alvast bedankt!

Laatste bevindingen persoon* entiteiten

PersoonContactinformatie
Soort -> LinkedIn documentatie, maar Linkedin in data. (dus zonder hoofdletter 'i')

PersoonReis
Van/TotEnMet 'Datetime2' maar ik zie alleen datums in de data
BetaaldDoor mist in documentatie

PersoonLoopban
Van/TotEnMet 'Datetime2' maar ook hier alleen datums (soms alleen jaartal) in data
Functie mist in documentatie
OmschrijvingNl/En geeft aan 255 max, maar kan ook langer zijn. b.v. 95a24091-b385-436e-bc3e-aaee5402e59a (284 karakters)

PersoonOnderwijs
OpleidingEn mist
Van/TotEnMet 'Datetime2' maar ook hier alleen datums (soms alleen jaartal) in data

Documentatie nevenfuncties

Onder PersoonNevenfunctie

  • Gewicht mist in documentatie
  • Vergoedingsoort -> O>m<kostenvergoeding, moet zijn Onkostenvergoeding (Alleen in documentatie, data is goed)
  • Omschrijving kan langer zijn dan 255, zie b.v. 4393a496-a09c-4a66-ad25-d804e81aace1 (403 karakters)

Product-specifiek ikoon

Op dit moment is er een blauw vierkant met vrij grote omvang als visuele representatie.

Het zou handig zijn qua herkenbaarheid als er ook een formele iconische weergave voor het product zou zijn, herbruikbaar zonder verlies van rechten.

Inconsistente schrijfwijze initialen leden

De schrijfwijze van van initialen - mogelijk door herkomst uit een ander systeem want lijkt vooral of uitsluitend oudleden te betreffen - is inconsistent.

Voorbeeld obv achternaam = Dijk:

image

Suggestie is om puntgescheiden te gebruiken, zodat ook dubbele voorletters kunnen zoals "Th." voor Theodora.

Inconsistentie functieomschrijving

Onder persoon -> functie zijn er drie mogelijkheden:

  • Oud Kamerlid
  • Eerste kamerlid
  • Tweede Kamerlid

Oud- en Tweede Kamerleden is K met hoofdletter, bij 1e Kamer niet.

RSS-feed op nieuwspagina van website

Daar we berichten over updates, storingen en onderhoud van het Open Data Portaal op de website plaatsen lijkt het ons wenselijk om een RSS-feed beschikbaar te stellen op de nieuwspagina. We gaan hiermee aan de slag.

Ophalen gerelateerde documenten (oData)

Goedemorgen,

Wij hebben een vraag omtrent het ophalen van gerelateerde documenten (dus geen bijlagen).
We voeren momenteel een query uit met de volgende beschikbare expand parameters: DocumentVersie, BronDocument, BijlageDocument, HuidigeDocumentVersie, DocumentActor, Kamerstukdossier, Zaak, Activiteit & Agendapunt maar zien geen gerelateerde documenten terugkomen.

Neem bijvoorbeeld dit kamerstuk. Op de website zien we daar twee gerelateerde documenten, maar in de JSON zien we deze niet:

{
"Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927",
"Soort": "Antwoord schriftelijke vragen",
"DocumentNummer": "2019D16854",
"Titel": null,
"Onderwerp": "Antwoord op vragen van het lid Van Nispen over het mogelijk strafrechtelijke karakter van het sluiten van drugspanden door de burgemeester ",
"Datum": "2019-04-24T00:00:00+02:00",
"Vergaderjaar": "2018-2019",
"Kamer": 2,
"Volgnummer": -1,
"Citeertitel": null,
"Alias": null,
"DatumRegistratie": "2019-04-23T00:00:00+02:00",
"DatumOntvangst": null,
"Aanhangselnummer": "181902411",
"KenmerkAfzender": null,
"Organisatie": "Tweede Kamer",
"ContentType": "application/pdf",
"ContentLength": 32150,
"GewijzigdOp": "2022-04-26T09:55:26.683+02:00",
"ApiGewijzigdOp": "2022-04-30T16:43:22.8081028Z",
"Verwijderd": false,
"DocumentVersie": [
{
"Id": "106ec4cb-db43-4ab2-9aed-01a5b756b58d",
"Status": "Vrijgegeven",
"Versienummer": 1,
"Bestandsgrootte": 108,
"Extensie": ".docx",
"Datum": "2019-04-23T10:51:58.693+02:00",
"GewijzigdOp": "2019-10-21T10:22:48.577+02:00",
"ApiGewijzigdOp": "2019-10-21T09:12:23.7939704Z",
"Verwijderd": false,
"Document_Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927"
},
{
"Id": "ffb35c1c-da22-45d4-919d-3fa9c400567f",
"Status": "Vrijgegeven",
"Versienummer": 3,
"Bestandsgrootte": 47,
"Extensie": ".pdf",
"Datum": "2019-04-26T13:50:52.757+02:00",
"GewijzigdOp": "2019-10-21T10:22:53.213+02:00",
"ApiGewijzigdOp": "2019-10-21T10:35:53.3975182Z",
"Verwijderd": false,
"Document_Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927"
},
{
"Id": "bda61cb5-4e37-4457-9aa9-cc8bc6db8072",
"Status": "Vrijgegeven",
"Versienummer": 2,
"Bestandsgrootte": 32,
"Extensie": ".doc",
"Datum": "2019-04-25T13:13:48.42+02:00",
"GewijzigdOp": "2019-10-21T10:22:57.427+02:00",
"ApiGewijzigdOp": "2019-10-21T11:59:28.9753681Z",
"Verwijderd": false,
"Document_Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927"
}
],
"BronDocument": [],
"BijlageDocument": [],
"HuidigeDocumentVersie": {
"Id": "ffb35c1c-da22-45d4-919d-3fa9c400567f",
"Status": "Vrijgegeven",
"Versienummer": 3,
"Bestandsgrootte": 47,
"Extensie": ".pdf",
"Datum": "2019-04-26T13:50:52.757+02:00",
"GewijzigdOp": "2019-10-21T10:22:53.213+02:00",
"ApiGewijzigdOp": "2019-10-21T10:35:53.3975182Z",
"Verwijderd": false,
"Document_Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927"
},
"DocumentActor": [
{
"Id": "bffe98f7-acf7-464d-a82e-95c31194fb49",
"Document_Id": "ec9315bf-e1d1-422e-a8fb-0000932ed927",
"ActorNaam": "F.B.J. Grapperhaus",
"ActorFractie": null,
"Functie": "minister van Justitie en Veiligheid",
"Relatie": "Eerste ondertekenaar",
"SidActor": "S-1-365867521-2120874753-1363728866-1133790722-4112211636-101436480",
"GewijzigdOp": "2019-10-21T11:45:07.76+02:00",
"ApiGewijzigdOp": "2019-10-21T21:22:24.554913Z",
"Verwijderd": false,
"Persoon_Id": "b05c47d7-4895-47f8-b972-009c1ca90107",
"Fractie_Id": null,
"Commissie_Id": null
}
],
"Kamerstukdossier": [],
"Zaak": [
{
"Id": "ec1c32a7-37f3-4668-91a3-a25f3d40e52b",
"Nummer": "2019Z05743",
"Soort": "Schriftelijke vragen",
"Titel": null,
"Citeertitel": null,
"Alias": null,
"Status": "Vrijgegeven",
"Onderwerp": "Het mogelijk strafrechtelijke karakter van het sluiten van drugspanden door de burgemeester ",
"GestartOp": "2019-03-25T00:00:00+01:00",
"Organisatie": "Tweede Kamer",
"Grondslagvoorhang": null,
"Termijn": null,
"Vergaderjaar": "2018-2019",
"Volgnummer": -1,
"HuidigeBehandelstatus": null,
"Afgedaan": true,
"GrootProject": false,
"Kabinetsappreciatie": null,
"GewijzigdOp": "2019-10-17T15:22:23.043+02:00",
"ApiGewijzigdOp": "2019-10-17T13:56:16.7228499Z",
"Verwijderd": false
}
],
"Activiteit": [],
"Agendapunt": []
}

Hoe zouden we, bijvoorbeeld voor dit specifieke document, de gerelateerde documenten uit de API kunnen halen?

Verband motie-nummer in publicatie en opzoeken in portaal

Het lijkt er op dat het lastig is om de onderliggende data van een gepubliceerde motie (bijv. de PDF, of bekende rood/groene vinkjes uitslag) terug te zoeken in het data-portaal.

Voorbeeld: van deze motie (https://www.tweedekamer.nl/kamerstukken/moties/detail?id=2020D54260&did=2020D54260) zijn in de PDF bekend het vergaderjaar 2020-2021, 35393 en nr 21.

Het bijbehorende record in het portaal is https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Zaak(dcd99b99-8ddd-4ac1-a0ab-87678a7e244d), maar daarin is alleen het Volgnummer 21 terug te vinden (maar dat is niet uniek). Bijvoorbeeld https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/Zaak?$filter=Vergaderjaar%20eq%20%272020-2021%27%20and%20Soort%20eq%20%27Motie%27%20and%20Volgnummer%20eq%2021 geeft veel resultaten terug.

Het record heeft wel een Nummer, namelijk 2020Z25819, maar dit is dan weer niet terug te leiden tot de data uit de motie tekst. Is de match echt alleen te vinden door op titel te zoeken?

Geen valide XML content

<content type="application/xml"> <ns1:verslag xmlns:ns1="http://www.tweedekamer.nl/xsd/tkData/v1-0" id="abc" ns1:verwijderd="false" ns1:bijgewerkt="2020-03-07T21:48:20.0603012+01:00" ns1:contentType="text/xml" ns1:contentLength="123"> <ns1:vergadering xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns1:referentieLiteral" ref="def"/> <ns1:soort>Tussenpublicatie</ns1:soort> <ns1:status>Ongecorrigeerd</ns1:status> </ns1:verslag> </content>

xsi:type="ns1:referentieLiteral" type referentieLiteral niet herkent namespace http://www.tweedekamer.nl/xsd/tkData/v1-0

Is er wel een external XSD ?

Documentatie beschikbaar maken volgens OpenAPI-specificatie (voorheen Swagger)

Het lukt me niet om in de documentatie terug te vinden of er een OpenAPI-specificatie is van de API's.

Mocht die er zijn: gelieve die een meer prominente plek te geven.

Mocht die er niet zijn: gelieve een OpenAPI-specificatie toe te voegen voor eenvoudiger ontsluiting. Het scheelt per API circa 1 mandag voor opname in Invantive Cloud / SQL.

De $metadata van OData is wel te vinden op https://gegevensmagazijn.tweedekamer.nl/OData/v4/2.0/.

Semantiek veld Gewicht bij bijvoorbeeld PersoonNevenfunctie

Zie ook #79

Het veld Gewicht komt in meerdere tabellen voor met als uitleg:

Waarde om de positie van een PersoonNevenfunctie in een lijst te bepalen.

Het is intuitief niet duidelijk voor mij wat de sorteer volgorde dan is.

Is het een primaire sorteervolgorde, dus eerst alles met gewicht (aflopend gesorteerd?) en daarna op jaar?

Of een secundaire sorteervolgorde, zoals eerst op jaar, en dan op gewicht oplopend of aflopend?

Type GewijzigdOp niet overal gelijk

Niet per sé fout, maar ik vraag mij af waarom er bij sommige entiteiten (bv KamerstukDossier of Document) het type van GewijzigdOp 'datetimeoffset' is en bij andere entiteiten (bv Persoon) het 'datetime2' is

Koppeling met videos van vergaderingen?

Ik probeer informatie over debatten te koppelen aan videos van debatten.

Stel ik heb videoverslag:

Dit verslag hoort bij de vergadering (met name de activiteit van soort plenaire vergadering in die vergadering):

Ik zag in de informatie in de html en de videostream geen bruikbare id's om de link mee te leggen.

Is het mogelijk om uit de informatie van het videoverslag een link te leggen met bijbehorend verslag, activiteit en vergadering?

Alvast bedankt!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.