Hoe komt die dataset in mijn geïntegreerde contract?”

Hoi allemaal,

Na mijn uitstapjes over objecttypebibliotheken, en Linked Data kom ik nu weer terug bij de basis: het  Linked Data Platform van CROW. De vorige keer heb ik verteld over de producent van data, en ben ik bijna oneindig uitgeweid over data, datasets en linked data. Ik heb jullie beloofd iets meer te vertellen over de Aanleverspecificaties en de rol van publicist, maar die sla ik lekker over want ik heb dringende vragen van diverse gebruikers gekregen over de vraag: leuk, die datasets, maar hoe kom ik erbij en hoe krijg ik die in mijn geïntegreerde contract?

Jullie hebben het heugelijke nieuws vast meegekregen vorig jaar: CROW heeft de “CROW Basisspecificaties 2018” gepubliceerd, een dataset gebaseerd op de Standaard RAW Bepalingen 2015 en de RAW Catalogus Bepalingen 2015. Daarin is ook een selectie gemaakt van eisen die geschikt zijn binnen geïntegreerde contracten, een vaste set en een facultatieve set. Daarnaast heeft Provincie Utrecht een eigen, individuele eisenset gepubliceerd en zijn een hele serie collectieve eisensets in de maak vanuit het Provinciaal Contracten Buffet, waaronder een set voor VRI’s en zonnewegen en nog een paar.

Leuk denk je, ik ga een contract maken met een VRI erin, maar ook andere objecten en ik heb mijn eigen individuele set. Wat moet ik nu doen? Nou, in onderstaande bekende en uiterst duidelijke afbeelding staat het toch: met SPARQL. Veel succes en sterkte ;-)

O nee, dat was geméén. Dat terwijl ik net bij een gezellige borrel geleerd heb dat CROW-ers slim, aardig en behulpzaam zijn. Ja, ik niet hoor, maar mijn lieve collega’s hier wel.

Eerst maar eens de inhoudelijke vraag: huh, al die datasets, overlapt dat, vult dat elkaar aan, hoe dan?

Voor geïntegreerde contracten bestaat nog geen marktstandaard, zoals RAW. In elk project worden daarom eisen verzonnen. Natuurlijk hebben wij System Engineers onderling inspiratie opgedaan en heel eigen taaltje en eigenaardige gewoontes opgedaan. Iedereen begint hoog over: een weg moet geschikt zijn voor zoveel verkeer met zo’n- en zo’n intensiteit, voor een bepaalde levensduur, en duurzaamheid betrouwbaarheid veiligheid lalalala…. dat weten jullie misschien beter dan ik. Vaak begint dan het politieke spel: een ingenieursbureau tekent die weg vast in, en komt een bestemmingsplan of tracébesluit, en dan komt de discussie: de oplossing ligt er toch al, moeten we die dan niet vastleggen? Soms komen er dan eisen bij als “wegligging en dwarsprofiel conform die tekening” of “…conform dit-en-dit alignement”. Soms word besloten om alleen de abstracte, hoog-over eisen voor te schrijven. Dan begint er iemand te piepen: wacht even. Levensduur en verkeersintensiteit, straks kiest de aannemer een hele onwenselijke verhardingssoort of…. Dan begint het spel: wil je vrijheid in je contract, of wil je gewoon de gemeentelijke, provinciale enzovoorts standaard voorschrijven? En moet er gezegd worden dat fietspaden rood moeten zijn, of is dat vanzelfsprekend? Wat is de rol van de richtlijnen van CROW? Moet het Handboek Wegontwerp ook worden voorgeschreven? Ik heb vaak genoeg meegemaakt, dat er uiteindelijk ook nog proeven worden voorgeschreven uit de RAW. Of dat overheden een hele set eisen op hoog detailniveau hebben, ergens in een document of meerdere documenten, die met één pennestreek ook worden voorgeschreven.

Dat hele pakketje gooi je dan over de schutting bij de aannemer, want die, die heeft een heel projectbeheersingssysteem, en die gaat alle eisen uit alle documenten kopiëren en plakken en interpreteren, en dan is alles “under control”.

