Het zou handig en nuttig zijn om voor iedere vergadering de naam en identifier van de gemeente op te nemen. Hier bij voorkeur gebruik maken van TOOI of OWMS.

(uit de vragenlijst van de werkgroep videotulenstandaard)

Natuurlijk persoon: als dit een spreker betreft die niet als medewerker bekend is, kan de naam mogelijk niet worden gescheiden in voornaam en achternaam. Deze is dan namelijk ontvangen van een vergadersysteem als één waarde, bijv. “Voornaam Achternaam”.

(uit de vragenlijst van de werkgroep videotulenstandaard)
Een publicatiedatum is mogelijk relevant om aan te geven wanneer een vergadering historisch beschikbaar is gekomen voor burgers (i.e. gepubliceerd op de website van de gemeente/provincie) en kan ook relevant zijn voor import/export tussen leveranciers.

VNG: Interessant punt, gaan we nog naar kijken. Hoe zit het als bijvoorbeeld alleen een agendapunt wordt aangepast? Verandert dan ook de publicatiedatum van de vergadering?
Werkgroep: Publicatiedatum op niveau van vergadering vastleggen. Mogelijk kunnen latere toevoegingen/wijzigingen worden geregistreerd in een audit trail - hiermee leg je de oorspronkelijke publicatiedatum en latere wijzigingen/toevoegingen vast.

In het informatiemodel is nu niet opgenomen welke gemeente de data betreft.
Voorstel is om hier de organisatie (gemeente of provincie) op te nemen met enekel basisgegevens en de vergadering,
agendapunt en eventueel personen daaraan te linken.

Dit zodat attributen met dezelfde rol (indicatieHamerstuk in dit geval) dezelfde naamgeving hebben.

Misschien ook korter (en consequenter?) om deze attributen te hernoemen naar isHamerstuk, isBesloten, etc.

Het informatiemodel bevat een enumeratie soort genaamd besluitvormingsStukkenType. Er wordt echter verder op geen enkel ander punt naar besluitvormingsStukkenType verwezen.

Kan deze soort weg, of had er ergens een verwijzing naar moeten zijn?

De WCAG standaard wordt door vele overheden gebruikt om informatie toegankelijk te maken. https://www.w3.org/TR/WCAG21/

Het is praktisch om de informatie die in WCAG velden wordt gebruikt te hergebruiken (formaat en inhoud).

Naar-staat de mapping van de inhoud van teksten en meta data, is er ook de mogelijkheid om velden te gebruiken voor het verbeteren van zoekmogelijkheden. Een voorbeeld: Voor het uitbreiden van zoekmogelijkheden in bevat WCAG 2.1 bijvoorbeeld “alternative for time-based media” welke gebruikt kan om content te vinden die in de bron niet tekstueel is.

Volgens ORI heeft spreekfragment "video/audio tijdsaanduiding aanvang" en "video/audio tijdsaanduiding einde" attributen.

Bijvoorbeeld:

Attribuutsoort details Video tijdsaanduiding aanvang

Wat voor waarde wordt er nou precies bij deze tijdsaanduidingen verwacht? Een integer, of een string in hh:mm:ss formaat? En als het een integer moet worden, wat representeert deze integer dan?

De swaggerui is niet heel veel duidelijker, helaas:

{
  "aanwezigeDeelnemer": {
    "id": "string"
  },
   ...
  "audioTijdsaanduidingAanvang": 0,
  "audioTijdsaanduidingEinde": "string",
  "videoTijdsaanduidingAanvang": 0,
  "videoTijdsaanduidingEinde": "string",
  "positieNotulen": "string",
...
}

Bij de informatieobjecten vind je in de link dit soort URLs:

  "link": "https://hoorn.bestuurlijkeinformatie.nl/Document/View/0d70815c-0b02-47e1-9353-b1ea893fdc8d",

