Deze discussie is een vervolg op deze melding in het forum Zaak- Documentservices
In de praktijk blijkt dat het gegeven omschrijving van een zaak (nu 80 tekens) niet groot genoeg is om een goede omschrijving in te vullen. Met een beetje naam/adres en korte omschrijving ga je over die grens heen.
Daarom het wijzigingsverzoek om het RGBZ aan te passen en het veld omschrijving van een ZAAK uit te breiden naar 250 tekens.
Dit attribuut is overgenomen uit GFO Zaken. De lengte is dus al 14 jaar gedefinieerd als maximaal 80 posities. Het bevreemd mij dat er procesapplicaties zijn die zaakgericht werken ondersteunen maar intern een lengte van 250 posities hanteren voor dit gegeven.
In zowel GFO Zaken als in RGBZ is dit attribuut gedefinieerd als ‘Een korte omschrijving van de zaak’. De maximale lengte van 80 posities sluit daar goed bij aan. Daarnaast is het attribuut ‘Toelichting’ beschikbaar met een maximale lengte van 1000 posities. Hierin kan desgewenst een uitgebreide omschrijving van de zaak worden opgenomen.
Daarom zie ik geen aanleiding om de lengte van dit attribuut aan te passen. En als wordt besloten dit toch te doen, dan lijkt het mij niet verstandig dit in een patch op te nemen.
Op zich ben ik het met bovenstaande eens, het is niet handig om in zowel een vakapplicatie als een zaaksysteem (tenminste, als ik het goed begrepen heb) andere veld definities dan die uit het RGBZ te hanteren.
Aan de andere kant, onderstaande is een vrij beknopte beschrijvingen die is al langer dan 80 tekens
Behandelen bouwaanvraag dd. 20-11-2018 van M. Verhoef betr. Beukenlaan 19 te Deventer
Uiteindelijk is het denk ik gewoon zo dat een Informatiemodel aan moet sluiten op behoeften in de werkelijkheid. Dus wanneer blijkt dat er behoefte is aan een langer veld moeten we dit niet tegenhouden omdat het al (in dit geval) 14 jaar een lengte van 80 tekens heeft.
'Niet handig' (1e alinea voorgaande reactie) is voorzichtig uitgedrukt. Afspraken over bijvoorbeeld de lengte van een attribuut zijn noodzakelijk om interoperabiliteit te bereiken. Dan moet vervolgens iedereen zich wel aan de afspraken houden, anders werkt die interoperabiliteit in de praktijk niet. Het laatste lijkt me de oorzaak van dit issue cq. deze discussie. Dat op zich kan geen reden zijn de afspraken te wijzigen. Wel kunnen we ons afvragen of een afspraak nog valide is vanuit inhoudelijke gronden. Oftewel, wat was de reden voor 80 posities en geldt die reden nog?
De naamgeving van het attribuut 'Zaakomschrijving' is verwarrend. Feitelijk gaat het om de naam die aan een zaak gegeven wordt. Maar goed, zo heette dit attribuut nou eenmaal in de voorloper van het RGBZ: het GFO Zaken. Het is verstandig de naam kort te houden, omdat deze her en der gebruikt zal worden in overzichten van zaken (een uitgebreidere omschrijving kan gegeven worden met de attribuutsoort Toelichting, zoals Roel al meld). Het is naast de zaakidentificatie de eerste aanduiding van een zaak. Maar hoe lang is reeel? Is 80 genoeg? Het is 'de kunst' om in de naam (cq. zaakomschrijving) de zaak kort en kernachtig te benoemen. Wat moet er in staan en wat niet? Een methode daarvoor is de zgn. GEHOPTE schrijfwijze:
- GEzichtspunt: wie doet de aanvraag, bij bijvoorbeeld een aanvraag van de gemeente bij een andere instantie dient dit aangegeven te worden.
- Handeling: de handeling die de gemeente uitvoert op de aanvraag/melding.
- Object: de persoon of het object waar de aanvraag/melding betrekking op heeft.
- Plaats: locatie waar de aanvraag/melding betrekking op heeft.
- Tijd: datum van de aanvraag/melding.
Voorbeelden:
- “Behandelen subsidieaanvraag mw. Boerstra voor Peuterspeelzaal De Dolfijn, 2015”
- “Behandelen aanvraag bouwvergunning Brinkweg 7 voor J. de Jong, 15 januari 2015”
Die voorbeelden zitten tegen de 80 posities. Bij een langere straatnaam of achternaam gaat het daarover heen. Dat zou een reden kunnen zijn om te kiezen voor meer dan 80 posities. Maar hoeveel? Dat begint met duidelijkheid over wat met de attribuutsoort bedoeld wordt en wat de inhoud moet zijn. Die GEHOPTE schrijfwijze kan daarvoor het uitgangspunt zijn.
En als we besluiten de lengte te wijzigen dan betekent dat een wijzigingsvoorstel voor het RGBZ met consequenties voor alle daarvan afgeleide koppelvlakken. Dus niet zomaar even een patch op één koppelvlak. Dan komt de interoperabiliteit in gevaar.
Voor de attribuutsoort Documenttitel kan dezelfde redenering gehouden worden. Opvallend is dat deze 200 posities lang is ...
En als we besluiten de lengte te wijzigen dan betekent dat een wijzigingsvoorstel voor het RGBZ met consequenties voor alle daarvan afgeleide koppelvlakken. Dus niet zomaar even een patch op één koppelvlak. Dan komt de interoperabiliteit in gevaar.
Het gaat in dit geval om een patch op StUF ZKN, het onderliggende sectormodel waar de Zaak- Documentservices 1.1 gebruik van maken. Wanneer StUF ZKN aangepast wordt gaat ZDS 1.1 eigenlijk automatisch mee met de nieuwe StUF ZKN patch.
Hoewel ZDS 1.2 ook gebruik maken van diezelfde elementen uit StUF ZKN zal hiervoor een patch uitgebracht moeten worden maar gezien de implementatiegraad van dat koppelvlak kan dat nooit een heel groot probleem zijn... Feitelijk hoeven alleen de geresolvede schema's opnieuw uitgebracht te worden.
In bovenstaand stuk zie ik op zich genoeg redenen om nog eens naar de veldlengte te kijken, al heeft Arjan natuurlijk wel gelijk met zijn vraag "wat is lang genoeg?".
Edit: Mijn opmerking over een patch op StUF ZKN en het automatisch meelopen van ZDS 1.1 hiermee was bedoeld om aan te geven dat de ZDS 1.1 wijzigingen in het RGBZ en StUF ZKN gewoon volgt. Dit geldt in principe ook voor ZDS 1.2, zij het dat daar de xsd schema's mogelijk nog expliciet aangepast moeten worden.
Het is niet de bedoeling om te suggereren dat met een simpele patch op StUF ZKN, zonder te kijken naar andere koppelvlakken en standaarden, dit probleem wat uiteindelijk voortkomt uit 2 leveranciers die zich niet aan het RGBZ gehouden hebben even snel opgelost kan worden.
Dit lijkt mij een kwestie van presentatie die niets met uitwisseling van gegevens te maken heeft. Het is de keuze van de ontvangende partij om de data te presenteren zoals hij dat wil. De voorbeelden van omschrijvingen die ik zie zijn allemaal samen te stellen uit velden die elders in het bericht staan: zaaktype, status, datum, adres, persoon, etc.
Is het niet beter om dit veld gewoon helemaal te verwijderen?