Bovenstaand verhaal kún je met de datasets op het Linked Data Platform ook blijven doen: gewoon de hoog-over projectspecifieke eisen in een vraagspecificatie-eisen stoppen, en dan de notitie erbij “en gij zult ook voldoen aan de Basisspecificaties, de set voor VRI en onze individuele dataset”. De aannemer moet dat gaan sorteren: welke objecten zitten wel in het contract, welke niet, zijn er tegenstrijdige eisen? Voordeel is wel, dat een aannemer de “CROW Basisspecificaties 2018” kan verwerken in zijn eigen bedrijfsstandaard: als daar eisen uit worden voorgeschreven in een project, kan hij snel zijn werk plannen en aan de slag omdat hij de linkjes al gelegd heeft naar zijn eigen keuringsplannen enzovoorts. In theorie natuurlijk, want de dataset wordt nu pas voor het eerst getest door een paar bedrijven.

Kan het beter?

In mijn ogen wel, ja. Ten eerste kun je die eisen selecteren, die van toepassing zijn binnen je project, bijvoorbeeld door te bepalen welke objecten er binnen het projectgebied zijn, en daar dan eisen bij te selecteren. Dan kun je ook tegenstrijdigheden er uithalen, en onderzoeken of deze set eisen voldoet aan je voorkeuren. Dan kan de aannemer, sorry, ópdrachtnemer, gericht aan de slag. En heb je zelf ook beter overzicht. Dit alles doe je heden ten dage niet meer in Word of Excel, maar in een handige applicatie waarbij je op verschillende manieren door de data heen kan “bladeren” of kan zoeken naar, ik noem maar wat, alle eisen aan de keerlussen in de weg. Dan kun je in één moeite door risicogestuurd gaan monitoren wat je opdrachtnemer uitvoert, met een handige zoekingang voor het contract, in plaats van een stapel papier waar je doorheen bladert.

Maar HOE dan?

Als eerste moet ik zeggen, het gebruik van de datasets is niet gratis – wij hebben nogal veel kosten gemaakt bij het ontvlechten van de data, het bedenken van het datamodel en het inrichten van het Linked Data Platform, en dit alles moet ook nog ondersteund worden. Daarom is een abonnement op “ProContract” nodig, en moet je project zijn aangemeld om de datasets te mogen gebruiken. Daarmee is overigens meteen de data beschikbaar voor alle partijen, ook de opdrachtnemer en zijn onderaannemers, alles uiteraard op voorwaarde dat het wordt toegepast binnen het kader van het project. In de Gebruikersinformatie staat hiervoor een gedragscode, waar we overigens graag review op krijgen om te horen of dit technisch en praktisch gezien werkbaar is. We hebben natuurlijk geen stichting Brein om voor ons te waken dat de data niet gekopieerd wordt – uiteindelijk bestaan we als CROW bij de gratie van jullie, die graag samen werken aan standaarden in plaats van ieder voor zich het wiel uit te vinden en dat graag bij CROW doen omdat we, nou ja, zo aardig en behulpzaam zijn. En slim. (Ik niet hoor).
Dus, je hebt een project in ProContract. Dan neem je contact op met ondergetekende, ja we moeten snél een helpdesk gaan inrichten, om een toegangscode te krijgen voor de datasets die je wilt gebruiken. En dan kun je, excuse le mot, gaan SPARQL-en. Dat wil zeggen, gaan zoeken in de data. Dat kan iedereen, toch?

Gelukkig zijn er applicaties, waarmee dat voor een contractschrijver of projectmanager geregeld kan worden. Dan moet er wel iets geprogrammeerd worden, een add-on gemaakt op je pakket waarmee je contracten samenstelt. Met die add-on kun je dan gaan zoeken, bijvoorbeeld via objecten naar eisen en dan door naar verificatiemethodes. Dat kan in principe een handige ICT-er voor je inrichten daarvoor staan handleidingen in de Gebruikersinformatie. En ook dat is natuurlijk in een pril stadium, de eerste partijen zijn nu de data aan het doorzoeken en aan het kijken hoe deze zoekmachine gebouwd kan worden. Ik heb me al laten vertellen dat het niet makkelijk is, en ik hoor graag van jullie ervaringen.

Ik hoop dat jullie het flink met me oneens zijn over van alles en nog wat in deze blog, laat van je horen dan werken we samen aan betere standaarden voor geïntegreerde contracten.

Groetjes, Elisabeth Klören
Elisabeth.Kloren@crow.nl