Het zou handig zijn als deze van dezelfde URL kunnen komen als de API zelf (opendata.ibabs.eu). Dat maakt de infrastructuur voor het ophalen van de data eenvoudiger (voorkomt dat voor iedere gemeente een andere externe site toegankelijk gemaakt moet worden)

Voeg de volgende waarden toe aan het informatiemodel en de API:

(uit de vragenlijst van de werkgroep videotulenstandaard)
Is het mogelijk om een behandelend ambtenaar toe te voegen bij agendapunten? Dit zou dan een vrij tekstveld zijn.

De huidige API specificatie is goed opweg om niet alleen een mooie REST API te worden, maar ook nog eens om een volwaardige Linked Data API te worden. Met een @context object (zie specificatie JSON-LD) kan dit realiteit worden.

Een @context JSON-LD object beschrijft de mapping tussen JSON keys en een URI. Hierdoor wordt het mogelijk om simpele, reguliere JSON namen te gebruiken, terwijl de semantische betekenis (en de daarbij RDF data) behouden blijft. Met andere woorden: door een @context beschrijving te hebben, kan je een gewone JSON API omzetten naar een RDF Linked Data API. Daarmee wordt het eenvoudig om de data op te slaan in triple stores en om het om te zetten naar formaten zoals Turtle, N-Triples, N-Quads of RDF-XML. Daarnaast maakt het de API nog iets makkelijker om te gebruiken: als een hergebruiker de JSON response wil gebruiken, kan hij de @context opvragen om de specificatie te bekijken.

Dit @context object kan in zijn volledigheid bij iedere respons worden bijgevoegd, maar dit zorgt voor een onnodig grote body. Gelukkig zijn er ook twee manieren om te linken naar een extern @context object, namelijk met een link in de body van de respons of met een speciale HTTP header. Ik zou willen aanbevelen om de eerste methode te gebruiken: een link in de body. Een respons komt er dan als volgt uit te zien:

{
    "@context": "https://vng.nl/ns/open-raadsinformatie/context.jsonld",
    "...": "..."
}

De link naar de @context resolved naar een bestand zoals het onderstaande:

{
    "@context": {
        "ori": "https://vng.nl/ns/open-raadsinformatie/",
        "naam": "ori:naam",
        "...": "..."
    }
}

Sub-issues:

• Het context object samenstellen. Imvertor (de software die voor VNG Realisatie diverse representaties maakt van een UML bestand) zou verantwoordelijk kunnen zijn voor het aanmaken van dit bestand.
• Het bestand online beschikbaar stellen van de @context bestand via een Namespace (URI) waar VNG-Realisatie controle over heeft.
• De @context waarden in de swagger documentatie naar de bovengenoemde URI laten linken. Momenteel tonen ze de waarde "string", dit zou een specifieke string moeten zijn naar het JSON-LD context object.
• De types in het @context object laten resolven naar hun definities. Voorbeeld: Het Vergadering type moet een link hebben, die als je hem opent, gaat naar een definitie van het concept Vergadering.
• De @type velden in de swagger docs laten linken naar de bovengenoemde Class definities van de typen.

(uit de vragenlijst van de werkgroep videotulen)
Het begrip ‘GEMEENTE’ wordt bij ieder object separaat benoemd als rubriek. Kan dit ook alleen op hoogste niveau worden gedaan?

NB: Dit lijkt inmiddels opgelost in het informatiemodel door naar Gremium te verwijzen.

Vaak is er een griffier per vergadering. Dit is voornamelijk nuttig voor commissiegriffiers e.d. Kan deze worden opgenomen als rolNaam bij ‘Aanwezige Deelnemer’?

(Uit de lijst met vragen van de werkgroep videotulenstandaard)

De iBabs api is momenteel voor de eerste test versie opgeleverd.
Deze is te vinden onder de url: https://opendata.ibabs.eu/api/
Er zijn 2 headers die expliciet gezet moeten worden anders werkt de api niet. Namelijk:

• X-Api-Key met waarde 10DAFA63-096D-4716-A2CA-29CEB3920C6D
• ibabs-site-name met waarde hoorn

