Deze pagina beschrijft de technische documentatie rondom IMBOR. Het IMBOR uniformeert begrippen voor het vakgebied ‘beheer openbare ruimte’ en voorziet in een ontologie die geschikt is voor zowel mens en machine.
IMBOR bestaat uit drie delen:
IMBOR Vocabulaire is het begrippenkader van IMBOR. Het beschrijft de universe of discourse van beheer van de openbare ruimte. De vocabulaire is een invulling van het 'model van begrippen' zoals dat gehanteerd wordt in het MIM. Het is tevens de invulling van het 'Toepassingstype 1' vanuit de NEN2660-2:2022 (afstemming van termen en definities). De uitdrukking is volledig in [skos-primer].
IMBOR Kern, ofwel de ontologie is het daadwerkelijke informatiemodel. Het betreft hier het logische informatiemodel zoals MIM dat erkend. De NEN2660-2:2022 is volledig toegepast en daarmee is het de invulling van het 'Toepassingstype 3 (gegevensintegratie en innovatie). Vandaar dat de LinkedData expressie ook met [rdf-schema] en [shacl] gedaan wordt. De relatie tussen de vocabulaire en de ontologie ligt middels een rdfs:seeAlso systematiek zoals de NEN2660-2:2022 dat voorschrijft. Elke concept in de ontologie heeft zodoende een definiëring in de vocabulaire.
IMBOR addenda zijn informatieve delen van IMBOR. In tegenstelling tot de voorgaande twee onderdelen kan elke organisaties deze van toepassing verklaren of niet. De addenda zijn (nog) niet in MIM uitgedrukt, wel in LinkedData maar op een minder strikte wijze dan de normatieve delen.
IMBOR wordt gepositioneerd als sectormodel. De focus ligt op de vaste gegevens van objecten die herkend worden voor het beheer van de openbare ruimte. Kijkend naar het landschap waarin IMBOR wordt gebruikt zijn er veel raakvlakken met landelijke, maar ook andere sectorale modellen. Om deze afstemming zo optimaal te laten verlopen is getracht om de top van de IMBOR hiërarchie (ofwel de klassenindeling) zo veel mogelijk aan te laten sluiten op andere modellen.
IMBOR wordt op twee manieren gedistribueerd, te weten in een Access database en in LinkedData. Van beiden distributiewijze worden detail uitleg gegeven en verschillende schema's gepresenteerd.
De wens om de beheeromgeving en beheerprocedures rondom IMBOR te concretiseren
Met werkgroepen is de inhoud medio 2020 voorlopig vastgesteld. Mede daarom is besloten om in 2021 een nieuwe release te doen die (minder) aanpassingen aan de inhoud heeft, maar vooral in modellering en structuur meer aansluiting vind bij de nieuwe standaarden en daardoor robuuster is. In de daaropvolgende versie is de inhoud waar nodig omgezet naar de nieuwe modellering en structuur.
Tot en met IMBOR2020-08 is zowel de publicatie van IMBOR en het beheer van de inhoud in Microsoft Access gedaan. Vanaf IMBOR2022 is een transitietraject ingegaan om IMBOR los te weken van de implementatie in Access. Hierdoor is IMBOR beschikbaar nu beschikbaar in zowel Access als in LinkedData. Het beheer van IMBOR wordt vooralsnog in Access gedaan, maar dit zal op termijn herzien worden.
2.1 Normatief & informatief
Deze ReSpec is ingedeeld in secties. Alle secties zijn 'normatief' tenzij dit anders vermeld is door de zin: "Dit onderdeel is niet normatief".
Normatief wil in deze context zeggen dat de informatie onderdeel is van IMBOR en wanneer men zich 'committeert aan IMBOR' zich aan deze secties dient te houden. Sommige secties zijn zodoende informatief en mogen gezien worden als 'suggesties', 'aanvullingen' of 'best practices' vanuit IMBOR. Een organisatie kiest zelf dan ook of zij zich ook aan die sectie committeert.
Figuur 1 IMBOR Normatief & Informatieve onderdelen
2.2 Toepassingsgebied
In het IMBOR zijn landelijke afspraken gemaakt over de objectgegevens voor het beheer van de openbare ruimte. Het is daarmee een belangrijk hulpmiddel dat beheerders ondersteunt bij de opzet en vulling van hun beheersystemen, bijvoorbeeld voor wegbeheer en groenbeheer. Hierdoor wordt integraal beheer van de openbare ruimte gemakkelijker en kunnen beheerder beter gegevens delen en hun data op orde houden.
In het IMBOR staat alle informatie die nodig kan zijn voor het beheer vastgelegd bij objecttypen, hun onderlinge relaties en in hun attributen en bijbehorende domeinwaarden. Door gebruik van deze benamingen ontstaat uniformiteit in het vakgebied ‘beheer openbare ruimte’; dit bevordert de communicatie en uitwisseling van gegevens.
De benamingen en indelingen zijn zoveel mogelijk afgestemd op de meest gebruikte standaarden, richtlijnen en normen voor het vakgebied openbare ruimte; het IMBOR zorgt er dus voordat deze eenvoudiger kunnen worden toegepast.
Met de IMBOR Vocabulaire is een 'taal' beschikbaar die gesproken kan worden in de BOR-(beheer openbare ruimte) sector. Deze kan in samenhang gebruikt worden met andere vocabulaires. Met de IMBOR Ontologie is een meer complete beschrijving van het model voor het beheer van de openbare ruimte beschikbaar. Hierin worden de informatiebehoeften beschreven, inclusief standaardisatie en de vastlegging daarvan voor gebruik in machines (computers).
2.2.1 IMBOR (door)ontwikkeling in software
IMBOR is begonnen als verrijking van het BGT|IMGeo, als specifiek informatiemodel voor het BOR domein. Inmiddels is het geëvolueerd naar een op zich zelf staande vocabulaire en ontologie. De titel 'informatiemodel' begint dan ook steeds minder te passen. Met de vernieuwde NEN2660-2:2022 is er een duidelijke lijn hoe informatie rondom de gebouwde omgeving kan worden vastgelegd en gedeeld. In het kader van de NEN2660-2:2022 is IMBOR dan ook 'gewoon' een ontologie. Vanuit CROW wordt dit ook zo benaderd. De keuze voor LinkedData heeft hier dan ook mee te maken. BGT|IMGeo (en zodoende ook het begin van IMBOR) zijn gemaakt om software op te bouwen. Het zijn modellen die beschrijven hoe de data moet worden vastgelegd om deze zonder informatieverlies te kunnen delen. Met de komst van LinkedData is deze vastlegging gestandaardiseerd op internationaal niveau. Er wordt met IMBOR dan ook een toekomst voorzien dat men geen software meer maakt voor het vastleggen van 'Boom' of 'Wegas', maar software maakt voor het vastleggen van klassen uit de NEN2660-2:2022, zoals 'DiscreetObject' en 'RuimtelijkObject'. Zodoende kan er veel meer dynamisch omgesprongen worden met de ontologie en hoeft software niet zo vaak aangepast te worden, maar is de gebruiker van de software (de kennishouder) in staat om zijn assets op de juiste manier te 'classificeren'.
Noot: Beoogd gebruik in software
Dit zegt ook iets over de beoogde implementatie van IMBOR in software pakketten. Vanuit IMBOR en CROW worden software leveranciers dan ook geadviseerd om zich in te stellen op de principes van de NEN2660-2:2022. Zodat zij hun software kunnen gaan 'vullen' met ontologiën zoals IMBOR en andere modellen die op de NEN2660-2:2022 gebaseerd zijn of gaan worden. Het toepassen van IMBOR betekent dan dat de klassen in softwarepakket worden 'gevuld' met de IMBOR-ontologie. Dit betekent ook dat toekomstige wijzigingen in nieuwe versies van het IMBOR relatief eenvoudig kunnen worden 'geconfigureerd' en dat geen herprogrammaring nodig is. Een demonstratie en de open-source software die hierbij hoort is hier te vinden.
2.2.2 Regie op standaarden
Met de modellering van IMBOR op basis van de NEN2660-2:2022 wordt het voor organisaties die standaarden proberen te ontwikkelen zoals Stichting CROW, Stichting RIONED en Geonovum ook gemakkelijker om hun standaarden op elkaar af te stemmen en aan elkaar te relateren zodat dit dan niet meer bij de software leveranciers of opdrachtgevers komt te liggen. Deze kunnen de standaarden dan beter in samenhang gebruiken. Om dit te laten werken moeten deze organisaties onderling afspreken om:
de modellering waar mogelijk te beschrijven volgens het MIM,
de relaties met andere standaarden wederzijds te beschrijven en continue te bewaken,
de ontologie (ook) als LinkedData te publiceren, en
zo veel mogelijk via dezelfde technieken te ontsluiten.
Dit vraagt zodoende niet alleen technische inspanning, maar zeker ook proces en organisatie afstemming.
2.3 Doelgroep
Dit document is bedoeld als 'technische documentatie' rondom IMBOR. Het is dan ook primair bestemd voor informatiearchitecten, gegevensbeheerders of softwareleveranciers die IMBOR willen toepassen en er implementaties van maken. Enige kennis van informatiemodellering is daarom benodigd. IMBOR richt zich in het bijzonder op de informatievoorziening binnen het (overheidsdomein) beheer van de openbare ruimte.
Er worden door de IMBOR modelleurs ook modelleerregels gehanteerd. Deze kunnen ook handig zijn voor diegene die IMBOR gebruiken en/of implementeren. Dit levende document is te vinden bij de IMBOR documentatie onder de noemer: IMBOR Modelleerregels.
3. IMBOR in modellen
Tot en met IMBOR2020-08 zat het metamodel van IMBOR in de content verwerkt. Vanaf 2021 is er expliciet gemaakt hoe IMBOR gemodelleerd is. Hierbij wordt gebruik gemaakt van de principes die het metamodel voor informatiemodellering (MIM) definieert.
3.1 Begrippenkader
Het model van begrippen is in deze context gelijk aan een 'vocabulaire'. Het definieert het begrippenkader van IMBOR. Begrippen mogen in verschillende informatiemodellen gebruikt worden, maar worden op één plek, één keer gedefinieerd. Onderstaande figuur toont wat de begrippen structuur is. De begrippen zijn beschikbaar in [skos-primer]. Zowel het MIM als de NEN2660-2:2022 bevelen dit aan.
Figuur 2 IMBOR vocabulaire structuur -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
3.2 Metastructuur
Binnen IMBOR gaan we uit van bestaande standaarden, te weten de NEN2660-2:2022, de NEN3610:2022 en het MIM. Daarom wordt naast de vocabulaire een ontologie onderscheiden. In deze ontologie maken we voornamelijk gebruik van het "NEN2660-2 Praktisch toplevelmodel". Alle concepten binnen de IMBOR ontologie worden beschreven binnen de context van de NEN2660-2:2022. Hiermee sluiten we aan bij de ordeningsregels en uiteindelijk ook de taalbinding die in de NEN2660-2:2022beschreven worden. Hiermee is het "NEN2660-2 praktisch toplevelmodel" ook de top van de IMBOR. Dit beschrijft de concepten, attributen en relaties binnen IMBOR. Onafhankelijk van de beheeromgeving waarin IMBOR beheert wordt zal deze leidend blijven. Waar mogelijk is dit in lijn met het MIM en de NEN3610:2022, echter de NEN2660-2:2022 blijft het voornaamste uitgangspunt.
Onderstaande figuur toont de metastructuur hoe IMBOR is opgebouwd. In de LinkedData versie wordt er middels een ETL-pipeline gezorgd dat het er correct volgens de NEN2660-2:2022 en MIM taalbinding uit komt. Deze IMBOR metastructuur is door de jaren heen zo gevormd en herkenbaar geworden door met name het onderscheidt tussen Klasse en Objecttype en het feit dat er bijvoorbeeld een Eenheid aan een combinatie van Attribuut en Klasse hangt. Voor de (LinkedData) eindgebruiker is vooral de NEN2660-2:2022 structuur van belang.
IMBOR wordt gedistribueerd in een MS Access database en LinkedData. IMBOR schrijft geenszins een fysiek datamodel voor bij implementatie.
Figuur 3 IMBOR structuur' -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
Het MIM wordt op meerdere plekken aangehaald binnen IMBOR. Omdat IMBOR in eerste instantie de NEN2660-2:2022 volgt is de semantiek tussen IMBOR en het MIM soms wat verwarrend. Daarom volgt hier een nadere toelichting:
Het Object in MIM is de instantie van het Objecttype in MIM. Deze zijn allebei een UML Class. In IMBOR zijn er Klassen onderscheiden, sommige Klassen krijgen het synoniem Objecttype. Dit betreffen de concrete klassen en vaak de 'bladeren van de boom', ofwel de onderste in de hiërarchie. Deze concrete klassen (ofwel Objectypen) zijn degene waar instanties van te verwachten zijn in de beheerpakketten. Deze instanties worden weer Object genoemd (in lijn met MIM). De vergelijking is te maken met Classes en Instances.
Het Attribuut en de Attribuutsoort in MIM zijn vergelijkbaar (conceptueel) met het Object en het Objecttype in MIM (de een is dus instantie van de ander). In IMBOR (en de NEN2660-2/OTL wereld) hebben zaken net een andere betekenis. Het Attribuut betreft de te registreren kenmerk of eigenschap van een Klasse.
In MIM wordt met het Datatype aangegeven wat de structuur is waaraan een waarde, oftewel de data zelf, aan moet voldoen.
Multipliciteit en Kardinaliteit zijn onderwerp van discussie in verschillende gremia. Ook het MIM is hier niet eenduidige in. Binnen IMBOR wordt de volgende werkwijze gehanteerd: Simply put: a multiplicity is made up of a lower and an upper cardinality. A cardinality is how many elements are in a set. Thus, a multiplicity tells you the minimum and maximum allowed members of the set. They are not synonymous. Dit is ontleend uit deze bron. Multipliciteit is dus de algemene term om aan te geven hoe vaak iets voorkomt. De getallen die daar ingevuld staan, betreffen de Kardinaliteit. Een voorbeeld: De relatie tussen een fiets en wielen heeft een Multipliciteit met een minimale Kardinaliteit van 2 en een maximale Kardinaliteit van 2.
4. IMBOR samenhang en hiërarchie
IMBOR wordt gepositioneerd als sectormodel. De focus ligt op de vaste gegevens van objecten die herkend worden voor het beheer van de openbare ruimte. Kijkend naar het landschap waarin IMBOR wordt gebruikt zijn er veel raakvlakken met landelijke, maar ook andere sectorale modellen. Om deze afstemming zo optimaal te laten verlopen is getracht om de top van de IMBOR hiërarchie (ofwel de klassenindeling) zo veel mogelijk aan te laten sluiten op andere modellen. Dit is gedaan om enerzijds niet zaken zelf te verzinnen, maar zaken aan te vullen. En anderzijds om uiteindelijk een semantisch sterke mapping tussen de sectorale modellen mogelijk te kunnen maken. Wanneer sectorale modellen allemaal gebaseerd zijn op dezelfde uitgangspunten is het makkelijkere om onderin de boom de vergelijking te kunnen maken. Vandaar dat voor IMBOR gekozen is om gebruik te maken van een polyhiërarchie gebaseerd op respectievelijk de NEN2660-2:2022 en de NEN3610:2022.
4.1 IMBOR Top hiërarchie
In onderstaand diagram is de top van de hiërarchie te vinden, met in kleur aangegeven waar de concepten vandaan komen. De relaties tussen de NEN2660-2:2022 en de NEN3610:2022 komen uit de NEN2660-2:2022 documentatie zelf. Deze indeling zorgt ervoor dat voor alle IMBOR Objecttypen (niet afgebeeld) er een logische hiërarchie is, waarmee duidelijk is hoe deze zich verhoudt tot de landelijke standaarden. Te zien is dat er weinig IMBOR specifieke (hoofd)klassen geïntroduceerd hoeven te worden omdat bijna alles al voldoende gedefinieerd wordt. Alle Objecttypen` hebben worden aan één of meerdere van deze klassen gehangen en krijgen hiermee een landelijke semantische definitie. De hiërarchie wordt tevens gebruikt om de attributen mee te distribueren, maar deze hebben (nog) geen landelijk/sectoraal kader. Hiermee wordt bedoeld dat dit diagram meer gebruikt moet worden als 'begrippenkader'(lees: de semantische afstemming van de modellen) dan dat het daadwerkelijk als een volwaardige ontologie ingezet kan worden. Dit is niet per se mogelijk omdat er geen volledige afstemming is tussen de attributen en onderlinge relaties.
Al deze concepten kennen definities, omdat er anders geen semantische discussies gevoerd kunnen worden zonder dat de definities van de concepten bekend zijn. Alle definities kunnen ingezien worden in de IMBOR viewer.
Figuur 4 IMBOR Top van de ontologie -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
4.1.1 Totstandkoming
De uitgangspunten voor de totstandkoming van deze hiërarchie waren:
Hergebruiken wat er reeds is;
Aansluiten bij de meest recente versie van de standaarden;
Alleen de concepten vermelden waar gebruik van gemaakt wordt;
Meervoudige overerving is toegestaan;
Alle Objecttypen moeten een plek krijgen;
Termen en definities uit te standaarden hergebruiken (boven eigen gemaakte);
De gebruikte relaties alleen komen alleen uit de NEN2660-2:2022, tenzij die niet in de behoefte voorzien;
Dan geniet het gebruiken van bestaande relaties de voorkeur boven eigen relaties;
4.1.2 Semantische relaties
Vanaf IMBOR2022 bestaan er semantische relaties. Middels relaties geadopteerd (inter)nationale standaarden zoals de NEN2660-2:2022 wordt het mogelijk gemaakt om tussen concepten binnen IMBOR betekenisvolle relaties te leggen. De relaties betreffen:
net:startNode uit INSPIRE via [NEN3610:2022][nen3610:2022]
NetwerkLink
NetwerkNode
endNode
net:endNode uit INSPIRE via [NEN3610:2022][nen3610:2022]
NetwerkLink
NetwerkNode
Voor de relatie isGeregistreerdMet geldt dat deze eigenlijk alleen gebruikt wordt voor registratiegegevens. Hiervoor wordt verwezen naar 'temporele aspecten' techdoc en in deze best practice
In het schema is te zien tussen welke (top)concepten de relaties kunnen lopen. In de IMBOR ontologie is vanuit IMBOR per Klasse een aanzet gegeven van de belangrijkste relaties die voorkomen. Het staat de gebruiker van IMBOR vrij om binnen de gezette kaders meer relaties op Objecttypen te leggen. De gezette kaders betreffen de relaties zoals vastgelegd in de ontologie (zie voorgaande tabel).
De relatie isSubtypeVan is de allerbelangrijkste relatie hier, omdat deze tussen alles kan gelden (indien van hetzelfde type). Het principe van 'overervering' geldt hier. Doordat FysiekObject en subtype is van (of: hoort bij de klasse van) Object gelden alle relaties van Object ook voor FysiekObject. Deze hiërarchie (ofwel: taxonomie) is daarmee leidend voor de relaties die mogen voorkomen. Hier gelden deze hele belangrijke regels (aan de hand van een voorbeeld):
Vanuit IMBOR wordt gesteld dat alle dingen die direct of indirect een subtype zijn van een Object een hasPart relatie mogen hebben naar alle dingen die direct of indirect een subtype zijn van Object, maar dan ook alleen van Object.
IMBOR is dus niet voorschrijvend welke tussen welke subtypen van Object deze hasPart relatie mag voorkomen.
Dezelfde regels gelden overigens ook voor het overerven van attributen.
4.1.2.2 Multipliciteit
Bij de relaties die in IMBOR worden aangegeven wordt altijd een multipliciteit (of: kardinaliteit) aangegeven. Hiermee worden soms dus wel bepaalde beperkingen opgelegd. Bijvoorbeeld: 'Kolk' en 'Deksel' zijn allebei FysiekObject. Dus is het mogelijk om een relatie hasPart tussen deze twee te leggen. In IMBOR wordt echter voorgeschreven dat deze relatie een multipliciteit van '1 op 1' heeft. Als er dus een instantie van een 'Kolk' bestaat moet er ook een hasPart relatie zijn naar een instantie van een Deksel.
4.1.2.3 Inverse van relaties
In de NEN2660-2:2022 is de nen2660:hasPart (heeftDeel) relatie niet-transitief. De 'isDeelVan'-relatie wordt niet expliciet gemodelleerd. In IMBOR is hier wel vraag naar, vandaar dat vanaf 2024 deze er binnen IMBOR een expliciete relatie nen2660:isPartOf relatie is gedefinieerd in het IMBOR aanvullend meta-model. Deze is de inverse van nen2660:hasPart en mag ook gebruikt worden op dezelfde manier, maar dan in de andere richting.
Eenzelfde constructie geldt voor nen2660:contains (bevat). Ook hier is in IMBOR vraag naar een expliciete modellering. Vandaar dat de nen2660:isContainedBy (bevindtZichIn) is toegevoegd in het IMBOR aanvullend meta-model.
Binnen de IMBOR cursus wordt uitgelegd wat de bouwstenen van IMBOR zijn. Deze ReSpec betreft de technische documentatie, maar de afbeeldingen die in de cursus gebruikt worden maken vrij goed duidelijk hoe een "ingewikkeld" technisch model simpel uitgelegd kan worden aan een assetmanager die uiteindelijk ook de opbouw van IMBOR moet begrijpen. Vandaar dat onderstaande figuren opgenomen zijn. Het eerste figuur illustreert simpel hoe het metamodel van IMBOR in elkaar zit, het tweede figuur illustreert dit met behulp van voorbeelden verder.
Figuur 5 IMBOR bouwstenen versimpeld
Figuur 6 IMBOR bouwstenen versimpeld met voorbeelden
4.3 Speciale modelleerconstructies
Binnen IMBOR zijn er een aantal modelleerkeuzes gemaakt die extra uitleg verdienen. Deze kunnen geschaard worden onder de 'informele' modelleerregels
4.3.1 Objecttypen
Klasse is een begrip geïntroduceerd in IMBOR2022. Het kan gelijkgesteld worden aan het NEN2660-2:2022 "Concept". Het is hiermee ook een supertype van bijvoorbeeld Objecttype en InformatieObject.
Objecttype is een speciaal soort Klasse. Binnen IMBOR worden deze onderscheiden omdat de term 'Objecttype' erg ingeburgerd is. Technische gezien zijn het de enige 'concrete' Klasse (tegenover de rest welke 'abstracte' Klasse zijn). Hiermee wil IMBOR aangeven dat deze abstracte klassen niet geïnstanteerd kunnen worden en de 'concrete' Objecttype juist wel. Objecttype zijn als enige ook ingedeeld in Zoekingangen.
De klassenstructuur is een polyhiërarchie. Dit betekent dat een child, meerdere parents kan hebben. Of in IMBOR termen gezegd: Een Objecttype of Klasse erft van meerdere Klasse attributen over. Dit is gedaan zodat we flexibeler om kunnen gaan bij welke klassen een Objecttype hoort en daarmee een Objecttype geen onnodige attributen krijgt. Er zullen een aantal Klasse 'disjoint' zijn, maar dat is nog niet expliciet opgenomen.
Tot IMBOR2022 was altijd het laagste niveau in de klasse hiërarchie een Objecttype. Vanaf IMBOR2025 is dit veranderd vanwege het feit dat dit alignments met externe modellen eenvoudiger en completer kunnen worden en het verdwijnen van de classificerende attributen type, typeGedetailleerd en TypeExtraGedetailleerd. Tevens ligt deze wijze van modelleren meer in lijn met de praktijk van modellen maken. Hierdoor kan het ook voorkomen dat subklassen (onder objecttypen) bestaan, die nietObjectentypen zijn (dus niet instantiërbaar). Voor elke Klasse wordt nu apart bekeken of deze concreet (instantiërbaar) of abstract (niet instantiërbaar) is.
Klassen zijn een abstract concept. Ze staan daarmee tegenover bijvoorbeeld Objecttype en InformatieObject die wel 'concreet' zijn. Hiermee wil IMBOR aangeven dat deze klassen _niet geïnstanteerd_ kunnen worden.
Speciale aandacht gaat uit naar de relaties tussen Objecttype en InformatieObject. Veel van de attributen die in IMBOR2020-08 aan een Objecttype hingen waren eigenlijk meer 'informatie over' dan een daadwerkelijk aspect van dat object. Vandaar dat vanaf IMBOR2022 is besloten om veel attributen te verhuizen naar InformatieObject. Hiermee is het dus wel van belang dat deze daadwerkelijk geïnstantieërd worden om de beschrijvende attributen vast te leggen. Dit is ook vastgelegd middels de multipliciteit.
Deze keuze is enerzijds gemaakt vanwege de interpretatie dat een InformatieObject een ‘object’ op zichzelf is, welke informatie bevat over een object (vandaar de isBeschrevenDoor relatie). Hiermee wordt de informatie van het 'object' gescheiden van de informatie over het 'object'. Anderzijds betreffen het ook vaak attributen die op termijn uit andere registraties zouden moeten komen.
Figuur 7 Voorbeeld InformatieObject
4.3.2.1 Inwinning-informatie
Inwinning-informatie is een InformatieObject voor het vastleggen van informatie m.b.t. de inwinning van een objecttype. Een vergelijkbare entiteit is Registratie-informatie, omdat dit ook 'meta' informatie bevat. Inwinning-informatie is echter speciaal omdat hier een speciale afspraak gemaakt moet worden met betrekking tot twee attributen van deze klasse. De attributen attribuut en domeinwaarde zijn nu van het datatype xsd:string. Maar eigenlijk mogen hier alleen respectievelijk de IMBOR attributen en bijbehorende IMBOR domeinwaarden voorkomen.
4.3.3 Gebiedsindeling & andere afleidbare attributen
De Klasse 'Gebiedsindeling' was gemodelleerd vanwege een legacy behoefte binnen IMBOR. De klasse distribueerde een set van attributen welke allemaal afgeleid kunnen worden van de geografische locatie. De meeste waren ook dubbel te leggen met de semantische relatie bevat. Om deze reden is de klasse Gebiedsindeling dus komen te vervallen en wordt aangemoedigd om gebieden expliciet te modelleren als klassen.
In IMBOR2025 zijn alle afleidbare attributen (waar de waarden 'automatisch bepaald' konden worden) vervangen door semantische relaties. Dit is gedaan vanwege het feit dat in IMBOR2022 de modellering nog onvoldoende geconformeerd was aan de NEN2660-2:2022. Vele IMBOR-attributen behelzen namelijk (ruimtelijke) relaties tussen verschillende objecten (bijvoorbeeld tussen Ruimtelijke gebieden en Reële objecten).
Het gebruik hiervan wordt gepropageerd vanuit de NEN2660 en IMBOR adopteert dit volledig. Een best practice hiervoor (met het voorbeeld 'Ruimtelijk vs. Reëel') is te vinden in: IMBOR best practices.
Figuur 8 Voorbeeld gebiedsindeling
Zie ook gerelateerde issue(s) op GitHub:
👇
Omdat IMBOR uitgaat van onderscheidende kenmerken als vuistregel om een Klasse of Objecttype te introduceren is het attribuut Verschijningsvorm onderkent. Dit is een attribuut zoals beschreven in deze sectie van MIM. In de LinkedData theorie zouden dit subklassen kunnen zijn van de objecttypen waaraan ze hangen. Echter om geen exponentiële groei van objecttypen te veroorzaken wordt gebruik gemaakt van deze 'indicatie classificerend'. Dit zijn detailleringen van het Objecttype welke geen specifieke informatiebehoefte hebben. In theorie staat het de softwareleverancier of opdrachtgever vrij om van de attribuut waarden wel expliciete subklassen te maken indien nodig. Bij eventuele uitwisseling zal dan weer een conversie nodig zijn. De 'indicatie classificerend' wordt in de MIM graaf aan de attributen (ofwel mim:Attribuutsoort) gehangen en kan vanuit daar ook geraadpleegd worden.
Verschijningsvorm is de vervanging van wat in vorige versie van IMBOR de attributen Type, TypeGedetailleerd en TypeExtraGedetailleerd waren. De hiërarchie die hier in zat is vervallen vanaf IMBOR2025. De waarden die Verschijningsvorm kan hebben zijn hiermee samengevoegd/opgeschoond tot één enkele lijst.
Zoekingangen (voorheen 'Vakdisciplines) betreffen een groepering die ook niets meer is dan dat is. Binnen IMBOR wordt deze voornamelijk gebruikt als zoekingang of als structurering om de hoeveelheid Objecttype makkelijker te kunnen inzien.
Ter verduidelijking: daadwerkelijke geregistreerde objecten (de instanties van Objecttype) kunnen in een beheersysteem zelf vervolgens ook tot meerdere Zoekingangen tegelijk behoren. IMBOR dwingt hier niets over af. Zoekingangen in IMBOR zijn een geste vanuit IMBOR om te zoeken. De indeling is daarmee niet per sé arbitrair te noemen, maar wel vanuit ons/één perspectief.
4.3.6 Gekwalificeerde waardeshapes
In de LinkedData versie van IMBOR wordt sh:class gebruikt om bij de semantische relaties en bij attributen die vaste waardelijst kennen aan te geven van welke klasse de waarde moet zijn (ofwel, waar de relatie naar toe loopt). Bijvoorbeeld bij een Sluis heeftDeel Sluisdeur wordt aangegeven dat een bepaalde sluis een bepaalde sluisdeur als onderdeel kan hebben. In de consultatieronde is gebleken dat het directe gebruik van sh:class die beperkende factor ook inbrengt, maar tegelijk ook vereist dat als die relatie meerdere keren voorkomt per klasse, al die waarden aanwezig moeten zijn.
In het voorbeeld van een sluis, bestaat ook Sluis heeftDeel Schutkolk. Met een modellering sec sh:class, vereist de SHACL-controle dat de schutkolken tegelijk ook sluisdeuren moeten zijn.
Dit is niet wat bedoelt wordt en dus onwenselijk.
Daarom worden in IMBOR2022 sh:class klassebeperkingen via sh:qualifiedValueShape ingeleid, zodat deze voorgenoemde combinatorische betekenis niet voorkomt.
De klasse Sluisdeur of Schutkolk is namelijk één van de kwalificerende waardes voor heeftDeel bij een Sluis.
Binnen IMBOR zijn topologische elementen (als TopologischElement) toegevoegd als speciaal soort GeometrischeRepresentatie. Het betreffen namelijk schematische representaties van een daadwerkelijke (FysiekObject), net zoals de geometrie. Middels de heeftBegrenzing relatie zijn meerdere geometrische representaties vast te leggen (bijvoorbeeld: 2D, 3D of schematisch).
IMBOR voorziet vanaf versie 2025 tevens in een elementaire modellering van netwerken. Het gaat hierbij om een topologische uitdrukking van de geografische gegevens van de beheerobjecten uit IMBOR, dat wil zeggen: in termen van knooppunten en verbindingen die de eigenschappen van de plaatsen van IMBOR-objecten voorstellen. Deze modellering is gebaseerd op implementatie van de basisstructuren van het netwerkmodel uit de Europese standaard INSPIRE die de NEN3610:2022 voorschrijft. De NEN3610:2022 adviseert INSPIRE toe te passen voor het modelleren van topologische dimensie parallel aan een geografische dimensie.
Op hoofdlijnen heeft dit geleid tot de toevoeging van de klassen Netwerk, NetwerkLink en NetwerkNode. Deze klassen zijn subklassen gemaakt van nen2660:GeometrischeRepresentatie. Voor NetwerkLink en NetwerkNode geldt dat ze middels nen2660:hasPart gerelateert kunnen worden aan Netwerk. Tussen NetwerkLink en NetwerkNode lopen twee semantische relaties, namelijk endNode en startNode. Kortweg betekent dit dat een NetwerkLink een NetwerkNode als beginpunt of als eindpunt kan hebben. In de ontwikkeling van IMBOR2025 is ervoor gekozen om deze als rdfs:subPropertOf van nen2660:hasPart te declareren.
Een voorbeeld gebruik van het netwerkmodel:
Voor een topologische representatie van een netwerk van waterwegen worden imbor:Waternode en imbor:Waterlink geïnstantieerd, met als onderlinge relaties endNode en startNode. Deze objecten maken deel uit van een bovenliggend imbor:Netwerk. De imbor:Waternode en imbor:Waterlink hebben nen2660:isDescribedBy met instanties van nen2660:PhysicalObject, zoals imbor:Watergang (bij een topologische representatie van reële objecten) of imbor:Waterweg (bij een topologische representatie van ruimtelijke gebieden). Dit standaardiseert dus de kern van de statische modellering van netwerken binnen het domein van de openbare ruimte. Gebruikers kunnen dit als kernmodellering gebruiken om hun specifieke netwerktoepassingen mee te realiseren.
IMBOR implementeert vanaf versie 2025, in samenhang met de implementatie van NEN2660-2:2022, de mogelijkheid uit NEN3610:2022 om tijdlijnen voor de registratie van historische wijzigingen van objecten.
NEN3610:2022 faciliteert versionering van objecten door de tijd heen door twee tijdlijnen te introduceren: de 'TijdlijnRegistratie' en de 'TijdlijnGeldigheid'. Daarnaast is er de 'Levensduur' van een object. Al deze zaken zijn binnen de NEN3610:2022 eigenschappen van de klasse nen3610:Registratie. De IMBOR-implementatie van deze temporele aspecten schippert tussen de NEN2660-2:2022 en de NEN3610:2022. IMBOR heeft namelijk niet alleen met nen3610:GeoObject te maken, maar ook met het onderscheid tussen nen2660:InformationObject en nen2660:PhysicalObject. Op nen2660:PhysicalObject past nen3610:Registratie in haar geheel en dit leidt tot een implementatie gelijk aan hoe NEN3610:2022 dit voor nen3610:GeoObject voorschrijft, namelijk m.b.v. van de relatie nen3610:registratiegegevens, zodanig dat geldt dat: nen3610:GeoObject > nen3610:registratiegegevens > nen3610:Registratie. Echter is deze implementatie voor nen2660:InformationObject niet altijd nodig, omdat TijdlijnGeldigheid en Levensduur betrekking heeft op toestandswijzigingen van het beschreven object in de niet-virtuele werkelijkheid. nen2660:InformationObject is een object dat niet bestaat buiten de virtuele werkelijkheid van het computersysteem. Daarom is voor nen2660:InformationObject alleen gekozen voor het implementeren van TijdlijnRegistratie – er zijn immers wel tijdstippen aan te wijzen waarop een informatieobject wijzigt en vervalt.
De implementatie heeft geleid tot de introductie van de klasse nen3610:Registratie, die zelf een subklasse is van nen2660:InformationObject. Dit is dus een speciaal informatieobject voor het beschrijven van nen2660:InformationObject en nen2660:PhysicalObject. nen3610:Registratie heeft de volgende subklassen:
imbor:TijdlijnRegistratie dient het vastleggen van wijzigingen door de tijd heen binnen de virtuele omgeving.
imbor:TijdlijnGeldigheid biedt de mogelijkheid tijdstippen vast te leggen waarop het virtuele object in representatie (d.w.z.: invulling van eigenschappen) overeenkomt met de werkelijkheid.
imbor:Levensduur is een afgeleide van imbor:TijdlijnGeldigheid die het vastleggen van de begin- en eindtijden van een object dient.
imbor:Versie legt vast op welke versie van het object in het computersysteem een toestand van een van de tijdlijnen betrekking heeft.
Instanties van nen2660:InformationObject of nen2660:PhysicalObject zijn gerelateerd aan de voorgenoemde klassen m.b.v. de relatie nen3610:registratiegegevens, die in overleg met zowel de NEN2660-2:2022 als de NEN3610:2022 als subproperty van nen2660:isDescribedBy wordt beschouwd.
4.3.8.2 Gebruik
Deze temporele aspecten zijn een toevoeging aan IMBOR 2025, maar hebben ook een betere scheiding wat betreft temporele eigenschappen in het model mogelijk gemaakt. De klasse imbor:Registratie-informatie is komen te vervallen en de rol van deze klasse wordt overgenomen door imbor:TijdlijnRegistratie. Daarnaast hebben op diverse plaatsen in het model verwijderingen plaatsgevonden van temporele eigenschappen die overeenkomen met een van de eigenschappen van de tijdlijnen. Overige attributen die een tijdstip registeren kunnen door gebruikers naar wens gekoppeld worden aan attributen van een van de tijdlijnen, maar er is, vanwege de specifieke betekenis van zo’n attribuut of vanwege de manier van presenteren van informatie die zo’n attribuut verzorgt, geen sprake van equivalentie met een van de eigenschappen van de tijdlijnen.
Het gebruik van de klasse 'Registratie' is dat een configuratie van een object dat gelabeld is met imbor:versie (attribuut van imbor:Versie) als een momentopname van dat object kan worden beschouwd. Als zodanig wordt het voor gebruikers gestandaardiseerd hoe en via welke tijdlijnen momentopnamen die gelabeld zijn met imbor:versie elkaar opvolgen. Er kan als zodanig een parallelle progressie zijn van imbor:TijdlijnRegistratie en imbor:TijdlijnGeldigheid. Als voorbeeld: een object 'X' kan, in de voor IMBOR relevante opzichten, sinds de initiële nen3610:beginGeldigheid van 'X' in werkelijkheid ongewijzigd zijn, maar in de virtuele registratie van dit object wel wijzigingen hebben ondergaan. imbor:tijdstipRegistratie krijgt daarom een nieuwe waarde, imbor:versie wordt opgehoogd en er is sprake van een nieuwe momentopname van object 'X'.
Het gebruik hiervan wordt gepropageerd vanuit de NEN3610:2022 en IMBOR adopteert dit volledig. Hoe de implementatie dan precies werkt wordt toegelicht in de NEN3610:2022, maar specifiek voor graphs en IMBOR is een uitwerking te vinden in: IMBOR best practice temporele aspecten.
4.3.9 Materie
Vóór IMBOR2022 werden materialen als attributen van Objecttypen vastgelegd. Binnen de NEN2660-2:2022 is hiervoor een modelleerconstructie gegeven die IMBOR nu toepast. Er kan een relatie bestaatUit (nen2660:consistOf) gelegd worden tussen de klasse ReeelObject en de klasse Materie. Dit betekent dat materialen dus ook een klasse zijn en ook als zodanig gemodelleerd zijn. Binnen IMBOR2022 zijn allerlei soorten materialen opgenomen. Deze lijst is op basis van 'expert judgement' samengesteld door de jaren heen. Elke soort relatie tussen een Object en een Materiaal kan gelegd worden.
Nu IMBOR zich committeert aan de NEN2660-2:2022 en daarmee LinkedData wordt er gekeken of de materialen apart van IMBOR beheert kunnen gaan worden. Het liefst wordt in de toekomst aangesloten bij een bestaand(e) lijst/initiatief. Voorsorterend daarop zijn daarom vanaf IMBOR2025 de materialen opgenomen in een aparte graaf (maar wel nog binnen de IMBOR namespace).
Ter verduidelijking IMBOR limiteert niet welke relaties er tussen een FysiekObject en een Materie gelegd kunnen worden.
4.3.10 Actoren en rollen
Vanaf IMBOR2025 is er een nieuw modelleerpatroon geïntroduceerd om relaties tussen klassen en actoren te modelleren, middels rollen. Deze constructie is ontleend uit de NEN2660-1:2022. Omdat de NEN2660-2:2022 hier geen standaard oplossing voor biedt, is er een in IMBOR een modelleerconstructie die conform de NEN2660-1:2022 gemaakt is. Het gaat hier om de introductie van imbor:Actor (als subklasse van nen2660:PhysicalObject) en imbor:Rol. Een imbor:Actor is een entiteit die in staat is om handelingen uit te voeren en een specifieke functie of positie te vervullen in een bepaalde context (bijvoorbeeld 'Gemeente X'). Met een imbor:Rol wordt een samenhangende verzameling van verwachtingen, verantwoordelijkheden, bevoegdheden en gedragingen die een Actor kan aannemen in relatie tot iets bedoelt (bijvoorbeeld 'Beheerder'). imbor:Actor wordt met de relatie imbor:speelt verbonden met een imbor:Rol. Welke op zijn beurt met een imbor:heeftBetrekkingOp relatie verbonden is met een nen3610:GeoObject of nen2660:InformatieObject.
IMBOR definieert subklassen van imbor:Actor, te weten: imbor:PublieksrechtelijkRechtspersoon en imbor:PrivaatrechtelijkRechtspersoon. Voor de eerste worden TOOI subklassen gebruikt, welke toegelicht worden in TOOI. De laatste kan geïnstantieerd worden om organisaties zoals 'ProRail' of 'TenneT' aan te maken.
De klasse imbor:Rol kent een aantal subklassen die herkenbaar zullen zijn voor de gemiddelde IMBOR gebruiker. Deze werden voorheen als attributen behandeld, maar zijn nu klassen. Voorbeelden hiervan zijn 'Beheerder', 'Eigenaar' en 'Fabrikant'. Deze klassen kunnen geïnstantieerd worden om de expliciete rol aan te geven. In onderstaande voorbeeld is in dikgedrukte letters de IMBOR modelleerconstructie te zien, daaronder een voorbeeld in de data.
imbor:Actor
imbor:speelt
imbor:Rol
imbor:heeftBetrekkingOp
imbor:GeoObject
ex:GemeenteX
imbor:speelt
ex:Beheerder123
imbor:heeftBetrekkingOp
ex:BoomX
ex:GemeenteX
imbor:speelt
ex:Eigenaar321
imbor:heeftBetrekkingOp
ex:BoomX
Figuur 9 Voorbeeld actor en rollen
Zie ook gerelateerde issue(s) op GitHub:
👇
Vanaf IMBOR2025 is er een hiërarchie geïntroduceerd binnen de attributen. Dit is niet alleen overzichtelijker voor 'navigatie', maar het stelt gebruikers ook in staat algemenere bevragingen te doen op het gebied van de attributen. Inhoudelijk verandert dit niets, maar het betreft de introductie van een attribuut dat abstract is, en een parent is van een ander attribuut.
Wanneer IMBOR geïmplementeerd moet worden in software is uiteraard de gehele content beschikbaar. Hiervoor zijn ook twee distributiekanalen beschikbaar:
IMBOR in LinkedData (TTL file en SPARQL-Endpoint)
IMBOR tabellen in MS Access database
Alle informatie hierover en versies hiervan is/zijn via GitHub releases te raadplegen. Een specifiek overzicht van de beschikbare SPARQL-Endpoints is hier op GitHub te raadplegen. Wat betreft het gebruik van IMBOR, raadpleeg de sectie over licenties.
Al deze vormen van distributie zijn (voorlopig) zonder kosten te raadplegen; Namelijk voor de SPARQL-Endpoint geldt dat we deze voorlopig onder de noemer van 'pilot' verstrekken. Bij veel gebruik/op termijn wordt gekeken hoe we hier met de kosten gaan omgaan.
Figuur 10 Overzicht IMBOR Beheer, Distributie en Publicatie
5.1 IMBOR in MS Access
IMBOR wordt momenteel beheerd in MS Access. In onderstaande diagram is een overzicht van de databasestructuur gegeven.
Het betreft hier dus niet een voorgeschreven datamodel voor een beheerapplicatie.
IMBOR is modulair opgebouwd, in Access wordt dit met de tabel prefixen vastgelegd.
imborVoc_* zijn de tabellen die het begrippenkader (of vocabulaire) van IMBOR beschrijven
imborKern_* zijn de tabellen die de (normatieve) elementen binnen de IMBOR ontologie beschrijven
imborKern_K_* zijn koppeltabellen binnen de ontologie die eigenlijk predicaten beschrijven
refModel_* zijn tabellen waarin externe ontologieën aangehaald worden. Hier staan de benodigde gegevens om relaties naar toe te kunnen leggen.
imbor_logging* zijn tabellen die voor de logging gebruikt worden
Figuur 11 IMBOR AccessDB structuur -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
Hieronder worden voor de vocabulaire en de het kernmodel een toelichting gegeven per tabel. De overige tabellen zijn voor de werking van de AccesDB zelf.
5.1.1 Vocabulaire
Alle tabellen die invulling geven aan de IMBOR Vocabulaire.
5.1.1.1 imborVoc_Termen
Deze tabel is onderdeel van het begrippenkader van IMBOR kan gezien worden als de vocabulaire. Deze heeft deze binnen Access een speciale status omdat hier de IMBORGUID ook gedeclareerd wordt voor de meeste elementen. Bijna alle tabellen halen hier informatie op. De tabel geeft inrichting aan het Niveau 1 van MIM (Model van begrippen) en aan de SKOS taalbindingen uit de NEN2660-2:2022.
Speciaal geval is ook de kolom KlasseType. Deze is gekoppeld aan de IMBORGUID zoals hiervoor vermeld. KlasseType geeft aan of een IMBOR concept geïnstanteerd kan worden (Concreet) of niet (Abstract).
5.1.1.2 imborVoc_Collecties
De enige andere tabel in het begrippenkader naast imborVoc_Termen. Dit betreft een overzicht van de collecties waarin de termen ingedeeld zijn.
5.1.2 Kernmodel
Alle tabellen die invulling geven aan het IMBOR Kernmodel.
5.1.2.1 imborKern_Attributen
Deze tabel bevat alle attributen die in IMBOR voorkomen, inclusief hun Datatype. De datatype volgen het [xmlschema11-1] en waar van toepassing wordt aangegeven of het een Enumeratie- of Referentielijst betreft.
5.1.2.2 imborKern_EnumeratiesDomeinwaarden
In deze tabel staan alle EnumeratieType binnen IMBOR, inclusief de relatie naar de Domeinwaarde. Het EnumeratieType en de Domeinwaarde worden één keer gedefinieerd in imborVoc_Termen en worden hier middels 1-op-N relaties aan elkaar gekoppeld.
De kolom BovenliggendeWaarde wordt gebruikt om aan te geven hoe de domeinwaarden zich tot elkaar hiërarchisch verhouden. Dit betreft een hulpkolom die nodig is om de formulieren op te bouwen en is niet normatief nodig.
5.1.2.3 imborKern_Hierachie
In deze simpele tabel wordt de polyhiërarchie van IMBOR beschreven. Concepten kunnen meerdere parents hebben. Door middel van de parent-child relatie wordt overerving geregeld. Alle childs krijgen ook de attributen van hun parents. Daarmee geldt dat ook alle Objecttypeen die onder de klassen hangen ook op dezelfde manier attributen overerven. Deze tabel is eigenlijk de vastlegging van het predicaat isSubType. Hier staat dus ook tot welke klasse een Klasse of Objecttype behoord en daarmee zijn eigenschappen (lees: attributen) overerft. Sinds IMBOR2025 wordt hier ook de hiërarchie van Attributen en Relaties bijgehouden. Middels de kolom HierarchieType wordt aangegeven welke soort er hiërarchisch ingedeeld wordt.
5.1.2.4 imborKern_K_KlasseAttributen
Dit betreft een koppeltabel waarin de attributen aan de klassen gekoppeld worden. Inclusief een indicatie van de Multipliciteit en in welke Eenheid dit attribuut vastgelegd kan worden.
Er komen o.a. Objecttypen, Klassen, ObjecttypeOnderdelen en Informatieobjecten voor in de kolom Klasse. Dit lijkt vreemd, maar is correct omdat het technisch gezien allemaal Klasse zijn (ofwel: subtypen van Klasse)
Daarnaast wordt de kolom Informatiemodel gebruikt om aan te geven in welk extern model er voor heeft gezorgd dat het betreffende attribuut is opgenomen in IMBOR. Hier wordt op termijn als nodig een mapping voor gemaakt. Nu is het 'beheerinformatie'.
De kolom OAGBD wordt gebruikt voor het informatieve deel dat beschreven wordt in het OAGBD addendum.
Als laatste staat hier ook welke waardelijst van toepassing is. Dit staat in EnumeratieType.
In deze tabel zijn de relaties opgenomen die normerend zijn binnen de IMBOR ontologie (inclusief hun multipliciteit). De relaties zelf ontlenen hun semantiek aan de NEN2660-2:2022.
Deze lijst is voorschrijvend, maar niet limitatief. In de implementatie mag een gebruiker zelf kiezen welke relaties er tussen de verschillende klassen aangegeven mag worden. Als er een relatie ontbreekt kan deze in de eigen implementatie gewoon gelegd worden. Uiteraard wil de IMBOR beheercommissie graag op de hoogte gehouden worden van deze inzichten.
5.1.2.6 imborKern_K_ZoekingangenObjecttypen
Met deze tabel wordt aangegeven binnen welke Zoekingang een Objecttype kan voorkomen. Het betreft hier groepering die ook niets meer dan dat is. Binnen IMBOR wordt deze voornamelijk gebruikt als zoekingang of als structurering om de hoeveelheid Objecttype makkelijker te kunnen inzien.
5.2 IMBOR in LinkedData
Naast de distributie in de relationele tabellen van Acces wordt ook een LinkedData variant aangeboden. Deze is gebaseerd op hetzelfde model als de Access versie. Omdat vooralsnog de Access database tevens als beheeromgeving voor IMBOR wordt gebruikt is de LinkedData versie een transformatie van de tabellen. De LinkedData versie wordt via een transformatie gepubliceerd uit de beheeromgeving. In de transformatie wordt de data getransformeerd naar het onderstaande structuur.
Figuur 12 IMBOR LinkedData Structuur -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
5.2.1 Ontologie indeling (in grafen)
Ook de LinkedData versie van IMBOR (IMBOR-LD) is volgt de modulaire indeling. In IMBOR-LD wordt dit met verschillende namespaces vastgelegd.
imbor-term:* zijn de concepten die het begrippenkader (of vocabulaire) van IMBOR beschrijven.
imbor:* zijn de concepten die de (normatieve) elementen binnen de IMBOR ontologie beschrijven (dit staat gelijk aan de 'imborKern').
imbor-domeinwaarde:* zijn alle domeinwaarden binnen IMBOR (dit zijn instanties). Deze staan in een aparte graaf vanwege de overzichtelijkheid.
imbor-refmodels:* zijn de concepten waarin externe ontologiën aangehaald worden. Hier staan de benodigde gegevens om relaties naar toe te kunnen leggen.
Qua indeling in grafen worden de volgende grafen onderscheiden:
https://data.crow.nl/imbor/term/ voor de vocabulaire.
https://data.crow.nl/imbor/def/ voor de kern (exclusief de domeinwaarden).
https://data.crow.nl/imbor/id/domeinwaarden/ voor de domeinwaarden.
https://data.crow.nl/imbor/aanvullend-metamodel/ voor de aanvullende meta concepten.
https://data.crow.nl/imbor/addendum/referentiemodellen/ voor de modellen waaraan gerefereerd wordt.
https://data.crow.nl/imbor/addendum/oagbd/ voor het OAGBD addendum.
https://data.crow.nl/imbor/addendum/geometrie/ voor het geometrie addendum.
https://data.crow.nl/imbor/addendum/materie/ voor het materie addendum.
https://data.crow.nl/imbor/mim/ voor het MIM addendum.
https://data.crow.nl/change/log/imbor/ voor de logging.
Omdat IMBOR een extensie is van de NEN2660-2:2022 is de IMBOR kern direct 'gesubclassed' aan de NEN2660-2:2022 concepten. Vandaar dat de concepten die we gebruiken uit de NEN2660-2:2022 afgebeeld zijn met de prefix nen2660:*.
Noot
In de NEN2660-2:2022 zit een kleine inconsistentie met GeoSPARQL. Er wordt namelijk niet verteld hoe deze toegepast moet worden. Om dit praktisch op te lossen wordt in de IMBOR Kern gesteld dat: nen2660:hasBoundary rdfs:subPropertyOf geo:hasGeometry. Dit kan gezien worden als een verduidelijking van de NEN2660-2:2022 voor de IMBOR context. Dit wordt opgelost in de Europese versie van de NEN2660-2, te weten de CEN17632.
5.2.2 Begrippenkader
Dit zijn alle classes (concepten) die tezamen het vocabulaire vormen (e.g. de thesaurus).
5.2.2.1 imbor-term:Term
Op deze class worden alle attributen vastgelegd die het concept (conceptueel) definiëren in tekstuele zin en vormt daarmee de basis voor het vocabulaire.
5.2.2.2 imbor-term:Collectie
Deze class bevat alle collecties waarin de termen kunnen worden ingedeeld.
5.2.3 NEN2660
Dit zijn alle classes uit de NEN2660-2:20222 waaraan wij ons committeren. De basis betreft met name het nen2660:DiscreteObject (buiten de NEN2660-2:2022 wordt dit ook wel als een 'Fysieke Object' gezien) en de nen2660:SpatialRegion (ook wel het 'Ruimtelijk Gebied'). Daarnaast betrekken we het nen2660:InformationObject om beschrijvingen toe te voegen en nen2660:Activity om functies te kunnen definiëren.
NEN2660 Concept
Definitie
nen2660:DiscreteObject
A real object consisting of a contiguous amount of form-retaining matter, held together primarily by internal forces (gravity, electromagnetic force)
nen2660:SpatialRegion
A physical object that encloses a certain area such as rooms, roads and rivers that is bound by real objects, other spatial regions or based on use or convention and that is empty or contains discrete or liquid or gaseous matter
nen2660:InformationObject
Thing that is a whole of information on itself and has an own identity
nen2660:GeometricEntity
A spatial representation
nen2660:EnumerationType
A type having a fixed or extendable set of simple instances having no further attributes or relations
nen2660:Activity
An activity is something possibly or actually happening in space and time
nen2660:Matter
A pure chemical substance, chemical bonding or mixture from which real objects are made
imbor:Actor
Een entiteit die in staat is om handelingen uit te voeren en een specifieke functie of positie te vervullen in een bepaalde context.
imbor:Rol
Een samenhangende verzameling van verwachtingen, verantwoordelijkheden, bevoegdheden en gedragingen die een Actor kan aannemen in relatie tot iets.
Vanaf IMBOR2025 is er een nieuw modelleerpatroon geïntroduceerd om relaties tussen klassen en actoren te modelleren, middels rollen. Deze constructie is ontleend uit de NEN2660-1:2022. Zie hiervoor de sectie Actoren en Rollen. Verder bevat het IMBOR kernmodel niet veel meer dan 'Objecten', 'Attributen', 'Domeinwaarden' en 'Relaties'. Dit wordt nog aangevuld met Zoekingangen. Het kernmodel is uitgevoerd in [rdf-schema] en [shacl]. Dit is volgens de taalbinding van de NEN2660-2 gedaan. Daarom is voor ieder concept in het Kernmodel ook een rdfs:seeAlso relatie aanwezig die naar de term in de IMBOR Vocabulaire verwijst. Hieronder worden alle onderdelen beschreven.
5.2.3.1 imbor:Klasse
Deze class betreft alle Klassen die IMBOR bevat. Met het attribuut dash:abstract wordt aangegeven of iets abstract (true) of concreet (false) is. Waarbij met concreet bedoeld wordt dat er in een beheersysteem of bij uitwisseling ook daadwerkelijk instanties van gemaakt zullen worden. Abstracte classes zullen voor eindgebruik niet heel belangrijk zijn en voor de meeste eindgebruikers ook niet zichtbaar zijn. De class heeft verder twee belangrijke relaties naar NEN2660-2:2022 concepten. Dit betreffen nen2660:isDescribedBy die naar het nen2660:InformationObject loopt en nen2660:hasBoundary die naar de nen2660:GeometricEntity loopt. Met de eerste wordt dus aangegeven dat 'meer informatie over het de imbor:Klasse te vinden is bij het het InformatieObject. Met de tweede wordt aangegeven dat de (concrete) imbor:Klasse gebonden is door een geometrie. Ofwel, er kan een geometrie van vastgelegd worden.
5.2.3.2 imbor:KlasseAttribuut
Deze class (die middels sh:property aan de imbor:Klasse hangt) is eigenlijk de koppeling tussen het 'Object' en het 'Attribuut'. Dit is een zogenaamde 'SHACL PropertyShape' en definieert dus welke attributen van toepassing zijn bij welk Objecttype en legt daar zaken over vast zoals: maximale kardinaliteit, in welke unit dit uitgedrukt moet worden van welke datatype het betreft. Er zijn in het schema twee beschrijvingen van imbor:KlasseAttribuut te zien. Dit komt omdat de property-shapes anders in elkaar zitten wanneer het een voorgedefinieerd datatype betreft (iets uit de [xmlschema11-1] lijn), dan wanneer het een waardelijst is.
5.2.3.3 imbor:Attribuut
Middels sh:path wordt de imbor:KlasseAttribuut verbonden met de daadwerkelijke imbor:Attribuut. Dit kan gezien worden als de 'conventionele' declaratie van het IMBOR attribuut.
5.2.3.4 imbor:EnumeratieType
De imbor:KlasseAttribuut wordt middels sh:class verbonden aan de imbor:EnumeratieType. Dit is een nen2660:EnumerationType. Deze lijst bevat eigenlijk 'instanties' van de daadwerkelijke domeinwaarden.
5.2.3.5 imbor-domeinwaarde:Domeinwaarde
Dit zijn de daadwerkelijke domeinwaarden die middels een rdf:type aan de `imbor:EnumeratieType gehangen worden. Deze worden (volgens MIM gebruik) in een aparte graaf geplaatst zodat de kern niet te groot wordt en omdat deze domeinwaarden vaker aan verandering onderhevig zijn.
5.2.3.6 imbor:Zoekingang
De instanties van deze class zijn de IMBOR Zoekingangen. Deze declareren middels een rdfs:member welke ObjectTypen uit imbor:Klasse binnen een zoekingang vallen.
5.2.4 Aanvullend 'metamodel'
Een aantal metaconcepten worden specifiek voor IMBOR gedefinieerd. Dit wordt gedaan middels het 'IMBOR Aanvullend Metamodel'. Dit betreft een kleine ontologie van beschrijvende concepten die er voor zorgen dat alle IMBOR specifieke properties netjes en navolgbaar gedefinieerd zijn. De locatie van dit model is op de GitHub te vinden.
5.2.5 SPARQL-Endpoints
CROW stelt haar kennis in basis als SPARQL-Endpoints ter beschikking. Alle andere vormen van distributie zijn in principe afgeleide daarvan. Dit geldt dus ook voor IMBOR. Het overzicht van de beschikbare SPARQL-Endpoints voor IMBOR is hier op GitHub te vinden.
Wat betreft versionering zijn er major (aangeduid per jaar) releases en minor releases (patches):
https://hub.laces.tech/crow/imbor/*YEAR*/*PUBLICATIE*/sparql is altijd de laatste versie
https://hub.laces.tech/crow/imbor/*YEAR*/*PUBLICATIE*/versions/*SUFFIX*/sparql is een specifieke versie (e.g. “00” is de initiële release, “01” is de eerste patch)
6. Logging, versie- & deltamanagement
Vanaf IMBOR2025 wordt er uitgebreid bijgehouden wat de wijzigingen zijn ten opzichte van de vorige versie. Dit wordt enerzijds gedaan voor de transparantie, anderzijds voor de (semi-)automatische verwerkingen van wijzigingen in de software die gebruik maakt van IMBOR. Er zijn meerdere manieren waarop deze wijzigingen bijgehouden en gedistribueerd worden.
GitHub issues: De meldingen, overwegingen en verwerking
Logging tabel (MS Access): De wijziging in de beheeromgeving in tabel vorm. Inclusief metadata hierover zoals de gerelateerde GitHub issue en in welke categorie de wijziging valt
Changelog (RDF): De wijziging in de beheeromgeving een triple vorm. Inclusief metadata hierover zoals de gerelateerde GitHub issue en in welke categorie de wijziging valt
Diff (RDF): Een 'verschillen' bestand tussen twee versies van een IMBOR RDF bestand. De diff is in triples en kan zodoende gecombineerd worden met de changelog
Diff (TSV): Een 'verschillen' bestand tussen twee versies van een IMBOR RDF bestand. De diff heeft de stijl van GitHub
GitHub Diff: Binnen de imbor-development repository worden voor elke commit bijgehouden wat de wijzigingen zijn. Bij een commit wordt de AccesDB omgezet naar aparte [IANA-TSV] bestanden. Deze worden op regel niveau vergeleken door GitHub.
Delta rapportages: Spreadsheets die op basis van de NEN2660-2 structuur rapporteren wat de wijzigingen zijn tussen twee versies van releases.
Op de GitHub pagina van IMBOR kunnen issues worden ingediend welke kunnen leiden tot wijzigingen. Deze kunnen door iedereen worden ingediend, inclusief de IMBOR teamleden zelf. Deze issues dienen als startpunt voor een wijziging. Voor IMBOR2025 is een 'milestone' gemaakt. Alle issues die aan deze milestone hangen zijn verwerkt in de 2025 versie. Hiermee is dus meteen inzichtelijke wat er allemaal verwerkt en veranderd is. Deze kan gezien worden als zeer uitgebreide releasenotes, waarbij ook duidelijk is waarom, hoe en door wie iets gewijzigd is.
IMBOR gebruikt vooralsnog een Access database als de beheeromgeving. Binnen deze beheeromgeving is een uitgebreide logging aanwezig. In principe worden alle wijzigingen die doorgevoerd worden in IMBOR hier gelogd. Deze tabel bestaat uit de volgende onderdelen.
Kolom
Uitleg
LoggingGUID
Unieke identifier voor de logging regel
VocabulairGUID
GUID van de term uit de vocabulaire, indien deze beïnvloed is door de wijziging
IMBORGUID
GUID van de het IMBOR concept wat beïnvloed is door de wijziging
Indien van toepassing de GUID van het concept waarnaartoe gewijzigd is
Deze tabel vormt ook de bron voor de changelog in RDF.
6.3 Changelog (RDF)
IMBOR (en CROW) willen eenduidiger zijn in hoe kennis naar de markt gedistribueerd wordt. Er is gekozen om alle producten in (NEN2660) RDF te verstrekken. Op deze manier hoeft de markt maar één manier te programmeren om CROW kennis in hun systemen en processen te verwerken. In 2025 is dit uitgebreid met het eenduidig verstrekken van de changelogs. Hiervoor is het [activitystreams-core] standaard geadopteerd. [activitystreams-core] is een protocol voor het beschrijven van activiteiten en interacties op het web in een gestandaardiseerd formaat. Het wordt o.a. gebruikt voor activiteitenlogboeken.
Elke Log-item wordt geclassificeerd als een crow_change:ChangeItem en als een van de klassen: as:Delete, as:Create of as:Update. Hiermee is snel inzichtelijk welke soort wijzigingen er zijn. Elk item heeft vervolgens de volgende eigenschappen:
Eigenschap
Uitleg
rdfs:comment
Gedetailleerde beschrijving van de wijziging zelf
rdfs:label
Titel van de wijziging
rdfs:seeAlso
URL van het gerelateerde GitHub issue
skos:changeNote
Aard van de aanpassing
skos:scopeNote
Scope waartoe de wijziging behoort
as:name
Titel van de wijziging
as:published
Datum waarop de wijziging is gelogd
as:summary
Gedetailleerde beschrijving van de wijziging zelf
as:to
URI('s) waar de wijziging betrekking op heeft
Deze structuur zit als volgt in elkaar.
Figuur 13 Changelog structuur
Noot
De vorm van deze changelog wordt voor alle CROW producten geadopteerd in de komende jaren.
6.4 Diff (RDF)
IMBOR (en CROW) willen eenduidiger zijn in hoe kennis naar de markt gedistribueerd wordt. Er is gekozen om alle producten in (NEN2660) RDF te verstrekken. Op deze manier hoeft de markt maar één manier te programmeren om CROW kennis in hun systemen en processen te verwerken. In 2025 is dit uitgebreid met het eenduidig verstrekken van de diff's (verschil bestanden) in RDF. Omdat bij CROW de standaard voor kennisverstrekking RDF wordt, geldt dit ook voor de diff's. Hiervoor is het [activitystreams-core] standaard geadopteerd. [activitystreams-core] is een protocol voor het beschrijven van activiteiten en interacties op het web in een gestandaardiseerd formaat. Het wordt o.a. gebruikt voor activiteitenlogboeken.
In deze diff bestanden worden de verschillen uiteengezet per IMBOR graph (of: IMBOR bestand). In de diff zitten rdf:Statement's. Deze statement zijn geclassificeerd als een as:Delete of as:Create. Deze bevatten drie eigenschappen die samen de triple vormen die gewijzigd is: rdf:subject, rdf:predicate, rdf:object. Zo is precies op triple niveau te zijn wat er weg is, of erbij is gekomen.
Figuur 14 Change statements structuur
Noot
De vorm van deze diff wordt voor alle CROW producten geadopteerd in de komende jaren.
6.4.1 Diff (TSV)
Voor diegene die RDF ingewikkeld vinden worden dezelfde wijzigingen als in de sectie hiervoor beschreven in een [IANA-TSV] bestand. Voor elke regel staat een + voor Create en een - voor Delete. Deze stijl is afkomstig van GitHub.
CROW gebruikt GitHub voor de ontwikkeling van IMBOR. Binnen de imbor-development repository worden voor elke commit bijgehouden wat de wijzigingen zijn. De folder tsv bevat automatisch gegenereerde [IANA-TSV] bestanden door 'GitHub actions'. Bij elke nieuwe commit van de AccessDB worden automatische de tabellen uit de database omgezet naar [IANA-TSV]. Daardoor kan op regel niveau bekeken worden wat er gewijzigd is omdat GitHub dit nu bijhoudt.
IMBOR (en CROW) willen eenduidiger zijn in hoe kennis naar de markt gedistribueerd wordt. Er is gekozen om alle producten in (NEN2660) RDF te verstrekken. Op deze manier hoeft de markt maar één manier te programmeren om CROW kennis in hun systemen en processen te verwerken. In 2025 is dit uitgebreid met het eenduidig verstrekken van de delta rapportages. Deze delta rapportages zijn (grotendeels) gebaseerd op de topstructuur van de NEN2660-2. In principe kan dus iedere ontologie die gebaseerd is op de NEN2660-2 vergeleken worden en in deze rapportages worden gepresenteerd.
Wijzigingen in de attributen, inclusief de grootheid (quantitykind)
Klassen-Attributen
Wijzigingen in de relatie tussen een klasse en een attribuut, inclusief de eenheid (unit), het datatype en de eventuele enumeratielijst
Klassen-Relaties
Wijzigingen in de relaties tussen klassen
Enumeraties
Wijzigingen in de enumeratietype, inclusief het type enumeratie en de bijbehorende domeinwaarden
Collecties
Wijzigingen in de collecties ('zoekingangen')
Collecties-Leden
Wijzigingen in leden (objecttypen) van de collecties ('zoekingangen')
De rapportage toont in de kolom changeStatus of iets NEW, DELETED, MODIFIED of UNCHANGED is. De rijen worden ook respectievelijk groen, rood, geel en grijs gemarkeerd.
In het geval van MODIFIED wordt in feller geel extra aangegeven wat er dan specifiek aangepast is. In de kolomnaam is de postfix _old en _new toegevoegd om het verschil te kunnen zien.
Figuur 15 Snippet van delta rapportage -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
In dit voorbeeld is het volgende te zien:
Op rij 1 staat een attribuut waarvan alleen de naam is gewijzigd
Op rij 2 staat een ander attribuut waarvan een aanpassing is geweest in de definitie
Op rij 3 staat weer een ander attribuut waarvan een grootheid (quantitykind) is toegevoegd
Noot
De vorm van deze delta rapportages wordt voor alle CROW producten geadopteerd in de komende jaren.
7. Relaties met andere modellen
Dit onderdeel is niet normatief.
IMBOR heeft relaties met andere modellen. IMBOR bevindt zich in een speelveld waar veel raakvlakken zijn met andere sectorstandaarden en nationale registraties. Deze relaties kunnen grofweg onderverdeeld worden in 'sterke' relaties en 'zwakke' relaties.
7.1 Modellen met sterke relatie
IMBOR heeft eigenlijk twee soorten sterke relaties met andere standaarden. Voor de NEN2660-2:2022, NEN3610:2022, het MIM, TOOI en [QUDT] geldt dat IMBOR daadwerkelijk gebruik maakt van deze standaarden om het eigen model op te bouwen. De andere soort sterke relatie betreffen 'alignments'. Deze alignments worden ontwikkeld volgens de principes beschreven in de whitepaper Ontology Matching trough alignment and extension: a Best Practice. In de figuur hieronder wordt het huidige landschap betreffende alignements weergegeven.
Figuur 16 Het landschap van alignments vanuit IMBOR perspectief
Hieronder wordt per model de sterke relatie met IMBOR beschreven.
7.1.1 NEN2660-2
De NEN2660-2:2022 vormt de belangrijkste leidraad voor IMBOR door twee belangrijke dingen te specificeren:
Een praktisch toplevelmodel waarin genoeg semantiek aangegeven wordt om IMBOR in uit te drukken
Een taalbinding (en daarmee de keuze voor) de LinkedData W3C standaarden.
IMBOR maakt gebruik van deze twee keuzes en probeert daarom zo goed mogelijk aan te sluiten. In onderstaande figuur is ook te zien waar de NEN2660-2:2022 zich op focust. IMBOR neemt plaats in de "M1: Informatie model" laag.
Figuur 17 NEN2660-2 scope in grijs grijze vlakken (bron: TNO)
In de sectie IMBOR samenhang en hiërarchie wordt de keuze en de interpretatie van het praktisch toplevelmodel toegelicht in detail. In de sectie IMBOR in LinkedData wordt de toepassing van de LinkedData principes in detail toegelicht.
7.1.2 NEN3610
De NEN3610:2022 is na de NEN2660-2:2022 de belangrijkste leidraad voor IMBOR. Binnen de NEN2660-2:2022 is reeds een relatie tussen de NEN2660-2:2022 en de NEN3610:2022 aangegeven. Het gaat hier alleen om een afstemming tussen de begrippenkaders. IMBOR heeft deze afstemming overgenomen in de tophiërarchie. Binnen IMBOR wordt daarmee zo veel mogelijk aangesloten op de semantiek van de NEN3610:2022 (en daarmee de NEN2660-2:2022), maar wordt (nog) geen volledige sterke relatie met de rest van de norm NEN3610:2022 beschreven. Er wordt zodoende ook niet beweerd dat er volledige compatibiliteit met de NEN3610:2022 is (wel met de NEN2660-2:2022), maar dat puur de begrippenkaders voor nu met elkaar afgestemd zijn. De NEN3610:2022 hiërarchie wordt tevens gebruikt om de verdeling van attributen binnen IMBOR te regelen. Naast dit onderdeel worden ook worden de attributen identificatie en domein (als verplicht vanuit de NEN3610:2022) volledige toegepast in IMBOR als identificerende attributen.
Vanaf IMBOR2025 is ook het Temporele Model en het Netwerk Model wat in NEN3610:2022 beschreven wordt toegepast.
Het Metamodel Informatie Modellering (MIM) is een gemeenschappelijk vertrekpunt voor het maken van informatiemodellen. Het model bevat duidelijke afspraken over het vastleggen van gegevensspecificaties en biedt tegelijkertijd ruimte aan de verschillende niveaus van modellering. Het MIM is in 2020 uitgekomen en vormt een belangrijke leidraad voor IMBOR2022 ondanks dat er niet volledig aan alle facetten voldaan wordt. Twee belangrijke dingen passen we toe:
Het scheiden van soort informatiemodellen in niveaus. In deze context dus het onderscheid tussen het Begrippenkader en het Kernmodel.
De inhoudelijke modellering van modelconcepten en de metagegevens ervan. Door IMBOR uit te drukken in het MIM is een standaard manier van vastleggen en uitleg geborgd.
Het MIM gaat uit van een begrippenkader en een explicietere modellering van een informatiemodel. Binnen IMBOR is dit toegepast door alles één keer te definiëren in het IMBOR vocabulaire (die ook los te gebruiken is) en vervolgens relaties tussen objecten, tussen objecten en attributen, etc. te modelleren in een meer gedetailleerd logisch informatiemodel (kernmodel). Het kernmodel en het begrippenkader worden vervolgens gelinkt. Dit onderscheid is ook te zien in de fysieke datamodellen voor Access en LinkedData.
Het tweede hoofdprincipe van het MIM betreft het modelleren van het IMBOR binnen het metamodel dat het MIM specificeert. Dit is in detail te zien in de sectie IMBOR in modellen. Iedereen die het MIM kent kan zodoende lezen hoe het IMBOR gemodelleerd is. Tevens kunnen informatiemodellen die volgens het MIM worden gemodelleerd (bijvoorbeeld de SOR) makkelijker met elkaar vergeleken worden.
De RDF vertaling zoals gebruikt in het MIM wordt niet gebruikt. Mede omdat de MIM metaclasses binnen IMBOR de ontologie niet direct gebruikt worden, maar alleen in het metamodel. Er wordt bijvoorbeeld gesteld dat een imbor:Objecttype van de metaclass mim:Objecttype is, daardoor is de imbor:Boom (welke rdf:type is van imbor:Objecttype) wel (indirect) gerelateerd aan het MIM, maar geen voorkomen van.
7.1.4 TOOI
TOOI staat voor "Thesauri en Ontologieën voor Overheidsinformatie". TOOI is een kennismodel. Het doel van dit kennismodel is het definiëren van een gemeenschappelijke taal waarmee data en metadata uitgedrukt kunnen worden, zodat overheidsinformatie beter vindbaar, toegankelijk, interoperabel en herbruikbaar (FAIR) wordt. IMBOR adopteert TOOI volledig waar dit kan. IMBOR zal de TOOI gaan gebruiken voor het standaardiseren van de klassen Ministerie, Gemeente, Waterschap, Samenwerkingsorganisatie, Provincie en OverigeOverheidsorganisaties. De URI's voor deze klassen worden overgenomen, (bijvoorbeeld https://identifier.overheid.nl/tooi/def/ont/Gemeente voor Gemeente) maar niet de registers voor gemeenten, provincies, etc. IMBOR-gebruikers kunnen instanties van de voorgenoemde klassen instantiëren en hiervoor de registers aanspreken, binnen het 'Register gemeenten' staat bijvoorbeeld: https://identifier.overheid.nl/tooi/id/gemeente/gm0228 voor 'gemeente Ede' of https://identifier.overheid.nl/tooi/id/oorg/oorg10004 voor Rijkswaterstaat. Deze bijbehorende URIs spelen dus een identificerende rol in de IMBOR-modellering, maar moet een IMBOR-toepassing zelf ophalen.
7.1.5 QUDT
Vanuit de NEN2660-2 wordt de [QUDT] ontologie aangewezen als de plek om alles rondom eenheden en grootheden vandaan te halen. Door hier naar te refereren i.p.v. iets nieuws te verzinnen wordt inspanning en verwarring bespaard. IMBOR tracht hier dan ook volledig bij aan te sluiten voor zover mogelijk. Tot IMBOR2022 werd een eigen lijst van grootheden en eenheden bijgehouden, maar sinds IMBOR2025 wordt [QUDT] gebruikt.
7.1.6 GWSW
De relatie met GWSW is al lange tijd binnen IMBOR aanwezig. Riolering wordt als één van de belangrijke 'zuilen' binnen het beheer van de openbare ruimte gezien. Vandaar dat er ook al vele gesprekken tussen Stichting Rioned en CROW geweest zijn om deze twee sectorstandaarden zo nauw mogelijk op elkaar aan te laten sluiten. GWSW is vanaf het begin al gedistribueerd volgens de LinkedData principes. IMBOR is dit pas vanaf 2021, vandaar dat de relatie altijd relatief impliciet is geweest. Sinds 2021 is de NEN2660-2 beschikbaar, juist om de samenhang tussen zulke standaarden meer te stroomlijnen. Vanaf IMBOR2025 is IMBOR Riolering vervangen door IMBOR Stedelijk Water. Dit onderdeel wordt geheel ingevuld vanuit het GWSW.
Binnen GWSW worden objecttypen, attributen en relaties beschreven die gaan over zowel statische als dynamische gegevens. Met statische gegevens worden gegevens bedoeld die relatief weinig veranderen en vaak voor meer doeleinden nodig zijn dan alleen beheer van de riolering. Onder dynamische gegevens worden dan ook meer de gegevens verstaan die regelmatig worden verzameld voor het assetmanagement (denk aan inspecties, metingen en uitgevoerde onderhoudsmaatregelen) en gegevens die daaruit worden berekend (denk aan planjaren, verwachte maatregelen en kostenramingen). Deze gegevens worden vaak in beheersystemen vastgelegd die voor rioolbeheer gemaakt zijn. IMBOR heeft een focus op alleen de vaste gegevens van objecten in de openbare ruimte. Vandaar dat er de relatie tussen IMBOR en GWSW zich alleen toelegt op de objecttypen, relaties en attributen die vaste gegevens beschrijven. Het deel van GWSW dat vaste gegevens beschrijft wordt nu door Rioned aangeleverd aan IMBOR onder de noemer IMBOR Stedelijk Water. Zodoende is er sterke semantische relatie (alignment) tussen GWSW en IMBOR gerealiseerd.
De opname van GWSW in IMBOR is voor de vaste gegevens dus 100%. Voor het dynamische deel van GWSW blijft de GWSW ontologie nodig.
IMBOR begon aanvankelijk als een aanvulling op de BGT/IMGeo, specifiek gericht op de wereld van Beheer Openbare Ruimte (BOR). De modellering van IMBOR was hierop afgestemd. Sinds 2020, parallel aan de opkomst van Object Type Libraries (OTL’s) in de gebouwde omgeving, heeft IMBOR zich ontwikkeld tot een zelfstandig model. Het is geëvolueerd van een data- en informatiemodel naar een volledige ontologie. Hierdoor zijn IMGeo en IMBOR steeds verder uit elkaar gegroeid. IMBOR fungeert nu als een model waarin beheerders van openbare ruimte hun informatiebehoeften voor assetmanagement processen kunnen vastleggen. Dit staat los van wettelijke basisregistraties. De geografische component (GEO) van assets, zoals vastgelegd in IMBOR, is slechts één van de vele kenmerken van zo’n asset. Dankzij nieuwe inzichten uit standaarden zoals MIM, NEN2660 en NEN3610, is het model van IMBOR aanzienlijk veranderd, zowel qua structuur als inhoud. De BGT/IMGeo is daarentegen al langere tijd stabiel gebleven. Deze stabiliteit Dit heeft bijgedragen aan de toenemende afstand tussen beide modellen. Tegenwoordig wordt erkend dat de gedetailleerde vastlegging van assets in IMBOR kan dienen als basis voor de wettelijke registratie in BGT/IMGeo. Met andere woorden, de informatie van BGT/IMGeo kan worden gegenereerd uit de assetinformatie die in comform IMBOR is vastgelegd.
Ondanks de verschillen moeten en willen GEO- en BOR-afdelingen binnen veel organisaties informatie delen. Het gaat immers om dezelfde assets en in veel organisaties is de geometrie uit de BGT leidend. Om deze samenwerking te faciliteren, is een sterke IMBOR-IMGeo-alignment ontwikkeld. Deze alignment koppelt beide modellen op een moderne, machineleesbare manier. Hierdoor kunnen gegevens vanuit de bron gedeeld worden. Via het alignment kan een gebruiker assetinformatie bekijken door de "lens" van zowel IMBOR als BGT/IMGeo. CROW heeft deze alignment opgezet om alle relevante BGT/IMGeo-onderdelen binnen IMBOR te plaatsen. Het is belangrijk om te benadrukken dat het omgekeerde niet kan: omdat IMBOR zo uitgebreid is, kunnen niet alle IMBOR-onderdelen aan BGT/IMGeo worden gekoppeld.
De principes voor het opstellen van alignments zijn gedocumenteerd in de whitepaper Ontology Matching trough alignment and extension: a Best Practice. Alignments zijn eenvoudig als de modellen sterk op elkaar lijken. Naarmate de modellen verder uit elkaar liggen, worden alignments complexer. De IMBOR-IMGeo-alignment is momenteel het meest complexe alignment dat CROW beheert.
Noot: Praktijkrichtlijn 2020
In 2020 is door CROW en Geonovum samen een praktijkrichtlijn uitgebracht. IMBOR2020-08 sluit aan op versie van IMGeo, 2.1.1. In IMGeo 2.1.1 ontbreken bepaalde subclassificaties van objecten die wel in IMBOR voorkomen. Om IMBOR-classificaties zonder gegevensverlies te kunnen uitwisselen tussen Geo- en BOR-afdeling binnen een organisatie middels het StUF-Geo BOR berichtenverkeer is deze werkafspraak/praktijkrichtlijn ‘Uitbreiding domeinwaarden en attributen’ ontwikkeld. De relatie tussen IMBOR en IMGeo is met deze praktijkrichtlijn helemaal uitgewerkt in een mapping tabel. In de praktijk wordt deze helaas niet of nauwelijks toegepast. Binnen IMBOR2022 is daarom op een iets hoger niveau een relatief sterke semantische relatie gelegd naar IMGeo2.2. Vanaf IMBOR2025 geldt deze praktijkrichtlijn niet meer.
De KOR 2023 (Kwaliteitscatalogus Openbare Ruimte) bevat zo'n 200 beeldmeetlatten voor het meten van de kwaliteit van de buitenruimte. Dit is een apart product van CROW, maar heeft een sterkte relatie met IMBOR. De KOR2023 heeft een officiële alignment met IMBOR. IMBOR en de KOR kunnen, met gebruikmaking van deze alignment, zodoende samen met elkaar gebruikt worden. De KOR wordt tevens als LinkedData gedistribueerd.
Noot
De KOR en IMBOR alignment moet nog officieel worden uitgebracht.
7.1.9 BOR-MELD
BOR-MELD is een CROW-standaard voor het vastleggen van meldingen over de openbare ruimte. De systematiek beschrijft welke informatie van een melding wordt vastgelegd, zowel het door de burger of bedrijf gemelde probleem (de ‘voorkant’ van de melding) als de achterliggende oorzaak en genomen actie (de ‘achterkant’ van de melding). De relatie met IMBOR is nagenoeg gelijk aan die van KOR. De uniforme categorisering van typen meldingen over de openbare ruimte is altijd gerelateerd aan één of meerdere IMBOR-objecttypen. Ofwel, elk objecttype binnen BOR-MELD kent een alignment naar een objecttype van IMBOR. IMBOR en BOR-MELD kunnen zodoende samen met elkaar gebruikt worden.
Noot
De BOR-MELD en IMBOR alignment moet nog officieel worden uitgebracht.
7.1.10 Wegbeheersystematiek
De Wegbeheersystematiek 2019 is een CROW publicatie. De relatie tussen IMBOR2020-08 en de Wegbeheersystematiek 2019 is uitvoerig beschreven. Uiteindelijk is de bedoeling dat de terminologie van IMBOR volledig wordt overgenomen in de Wegbeheersystematiek middels een alignment. In 2025 wordt verkend of de Wegbeheersystematiek ook gedistribueerd kan worden als informatiemodel in LinkedData. Wanneer dit gebeurt zal de expliciete sterke semantische relatie onderdeel zijn van de publicatie.
Noot
De Wegbeheersystematiek en IMBOR alignment moet nog officieel worden uitgebracht.
7.1.11 GWSL
GWSL moet het GWSW voor openbare verlichting worden, gebaseerd op het IMBOR framework (en dus de NEN2660-2:2022). GWSL bevat objecttypen, relaties en attributen die gaan over zowel statische als dynamische gegevens. Net zoals bij GWSW en IMWV bevat IMBOR zodoende alleen het deel betreffende de statische gegevens van GWSL. In de praktijk is de Zoekingang 'Verlichting' binnen IMBOR dus 1-op-1 gelijk aan het deel van GWSL dat over de vaste (statische) gegevens gaat (overigens is dat ook het enige GWSL wat tot en met 2021 gerealiseerd is). IMBOR en GWSL zijn beiden volledig op de NEN2660-2:2022 gebaseerd en wanneer GWSL in een eerste versie gereed is zal het beheer ook door CROW gedaan worden.
7.2 Andere gerelateerde modellen
Naast deze sterke relaties heeft IMBOR raakvlakken/relaties met veel meer modellen. Er is getracht om de relatie die er vanuit IMBOR erkend wordt zo goed mogelijk aan te geven. Dit omdat de gebruiker van IMBOR dan zelf deze kennis kan beoordelen, eventueel gebruiken of verbeteren. Hieronder worden de relatie met andere standaarden beschreven. Van een aantal standaarden zijn ook binnen de IMBOR distributies gegevens overgenomen of zijn de relaties expliciet (met zwakke semantiek) aangegeven als 'externe link lijsten'. Dit wordt dan ook vermeld.
Vanwege de positie van IMBOR worden er veel relaties naar andere standaarden gelegd. Binnen IMBOR zijn gegevens soms 'van toepassing verklaard' in IMBOR (gekopieerd) om de relatie tussen de twee te kunnen aangeven. Dit is wat CROW betreft een tijdelijke situatie. Wanneer meer standaarden in LinkedData uitgedrukt worden EN er standaarden zijn hoe modellen op elkaar 'gemapt' kunnen worden zullen we sterke semantische relaties gaan leggen. Dan worden de gekopieerde gegevens ook daadwerkelijk bij de bron onderhouden en refereert IMBOR er alleen maar naar.
7.2.1 NEN2767-4
De NEN2767 en IMBOR hebben een lange historie. Veel gebruikers van IMBOR gebruiken ook de NEN2767-4 Conditiemeting infrastructuur. Er is in 2020 ook besloten dat de afstemming tussen de twee duidelijker gemaakt moet worden. Hiervoor is een gezamenlijk project gestart door de NEN en CROW. Hier zijn nog geen tastbare resultaten van. Tot nu toe is daarom in IMBOR een zwakke semantische relatie gelegd vanuit het IMBOR perspectief. Voor de IMBOR objecttypen waar een equivalent erkend wordt in de NEN2767-4 is dit aangegeven. De relatie tussen de IMBOR concepten en de NEN concepten is niet meer dan een 'bekijk ook' relatie die door CROW vanuit het IMBOR perspectief uitgewerkt is. Deze vastlegging is gedaan zodat bekeken kan worden hoe de NEN2767-4 is opgenomen in IMBOR en geeft een aanzet voor een vertaling tussen de twee standaarden. Deze aanzet kan door een softwareleverancier of organisatie worden overgenomen of uitgewerkt.
Noot
De NEN2767-4 en IMBOR alignment moet nog officieel worden uitgebracht.
7.2.2 NLCS
De Nederlandse CAD standaard (NLCS) is de CAD-standaard van de Nederlandse GWW-sector. Deze open standaard bevat afspraken voor het omgaan met metadata, digitaal tekenen, het uiterlijk van de tekening en vooral de bestandsopbouw van tekenwerk. IMBOR heeft vooralsnog geen directe relatie met de NLCS. De IMBOR objecten bevatten doorgaans geometrie. Deze geometrie kan ook uitgedrukt worden in de NLCS. Dit is echter geen onderdeel van IMBOR.
In 2025 wordt binnen het DOOR-programma een verkenning gedaan om de relatie tussen IMBOR en NLCS sterker te maken.
De SOR was in IMBOR 2022 aanwezig, maar is inmiddels niet verder ontwikkeld. In IMBOR2025 heeft deze geen plek meer.
7.2.4 IMKL
Het informatiemodel Kabels en Leidingen (IMKL) vormt een gemeenschappelijk begrippenkader voor gegevensuitwisseling voor werkzaamheden aan Kabels en Leidingen en gerelateerd grondverzet. Het IMKL is gebaseerd op NEN3610 en daarmee onderdeel van de NEN3610 familie. De relatie tussen IMKL en IMBOR is eenvoudig, maar noodzakelijk. Binnen IMBOR wordt het InformatieObject 'IMKL-informatie' onderscheiden. Een aantal Klasse en daarmee Objecttypen hebben relaties met dit InformatieObject. Hiermee worden diverse attributen die binnen IMKL noodzakelijk zijn geregistreerd binnen IMBOR. Op termijn kan er een sterke semantische relatie (mapping) tussen het IMKL en IMBOR gerealiseerd worden. De huidige vastlegging is gedaan zodat bekeken kan worden hoe IMKL informatie is opgenomen in IMBOR en geeft een aanzet voor een vertaling tussen de twee. Deze aanzet kan door een softwareleverancier of organisatie worden overgenomen of uitgewerkt.
7.2.5 IMWV
Het IMWV is een afsprakenstelsel dat beschrijft hoe naast objectgerichte gegevens ook verkeersgegevens voor verkeerskundige vraagstukken op uniforme wijze kunnen worden vastgelegd. Het bevat een beschrijving van de fysieke objecten en statische gegevens die aan de fysieke objecten gekoppeld kunnen worden. Inhoudelijk is er dan ook een sterke relatie met IMBOR en het is zelfs ontwikkeld binnen de beheeromgeving van het IMBOR. Het IMWV bevat net als in het IMBOR geen beschrijvingen/afspraken van dynamische gegevens (zoals realtime verkeersgegevens, wachttijden, openingstijden van bruggen, verkeersongevallen, etc.) of gegevensbehoefte van verkeerskundige vraagstukken ten aanzien van bijvoorbeeld parkeren en verkeersmanagement.
Vanaf IMBOR2025 is het IMWV buiten IMBOR geplaatst. Op termijn wordt bekeken wat er met IMWV en de relatie tot IMBOR gedaan moet worden.
De Aquo-standaard (Aquo) is de Nederlandse standaard voor het uitwisselen van gegevens binnen de watersector, beheert door het Informatiehuis Water. Een onderdeel is het Informatiemodel Water (IMWA). IMBOR heeft geen directe relatie met Aquo (of het IMWA). Wel is de content van IMBOR geïnspireerd door de begrippenlijst (Aquo-lex) van Aquo. De metastructuur van IMBOR en Aquo zijn gelijk, want beiden zijn gebaseerd op het MIM.
7.2.7 BAG
De Basisregistratie Adressen en Gebouwen (BAG) bevat gegevens van alle adressen en gebouwen in Nederland, zoals bouwjaar, oppervlakte, gebruiksdoel en locatie op de kaart. De BAG is onderdeel van het overheidsstelsel van basisregistraties. IMBOR heeft geen directe relatie met de BAG. Wel is het BAG onderdeel 'Pand', direct overgenomen als een in IMBOR te gebruiken Objecttype. Hiermee is binnen een organisatie eventueel een relatie te realiseren. De metastructuur van IMBOR en de BAG zijn gelijk, want beiden zijn gebaseerd op het MIM.
7.2.8 BRK/IMKAD
Het Informatiemodel Kadaster (IMKAD) is de basis voor de uitwisseling van Kadaster-gegevens. Het geeft inzicht in de kenmerken van de gegevens uit de Basisregistratie Kadaster (BRK) en de onderlinge samenhang ervan. IMBOR heeft geen directe relatie met BRK/IMKAD. Er zijn relaties te herkennen tussen perceelinformatie en beheerinformatie. Deze zijn echter geen onderdeel van het IMBOR. De metastructuur van IMBOR en IMKAD zijn gelijk, want beiden zijn gebaseerd op het MIM.
7.2.9 BRO
De Basisregistratie Ondergrond (BRO) is een centrale registratie met publieke gegevens over de Nederlandse ondergrond. Het is onderdeel van het overheidsstelsel van basisregistraties. IMBOR heeft geen directie relatie met de BRO. Er zijn relaties te herkennen tussen de BRO 'Grondwatermonintoringsput' en de IMBOR 'Peilbuis'. Deze zijn echter geen onderdeel van het IMBOR. De metastructuur van IMBOR en BRO zijn gelijk, want beiden zijn gebaseerd op het MIM.
7.2.10 IMGeluid
Het informatiemodel Geluid (IMGeluid) beschrijft de semantiek van digitale bestanden voor de Centrale Voorziening Geluidsgegevens. IMBOR heeft geen directe relatie met het IMGeluid. Er zijn echter wel raakvlakken te benoemen die op termijn in lijn met elkaar gebracht moeten worden. Het gaat hierbij met name om de taxonomie van Asfaltverharding en de materie van het wegdek. De lijst zoals beschreven bij IMGeluid zou kunnen worden afstemt op gebruik binnen IMBOR. De metastructuur van IMBOR en IMGeluid zijn gelijk, want beiden zijn gebaseerd op het MIM.
7.2.11 IMNa
Het Informatiemodel Natuur (IMNa) is de standaard voor uniforme digitale uitwisseling van natuurgegevens. IMBOR heeft geen directie relatie met het IMNa. Er zijn relaties te herkennen tussen de indeling van de terreindelen in het buitengebied. Deze zijn echter geen onderdeel van het IMBOR.
7.2.12 NWB
Het Nationaal Wegenbestand (NWB) is een open databestand met alle openbare wegen in Nederland die een straatnaam of wegnummer hebben en in beheer zijn bij het Rijk, provincies, gemeenten en waterschappen. IMBOR heeft geen directe relatie met het NWB. Er zijn relaties te herkennen tussen de de NWB 'Wegas' en de IMBOR 'Wegas'. Deze zijn echter geen onderdeel van het IMBOR.
7.2.13 WeginfraNL
WeginfraNL is een voortvloeisel uit o.a. de PIM-OTL (Pavement Information Modelling). Het uiteindelijke doel was om PIM-OTL door te ontwikkelen tot een nationale referentieontologie voor het domein weginfrastructuur, nu aangeduid als de ontologie
voor WeginfraNL. Dit is in opdracht gedaan van het 'Transitiepad Duurzame Wegverharding'. De eerste fase van de ontologie voor WeginfraNL omvat concepten, relaties en attributen voor het registreren, structureren en delen van bouw- en assetmanagementgegevens (As Built-fase) tussen stakeholders (opdrachtgevers en aannemers) in de weginfrastructuur en wegenbouw. WeginfraNL en IMBOR hebben nog geen directe relatie. Maar voor 2025 wordt verwacht dat een officiële alignment tussen de twee wordt uitgebracht.
7.2.14 WIBON
De Wet informatie-uitwisseling bovengrondse en ondergrondse netten en netwerken (WIBON). Deze wet schrijft de wijze van informatie-uitwisseling tussen netbeheerders en grondroerders voor. IMBOR heeft geen directe relatie met WIBON. Gegevens uit IMBOR kunnen echter wel gebruikt worden om te voorzien in de wettelijke eisen voor bijvoorbeeld het aanleveren van netinformatie. Tevens leunt WIBON sterk op het IMKL.
7.3 Externe link lijsten
Op de GitHub pagina van IMBOR worden 'externe link lijsten` geplaatst. Dit betreffen lijsten met linkjes naar concepten uit andere ontologieën (zie definitie). Dit zijn informele handreikingen vanuit IMBOR die geen status hebben. Deze lijsten kunnen gebruikt worden als startpunt om per project of implementatie een mapping te maken vanuit IMBOR naar de andere ontologie. Tegenover deze informele handreikingen staan officiële alignments. Dit betreffen sterke semantische relaties die beheert worden en waaruit automatische kennis kan worden afgeleid. Deze worden anders gedistribueerd.
De lijsten zijn op deze GitHub pagina te downloaden.
Zie ook gerelateerde issue(s) op GitHub:
👇
Issue 1350: Mapping-tabellen uit IMBOR worden als handvatten naast de Access-database aangeboden. Impact 2 | Middel
8. MIM addendum
Dit onderdeel is niet normatief.
Het MIM biedt een optie aan om een model in LinkedData uit te drukken. Het MIM uitgedrukt in LD houdt onder ander een ontologisch metamodel in. Dit betekent dat er voor elk van de modelelementen van het MIM een klasse en/of eigenschap gedefinieerd is in termen van [rdf11-primer], [rdf-schema], [owl2-overview] en [shacl]. De manier om dit te doen wordt beschreven in MIM - Metamodel in LinkedData. Middels deze specificatie is IMBOR zo ver mogelijk in MIM uitgedrukt.
Dit is gedaan voor imbor:Klasse, imbor:Attribuut, imbor:SemantischeRelatie, imbor:EnumeratieType en imbor:Domeinwaarde. De onderlinge samenhang wordt niet in dit addendum genoemd omdat deze uit de IMBOR ontologie gehaald kan worden. De SHACL taalbinding van de NEN2660-2:2022 lijkt op dezelfde manier als MIM dit doet. De enige toevoeging daarom is een verwijzing vanuit de sh:PropertyShape naar de rdf:Property, middels mim:equivalent. Dit is dubbel met sh:path, maar hierdoor wordt wel expliciet aangegeven dat MIM de relatie tussen het Objecttype en de Attribuutsoort toekent aan het Attribuutsoort. Verder zijn zo veel mogelijk (verplichte) MIM metagegevens ingevuld.
De dataset is beschikbaar in een aparte graaf die, wanneer gewenst, bij de IMBOR ontologie kan worden ingeladen.
9. Geometrie
Dit onderdeel is niet normatief.
IMBOR is primair bedoeld om te standaardiseren in type objecten en hun attributen (informatiebehoefte) betreffende vaste gegevens. De geometrische representatie wordt vaak ook als een vast gegeven gezien. De representatie van een object is echter één van de gegevens die geregistreerd wordt. Vanuit de GIS systemen wordt het echter herkend als het gegeven van het object. Er zijn echter meerdere (geometrische)representaties mogelijk. Per toepassing zal de meest geschikte representatie worden gekozen en dus gaat IMBOR daar geen bindende uitspraken over doen. Temeer omdat IMBOR vaak in combinatie met de landelijke registratie BGT/IMGeo gebruikt wordt en die al uitweidt over de geometrische vastlegging.
Er is wel een addendum beschikbaar binnen IMBOR waarin suggesties worden gegeven voor geometrische vastlegging. Het Geometrie addendum geeft aan welke soort geometrische vastlegging de voorkeur heeft en welke er meer mogelijk zijn. Indien een organisatie zich committeert aan het Geometrie addendum, dan betekent dit dat de geometrische vastlegging zoals voorgesteld wordt toegepast in die context. In Access is het addendum verwerkt middels de Klasse GeometrischeEntiteit (en zijn subklassen) en de relatie heeft begrenzing. Hetzelfde geldt voor de LinkedData versie, echter staat de informatie daar in een aparte graaf.
In het addendum wordt per Objecttype minimaal één relatie naar een geometrie klasse uit Simple Features met de multipliciteit 1-1 meegegeven. Dit kan op Objecttype niveau geregistreerd worden of op de Klasse erboven (wanneer het voor allemaal geldt). Vervolgens worden eventueel meerdere relaties naar andere geometrie klassen meegegeven met een multipliciteit 0-1. Dit moet geïnterpreteerd worden als: "Wanneer het geometrie addendum van IMBOR van toepassing verklaard wordt, dan moet er minimaal één
geometrie vastgelegd worden middels van het type dat de 1-1 multipliciteit heeft. Er mag vervolgens ook geometrie aangeleverd worden volgens de andere gespecificeerde vormen van geometrie."
10. OAGBD
Dit onderdeel is niet normatief.
OAGBD is een addendum welke in IMBOR zit vanaf 2021. De eerste versie is de resultante van een onderzoek wat de gemeenten Almelo en Utrecht hebben gedaan. Het onderzoek heeft gekeken naar informatieverlies tijdens de 'levensfases' van een object. In dit geval is de opeenvolging van objectlevensfases:
>> Ontwerp >> Aanleg >> Geo >> Beheer
De letters staan dan ook voor:
O = Ontwerp
A = Aanleg
G = Geovoorziening
B = Beheer
D = Dynamisch gegeven
Binnen het onderzoek is bij elke combinatie van klasse en attribuut in IMBOR2022 aangegeven in welke levensfase van het object de informatie doorgaans bekend is. Zo is inzichtelijk gemaakt dat veel informatie reeds beschikbaar is in vroege fasen van het object en dat er getracht kan worden deze informatie mee te nemen naar volgende fasen.
Binnen IMBOR in Access is de tabel met klassen en attributen hiervoor uitgebreid met een extra veld: OAGBD. Binnen de LinkedData versie is de beschikbaar als een aparte graaf.
De bovenstaande conceptualisering van objectlevensfases is ontwikkeld voor de onderverdeling van IMBOR-attributen. Binnen de NEN2660-2:2022 wordt door het begrip ‘levenscyclus’ onderscheid gemaakt tussen geplande en gerealiseerde entiteiten. De wisselwerking tussen gepland en gerealiseerd heeft de volgende relatie met OAGBD. In het lineaire doorlopen van OAGBD komt het object in O overeen met een geplande entiteit. Vanaf A bestaat het object in de werkelijkheid en is het als zodanig een gerealiseerde entiteit. Echter, mocht de opeenvolging van levensfases cyclisch worden, dat wil zeggen, B gaat over naar D, bijvoorbeeld wanneer een object wordt herzien, wordt aangepast, wordt verplaatst etc., dan gaat een gerealiseerde entiteit over naar een geplande entiteit, om in A wederom een gerealiseerde entiteit te worden.
OAGBD kan dus gezien worden als een situatiespecifieke verbijzondering van de algemene wisselwerking tussen geplande en gerealiseerde entiteiten uit NEN2660-2:2022.
11. Licenties
IMBOR is sinds 2022 een open standaard die door CROW kosteloos beschikbaar wordt gesteld. De vorige versies van het IMBOR waren alleen toegankelijk met een betaald abonnement op de CROW-kennismodule IMBOR en IMWV. CROW beheert het IMBOR volgens de richtlijnen van het Forum voor Standaardisatie (BOMOS). Voorwaarde om het IMBOR ook in de toekomst kosteloos te kunnen publiceren is dat CROW voldoende structurele financiering krijgt voor een zorgvuldig beheer van het IMBOR.
Meer informatie over de voorwaarden waaronder het IMBOR als open standaard wordt gepubliceerd is te vinden in de specifieke secties hieronder en in het Beheerplan IMBOR.
Component
Licentie
Onderdelen
IMBOR gegevens
CC BY 4.0
Alle data in de gehele IMBOR Ontologie (IMBOR Vocabulaire, IMBOR Kern, IMBOR Domeinwaarde, etc.)
