Objecttypebibliotheken: Vanaf nu permanent in de mode

Hoi trouwe fanschare,

zoals beloofd deze keer een blog over het meest hippe onderwerp van de afgelopen jaren, de objecttypebibliotheek. In Nederland meestal afgekort als OTL van de Engelse term ‘object type library’, omdat OTB ook al gebruikt wordt voor Ontwerp Tracé Besluit. Jullie lezen dit in januari, maar ik schrijf het vlak voor de kerst, vandaar dat ik de hele Santa-kraam opengooi voor voorbeelden.

De hamvraag is: waartoe is een objecttypebibliotheek op aarde, waar wil je hem voor gebruiken? Dat bepaalt welke techniek je moet gebruiken en welke informatie erin moet staan. Hieronder, met steeds toenemende complexiteit, verschillende toepassingen van een objecttypebibliotheek.

Vocabulaire / woordenboek – dezelfde taal spreken

Toen ik, langer dan lang geleden, tien jaar ofzo, begon als junior Systems Engineer op het project Stationsgebied Driebergen-Zeist had ik nog nooit gehoord van objecttypebibliotheken. Wel leerde ik daar van een ervaren collega over het opstellen van een functie- of objectstructuren. Met een schuin oog naar de functies van in de model vraagspecificatie eisen van Rijkswaterstaat, en de objectenlijst van ProRail (voor liefhebbers: de BID00001) begonnen we voor het project, rijp en groen door elkaar, objecttypen te definiëren - “gebiedsontsluitingsweg” - en de objecten in het projectgebied te benoemen - “De Driebergseweg”, of wacht, even verderop heet het de “Hoofdstraat”, welke bedoelen we? Of allebei? Wie schetst je verbazing, in de enorme berg rapporten, tekeningen en berekeningen die er destijds al waren over het project, werden verschillende benamingen gebruikt voor objecten, verschoven de grenzen van het systeem steeds en hoe ga je om met fasering, dezelfde weg ziet er het ene jaar heel anders uit (twee rijstroken) dan het volgende jaar (vier rijstroken), zijn het dan twee wegen of één object? En de Hoofdstraat is van de Gemeente Driebergen; maar de Driebergseweg is van de gemeente Zeist. Knippen? Delen? Maar ja, het is wel één en dezelfde weg.

Mijn collega destijds (ik noem maar even geen namen 😉) vond het ook handig, om de objecten logisch te nummeren, en de eisen ook. Als je dan de systeemspecificatie zou uitprinten op papier kon je als lezer “handig” herkennen waar je was. Indertijd hadden vele System Engineers deze gewoonte. Met de unieke nummers en hopelijk unieke namen van objecten kon je dan in alle rapporten over hetzelfde praten. Tenminste, als iedereen zo gedisciplineerd zou zijn. Als je helemaal ingewikkeld wilde doen dan nam je ook nog een versienummering op in de logische nummering.

Wat een hoofdpijn leverde dat op. Vooral door voortschrijdend inzicht – je schuift zo even een paar objecten of eisen op in je structuur, dan kan je daarna lekker met de hand alles weer omnummeren. Natuurlijk bleken alle specialisten in hun rapportages nog steeds hun eigen benamingen te gebruiken. Met onze Systems Engineering zorgden we gewoon voor een elfde plek waar je óók nog informatie kon vinden over de objecten met weer een nieuwe naam. Tsja, Systems Engineering is soms meer politiek dan wijsheid.

Dit zullen we maar een objecttypebibliotheek met één ster noemen, dit voorbeeld. Een handige lijst van objecten en definities zodat iedereen dezelfde taal spreekt (uniformiteit). Met welke techniek je deze OTL opstelt? Dat ligt eraan hoe je hem gebruikt. Binnen een project of bedrijf is een papieren lijst met objecten aan de muur misschien voldoende, dan kan iedereen dezelfde namen gebruiken. Als je de termen wilt publiceren zodat meerdere organisaties ermee kunnen werken, of als je wilt kunnen zoeken of verwijzen naar een term vanuit meerdere applicaties is linked data handiger.

Thesaurus – zoeken in publicaties