De 2e header value gaat verdwijnen zodra het model is aangepast om dit op te halen via een api call.

De volgende api calls zijn beschikbaar:

• https://opendata.ibabs.eu/api/vergaderingstypes
• https://opendata.ibabs.eu/api/vergaderingen
  • Hier is een query parameter 'vergaderingstypeId' verplicht. Deze vind je in de eerste api call
• https://opendata.ibabs.eu/api/vergaderingen/{agendaId}
• https://opendata.ibabs.eu/api/agendapunten/{agendapuntId}
• https://opendata.ibabs.eu/api/informatieobjecten/{documentId}

Je kunt je opmerkingen plaatsen bij dit issue zodat we kunnen bijhouden wat er gebeurd.

Nadat /Open-Raadsinformatie naar /ODS-Open-Raadsinformatie is omgezet, werken de URLs in de markdown documenten niet meer. Een optie is om relatieve paden te gebruiken.

Op dit moment bevat het informatiemodel een url veld, welke verwijst naar de JSON API representatie van een resource.

Als hergebruiker van ORI data is het vaak handig om een link te hebben naar de webpagina waar de resource te zien was. Concreet: ik wil een "bekijk originele bron" button toevoegen op OpenBesluitvorming.nl, en daarvoor zou een link naar die page heel handig zijn.

Vooral bij vergaderingen is dat waardevol, omdat RIS systemen soms functionaliteiten hebben die niet in de API zijn gespecificeerd, or niet zijn verwerkt in een hergebruik-applicatie.

Naam ideetjes:

• webURL
• originalURL / origineleURL
• sourceURL / bronURL

Zo te zien omdat in headers verwezen wordt naar Bevragingen-ingeschreven-personen/master/api-specificatie/headers.yaml die niet langer beschikbaar/bereikbaar lijkt te zijn.

Voor het koppelen van de ORI-collectie aan andere publicerende instanties, zoals specifiek Open Overheid wordt het gebruik van standaarden voorgeschreven.
In de huidige API-specificatie lijken hierbij in ieder geval de volgende standaarden rond document management te missen:

1. (Verplicht) gebruik van Organisatie-Id conform de registers op Standaarden.Overheid.NL:
   https://identifier.overheid.nl/tooi/set/rwc_gemeenten_compleet
   https://identifier.overheid.nl/tooi/set/rwc_provincies_compleet
   https://identifier.overheid.nl/tooi/set/rwc_waterschappen_compleet

2. (Verplichte) aanduiding van informatiecategoriën volgens
   https://identifier.overheid.nl/tooi/set/scw_woo_informatiecategorieen

Ander waardelijsten kunnen nog worden toegevoegd, daarvoor kunnen we de opdracht aan KOOP afwachten.

(uit de vragenlijst van de werkgroep videotulenstandaard)
In de catalogus wordt 'Agendapunt kenmerk' gedefinieerd als “De weergave van het Agendapuntvolgnummer op de agenda.” Dit lijkt hetzelfde als 'Agendapunt Identificatie'. Willen jullie dit uitzoeken?

Goedemiddag,

Het informatiemodel bestuderende viel me op dat mediabronType, genoemd als datatype van 'Type' onder class 'Mediabron', ontbreekt in het schema. Uit welke attributen/elementen bestaat mediabronType?

Wij koppelen aan agendapunten informatie over gerelateerde personen.
Bijv. wie is de voorzitter, griffier en/of notulist.
Voor onderzoeken rondom de rol van de burgemeester, of naar verschillen tussen vergadering obv wie hem voorzit, is dat in onze ogen erg relevante data.

Bijvoorbeeld hier:

Verwijder deze dubbelingen!

Zie POST /besluiten.

Als hergebruiker zou ik graag willen dat ik bij een gevonden spreekfragment direct de video kan tonen op het juiste tijdstip.

Om dit mogelijk te maken, zou de client (de hergebruiker) in staat moeten zijn om:

• Het startmoment in de video te vinden
• De video URL te vinden
• De juiste headers / query parameters mee te sturen in een request voor de time-range

Ik ben niet echt thuis in hoe je audio / video over HTTP deelt, maar denk dat het belangrijk is om het helder te hebben - anders gaat het bovenstaande waarschijnlijk niet lukken.

De WhatWG <video> specificatie lijkt me een goed beginpunt. Hierin worden zowel een mime_type en een url gebruikt, zodat het mogelijk is om meerdere videobronnen voor hetzelfde materiaal te delen.

Ik zie alleen nog geen manier om het video startpunt mee te nemen naar de server in een HTTP request.

Bij het aanklikken van documenten komt geen resultaat
"Oeps, er is iets mis gegaan.
499
Try again"

De wens bij enkele leveranciers bestaat de wens om de standaard ook in een push-variant te kunnen gebruiken.

• Dagelijksbestuurlidmaatschappen
• Fractielidmaatschappen
• Stemmen
• Stemresultatenperfractie

De webVTT is een standaard van Mozilla : https://developer.mozilla.org/en-US/docs/Web/API/WebVTT_API

Daar waar het mogelijk is, is het handig om dit formaat te hanteren in de uitwisseling.

Hoe wordt daar over gedacht ?

In RGBZ 1 bestaat het eerste deel van identificaties (zaakidentificatie, documentidentificatie etc.) uit de 4-cijferige gemeentecode.
Dit is in RGBZ 2 vervangen door een identificatie gecombineerd met een 9-cijferige code voor de bronorganisatie. Deze code bevat Het RSIN van de Niet-natuurlijk persoon zijnde de organisatie die de zaak heeft gecreeerd. Het patroon is De in het NHR voorkomende unieke identificaties van rechtspersonen en samenwerkingsverbanden. Hiermee kunnen ook niet-gemeenten worden vastgelegd, wat weer van belang is voor samenwerking in de keten etc.

De 4-cijferige gemeentecode als onderdeel van identificaties is komen te vervallen.

Om de gegevens in de verschillende registers (Zaken, Documenten, Besluiten, Raadsinformatie, ?) goed aan elkaar te kunnen relateren is de bronorganisatie noodzakelijk.

https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/attribuutsoort/zaak.bronorganisatie
https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/attribuutsoort/zaak.zaakidentificatie

Allen,

De bestaande standaard voor Open Raadsinformatie is primair geschikt voor data ontsluiting voor vergaderingen die al plaats hebben gevonden. Het datamodel dat hiervoor is gedefinieerd lijkt me compleet.

Om de standaard ook geschikt te maken voor uitwisseling van data tussen vergadervoorbereiding / papierloos vergaderen applicaties en Cmeets moet het wel mogelijk zijn om data uit te wisselen met behulp van de standaard. Met alleen GET operaties gaat dat niet lukken.

Wanneer wordt er welke data uitgewisseld:

1. Net voor de vergadering
   a. import van een vergadering in Cmeets
2. Tijdens de vergadering
   a. terugleveren van timestamps door Cmeets
   i. start vergadering
   ii. agenda punten
   iii. spreekbeurten
   iv. stemmingen
   b. terugleveren van (individuele) stemmingsresultaten door Cmeets
   c. mogelijkheid tot live updaten agendapunten en moties/ en stemmingen
3. Na afloop van de vergadering
   a. stop vergadering
   b. eventueel alle timestamps indien live aanlevering niet supported/gewenst is.

Aangezien er veel datauitwisseling plaatsvindt tijdens een vergadering is het misschien handig om de enum vergaderingStatus uit te breiden met actief/live of iets dergelijks en eventueel nog met gepauzeerd/geschorst.

Omdat Cmeets in veel gevallen verantwoordelijk is voor het aansturen van het microfoon systeem is het voor ons van belang dat we per deelnemer weten of diegene stemrecht heeft. Op deze manier kunnen we het elektronisch stemmen per post aansturen. Verder is het in Cmeets ook mogelijk om per deelnemer een stemgewicht op te geven.

