Het Informatiemodel Beheer Openbare Ruimte (IMBOR) is een uitgebreid informatiemodel waarmee je zo ongeveer ieder objecttype dat je tegenkomt als (publieke) beheerder kunt beschrijven. De IMBOR is ontstaan uit bijdragen van vele tientallen beheerders die allemaal vanuit hun ervaring informatiebehoeften hebben ingebracht. Het is een grootste gemene deler van het beschrijven van objecten vanuit talrijke gemeentes, provincies, waterschappen en andere beheerders van objecten in de openbare of publieke ruimte. Voor uitwisselbaarheid en herkenbaarheid wil je daar graag gebruik van maken. Alleen: het bevat vanuit hoe het ontstaan is veel meer dan je waarschijnlijk als individuele beheerder nodig hebt. Maar hoe bepaal je uit die enorme ruif gericht die elementen die je echt nodig hebt?
Allereerst moeten we dan bekijken welke gegevenselementen er allemaal voorkomen in de IMBOR. In de basis zijn dit de objecttypes die in een taxonomie zijn geplaatst. De makers van IMBOR, het CROW, hebben het model netjes gepubliceerd in de IMBOR Viewer. De objecttypes en de klassen direct boven het objecttype zijn de eerste interessante om te beschouwen. Denk bijvoorbeeld aan de klasse “Groenobject”, met als objecttypen “Bos”, “Gras- en kruidachtigen”, “Planten” of “Struiken”. Maak een platte lijst in een spreadsheet van de objecttypen met alle attributen volgens het model en groepeer de objecttypen per klasse er direct boven. Vaak matchen deze klassen met disciplines. Vink vervolgens de objecttypen aan die je werkelijk wilt gebruiken. In het voorbeeld van de klasse Groenobject hierboven, gebruik je misschien wel Gras- en kruidachtigen, Planten en Struiken, maar geen Bos. Deze stap is minder triviaal dan het lijkt: je moet de definities van de IMBOR objecttypen goed (leren) kennen, en als je nog geen IMBOR gebruikt, afbeelden op je eigen definities. Mocht je al een applicatie hebben ingericht op basis van IMBOR, dan blijkt vaak dat deze (veel te) veel bevat en wil je dit inperken, maar het voordeel is wel dat je al een systeem hebt dat je wilt gaan vullen. Of als je dit al gedaan hebt, blijkt vaak dat je nog niet scherp bent in wat je wel, en wat je niet gebruikt. Het gesprek over wat je wel en niet gebruikt gaat met assetmanagers of hun gedelegeerden. In ieder geval is de Assetmanager de eigenaar van de data en de keuze welke objecttypen de discipline beheert en wil vastleggen.
De tweede stap is om de attributen per gekozen objecttype vast te stellen. Een deel van de attributen zal generiek blijken te zijn. Denk bijvoorbeeld aan het unieke ID, de geometrie, verantwoordelijken (wie is eigenaar en wie beheert): het is in ieder geval zaak om dit op centraal niveau vast te stellen. Vervolgens kun je per discipline, of per assetmanager, de attributen kiezen. Een tip: handhaaf een “nee, tenzij”-beleid. Je krijgt een attribuut alleen als registratie van dat attribuut een significant positieve bijdrage aan een (beheer)proces oplevert. Dit voorkomt dat bij inwinning veel tijd en aandacht besteed moet worden voor de inwinning, vaak in projecten buiten de beheerorganisatie, waarvan blijkt dat de verantwoordelijke discipline niet eens kan uitleggen wat het gevraagde attribuut betekent. Kritisch zijn is echt het adagio!
Definieer als derde stap de domeinwaarden bij gekozen attributen, waarvan IMBOR zegt dat ze organisatie-specifiek zijn. Als je dit openlaat, krijg je een enorme variatie aan waarden, terwijl de kracht juist is dat je uit vooraf gedefinieerde waarden efficiënt selecties kunt maken in de database, iets wat je in je beheerprocessen enorm helpt om in te zoomen op die objecten waar je iets mee wilt.
Tot slot kan het zijn dat je een keuze wilt maken uit semantische relaties, maar in de praktijk zijn de meeste al gedefinieerd, en als je een relationele database hebt (en geen graph database die goed kan omgaan met een Linked Data-model) is dit nog niet zo makkelijk. Voorbeelden die je wel veel ziet zijn armaturen die bij palen horen, of een object dat meerdere kleuren kan hebben. Zie deze echter als laatste stap en doe daar alleen iets mee als je ze echt nodig hebt.
Diegenen onder jullie die al verder zijn in deze materie zullen denken: “maar daar heb ik toch een Object Type Library (OTL) voor?”. Ja, dat klopt, maar de ervaring leert dat je de mensen in de beheerorganisatie laagdrempelig en begrijpelijk functionele keuzes wilt laten maken. En als beheerder heb je nu eenmaal een heel ander vak dan je af te vragen hoe je met een “Object Type Library je ontologie” gaat beschrijven, terwijl je gewoon wilt weten hoe je een vaste brug vastlegt, of een groenvoorziening, rioolleiding of verharding. Hoe je dat verder technisch vormgeeft is dan meer aan de informatiespecialisten. De essentie is: de keuze welke objecttypen en attributen je gebruikt, zijn in eerste instantie functioneel en niet technisch. Focus op het keuzeproces met de beheerorganisatie en maak de middelen daarvoor laagdrempelig en begrijpelijk. Het resultaat is in eerste instantie een platte tabel in een spreadsheet, die vervolgens als input kan dienen voor een OTL en de inrichting van applicaties door informatiespecialisten.