Als kenniswerker op het gebied van de UAVgc en systeemgerichte contractbeheersing (SCB) is het flink aanpoten om de data en de datastructuren goed te kunnen volgen, is de ervaring van Bob Nonnekens.
Onze gewaardeerde collega Elisabeth Klören is een ware data-goochelaar. Ze verbaast klant en collega met een vanzelfsprekende kennis en begrip van de datamodellen die we gebruiken om contractdata op een intelligente wijze voor de gebruiker te ontsluiten. Bovendien schrijft ze daar ook nog aansprekende blogs over die een breed publiek hebben. En daarmee is ze in staat om zowel opdrachtgevers, ingenieursbureaus en aannemingsbedrijven op adequate wijze te ondersteunen in hun behoefte aan eenduidige en goed ontsloten contractdata.
Maar in alle eerlijkheid, als kenniswerker op het gebied van de UAVgc en van systeemgerichte contractbeheersing (SCB) is het flink aanpoten om de data, de datastructuren en de wijze waarop deze ontsloten worden goed te kunnen volgen. Ik kan mij voorstellen dat er meer mensen het gevoel herkennen dat ze de klok horen luiden maar nog niet goed weten waar de klepel hangt. Met deze blog probeer ik die klepel te duiden vanuit het zichtpunt van een niet-data-analist, de ‘leek’.
Maar eerst de vraag, waarom moeilijke datamodellen, waarom het CROW Linked Data Platform, waarom niet een eenvoudige tabel met unieke eiscodes?
Toegegeven, de eisen, specificaties sèc, zijn best op te sommen in een tabel. Maar dat is dan ook alles wat je krijgt, een opsomming waaruit je kunt knippen en plakken en met een tekstzoekfunctie kunt zoeken op (delen) van woorden en zinnen.
Maar eisen staan niet op zichzelf, ze zijn opgehangen aan functies, aan systemen en objecten. Daarnaast hebben ze relaties met andere functies, systemen en objecten, binnen en buiten het Werk. Bovendien wil je de partijen die gebruik maken van de contractdata in de gelegenheid stellen om met die contractdata hun processen te beheersen. Dat vraagt weer om nieuwe tabellen en overzichten die elke partij weer in zijn eigen format opstelt en die daardoor niet of slecht relateerbaar zijn. En daar komt de meerwaarde van een linked data model om de hoek kijken.
Daarin worden al die specs, functies, objecten, systemen, toetsmethoden, fasen, activiteiten, raakvlakken, etc. als afzonderlijke objecten en hun onderlinge afhankelijkheden gedefinieerd. Ieder object heeft een relatie met een ander subject (deze combinatie wordt een Triple genoemd). Al die objecten en hun onderlinge afhankelijkheden (in triples beschreven) samengevoegd vormen het veelgenoemde Turtle-bestand (.TTL file). Al die dimensies zijn niet op eenduidige wijze verenigbaar in een ‘platte’ tabel.
Bij mij roept dat het beeld op van een tweedimensionaal wezen, een ‘Platlander’, die in zijn X-Y wereld een punt ziet opdoemen die langzaamaan een lijn wordt en dan weer verdwijnt. Voor ons, driedimensionale wezens, is het duidelijk dat een kegel door de wereld van de Platlanders sneed. Wij zien die derde dimensie (Z) èn de vierde dimensie (tijd) en kunnen die concepten samenvoegen tot een visualisatie van een kegel dat door een vlak kwam. Ons dataplatform voegt daar nog een heel aantal dimensies aan toe. Art by: Bob Nonnekens (CROW)
Nou is die turtlefile een enorme brij van data en datarelaties. Dat is natuurlijk niet gebruiksvriendelijk. Met behulp van ProContract kun je weer voor opstellers en gebruikers leesbare vraagspecificaties maken, waarbij het tekstdeel van het document uit Procontract komt en de eisen er met behulp van tools zoals Relatics ingezet kunnen worden. De noodzakelijke specificaties (objecten) en hun relaties worden zo samengebracht. Doordat die relaties al waren gedefinieerd (de triples) komen de relevante neven-specificaties (subjecten) direct in beeld. Dat draagt bij aan de gewenste consistentie.
En hoe krijg je die data in je software-pakket voor het maken van vraagspecificaties? Dit kan met behulp van een add-on, die je kunt laten programmeren (daar heeft CROW een instructie voor) of door een ICT’er met SPARQL door de data te laten zoeken, die daarmee de tabel maakt met de informatie die jij voor je project nodig hebt. Elisabeth en haar collega’s staan u bij vragen hierover graag terzijde.
Door een wereldwijde erkende en gebruikte data standaard (W3C) te gebruiken en de datasets met een unieke locatie (de HTTP-URI) beschikbaar te stellen zijn de gebruikers in staat deze data in hun eigen relationele databases te gebruiken voor de project- en contractbeheersing. En daar voel ik me als UAVgc kenniswerker weer goed mee bediend. U hopelijk ook!
Bob Nonnekens
Maar in alle eerlijkheid, als kenniswerker op het gebied van de UAVgc en van systeemgerichte contractbeheersing (SCB) is het flink aanpoten om de data, de datastructuren en de wijze waarop deze ontsloten worden goed te kunnen volgen. Ik kan mij voorstellen dat er meer mensen het gevoel herkennen dat ze de klok horen luiden maar nog niet goed weten waar de klepel hangt. Met deze blog probeer ik die klepel te duiden vanuit het zichtpunt van een niet-data-analist, de ‘leek’.
Maar eerst de vraag, waarom moeilijke datamodellen, waarom het CROW Linked Data Platform, waarom niet een eenvoudige tabel met unieke eiscodes?
Toegegeven, de eisen, specificaties sèc, zijn best op te sommen in een tabel. Maar dat is dan ook alles wat je krijgt, een opsomming waaruit je kunt knippen en plakken en met een tekstzoekfunctie kunt zoeken op (delen) van woorden en zinnen.
Maar eisen staan niet op zichzelf, ze zijn opgehangen aan functies, aan systemen en objecten. Daarnaast hebben ze relaties met andere functies, systemen en objecten, binnen en buiten het Werk. Bovendien wil je de partijen die gebruik maken van de contractdata in de gelegenheid stellen om met die contractdata hun processen te beheersen. Dat vraagt weer om nieuwe tabellen en overzichten die elke partij weer in zijn eigen format opstelt en die daardoor niet of slecht relateerbaar zijn. En daar komt de meerwaarde van een linked data model om de hoek kijken.
Daarin worden al die specs, functies, objecten, systemen, toetsmethoden, fasen, activiteiten, raakvlakken, etc. als afzonderlijke objecten en hun onderlinge afhankelijkheden gedefinieerd. Ieder object heeft een relatie met een ander subject (deze combinatie wordt een Triple genoemd). Al die objecten en hun onderlinge afhankelijkheden (in triples beschreven) samengevoegd vormen het veelgenoemde Turtle-bestand (.TTL file). Al die dimensies zijn niet op eenduidige wijze verenigbaar in een ‘platte’ tabel.
Bij mij roept dat het beeld op van een tweedimensionaal wezen, een ‘Platlander’, die in zijn X-Y wereld een punt ziet opdoemen die langzaamaan een lijn wordt en dan weer verdwijnt. Voor ons, driedimensionale wezens, is het duidelijk dat een kegel door de wereld van de Platlanders sneed. Wij zien die derde dimensie (Z) èn de vierde dimensie (tijd) en kunnen die concepten samenvoegen tot een visualisatie van een kegel dat door een vlak kwam. Ons dataplatform voegt daar nog een heel aantal dimensies aan toe. Art by: Bob Nonnekens (CROW)Nou is die turtlefile een enorme brij van data en datarelaties. Dat is natuurlijk niet gebruiksvriendelijk. Met behulp van ProContract kun je weer voor opstellers en gebruikers leesbare vraagspecificaties maken, waarbij het tekstdeel van het document uit Procontract komt en de eisen er met behulp van tools zoals Relatics ingezet kunnen worden. De noodzakelijke specificaties (objecten) en hun relaties worden zo samengebracht. Doordat die relaties al waren gedefinieerd (de triples) komen de relevante neven-specificaties (subjecten) direct in beeld. Dat draagt bij aan de gewenste consistentie.
En hoe krijg je die data in je software-pakket voor het maken van vraagspecificaties? Dit kan met behulp van een add-on, die je kunt laten programmeren (daar heeft CROW een instructie voor) of door een ICT’er met SPARQL door de data te laten zoeken, die daarmee de tabel maakt met de informatie die jij voor je project nodig hebt. Elisabeth en haar collega’s staan u bij vragen hierover graag terzijde.
Door een wereldwijde erkende en gebruikte data standaard (W3C) te gebruiken en de datasets met een unieke locatie (de HTTP-URI) beschikbaar te stellen zijn de gebruikers in staat deze data in hun eigen relationele databases te gebruiken voor de project- en contractbeheersing. En daar voel ik me als UAVgc kenniswerker weer goed mee bediend. U hopelijk ook!
Bob Nonnekens
Delen via