(uit de vragenlijst van de werkgroep videotulenstandaard)

Relaties tussen agendapunten kunnen alleen worden gekoppeld als subagendapunten. Er zijn echter ook relaties tussen agendapunten van verschillende vergaderingen mogelijk. Kan dit worden toegevoegd? Dit zou bijv. kunnen door de relatie tussen agendapunten definieerbaar te maken.

https://opendata.ibabs.eu/api/vergaderingen/c5bb0b32-43b7-4f0c-95f8-0641b55f7f89

"aanvangVergadering": null,
"audioLink": "",
"eindeVergadering": null,
"locatie": "IBabs Connect",
"naam": null,
"status": 0,
"vergaderdatum": null,
"vergaderingsidentificatie": null,

Naast het vastleggen van nieuwe records willen we ook bestaande data kunnen aanpassen.

• Vergadering : Vergaderingstype wordt uitgebreid met "Statenvergadering" en "Statencommissievergadering" ("Presidium" ook toevoegen bij vergaderingstype.)
  Gremium-constructie past voor de Staten.

• Ingekomen stuk kunnen ook ingediend worden door een organistie-onderdeel of een externe partij.

• Er is onderscheid gewenst tussen hamerstukken of stukken die besproken worden. De vraag hierbij is of dit een eigenschap van de het besluitvormingsstuk, het besluit of de stemming.

• Agendapunt Toevoegen indicatie hamerstuk of niet.

• In aanwezige deelnemer : Vertegenwoordigd organisatie --> moet zijn vertegenwoordigt organisatie of vertegenwoordigde organisatie.

