Wat is de OTL?

Waarom ontwikkelt RWS een OTL?

In de praktijk van de bouwwereld is het belangrijk dat:

• Alle partijen dezelfde perceptie hebben van wat de objecten zijn in het bouwwerk.
• We zorgen voor eenduidige definities en afspraken over deze objecten.
• Er sprake is van efficiënte foutloze uitwisseling van digitale informatie.

Het is belangrijk dat bouwpartners bij het vastleggen en uitwisselen van informatie* over een bouwwerk dezelfde definities van (deel-)objecten gebruiken. Om te voorkomen dat we deze definities steeds weer opnieuw moeten bedenken zijn Objectenbibliotheken onmisbaar. Hiermee:

• Verkleinen we het aantal fouten in de bouw van een project
• Maken we digitale uitwisseling van enorme hoeveelheden areaaldata mogelijk

* Informatie = data waarop je kan acteren

Doel van de OTL

Standaardiseren van datastructuren t.b.v. het geautomatiseerd vastleggen en uitwisselen van data over objecten / assets (zoals een bepaalde sprinklerinstallatie in een specifieke tunnel)​​​​​​​.

Omschrijving van  de onderdelen van de OTL

Het vastleggen van een taal voor het uitdrukken van kennis over de (fysieke) wereld gaat het beste in de vorm van een kennismodel (in het Engels: knowledge graph). Cruciaal is dat we in het kennismodel feiten vastleggen over het te hanteren datamodel, maar ook over de wereld. De Rijkswaterstaat-OTL omvat dus niet alleen een semantisch model, maar ook taxonomieën en registers met referentiegegevens over materiaalsoorten, pomptypen, soorten beton, et cetera. Het is van belang het semantisch model, de taxonomieën, en de registers in samenhang te onderhouden en te gebruiken.

Het kennismodel is modulair opgebouwd en bestaat uit vele onderdelen. Elk van deze onderdelen vormt een eenheid van beheer, onderhoud en publicatie. Ze kennen onderlinge afhankelijkheden maar zijn intern sterk coherent. Daarom noemen we een dergelijk onderdeel ook wel module. Binnen de Rijkswaterstaat-OTL onderscheiden we vier belangrijke typen van modules:

• Semantisch model (ontologie). Het semantisch model beschrijft het vocabulaire waarmee we onze wereld beschrijven en bepaalt daarmee de structuur en betekenis van data.
• Taxonomieën (thesauri). Een taxonomie definieert begrippen waarmee we zaken indelen om ze vindbaar en hanteerbaar te maken.
• Registers. Een register is een verzameling resourcebeschrijvingen die een mate van geldigheid heeft. Voorbeelden zijn het register van gemeenten, van soorten verkeersborden, etc. In veel gevallen wordt de registerhouder aangewezen bij wet.
• Waardelijsten. Een lijst resources die een momentopname vormt van een taxonomie of register t.b.v. een toepassing. Een voorbeeld is de gemeentelijst op peildatum 1 januari 2022.

Functies van de OTL

De OTL is informatiemodel voor:

• Classificatie: wat is het object waar ik meer over wil weten/iets over vast wil leggen? (i.e. eenduidige definities/beschrijving)

Wanneer je bij een registratie (record) in een BMS aangeeft wat het bijbehorende OTL-type is, is het duidelijk dat deze registratie gegevens bevat. (i.e. over een boogbrug)

• Specificatie: wat wil ik over dit object weten, en welke eisen stel ik aan de vastlegging ervan? (i.e. kenmerken, relaties en datakwaliteitseisen)

In de OTL is vastgelegd wat we allemaal over een Boogbrug kunnen/willen vastleggen, dit op basis van de in kaart gebrachte informatiebehoefte.

De OTL is input voor:

• Harmonisatie: kan ik de vastlegging van de gegevens in onze BMS'en in lijn krijgen met deze specificaties? (i.e. meer eenduidig en consistent)

Met de OTL kan worden bepaald of de BMS voldoen aan deze specificatie.

Zo ja, dan kunnen we de database structuur van dat BMS mappen op de structuren in de OTL. Dit zorgt ervoor dat we van alle velden in een BMS weten wat ermee wordt bedoeld.

Zo nee, dan kunnen we of de OTL erop aanpassen of een wijziging op de BMS aanvragen.

• Validatie: kan ik inzichtelijk maken of onze gegevens voldoen aan de eisen die ik aan de vastlegging heb gesteld? (zowel vooraf bij inwinning als achteraf in onze BMS’en)

Ook kunnen we de OTL gebruiken om datakwaliteit te meten. Als we er vanuit gaan dat de BMS’en zijn gemapt op de OTL (i.e. harmonisatie), dan kan de vulling ervan geautomatiseerd worden opgehaald en tegen de specificaties uit de OTL worden gevalideerd.

De OTL is randvoorwaarde voor:

• Integratie: kan ik de gegevens uit diverse BMS-en en van extern samenvoegen

Als de achterliggende BMS’en zijn gemapt op de OTL (i.e. harmonisatie), en de data volledig en correct is (i.e. validatie), dan kan de vulling met de BMS’sen technisch worden samenvoegd tot één bestand, en met ILS’en worden uitgewisseld met de markt.

Waar past de OTL in het grotere plaatje?

Het ondersteunt bij het op orde krijgen en houden van areaaldata.

Een van de doelstellingen waar de afgelopen jaren flink aan is gewerkt is Situatie buiten = Situatie binnen. Dit staat in het teken van het realiseren van een continu proces voor de data van de gehele levenscyclus van het areaal. Waarbij het doel is deze data voldoende actueel, betrouwbaar, compleet en vindbaar te krijgen én te houden.

Binnen deze doelstelling is areaaldata op orde krijgen en houden een belangrijke pilaar. Het motorblok is een van de onderdelen die bijdraagt aan deze pilaar. Dit door vastgelegde data te toetsen aan de hand van definities en kwaliteitseisen.

Gezamenlijk hebben de ontwikkelteams gewerkt aan de producten van het motorblok, op te delen in vier functionele componenten .

Het motorblok is een verzameling van producten die in samenhang helpen bij areaaldata op orde brengen .