Een stapje mooier (#nerdalert) is de Thesaurus. Elke keer als ik dit in probeer te typen dan staat er “Theasaurus”, ik denk dat het hier om een theedrinkende bibliothecaris-dinosaurus gaat van een soort dat alleen in het universum van Walt Disney voorkomt. Waartoe is de Thesaurus op aarde? Sinds de oudheid als woordenboek of catalogus bij een bibliotheek; in digitale vorm als slimme zoekingang voor documenten of websites. Zo zijn we de meerwaarde van een Thesaurus voor onze Kennisbank aan het onderzoeken.

In een Thesaurus is het woordenboek met termen, synoniemen en definities uitgebreid met een “zwakke taxonomie”. In gewone mensentaal: Termen zijn aan elkaar gerelateerd. Bredere term (dennenboom, bredere term: naaldboom); nauwere term (Naaldboom, nauwere termen: dennenboom, spar); Gerelateerde term (dennenboom; gerelateerde term: kerstboom). Vanuit de oorsprong vanuit boekdrukkunst en de wereld van uitgeverijen bevat een thesaurus ook alle informatie over “het boek”: auteur, uitgever, versie enzovoorts.

Classificatie – uitwisseling van gegevens

Voor objecten is, als je Wikipedia gelooft, een classificatie nagenoeg hetzelfde als een taxonomie. In de Thesaurus heb je al objecten met definities en relaties tussen begrippen. Een classificatie kan een stap verder gaan: de objecten krijgen eigenschappen mee, de relaties worden scherper gedefinieerd als subtype en supertype van objecten met gezamenlijke eigenschappen. Een classificatie wordt gebruik om een productencatalogus te publiceren, of om te zorgen dat verschillende applicaties gegevens over eigenschappen van objecten op dezelfde manier opslaan, zodat gegevens uitgewisseld kunnen worden. IMBOR is onder andere bedoeld voor deze behoefte – het zorgt ervoor dat iedere gemeente gegevens van objecten op dezelfde manier opslaat, in elk geval de wettelijk verplichte gegevens in het kader van de Omgevingswet (de BGT).

Meronomie – gevolgtrekkingen

Een meronomie (term uit computerwetenschap) heet ook wel een decompositie (term uit systems engineering) of. Een meronomie bestaat uit geheel – deel relaties. Als je aan je classificatie ook een samenstelling toevoegt (“een kerstboom bestaat uit een naaldboom met kerstversieringen”) wordt je objecttypebibliotheek ook bruikbaar om automatisch gevolgtrekkingen te maken. Bijvoorbeeld bij het ontwerp van je kerstboom weet je dat je moet kiezen uit een lijst met naaldbomen, en uit een lijst met kerstversieringen. En de computer snapt dat hij je die lijst moet voorschotelen. Als je ook een adventskaars in je kerstboom hangt, krijg je een foutmelding.

Hoor ik je nou zeggen: hé, dat passen wij al toe in UAVgc-contracten, toch? De functie- of objectenstructuur is een decompositie! Nou, dat zou ik je graag willen beloven; mijn ervaring in de praktijk is zo: “Elisabeth, wil je alle kerstversieringen bij elkaar zetten, de Kerstman moet steeds zo zoeken om “zijn” objecttypen te vinden”. Ja, dan heb je weer een mens nodig om te beredeneren of de boom volledig is, of dat we nog een object zijn vergeten. Zoals ik zei, meer politiek dan automatisering.

Ontology – the whole shebang

IMBOR is op dit moment een accesdatabase, en daarom nog niet bruikbaar zoals computernerds ons voorspiegelen dat een ontologie bruikbaar is. Maar het is wel zo bedoeld: “Doel [….] is landelijke uniformering van de benamingen van objectgegevens […..] en de bijbehorende waarden [….]. Een voorbeeld van een IMBOR beheerattribuut voor het objecttype ‘Boom’ is ‘Vrije doorrijhoogte’ met de bijbehorende mogelijke domeinwaarden ‘2,5 m en groter’, ‘4,5 m en groter’, ’6,5 m en groter’ en ‘onbekend’. Een ontologie maakt het mogelijk, om te volledig automatisch te controleren of gegevens over het object voldoen aan de gedefinieerde waarden. Dat is handig, als je als overheid bijvoorbeeld automatisch wilt controleren of de areaalgegevens van een opdrachtnemer voldoen aan je eisen.

Helaas, een groot deel van het bovenstaande is theorie. Zolang iedere overheid, aannemer en adviseur een eigen objecttypebibliotheek maakt, gaan softwareleveranciers zich hier niet op aanpassen. Ook de (inter-)nationale standaarden zijn nog lang niet zo ver. Daarom is de DigiDealGO ook zo belangrijk: we moeten gezamenlijk ontwikkelen, anders kunnen we nooit vergaande automatisering bereiken en blijven we informatie handmatig knippen en plakken, met hulp van unieke nummers of namen.