• Type vragen komen nu niet terug: Er zijn technische vragen (over een agendapunt) of (politieke vragen die niet gekoppeld zijn aan behandeling van een agendapunt. Voorstel : technische vraag die ook vaak schriftelijk worden ingediend , mondelinge politieke vragen of schriftelijke politieke vragen .

• Toezeggingen : Een gedeputeerde doet een toezegging om iets te doen.

• Mededeling : (Kan vaak een antwoord zijn op een toezegging zijn)

• Toezeggingen dit valt in de categorie moties en amendementen. Toezeggingen en mededelingen toevoegen aan de informatieobject.

• Enumeratie functie:
  Commissaris van de Koning
  Gedeputeerde
  Statenlid
  Provinciesecretaris
  Ambtenaar/medewerker gemeente (gemeente weghalen….)
  Overig (voorstel om weg te halen

• Rolnaam:
  Statenlid
  Portefeuillehouder (ook geldig voor gemeenten)

• Indicator in functie van raadslidmaatschap :
  Hernoemen naar "Indicator nevenfunctie vanwege lidmaatschap"

• germiumSoort:
  Provinciale staten
  Statencommissie
  College van Gedeputeerde Staten
  Preasidium

• vergaderingstype
  Statencommissievergadering --> hoeft toch niet.

• Preasidium --> = Presidium.

• Alle enumeratiewaarden laten beginnen met hoofdletters.

• Enumeratie-waarde: Commissaris --> Commissaris van de Koning (Let op de hoofdletters).

• Dagelijkse bestuur --> Dagelijks bestuur

• Naam indiendende organisatie kan uit ingekomen stuk worden verwijderd.

Zoals toegelicht door GO & Notubiz (op 21-6-2021) wordt er vanuit gemeenten ook gevraagd naar het opnemen van stemgedrag in de Open Data API. We zouden dit dan ook graag terugzien in de volgende release.

Bijvoorbeeld: https://opendata.ibabs.eu/api/informatieobjecten/1cee9c81-674c-4d36-910f-61dd7ba4409b

Deze output:

System.UnauthorizedAccessException: The user is not allowed to view the document with id '1cee9c81-674c-4d36-910f-61dd7ba4409b'.
   at iBabs.Handlers.Public.PublicDocumentHandler.GetDocument(GetDocumentRequest request)
   at iBabs.Public.Api.Controllers.DocumentController.Get(Guid id) in C:\TFS\iBabsPublic\iBabs.Public.Api\Controllers\DocumentController.cs:line 85
   at lambda_method(Closure , Object , Object[] )
   at Microsoft.Extensions.Internal.ObjectMethodExecutor.Execute(Object target, Object[] parameters)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

HEADERS
=======
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: Keep-Alive
Host: ibabs-opendata-api-app-svc-01.azurewebsites.net
Max-Forwards: 10
User-Agent: PostmanRuntime/7.26.8
Via: 1.1 Azure
X-Api-Key: 10DAFA63-096D-4716-A2CA-29CEB3920C6D
ibabs-site-name: hoorn
Postman-Token: 75c3c46f-9ab7-440e-aef3-1e51b23d303c
X-Forwarded-For: 213.10.219.132, 147.243.84.77:22362
X-Azure-ClientIP: 213.10.219.132
X-Azure-Ref: 0vKb1XwAAAAApN8aqVgcERZBrcOhF8761QlJVMzBFREdFMDQxMgA2NjhiMzNkOS02MTgwLTRjODktOGZiOC1mZTA4ZDRmNTlhYTk=
X-Forwarded-Host: opendata.ibabs.eu
X-Forwarded-Proto: https
X-Azure-RequestChain: hops=1
X-Azure-SocketIP: 213.10.219.132
X-Azure-FDID: 668b33d9-6180-4c89-8fb8-fe08d4f59aa9
X-WAWS-Unencoded-URL: /api/informatieobjecten/1cee9c81-674c-4d36-910f-61dd7ba4409b
CLIENT-IP: 147.243.84.77:22362
X-ARR-LOG-ID: 77cfb502-9139-46a8-81fd-c145c516a0a6
DISGUISED-HOST: ibabs-opendata-api-app-svc-01.azurewebsites.net
X-SITE-DEPLOYMENT-ID: ibabs-opendata-api-app-svc-01
WAS-DEFAULT-HOSTNAME: ibabs-opendata-api-app-svc-01.azurewebsites.net
X-Original-URL: /api/informatieobjecten/1cee9c81-674c-4d36-910f-61dd7ba4409b
X-ARR-SSL: 2048|256|C=US, O=Microsoft Corporation, CN=Microsoft RSA TLS CA 01|CN=*.azurewebsites.net
X-AppService-Proto: https
X-Forwarded-TlsVersion: 1.2

• Vergadering : Vergaderingstype wordt uitgebreid met "Statenvergadering" en "Statencommissievergadering" ("Presidium" ook toevoegen bij vergaderingstype.)
  Gremium-constructie past voor de Staten.

• Ingekomen stuk kunnen ook ingediend worden door een organistie-onderdeel of een externe partij.

• Er is onderscheid gewenst tussen hamerstukken of stukken die besproken worden. De vraag hierbij is of dit een eigenschap van de het besluitvormingsstuk, het besluit of de stemming.

• Agendapunt Toevoegen indicatie hamerstuk of niet.

• In aanwezige deelnemer : Vertegenwoordigd organisatie --> moet zijn vertegenwoordigt organisatie of vertegenwoordigde organisatie.

• Type vragen komen nu niet terug: Er zijn technische vragen (over een agendapunt) of (politieke vragen die niet gekoppeld zijn aan behandeling van een agendapunt. Voorstel : technische vraag die ook vaak schriftelijk worden ingediend , mondelinge politieke vragen of schriftelijke politieke vragen .

• Toezeggingen : Een gedeputeerde doet een toezegging om iets te doen.

• Mededeling : (Kan vaak een antwoord zijn op een toezegging zijn)

• Toezeggingen dit valt in de categorie moties en amendementen. Toezeggingen en mededelingen toevoegen aan de informatieobject.

• Enumeratie functie:
  Commissaris van de Koning
  Gedeputeerde
  Statenlid
  Provinciesecretaris
  Ambtenaar/medewerker gemeente (gemeente weghalen….)
  Overig (voorstel om weg te halen

• Rolnaam:
  Statenlid
  Portefeuillehouder (ook geldig voor gemeenten)

• Indicator in functie van raadslidmaatschap :
  Hernoemen naar "Indicator nevenfunctie vanwege lidmaatschap"

• germiumSoort:
  Provinciale staten
  Statencommissie
  College van Gedeputeerde Staten
  Preasidium

• vergaderingstype
  Statencommissievergadering --> hoeft toch niet.

• Preasidium --> = Presidium.

• Alle enumeratiewaarden laten beginnen met hoofdletters.

• Enumeratie-waarde: Commissaris --> Commissaris van de Koning (Let op de hoofdletters).

• Dagelijkse bestuur --> Dagelijks bestuur

• Naam indiendende organisatie kan uit ingekomen stuk worden verwijderd.

Bij opvragen eerste pagina staat er keurig een 'next' link in de response:
"_links": { "self": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1&pagina=1" }, "next": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1&pagina=2" }, "last": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1&pagina=13" } },

Echter, ga je naar de volgende pagina, dan ontbreekt die:
"_links": { "self": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1&pagina=2" }, "first": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1" }, "prev": { "href": "https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1" } },

Sommige onderwerpen komen tijdens verschillende vergaderingen terug. Zo'n onderwerp wordt meestal een Dossier genoemd. Diverse raadsinformatiesystemen / vergadersystemen bieden hier ook functionaliteit voor. Als hergebruiker is dit concept bijzonder handig, want het maakt de informatie makkelijker door te bladeren. Ik denk dat het nuttig zou zijn als dit zou worden toegevoegd aan het model.

Volgens mij is het model van het Dossier als volgt:

• Relatie naar Stuk (Bijlage / informatieobject), n - n (in een dossier zitten meerdere bijlagen, aan een bijlage kunnen meerdere dossiers worden gekoppeld)
• Naam
• Beschrijving (achtergrondinformatie)
• Valt onder Dossier

Soms worden dossiers getoond als mappen, en is er ook nesting mogelijk (dossiers binnen een dossier).

Ik denk dat deze relatie ook anders is dan een Zaak, gezien een zaak doorgaans in een extern systeem wordt beschreven, en een Dossier niet.

Op de pagina 'Informatiemodel' is een link opgenomen naar de Catalogus Open Raads- en Stateninformatie, maar deze link is dood. Wordt er nog een catalogus toegevoegd met uitleg over de betekenis van alle termen in het model?

In de openapi.yaml zijn de resources behorend bij een object geplaatst in de _links resource.

Een voorbeeld hiervan is bij het vergadering object. Deze bevat de volgende _links:
aanwezigeDeelnemers
agendapunten
informatieobjecten
vergaderingen

Deze zouden geplaatst moeten worden in de _embedded resource omdat ze onderdeel zijn van de vergadering.

In het informatiemodel is nu niet opgenomen welke provincie de data betreft.
Voorstel is om hier de organisatie (gemeente of provincie) op te nemen met enkel basisgegevens en de vergadering,
agendapunt en eventueel personen daaraan te linken.

REST (REpresentational State Transfer) is ontworpen om de huidige staat van objecten over de lijn te communiceren. Voor de meeste hergebruikers, die simpelweg resources willen weergeven, volstaat dit. Helaas is dit in sommige situaties niet voldoende. Voor een aantal usecases is een systeem nodig waar de wijzigingen opvraagbaar zijn, in plaats van de huidige staat. Ik wil graag een aantal situaties toelichten waarin REST tekort schiet en waar we dus iets anders nodig zouden kunnen hebben:

Het bijhouden van een (volledige) kopie

Sommige systemen hebben een (deel van) de data nodig voor interne opslag. Hiervoor is synchronisatie nodig. Om te illustreren waarom dit lastig gaat over een traditionele REST API: bij Open Raadsinformatie vragen we elke nacht aan alle raadsinformatiesystemen alle vergaderingen op van de afgelopen maand en de komende maand. Deze vergelijken we met de data die we al hebben. Deze aanpak heeft een aantal nadelen:

• We missen wijzigingen die meer dan 30 dagen in het verleden / toekomst liggen.
• Het vraagt veel bandbreedte en rekenkracht - zowel aan de data aanbieder server als de hergebruiker.
• We hebben logica nodig om de wijzigingen te detecteren en om te voorkomen dat er resources (onterecht) dubbel worden aangemaakt.

Het snel ontvangen van updates

Sommige systemen willen weten wanneer iets veranderd. Denk bijvoorbeeld aan een mail notification systeem zoals in 1848.nl, waar meldingen worden verstuurd wanneer een item met een bepaalde zoekterm is toegevoegd. Ook dit is lastig te realiseren door alleen gebruik te maken van een REST API: als je minder dan 5 minuten vertraging wil hebben, moet je iedere 5 minuten pullen. Dat worden met een naïeve implementatie al snel zware requests.

Voorstel

Ik stel voor dat de Open Raadsinformatie API een endpoint specificeert waarin een hergebruiker een lijst van wijzigingen (events / deltas / feed items / activities) kan opvragen. Een goed gedocumenteerde en veel geïmplementeerde specificatie die kan volstaan, is de W3C Activity Streams standaard. Het is relatief eenvoudig om hier een minimale implementatie voor te schrijven. De leverancier kan een lijst met URLs van items teruggeven op een bepaald endpoint (/feed, bijvoorbeeld). Het client systeem kan vervolgens middels losse requests de inhoud van de aangemaakt / gewijzigde items ophalen, of de verwijderde items zelf verwijderen.

Om als hergebruiker te kunnen vaststellen of er wijzigingen zijn doorgevoerd in eerder verwerkte records zou het nuttig om hier faciliteiten aan toe te voegen in de ORI-API.

Een optie is om aan GET /vergaderingen een optionele parameter gewijzigdSinds toe te voegen. Het resultaat zou dan moeten zijn alle vergaderingen waarin iets is gewijzigd sinds dat moment. Het gaat dan om alle zaken die aan een vergadering 'hangen', dus agendapunten en informatieobjecten. Belangrijk aandachtspunt is dat het inzichtelijk moet zijn welke informatieobjecten zijn verwijderd (status opnemen in de respons). Dit kan van groot belang zijn als er abusievelijk vertrouwelijke documenten zijn gepubliceerd die moeten worden verwijderd. Ik meen zelfs dat dit vanuit AVG-oogpunt verplicht is, maar dat is voer voor de experts op dat vlak.

Groet,

Jaco.

HTTP Content Negotiation uses HTTP headers in both request and response to enable negotiation of serialization formats. Including this in an API specification greatly enhances its compatibility.

Since this API aims to comply to RDF constraints (IDs are URLs, keys are URLs, Resources have Classes which are URLs), it makes sense to allow other RDF serialization options, such as N-Triples and Turtle.

(uit de vragenlijst van de werkgroep videotulenstandaard)
BesluitvormingsStukkenType: Dit gaat ook over Hamerstukken vs Bespreekstukken. Is dit niet dubbel met Hamerstuk?

In een politieke markt zie je dat meerdere vergaderingen naast elkaar plaatsvinden die alleen maar herkenbaar zijn aan bijv. de naam van de zaal waarin ze gehouden worden. Ze starten op hetzelfde moment, zijn van dezelfde soort.
Dit model geeft - voor zover wij zien - geen houvast om dat goed uit elkaar te houden.

Op de pagina van het Informatiemodel.md wordt bij 'Doel' verwezen naar een technisch model, via de link: https://github.com/VNG-Realisatie/ODS-Open-Raadsinformatie/blob/master/docs/Uitwisselingsmodel.md. Deze link werkt niet (meer). Het model is nu alleen in jpg aanwezig.

Een technisch model zou zeer welkom zijn.