IMBOR Technische documentatie

Samenvatting

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 (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 aansluiting met MIM is nog niet goed genoeg en is nog in ontwikkeling. De NEN2660-2 is wel 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 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 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.

Datum	Versie	Toelichting
16-04-2021	0.1	Initiële versie Respec publicatie n.a.v. major release 'Herstructurering IMBOR 2022'
30-06-2021	0.2	Update van diagrammen en LD informatie
23-07-2021	0.3	Toevoeging Top hiërarchie + release concept AccessDB
20-08-2021	0.4	Uitleg over referentiemodellen
01-09-2021	0.5	Aanpassingen tbv laatste versie AccessDB + onderscheid informatieve delen
15-10-2021	0.6	Laatste aanpassingen t.b.v. consultatie versie IMBOR2022.c02
26-10-2021	0.7	Consultatie versie (typo's)
08-11-2021	0.8	Aanpassing van IMBOR2021 naar IMBOR2022
24-12-2021	0.9	Eerste aanpassingen na consultatie ronde
22-02-2022	0.91	Transfer naar /imbor/techdoc/
10-03-2022	1.0	IMBOR 2022 release
25-03-2022	1.1	IMBOR 2022.01 release en licentie informatie
13-05-2022	1.11	Update naar nieuwe ReSpec template CROW
22-03-2023	1.12	Update OAGDB en redacteurs

Het IMBOR uniformeert begrippen voor het vakgebied ‘beheer openbare ruimte’. Het IMBOR heeft relaties met Basisregistratie Grootschalige Topografie (BGT) en op het Informatiemodel Geografie (IMGeo). Zie ook over IMBOR.

In 2021 is besloten om IMBOR te herzien n.a.v. een aantal ontwikkelingen:

IMBOR wordt in beheer genomen, i.p.v. in ontwikkeling te zijn
Het beschikbaar komen van de NEN2660-2
Het beschikbaar komen van de herziende NEN3610
De vraag om LinkedData versies van sectorstandaarden
De bredere adoptie van het MIM
De adaptatie van het werken met ontologieën (vaak onder de noemer 'OTL's)
De vraag om afstemming tussen standaarden (SOR, IMBOR-NEN2767-4, GWSW, GWSL en CB-NL2.0)
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.

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. Hiermee zal IMBOR2022 beschikbaar komen in zowel Access als in LinkedData. Het beheer van IMBOR wordt vooralsnog in Access gedaan, maar dit zal in de loop van 2021/2022 nader bekeken worden.

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.

IMBOR Normatief & Informatief — Figuur 1 IMBOR Normatief & Informatieve onderdelen

Noot

In de sectie "Referenties" onder aan deze ReSpec pagina worden W3C referenties genoemd. Deze staan daar als 'informatieve referenties'. Dit is een ReSpec 'bug'. Alles wat daar vermeld staat is onderdeel van het normatieve gedeelte van IMBOR.

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 is alle informatie die nodig is 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.

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 is er een duidelijke lijn hoe informatie rondom de gebouwde omgeving kan worden vastgelegd en gedeeld. In het kader van de NEN2660-2 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, zoals 'DiscreetObject' en 'RuimtelijkObject'. Zodoende kan er veel dynamische 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'.

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. Zodat zij hun software kunnen gaan 'vullen' met ontologiën zoals IMBOR en andere modellen die op de NEN2660-2 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.

Met de modellering van IMBOR op basis van de NEN2660-2 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:

hun ontologie te baseren op de NEN2660-2 en de NEN3610,
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.

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.

Tot en met IMBOR2020-08 zat het metamodel van IMBOR in de content verwerkt. Vanaf 2021 wordt er expliciet gemaakt hoe IMBOR gemodelleerd is. Hierbij wordt gebruik gemaakt van de principes die het metamodel voor informatiemodellering (MIM) definieert. Hier worden vier 'lagen' van modellen gedefinieerd:

Niveau 1: Model van begrippen
Niveau 2: Conceptueel informatiemodel
Niveau 3: Logisch informatiemodel
Niveau 4: Fysiek datamodel

IMBOR acteert in niveau 1 en niveau 3. Niveau 2 wordt voor IMBOR over geslagen en bestaat alleen impliciet. Niveau 4 beschrijft IMBOR in het kader van de distributie. Dit is dus geen uitleg hoe IMBOR geïmplementeerd moet worden in een database. Maar een uitleg hoe de onderdelen van IMBOR uitgedrukt worden in de MS Access distributie en de LinkedData distributie.

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 betreft het 'metamodel' van de IMBOR Vocabulair. Dit is gebaseerd op een SKOS model (de content wordt later dan ook in SKOS uitgedrukt). Zowel het MIM als de NEN2660-2 bevelen dit aan. Onderstaande figuur is niet het model zelf, maar het (conceptuele) metamodel hiervan.

De IMBOR Vocabulaire is te verkennen op:

begrippen.crow.nl/IMBOR

Figuur 2 IMBOR Vocabulair 'Metamodel' -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie

Binnen IMBOR gaan we uit van bestaande vocabulaires, te weten de NEN2660-2, de NEN3610 en het MIM. Binnen het logische informatiemodel wordt 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. Hiermee sluiten we aan bij de ordeningsregels en uiteindelijk ook de taalbinding die in de NEN2660-2 beschreven worden. Hiermee is het "NEN2660-2 praktisch toplevelmodel" ook de top van de IMBOR. Het logische informatiemodel beschrijft alle 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, echter de NEN2660-2 blijft het voornaamste uitgangspunt.

Onderstaande figuur is niet het logische informatiemodel zelf, maar het metamodel hiervan. Dit metamodel is specifieke voor IMBOR en staat dus 'naast' het MIM. De opzet hiervan wijkt af van de NEN2660-2 (en ook van MIM). In de LinkedData versie wordt er middels een ETL-pipeline gezorgd dat het er correct volgens de NEN2660-2 taalbinding uit komt. Het IMBOR 'Metamodel' is nodig om dat vanuit "legacy" zaken (zoals het onderscheidt tussen Klasse en Objecttype en het feit dat er bijvoorbeeld een Eenheid aan een combinatie van Attribuut en Klasse hangt) nu eenmaal zo IMBOR zaten/zitten. Kortom, de (LinkedData) eindgebruiker zal niks te maken hebben met dat metamodel, maar volgt volledig de NEN2660-2.

Figuur 3 IMBOR Kern 'Metamodel' -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie

Semantiek t.o.v. MIM

Het MIM wordt op meerdere plekken aangehaald binnen IMBOR. Omdat IMBOR in eerste instantie de NEN2660-2 volgt is de semantiek tussen IMBOR en het MIM soms wat verwarrend. 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. De Attribuutsoort werd in IMBOR2020-08 gebruikt om aan te geven 'wat voor een soort attribuut het betrof. Dit is in IMBOR2022 vervangen door TypeAttribuut.

In MIM wordt met het Datatype aangegeven wat de structuur is waaraan een waarde, oftewel de data zelf, aan moet voldoen. In IMBOR2020-08 zat dit vermengd in de Attribuutsoort en het Gegevenstype. Dit is anders aangepakt in IMBOR2022. Gegevenstype is dan ook vervangen door Datatype.

Multipliciteit en Kardinaliteit zijn onderwerp van discussie in verschillende gremia. Ook het MIM is hier niet eenduidige in. Binnen IMBOR2022 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. Source

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.

Omdat IMBOR nu nog gedistribueerd wordt in een MS Access database en LinkedData is het fysieke datamodel een beschrijving van hoe de IMBOR onderdelen uitgedrukt worden. Dit betekent geenszins dat IMBOR ook dit fysieke datamodel voorschrijft bij implementatie. Het geeft wel een goed inzicht in hoe de relaties lopen en welke verschillende (normatieve) onderdelen IMBOR kent. Het model wordt nader beschreven in de volgende secties.

Het fysieke datamodel in LinkedData kan gelijk worden gesteld aan de 'serialisatie'. In het geval van IMBOR is dit [turtle].

De IMBOR Ontologie is te verkennen in de 'CROW | Ontologie verkenner' op:

docs.crow.nl/onto-verkenner/imbor

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 IMBOR2022 gekozen is om gebruik te maken van een polyhiërarchie gebaseerd op respectievelijk de NEN2660-2, de NEN3610, de SOR, het IMGeo2.2, het IMKL2.0 en het IMWV.

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 en de NEN3610 komen uit de NEN2660-2 documentatie zelf. En de relaties tussen de NEN3610 en de SOR komen uit de documentatie van de SOR 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 zeer weinig IMBOR specifieke (hoofd)klassen geïntroduceerd hoeven te worden omdat bijna alles al voldoende gedefinieerd wordt. Alle (ongeveer 500) 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.

IMBOR 2022 Top hiërarchie — Figuur 4
IMBOR Top van de ontologie -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie

Al deze concepten kennen definities. Omdat er geen semantische discussies gevoerd kunnen worden zonder dat de definities van de concepten bekend zijn worden ze hieronder uiteengezet. (Dit betreft een extract uit de SVG/XML)

Aanschaf-informatie: Verzameling van gegevens die te maken hebben met de monetaire waarde van een object.
Activiteit: Iets dat mogelijk of daadwerkelijke gebeurt in ruimte en tijd.
Apparaat: Een (vaak compact) mechanisch of elektronisch ding dat is gemaakt of toegepast voor een specifieke toepassing en doorgaans in één behuizing gevat is.
Bak: Object met een permanent karakter dat dient om iets in te bergen of te verzamelen.
Begroeiing: Planten die op natuurlijke wijze zijn ontstaan of door mensen zijn aangeplant.
Beheerd object: Object welke door een organisatie beheerd wordt in de beheerfase van zijn levenscyclus.
Bereikbaarheid-informatie: Registratie van gegevens die betrekking hebben op de bereikbaarheid van het object.
Bodem: Bovenste begrenzing van het aardoppervlak, exclusief oppervlaktewater
Bord: Een paneel waarop informatie wordt afgebeeld.
Bordopschrift: Informatieobject voor het vastleggen van de informatie op een bord.
Bouwwerk: Gegevens die specifiek zijn voor een met de aarde verbonden duurzaam bouwwerk, dat niet valt onder de definities van een pand of kunstwerk.
Certificering-informatie: De verzameling van gegevens die gebruikt kan worden voor de wijze waarop een object gecertificeerd is.
Complex: Functionele ruimte die een verzameling van één of meer gebouwen, constructies, verharding, water en begroeiing betreft die samen een eenheid vormen.
Constructie: Gebouwd object dat direct of indirect met de grond is verbonden en bedoeld is om ter plaatse te functioneren.
Constructielaag: Laagopbouw onder begroeiing of verharding.
Constructieonderdeel: Constructieonderdeel, onderdeel van een objecttype die als zelfstandig objecttype beheerd kan worden.
DiscreetObject: Reëel object dat bestaat uit een aaneengesloten hoeveelheid vormvaste materie, primair bijeengehouden door interne krachten (zwaartekracht of elektromagnetische kracht)
Document: Informatieobject voor het registreren en koppelen van documenten aan objecttypes.
Ecologische zone: Functionele ruimte speciaal voor het registreren van functionele aandachts- en onderzoeksgebieden.
Flora en fauna-informatie: Verzameling van gegevens die te maken hebben met het beheer van Flora en Fauna.
Functie: Een activiteit die het externe gedrag beschrijft van het object die de activiteit uitvoert.
Functioneel gebouwobject: Een gebouw gerelateerde ruimte met een specifieke functie.
Functionele ruimte: Ruimte met een specifieke functie.
Functionele zonering: Een gebied met een specifieke functie.
FunctioneleEntiteit: Entiteit waarbij het gaat om het externe gedrag waarbij de uitvoer bijdraagt aan doelstellingen van belanghebbenden geïmplementeerd/gespeeld door een of meer technische entiteiten.
FysiekObject: Iets dat mogelijk of daadwerkelijk bestaat in ruimte en tijd, waarneembaar door de zintuigen.
GM*: GML features
Gebiedsindeling: Object welke gegevens kent betreffende de vastlegging binnen registratieve ruimten.
Gebouw: Overdekte en geheel of gedeeltelijk met wanden omsloten constructief zelfstandige eenheid bedoeld voor het in een afgeschermde omgeving onderbrengen van mensen, dieren of voorwerpen of voor de productie van goederen.
Gebouwcomponent: Component aan de buitenzijde van een gebouw, die het aanzicht van het gebouw mede bepaalt
Gebruikszone oppervlaktewater: Begrensd oppervlaktewatergebied dat een bepaald gebruik kent
Geo-object: Een fenomeen in de werkelijkheid, dat direct of indirect is geassocieerd met een locatie relatief ten opzichte van de aarde.
Geografische ruimte: Ruimte die bekend staat onder een vanuit de historie of in de volksmond bekende benaming of een fysisch-geografische samenhang kent.
GeometrischeRepresentatie: Een ruimtelijke representatie van een object.
Groenobject: Kleinste functioneel onafhankelijk stukje van een begroeid terrein dat er binnen het objecttype Begroeiing van NEN 3610 wordt onderscheiden, met aaneengesloten vegetatie.
Holle leiding: Holle leiding voor het doorstromen van gassen, vloeistoffen of capsules, bestemd om hetzij gas, een vloeistof of capsules te transporteren, hetzij een vloeistof als intermediair te gebruiken voor het transport van warmte of een opgeloste of verpulverde stof.
Hulplijn: Lijnvormig element wat vaak gebruik wordt in combinatie met andere objecttypen.
IMKLBasis object: Abstract data object dat de basis attributen bevat van de IMKL extensie.
InformatieObject: Thing that is a whole of information on itself and has an own identit
Installatie-informatie: Gegevens die betrekking hebben op de installatie van een object.
Installatie: Constructie die een technisch samenhangend systeem betreft dat een bepaald doel dient
Inwinning-informatie: Informatieobject voor het vastleggen van informatie m.b.t. de inwinning van een objecttype.
Resultaat verkeerstelling: Het vastleggen van het resultaat van alle verkeerstellingen op een wegas per jaar.
Juridische ruimte: Ruimte waar een juridisch instrument beleid of regelgeving toepast.
Kabel: Een geheel van geleiders welke voorzien zijn van één ommanteling en bestemd is voor transport van energie of data.
Kabelgeul: Ruimtebeslag dat door een gemeenschappelijk tracé van één of meer kabels, buizen, HDPE- en/of mantelbuizen - die toebehoren aan één netwerkbeheerder - wordt gevormd.
Kast: Constructie met een permanent karakter dat dient om iets in te bergen en te beschermen
Kering: Voorziening met een kerende functie
Kunstwerk: Civieltechnisch werk voor de infrastructuur van wegen, water, spoorbanen, waterkeringen en/of leidingen.
Kunstwerkdeel: Onderdeel van een civieltechnisch werk voor de infrastructuur van wegen, water, spoorbanen, waterkeringen en/of leidingen
Leiding: Een geheel van geleiders of ruimte welke voorzien zijn van één ommanteling en bestemd is voor transport van materie, data of energie.
Luchtvaartzone: Functionele ruimte die in gebruik is voor luchtvaart
Luchtvaartruimte: Verkeerruimte voor voertuigen die zich door de lucht verplaatsen.
Mast: Hoge draagconstructie voor een installatie of het transport van energie en elektromagnetische straling
Materie: Zuivere stof, chemische verbinding of mengsel
Memo: Informatieobject voor het gebruik en de registratie van memo's bij een objecttype.
Monument-informatie: Registratie van gegevens van monumentale objecten.
Object: Superklasse van het model. Ouder van de kinderen FysiekObject en Informatieobject. Enititeit die bestaat of kan bestaan binnen ruimte of tijd. Een object voert een activiteit uit en verandert door een activiteit.
Onbepaald terrein: Fysiek begrensd en zichtbaar terrein dat bij een gebouw hoort, dat niet verder wordt gedetailleerd in andere reële objecten en dat bestaat uit een mengvorm van verharding, water, begroeiing en/of constructies.
Onderhoud-informatie: Gegevens die nodig zijn voor het plannen en registreren van het onderhoud van objecten.
Ondertunneling: Ondergrondse of onder water gelegen verbinding tussen twee punten, aan beide einden voorzien van een open bakconstructie.
Open leiding: Een rioolleiding waarvan de bovenzijde niet is afgesloten.
Opening kunstwerk: Gegevens die betrekking hebben op de oplevering van een object.
Oplever-informatie: Gegevens die betrekking hebben op de oplevering van een object.
Overbrugging: Kunstwerk dat een beweegbare of vaste verbinding tussen twee punten betreft, die door water, een weg of anderszins gescheiden zijn, bestaande uit een brugdek/-bak met landhoofden en veelal gesteund door pijlers
Paalconstructie: Lage draagconstructie voor onder meer installaties of borden
Plaatsbepalingspunt: Een Plaatsbepalingspunt is een punt dat is ingemeten en vervolgens gebruikt is bij en onderdeel uitmaakt van de begrenzing (geometrie) van reële objecten.
Put: Gegraven of geboorde kokervormige diepte waarin zich (vloei)stoffen bevinden.
Randgroenobject: Gegevens die betrekking hebben op de oplevering van een object.
Randverhardingsobject: Gegevens die betrekking hebben op de oplevering van een object.
Recreatiezone: Functionele ruimte die in gebruik is voor openlucht recreatie
Reëel object: Geo-object dat zich geheel materieel manifesteert
ReëelObject: Fysiek object (vormvast of niet-vormvast) dat in de werkelijkheid tastbaar en zichtbaar is (of kan zijn), door de mens gemaakt of natuurlijk ontstaan.
Registratie-informatie: Metagegevens voor het vastleggen van wijzigingen van de objectgegevens. Deze gegevens kunnen ook gebruikt worden voor het vastleggen van de historie.
Registratieve ruimte: Op basis van wet- of regelgeving afgebakende ruimte die als eenheid geldt van politiek/bestuurlijke verantwoordelijkheid of voor bedrijfsvoering.
RuimtelijkGebied: Fysiek object dat een bepaald gebied omsluit zoals een vertrek, rijbaan en rivier, die wordt begrensd door reële objecten of andere ruimtelijke gebieden (bijvoorbeeld op basis van gebruik of conventie) en dat voornamelijk vloeibare of gasvormige hoeveelheid materie bevat.
Rurale beheerzone: Een afgebakend gebied voor generieke beheerdoeleinden binnen het landelijk gebied.
Samengesteld rioleringsobject: Klasse van rioleringsobjecten waarbinnen meerdere reële objecten een samenhangend, functioneel, geheel vormen.
Scheepvaartruimte: Transportruimte voor voertuigen die zich over water verplaatsen .
Scheiding: Kunstmatig obstakel met een werende functie.
Sensor: Apparaat voor de meting van een fysieke grootheid (bijv. temperatuur, licht, druk, elektriciteit).
Sluisdoorvaart: Gegevens die betrekking hebben op de oplevering van een object.
Software: Informatieobject voor de registratie van basisgegevens van het programma (software) die binnen of die in directe relatie met het objecttype gebruikt wordt.
Soortnaamgroenobject: Gegevens die betrekking hebben op de oplevering van een object.
Spoorverkeerruimte: Transportruimte voor voertuigen die zich over rails verplaatsen.
Spoorzone: Functionele ruimte die in gebruik is voor spoorwegen.
Stadsverwarming: Stadsverwarming of warmtedistributie is een verwarmingssysteem, waarbij de woningen worden verwarmd via een ondergronds netwerk van warmwaterleidingen.
Straatmeubilair: Een ruimtelijk object ter inrichting van de openbare ruimte.
TechnischEntiteit: Entiteit waarbij het gaat om de technische eigenschappen die nul of meerdere functionele entiteiten implementeert of speelt.
TopologischElement: Een topologisch element is een configuratie waarin vastgelegd wordt hoe objecten verbonden zijn of hoe ze relatief tot elkaar gepositioneerd zijn.
Transportruimte: Natuurlijke of aangelegde transportlijnen of verbindingen met knooppunten waarlangs stromen zich verplaatsen.
Tunneldeel: Onderdeel van een kunstmatig aangelegde, kokervormige onderdoorgang dat essentieel is voor de constructie.
Urbane beheerzone: Een afgebakend gebied voor generieke beheerdoeleinden binnen het stedelijk gebied.
Utiliteitsnet: Een verzameling van netwerkelementen die tot één type nutsvoorzieningennet behoren.
Valruimte-informatie: Gegevens die de valruimte van een speel- of sporttoestel vastleggen.
Vegetatieobject: Solitair vegetatieobject of lijn- of vlakvormige groep gelijksoortige vegetatieobjecten met een beperkte omvang.
Verharding: Een door egaliseren, verstevigen en/of verruwen voor het beoogde gebruik geschikt gemaakte oppervlak, bestaande uit in één of meer lagen over een ondergrond of onderliggende constructie aangelegd materiaal
Verkeerruimte: Transportruimte voor verkeer via land, water of lucht.
Verkeersintensiteit: Het vastleggen van de verkeersintensiteit per prognosejaar bij een wegas.
Verkeerskundig functionele zone: Functionele ruimte die een verkeerskundige functie kent.
Verkeerstelling: Het registreren van verkeerstellingen bij een Wegas.
Virtuele ruimte: Geo-object dat zich geheel of gedeeltelijk niet-materieel manifesteert en dus slechts in abstracte en/of geregistreerde vorm bestaat.
Water: Massa van water dat de bodem bedekt of in normale omstandigheden kan bedekken
Waterbeheerzone: Een afgebakend gebied specifiek van belang voor waterbeheer.
Waterinrichtingsobject: Een ruimtelijk object ter inrichting van het water.
Waterverplaatsingruimte: Transportruimte waardoor water zich verplaatst.
Waterstaatkundig kunstwerk: Kunstwerk voor de beheersing van het oppervlaktewater en alles wat daarin voorkomt
Weginrichtingsobject: Een ruimtelijk object dat dient voor de inrichting van de openbare weg.
Wegverkeerruimte: Transportruimte voor voertuigen die zich over wegen verplaatsen .
Wegzone: Functionele ruimte die in gebruik is voor weginrichting

De uitgangspunten voor de totstandkoming van deze hiërarchie waren:

Hergebruiken wat er reeds is;
Aansluiten bij de meest recente versie van de standaarden;
NEN2660-2 gebruiken als uitgangspunt, inclusief de daarin vermelde relatie met de NEN3610;
Aansluiting eerst op de SOR (dan pas IMGeo), inclusief de daar in vermelde relatie met de NEN3610;
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);
Type relaties alleen degene uit toegestaan uit NEN2660-2;
Vooralsnog alleen Object, FysiekObject, Activiteit, GeometrischeRepresentatie en InformatieObject gebruiken uit de NEN2660-2 (en in IMBOR2022 daar verder op in gaan);
Verdeling van attributen over Objecttypen moet zo veel mogelijk gelijk blijven t.o.v. IMBOR2020-08 (afgezien van waar de koppeling al niet goed was);

Ten opzichte van IMBOR2020-08 is de introductie van semantische relaties een grote verandering. Middels relaties geadopteerd uit de NEN2660-2 wordt het mogelijk gemaakt om tussen concepten binnen IMBOR betekenisvolle relaties te leggen. De relaties betreffen:

isSubtypeVan (NEN2660-2: Is een verbijzondering van)
heeftDeel (NEN2660-2:hasPart)
isVerbondenMet (NEN2660-2:isConnectedTo)
isBeschrevenDoor (NEN2660-2:isDescribedBy)
bevat(NEN2660-2:contains)
heeftBegrenzing (NEN2660-2:hasBoundary)
voertUit (NEN2660-2:executes)
bestaatUit (NEN2660-2:consistsOf)

In het schema is te zien tussen welke (top)concepten de relaties kunnen lopen. In de IMBOR ontologie (in Access en LinkedData) 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 Objecttype niveau te leggen.

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.

IMBOR Bouwstenen — Figuur 5
IMBOR bouwstenen versimpeld

IMBOR Bouwstenen voorbeelden — Figuur 6
IMBOR bouwstenen versimpeld met voorbeelden

Binnen IMBOR zijn er een aantal modelleerkeuzes gemaakt die extra uitleg verdienen. Deze kunnen geschaard worden onder de 'informele' modelleerregels

Objecttype is een speciaal soort Klasse. Het betreft hier namelijk het blad van de klasseboom. Ofwel de onderste laag. 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 mogen worden en de 'concrete' Objecttype juist wel. Objecttype zijn als enige ook ingedeeld in Vakdisciplines.

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 mogen 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 in IMBOR2022 is besloten om veel attributen te verhuizen naar InformatieObject. Hiermee is het dus wel van belang dat deze daadwerkelijk geïnstantieërd worden in de beheersystemen 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.

De Klasse 'Gebiedsindeling' is gemodelleerd vanwege een legacy behoefte binnen IMBOR. De klasse distribueert een set van attributen welke allemaal afgeleidt kunnen worden van de geografische locatie. De meeste zijn ook dubbel te leggen met de semantische relatie bevat. Bijna alle attributen hebben dan ook als waarde binnen TypeAttribuut de waarde 'Wordt automatisch bepaald'. Zie ook Automatische waarden.

Op termijn zal gekeken moeten worden of de expliciete modelleering via de semantische relaties hier ook afdoende voor is.

Enkele attributen hebben als TypeAttribuut de waarde 'Wordt automatisch bepaald'. Hiermee wordt aangegeven dat bij de implementatie in een (GIS) systeem de daadwerkelijke waarde van het attribuut berekend wordt door het beheerpakket, maar expliciet opgeslagen wordt op dit attribuut. Elke organisatie of leverancier kan zelf kiezen hoe dit te implementeren, deze modellering binnen IMBOR geeft alleen maar aan dat het een 'afgeleid' attribuut betreft. Dit is (toentertijd) besloten omdat dit de query's binnen de systemen aanzienlijke sneller maakt en men zeker weet dat deze waarden expliciet bevraagbaar zijn.

Op termijn zal gekeken moeten worden of de expliciete modelleering via de semantische relaties hier ook afdoende voor is.

Omdat IMBOR uitgaat van onderscheidende kenmerken als vuistregel om een Klasse of Objecttype te introduceren zijn er de attributen Type, TypeGedetailleerd en TypeExtraGedetailleerd onderkent. Dit zijn attributen zoals beschreven in deze sectie van MIM. In de LinkedData theorie zouden dit subklassen 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. Ten opzichte van IMBOR2020-08 zijn in IMBOR2022 veel waarden die eerst van het attribuut Type waren opgeschoven en 'gepromoveerd' naar een echt Objecttype. Bijvoorbeeld 'Beweegbare brug' en 'Vaste brug' zijn nu Objecttype in IMBOR2022, terwijl in IMBOR2020-08 deze een waarde waren binnen het Type attribuut. Hiermee zijn de TypeExtraGedetailleerd gepromoveerd naar TypeGedetailleerd en TypeGedetailleerd gepromoveerd naar Type. Er zijn dus veel Objecttypen bijgekomen, dit maakt IMBOR meer expliciet. 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.

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 Vakdiscipline tegelijk behoren. IMBOR dwingt hier niets over af. Vakdisciplines 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.

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 IMBOR2022 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). In IMBOR is er vooralsnog echter geen aandacht gegeven aan topologie. De enige topologie die momenteel onder TopologischElement in IMBOR zit betreft hetgeen GWSW specificeert. Dit is gedaan om de relatie tussen GWSW en IMBOR zo overzichtelijk en compleet mogelijk te maken. Zie ook GWSW als referentiemodel. Er wordt niet uitgesloten dat IMBOR in de toekomst zelf ook specificaties van topologie gaat maken.

Vóór IMBOR2022 werden materialen als attributen van Objecttypen vastgelegd. Binnen de NEN2660-2 is hiervoor een modelleerconstructie gegeven die IMBOR2022 toepast. Er kan een relatie bestaatUit 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 allemaal soorten materialen opgenomen en met relaties verbonden aan de juiste ObjectTypen. Deze lijst is op basis van 'expert judgement' samengesteld door de jaren heen. Nu IMBOR zich committeert aan de NEN2660-2 en daarmee LinkedData wordt er gekeken of de materialen apart van IMBOR beheert kunnen gaan worden. Het liefst wordt aangesloten bij een bestaand(e) lijst/initiatief. De gesprekken hiervoor worden in 2022 gepland.

Ter verduidelijkingL IMBOR limiteert niet welke relaties er tussen een FysiekObject en een Materie gelegd kunnen worden. We geven alleen 'voorstellen'.

Voor de gebruiker van IMBOR wordt een inkijkmogelijkheid (publicatie) van IMBOR op meerdere manieren gegeven:

De gedistribueerde Access database biedt middels formulieren de mogelijkheid om direct IMBOR te raadplegen
Middels voorgedefinieerde queries op de CROW SPARQL webapplicatie
De vocabulair van IMBOR is te raadplegen via het thesaurus platform van CROW begrippen.crow.nl
In de loop van 2022 wordt een ontologie viewer ter beschikking gestelt

Al deze vormen van publicatie zijn zonder kosten te raadplegen. Voor de CROW SPARQL webapplicatie is wel een MijnCROW account nodig.

Wanneer IMBOR geïmplementeerd moet worden in software is uiteraard de gehele content beschikbaar. Hiervoor zijn ook twee distributiekanalen:

IMBOR tabellen in Access
IMBOR in LinkedData (TTL file en SPARQL-Endpoint)

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.

Wat betreft het gebruik van IMBOR, raadplegen de sectie over licenties

IMBOR Beheer Distributie Publicatie — Figuur 7 Overzicht IMBOR Beheer, Distributie en Publicatie

Noot

De IMBOR Ontologie viewer is nog in ontwikkeling en zal in de loop van 2022 klaar zijn.

Omdat IMBOR momenteel nog beheerd wordt in MS Access is het fysieke datamodel hier van toepassing. Middels het fysieke datamodel diagram wordt een uitleg gegeven hoe deze geïnterpreteerd moet worden. Het betreft hier dus niet een voorgeschreven datamodel voor een beheerapplicatie.

IMBOR fysiek datamodel Access — Figuur 8 IMBOR fysiek datamodel -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie

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.

Er is gekozen om het fysieke datamodel van de MS Access database te versimpelen t.o.v. de theoretische uitwerking, dit is gedaan zodat in MS Access gemakkelijker query's opgezet kunnen worden. Een belangrijke keuze hier is om de IMBOR identifier (lees: IMBORGUID) te laten declareren in de imborVoc_Termen tabel. Zodoende wordt deze tabel de single-source-of-truth binnen de Access database.

Dit geldt niet voor de koppeltabellen, daar wordt wel de IMBORGUID gedeclareerd.

Door de versimpeling in Access zouden er tabellen ontstaan die niets meer zouden bevatten (omdat GUID, Label, Definitie, Synoniem en Toelichting in imborVoc_Termen zijn opgenomen) zijn deze tabellen weggelaten. Het gaat om:

imborKern_Multipliciteit
imborKern_Eenheden
imborKern_TypeAttributen
imborKern_Datatypen
imborKern_Vakdisciplines
imborKern_SemantischeRelaties
imborKern_Objecttypen
imborKern_EnumeratieTypen

In het diagram van het fysieke datamodel wordt dit ook aangegeven door de groene tekst van een datatype. Hier staat de theoretische tabel waar de waarde vandaan zou moeten komen. Echter in de Access database is dit versimpeld door deze op te halen uit imborVoc_Termen.

Alle tabellen die invulling geven aan de vocabulaire.

Deze tabel is onderdeel van het begrippenkader van IMBOR kan gezien worden als de vocabulaire. Zoals eerder vermeld 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. 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).

De enige andere tabel in het begrippenkader naast imborVoc_Termen. Dit betreft een overzicht van de collecties waarin de termen ingedeeld zijn.

Alle tabellen die invulling geven aan het IMBOR kernmodel.

Klasse is een nieuw begrip vanaf IMBOR2022. Het kan gelijkgesteld worden aan het NEN2660-2 "Concept". Het is hiermee ook een supertype van bijvoorbeeld Objecttype en InformatieObject.

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.

Er zijn Klasse die 1-op-1 overeenkomen met een Objecttype. Dit is intentioneel. Dit maakt verder geen verschil, want een Objecttype is technisch gezien ook een Klasse. Op deze manier is gerealiseerd dat er geen attributen aan een Objecttype hoefden worden gehangen. Omdat de naam Objecttype zo ingeburgerd is in de IMBOR terminologie moest deze vooralsnog wel gehandhaafd worden.

In imborKern_Klassen komen o.a. "Objecttypen", "Klassen", "ObjecttypeOnderdelen" en "Informatieobjecten" voor. Dit lijkt vreemd, maar is correct omdat het technisch gezien allemaal Klasse zijn (ofwel: subtypen van Klasse)

We nemen InformatieObject op als Klasse, daarmee kunnen we concrete 'klassen' introduceren zoals document en memo. Deze zijn dan te instantiëren en te relateren (doormiddel van de relatie isBeschrevenDoor) aan Objecttypen. Hiermee kan de klasse InformatieObject ook gerelateerd worden aan de NEN2660-2.

De kolom "Volgorde" in imborKern_Klassen is een beheertechnische kolom voor de Access formulieren. Daarmee geen normatief onderdeel van IMBOR. Dit is in het diagram ook te zien door de grijze tekst. Er kan dus ook geconcludeerd worden dat de tabel in principe geen toegevoegd waarde heeft voor de IMBOR kern, deze tabel zou dan eigenlijk ook in het lijstje kunnen staan dat vermeld staat in Tabelindeling. maar de kolom 'Volgorde' zorgt voor deze uitzondering.

In deze simpele tabel wordt de polyhiërarchie van de IMBOR top beschreven. Klassen 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.

Dit is een hulptabel Deze tabel wordt automatisch gegenereerd middels een AccessDB module die zich baseert op imborKern_Klassenindeling. Het betreft een hulptabel waarin voor ieder Objecttype apart wordt achterhaald van welke Klassen hij de attributen moet overerven. De ChildID = Objecttype, de ParentID = de Klasse. De formulieren in de AccessDB baseren zich hierop.

Deze tabel bevat alle attributen die in IMBOR voorkomen, inclusief hun TypeAttribuut en hun Datatype. De attribuutsoorten en datatypen zijn ook versimpeld t.o.v. IMBOR2020-08. De datatype volgens nu het [xmlschema11-1].

De kolom BovenliggendAttribuut wordt gebruikt om aan te geven hoe de attributen zich tot elkaar hiërarchisch verhouden. Dit betreft een kolom die nodig is om de formulieren op te bouwen en is niet normatief nodig (grijs in diagram).

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 (grijs in diagram).

Dit betreft een koppeltabel waarin de attributen aan de klassen gekoppeld worden. Inclusief een indicatie 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.

Met deze tabel wordt aangegeven binnen welke Vakdiscipline 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.

De introductie van semantische relaties (betekenisvolle relaties) is samen met de introductie van de klassen de grootste wijziging t.o.v. IMBOR2020-08. Met deze introductie is een generieke manier gecreëerd om relaties tussen Klasse te beschrijven. 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.

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.

Omdat de referentiemodellen een informatief onderdeel van IMBOR zijn, worden deze beschreven in een apart sectie.

Naast de distributie in de relationele tabellen van Acces wordt ook een LinkedData variant aangeboden. Deze is gebaseerd op hetzelfde logische 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 getrokken uit de beheeromgeving. In de transformatie wordt de data getransformeerd naar het onderstaande fysieke datamodel.

IMBOR fysiek datamodel LD — Figuur 9 IMBOR fysiek datamodel in LinkedData -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie

Ook de LinkedData versie van IMBOR (IMBOR-LD) is volgt de modulaire indeling. In IMBOR-LD wordt dit met verschillen grafen (gerepresenteerd via prefixen) 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 ontologien aangehaald worden. Hier staan de benodigde gegevens om relaties naar toe te kunnen leggen.

Omdat IMBOR een extensie is van de NEN2660-2 is de IMBOR kern direct 'gesubclassed' aan de NEN2660-2 concepten. Vandaar dat de concepten die we gebruiken uit de NEN2660-2 afgebeeld zijn met de prefix nen2660:*.

Noot

In de NEN2660-2 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 voor de IMBOR context.

Dit zijn alle classes (concepten) die tezamen het vocabulaire vormen (e.g. de thesaurus).

Op deze class worden alle attributen vastgelegd die het concept (conceptueel) definiëren in tekstuele zin en vormt daarmee de basis voor het vocabulaire.

Deze class bevat alle collecties waarin de termen kunnen worden ingedeeld.

Dit zijn alle classes uit de NEN2660-2 waaraan wij ons committeren. De basis betreft het nen2660:DiscreteObject (buiten de NEN2660-2 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.

Gedefinieerd als: "A real object consisting of a contiguous amount of form-retaining matter, held together primarily by internal forces (gravity, electromagnetic force)"

Gedefinieerd als: "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"

Gedefinieerd als: "Thing that is a whole of information on itself and has an own identity"

Gedefinieerd als: "A spatial representation"

Gedefinieerd als: "A type having a fixed or extendable set of simple instances having no further attributes or relations"

Gedefinieerd als: "An activity is something possibly or actually happening in space and time"

Gedefinieerd als: "A pure chemical substance, chemical bonding or mixture from which real objects are made"

Het IMBOR kernmodel bevat niet veel meer dan 'Objecten', 'Attributen' en 'Domeinwaarden'. Dit wordt nog aangevuld met de `Vakdisciplines'. Het kernmodel is uitgevoerd in [rdf-schema] en [shacl]. Dit is volgens de taalbinding van de NEN2660-2 gedaan. Hieronder worden de onderdelen beschreven.

Deze class betreft alle Klassen, InformatieObjecten en Objecttypen 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 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.

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.

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.

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.

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.

De instanties van deze class zijn de IMBOR Vakdisciplines. Deze declareren middels een rdfs:member welke ObjectTypen uit imbor:Klasse binnen een vakdiscipline vallen.

Omdat de referentiemodellen een informatief onderdeel van IMBOR zijn, worden deze beschreven in een apart sectie.

Een aantal metaconcepten worden specifiek voor IMBOR gedefinieerd. Dit wordt gedaan middels het 'IMBOR Aanvullend Metamodel'. Dit betreft een kleine ontologie van beschrijfende concepten die er voor zorgen dat alle IMBOR specifieke properties netjes en navolgbaar gedefinieerd zijn.

Dit onderdeel is niet normatief.

Binnen IMBOR zijn relaties opgenomen naar andere modellen. IMBOR bevindt zich in een speelveld waar veel raakvlakken zijn met andere sectorstandaarden en nationale registraties. Het betreft een onderdeel wat los staat van de 'normatieve' IMBOR onderdelen en mag gezien worden als een handreiking vanuit, en aan de IMBOR community. De exacte vorm van deze afhankelijkheden is nog niet formeel gemaakt. Ook binnen IMBOR2022 is nog geen formele 'mapping' gemaakt naar andere standaarden. Wel 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. Dit wordt dan ook vermeld. Hoe dit daadwerkelijk in de distributies zit is vermeld in deze sectie voor IMBOR in Access en IMBOR-LD.

Vanwege de positie van IMBOR worden er veel relaties naar andere standaarden gelegd. Binnen IMBOR zijn gegevens (bijvoorbeeld van GWSW) overgenomen 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.

De NEN2660-2 vormt de belangrijkste leidraad voor IMBOR2022 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 zich op focust. IMBOR neemt plaats in de "M1: Informatie model" laag.

Figuur 10
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.

Noot

In 2022 is de nieuwe versie van de NEN2660-2 vrijgegeven waaraan IMBOR zich committeert.

De NEN3610 is in 2022 herzien (t.o.v. 2011) en vormt de basis van de Samenhangende objecten registratie (SOR) die binnen het DiSGeo programma wordt opgetuigd. Binnen de NEN2660-2 is reeds een relatie tussen de NEN2660-2 en de NEN3610 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 (en daarmee de NEN2660-2), maar wordt (nog) geen volledige sterke relatie met de rest van de norm NEN3610 beschreven. Er wordt zodoende ook niet beweerd dat er volledige compatibiliteit met de NEN3610 is (wel met de NEN2660-2), maar dat puur de begrippenkaders voor nu met elkaar afgestemd zijn. Dit is gedaan vanwege de te verwachten sterke relatie met de SOR die ongeveer hetzelfde doet. De NEN3610 hiërarchie wordt tevens gebruikt om de verdeling van attributen binnen IMBOR te regelen. Wel worden de attributen identificatie en domein (als verplicht vanuit de NEN3610) volledige toegepast in IMBOR als identificerende attributen.

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.

Noot

In 2022/2023 zijn er gesprekken gaande tussen CROW, Geonovum en NEN om het in samenhang gebruiken van de NEN3610, NEN2660 en het MIM beter te faciliteren. IMBOR2022 vormt hierbij de eerste praktijkproef. Te verwachten valt dat IMBOR2023 zodoende nog meer principes uit het MIM toepast.

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. Na de release van IMBOR2022 wordt verwacht dat ook GWSW de NEN2660-2 gaat toepassen (in navolging van IMBOR). Wanneer dit het geval is zullen Stichting RIONED en CROW trachten de standaarden op een zuivere manier exact op elkaar af te stemmen. Tot die tijd moet dit 'handmatig' gedaan worden. GWSW is dan ook één van de standaarden waar een relatie is opgenomen in de IMBOR distributies.

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 is voor nu nog overgenomen in IMBOR(gekopieerd), maar dit moet in de toekomst een semantische relatie worden. De verwachting is dat in de loop van 2022 bij zowel IMBOR, GWSW en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen GWSW en IMBOR gerealiseerd worden, waardoor veel objecten van GWSW niet meer overgenomen hoeven te worden in IMBOR, maar dat er naar gelinkt wordt. In de tussentijd is dat nog niet het geval en is er dus sprake een 'kopie' van een deel van GWSW in IMBOR. De relatie tussen de IMBOR concepten en de GWSW concepten is nu 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 GWSW 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.

De opname van GWSW in IMBOR is zodoende niet 100%. De meeste objecttypen, attributen en relaties zijn aanwezig in IMBOR en er zijn 'mapping' regels gemaakt voor de objecttypen (zoals hierboven beschreven). Zie hiervoor ook nog appendix A

De NEN2767 en IMBOR hebben ook 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. Dit project is gestart, maar de resultaten hiervan worden in 2022 pas verwacht. 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.

Voor IMBOR objecttypen waar een NEN equivalent gezien wordt (zowel Beheerobject, Element als Bouwdeel) is dit aangegeven in IMBOR. Hiermee staat het NEN concept dus ook 'in' IMBOR. De verwachting is dat in de loop van 2022 bij het IMBOR en in de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Als het ook lukt om de NEN2767-4 hierin door te ontwikkelen kan dan een sterke semantische relatie (mapping) tussen de NEN2767-4 en IMBOR gerealiseerd worden, waardoor veel objecten niet meer overgenomen hoeven te worden in IMBOR, maar dat er naar gelinkt wordt. In de tussentijd is dat nog niet het geval en is er dus sprake een 'kopie' van een deel van de NEN2767-4 in IMBOR. 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.

De relatie tussen BGT/IMGeo en IMBOR is altijd noodzakelijk geweest. IMBOR maakt gebruik van de IMGeo-objecten (en daarmee dus de 'verrijkte' BGT objecten). IMGeo levert de geometrie die in IMBOR wordt verrijkt met beheerinformatie. Er is echter wel sprake van een relatief gecompliceerde relatie. 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. Daarnaast is door de introductie van de SOR de toekomst van IMGeo helaas nog ongewis. Binnen IMBOR2022 is daarom op een iets hoger niveau een relatief sterke semantische relatie gelegd naar IMGeo2.2.

Binnen IMBOR is een 'mapping' opgenomen naar IMGeo die de 'uitdrukking in' semantiek kent. Hiermee is het mogelijk om IMBOR objecttypen vast te leggen met een IMGeo geometrie. De verwachting is dat in de loop van de tijd richting de ontwikkeling van de SOR bij zowel IMBOR, DisGeo en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen IMGeo (of de SOR) en IMBOR gerealiseerd worden. In de tussentijd is dat nog niet het geval en is er dus sprake een uitdrukking van IMBOR objecttypen in IMGeo geometrie. Deze vastlegging is gedaan zodat bekeken kan worden hoe IMGeo zich verhoudt tot IMBOR en geeft een aanzet voor een vertaling tussen de twee. Deze aanzet kan door een softwareleverancier of organisatie worden overgenomen of uitgewerkt.

De SOR is een relatief nieuwe ontwikkeling die het landschap van standaarden en basisregistraties waarschijnlijk redelijk op zijn kop gaat zetten, hoewel de echte implicaties nog ongewis zijn. Binnen IMBOR is de verwachting dat IMBOR een 'uitklapmodel' van de SOR gaat worden. In objecttypen hiërarchie is daarom getracht om waar mogelijk de SOR begrippen te hanteren. Ook hier gaat het weer om het gebruik maken van het begrippenkader en nog niet persé de overig modelleerconstructies. Omdat de SOR praktisch een extensie van de NEN3610 is, is IMBOR voor zover mogelijk in lijn met de consultatieversie van de SOR gemaakt. Er is geen expliciete relatie gelegd.

Noot

Er is nog geen definitieve versie van de SOR verschenen. Er is begin 2021 een tweede consultatie gedaan. De verwachting is dat de SOR nog wel een tijdje op zich laat wachten en dat de huidige registraties tot die tijd gewoon blijven gelden. IMBOR zal t.z.t. zich waar nodig aanpassen om aan te sluiten. Meer informatie over de ontwikkeling van de SOR is ook de vinden bij de VNG.

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 de Klasse 'IMKLBasisObject' onderscheiden. Een aantal Klasse en daarmee Objecttypen zijn specialisaties van deze IMKL klasse. Daarmee worden diverse attributen die binnen IMKL noodzakelijk zijn geregistreerd binnen IMBOR. De verwachting is dat in de loop van 2022 bij zowel IMBOR, Geonovum en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan 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.

Binnen IMBOR is een 'mapping' opgenomen naar IMKL die de 'uitdrukking in' semantiek kent. Hiermee is het mogelijk om IMBOR objecttypen te vergelijken met de belangrijkste IMKL featuretypes. De verwachting is dat in de loop van de tijd de ontwikkeling bij zowel IMBOR, IMKL en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen IMKL en IMBOR gerealiseerd worden. In de tussentijd is dat nog niet het geval en is er dus sprake van een zwakke semantische relaties. Deze vastlegging is gedaan zodat bekeken kan worden hoe IMKL zich verhoudt tot IMBOR en geeft een aanzet voor een vertaling tussen de twee. Deze aanzet kan door een softwareleverancier of organisatie worden overgenomen of uitgewerkt.

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. In de praktijk komt het er op neer dat de Vakdiscipline 'Verkeer' binnen IMBOR 1-op-1 het IMWV is. De kritische lezer zal zien dat er toch een aantal dynamische gegevens (vanuit het IMWV) in IMBOR zitten (bijvoorbeeld over verkeersintensiteit). Dit is gedaan omdat er geen andere plaats van registratie is. De verwachting is dat in de loop van 2022 bij zowel IMBOR, IMWV en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen IMWV en IMBOR gerealiseerd worden waardoor er naar gelinkt wordt. In de tussentijd is dat nog niet het geval en is er dus sprake van een aantal attributen die formeel niet binnen de scope van IMBOR passen.

De KOR 2018 (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. Elke beeldmeetlat is gerelateerd aan één of meerdere IMBOR objecttypen. Ofwel, elk objecttype binnen de KOR kent een equivalent binnen IMBOR. IMBOR en de KOR kunnen zodoende samen met elkaar gebruikt worden.

Noot

De KOR is in 2018 opnieuw uitgebracht. In 2021 wordt verkend of de KOR ook gedistribueerd kan worden als informatiemodel in LinkedData. Wanneer dit gebeurt zal de expliciete sterke semantische relatie onderdeel zijn van de publicatie.

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 equivalent binnen IMBOR. IMBOR en BOR-MELD kunnen zodoende samen met elkaar gebruikt worden.

Noot

In 2021 wordt verkend of de BOR-MELD ook gedistribueerd kan worden als informatiemodel in LinkedData. Wanneer dit gebeurt zal de expliciete sterke semantische relatie onderdeel zijn van de publicatie.

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. Omdat de QUDT in LinkedData vorm kent en IMBOR meerdere distributievormen kent, is er een tussenstap middels een referentiemodel. IMBOR houdt een eigen lijst van grootheden en eenheden bij, maar middels een referentiemodel wordt de semantisch sterke mapping vastgelegd. De LinkeData distributie van IMBOR is zodoende in lijn met hoe het gebruik van de QUDT ontologie in de NEN2660-2 bedoelt wordt.

Binnen IMBOR wordt geregistreerd hoe de IMBOR Eenheid uitgedrukt worden in QUDT specificaties. Hiermee wordt de mogelijkheid geboden om, wanneer er in LinkedData gewerkt wordt, de QUDT ontologie te gebruiken.

GWSL moet het GWSW voor openbare verlichting worden, gebaseerd op het IMBOR framework (en dus de NEN2660-2). 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 Vakdiscipline '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 gebaseerd en wanneer GWSL in een eerste versie gereed is zal het beheer ook door CROW gedaan worden.

Noot

Er is nog geen definitieve versie van GWSL verschenen. Er is in 2021 hard gewerkt aan een eerste versie.

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.

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.

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.

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.

In de huidige staat van de CB-NL is er nog geen relatie tussen IMBOR en de CB-NL. Er wordt in 2021 gewerkt aan een CB-NL2.0. Deze zal volledig gebaseerd zijn op de NEN2660-2 principes. Daarmee wordt het een stuk makkelijker om de relatie te leggen naar IMBOR. Deze zal echter pas op zijn vroegst in 2022 verkend worden.

Het informatiemodel Geluid (IMGeluid) beschrijft de semantiek van digitale bestanden voor de Centrale Voorziening Geluidgegevens. 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.

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.

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 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.

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.

PIM staat voor Pavement Information Modelling en wordt het centraal bedrijfsinformatiesysteem voor opdrachtnemers in de asfaltverhardingenbranche. PIM en IMBOR hebben nog geen directe (expliciete) relatie maar er zijn verregaande gesprekken bezig om de twee standaarden af te stemmen. De afstemming zal met name gedaan worden op de verschillende objecttypen binnen IMBOR. Uiteindelijk is de bedoeling dat IMBOR een vastlegging van asfaltconstructies en verhardingen nastreeft waar de gegevens die benodigd zijn voor PIM direct aan te relateren zijn. De verwachting is dat in de loop van 2022 bij zowel IMBOR, PIM en de sector voldoende inburgering van de LinkedData principes, de NEN2660-2 en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen PIM en IMBOR gerealiseerd worden.

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. In 2022 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.

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.

In de Access distributie staan de informatieve tabellen die de relaties naar andere modellen bevatten.

Noot

De manier waarop er nu relaties gelegd worden naar externe modellen wordt nog onder de loep genomen. Dit geldt zowel voor de manier waarop dat nu vastligt (met de refModel tabellen), maar ook voor de semantiek van deze relatie. De huidige mapping wordt omgeschreven in de kolom RelatieInformatie. Dit verschilt per model, maar er is nergens sprake van een sterke semantiek.

Het is de bedoeling om later in 2022 te kijken of er semantisch sterkere relaties gelegd kunnen worden naar de verschillende referentiemodellen. En daarmee ook een 'volwaardige' mapping te maken. Hier loopt de techniek vooralsnog voor op de governance. Zie voor meer informatie ook Toelichting per referentiemodel

Dit betreffen alle tabellen die externe modellen representeren. We nemen niet de onderlinge relaties tussen Objecttypen, Attributen en Domeinwaarden over zoals deze vastgelegd zijn in de referentiemodellen. We zorgen dat we alleen de concepten opnemen in onze registratie zodat we een verwijzing kunnen maken.

Hier wordt de meta-informatie opgenomen van de informatiemodellen die we aanhalen in IMBOR.

In deze tabel worden de 'objecttypen' uit de referentiemodellen opgenomen zodat er aan gerelateerd kan worden.

In deze tabel worden de 'attributen' uit de referentiemodellen opgenomen zodat er aan gerelateerd kan worden.

In deze tabel worden de 'domeinwaarden' uit de referentiemodellen opgenomen zodat er aan gerelateerd kan worden.

In deze tabel wordt de daadwerkelijk relatie gelegd tussen dus combinaties van Objecttypen, Attributen en Domeinwaarden in IMBOR en de Objecttypen, Attributen en Domeinwaarden uit een referentiemodel.

Dit is een nieuwe toevoeging vanaf IMBOR2022 en is nog in bèta. Met een minimale datasets wordt aangegeven welke objecttype - attribuut combinaties relevant zijn voor een bepaald informatiemodel (doorgaans een 'Methodiek')

In de LinkedData distributie staan de informatieve concepten die de relaties naar andere modellen bevatten. Deze staan in een aparte graaf en zodoende dus apart van de Vocabulaire en Kern (ontologie)

Noot

De manier waarop er nu relaties gelegd worden naar externe modellen wordt nog onder de loep genomen. Dit geldt zowel voor de manier waarop dat nu vastligt (met de 'mapping' classes), maar ook voor de semantiek van deze relatie. De huidige mapping wordt omgeschreven in de property skos:scopeNote. Dit verschilt per model, maar er is nergens sprake van een sterke semantiek.

Dit betreffen alle Classes in het de graaf 'Addendum Referentiemodellen'. We nemen niet de onderlinge relaties tussen Objecttypen, Attributen en Domeinwaarden over zoals deze vastgelegd zijn in de referentiemodellen. We zorgen dat we alleen de concepten opnemen in onze registratie zodat we een verwijzing kunnen maken.

Hier wordt de meta-informatie opgenomen van de informatiemodellen die we aanhalen in IMBOR. Elk model heeft een eigen GUID, skos:prefLabel en skos:definition. Daarnaast wordt op de rdfs:seeAlso property de URL vastgelegd naar de website van het informatiemodel, op dct:publiser de beheerder van het informatiemodel en op schema:version een tekstuele vastlegging van de versie van het informatiemodel.

Het informatiemodel wordt door zowel IMBOR kern concepten als door concepten uit de addenda als bron gerefereert middels dct:source.

Dit betreft de Class die de link is tussen de IMBOR ontologie en de referentiemodellen (ofwel het normatieve en informatieve deel). De class heeft ook een GUID. Daarnaast is er ruimte voor een toelichting op de mapping in skos:note en wordt de relatie informatie op de skos:scopeNote beschreven.

Middels de property imborObjectype wordt de relatie naar het IMBOR Objecttype gelegd en middels de property refObjecttype wordt de relatie naar het Objecttype uit het referentiemodel gelegd.

Omdat in dit geval het attribuut en de domeinwaarde altijd samen voorkomen worden deze gegroepeerd in een blanknode. Middels de properties imborAttribuutDomeinwaarde en refAttribuutDomeinwaarde wordt de relatie gelegd tussen de Mapping en de blanknode. Vanuit de blanknode wordt middels een rdf:List constructie naar de verschillende attributen en domeinwaarden verwezen.

Dit betreffen de 'ObjectTypen' die in de referentiemodellen onderscheiden worden.

Dit betreffen de 'Attributen' die in de referentiemodellen onderscheiden worden.

Dit betreffen de 'Domeinwaarden' die in de referentiemodellen onderscheiden worden.

IMBOR Technische documentatie

Samenvatting

1. Versie historie

2. Inleiding

2.1 Normatief & informatief

2.2 Toepassingsgebied

2.2.1 IMBOR (door)ontwikkeling in software

2.2.2 Regie op standaarden

2.3 Doelgroep

3. IMBOR in modellen

3.1 Model van begrippen

3.2 Logisch informatiemodel

3.3 Fysiek datamodel

4. IMBOR samenhang en hiërarchie

4.1 IMBOR Top hiërarchie

4.1.1 Definities in hiërarchie

4.1.2 Totstandkoming

4.1.3 Semantische relaties

4.2 IMBOR Bouwstenen

4.3 Speciale modelleerconstructies

4.3.1 Objecttypen

4.3.2 InformatieObjecten

4.3.3 Gebiedsindeling

4.3.4 Automatische waarden

4.3.5 Classificerende attributen

4.3.6 Vakdisciplines

4.3.7 Gekwalificeerde waardeshapes

4.3.8 Topologische elementen

4.3.9 Materie

5. IMBOR distributie

5.1 IMBOR in MS Access

5.1.1 Tabelindeling

5.1.2 Begrippenkader

5.1.2.1 imborVoc_Termen

5.1.2.2 imborVoc_Collecties

5.1.3 Kernmodel

5.1.3.1 imborKern_Klassen

5.1.3.2 imborKern_Klassenindeling

5.1.3.3 imborKern_KlassenChildParent

5.1.3.4 imborKern_Attributen

5.1.3.5 imborKern_EnumeratiesDomeinwaarden

5.1.3.6 imborKern_K_KlasseAttributen

5.1.3.7 imborKern_K_VakdisciplinesObjecttypen

5.1.3.8 imborKern_K_ObjecttypenSemantischeRelaties

5.1.4 Referentiemodellen

5.2 IMBOR in LinkedData

5.2.1 Ontologie indeling (in grafen)

5.2.2 Begrippenkader

5.2.2.1 imbor-term:Term

5.2.2.2 imbor-term:Collectie

5.2.3 NEN2660

5.2.3.1 nen2660:DiscreteObject

5.2.3.2 nen2660:SpatialRegion

5.2.3.3 nen2660:InformationObject

5.2.3.4 nen2660:GeometricEntity

5.2.3.5 nen2660:EnumerationType

5.2.3.6 nen2660:Activity

5.2.3.7 nen2660:Matter

5.2.4 Kernmodel

5.2.4.1 imbor:Klasse

5.2.4.2 imbor:KlasseAttribuut

5.2.4.3 imbor:Attribuut

5.2.4.4 imbor:EnumeratieType

5.2.4.5 imbor-domeinwaarde:Domeinwaarde

5.2.4.6 imbor:Vakdiscipline

5.2.5 Referentiemodellen

5.2.6 Aanvullend 'metamodel'

6. Referentiemodellen

6.1 Toelichting per referentiemodel

6.1.1 NEN2660-2

6.1.2 NEN3610

6.1.3 MIM

6.1.4 GWSW

6.1.4.1 GWSW als referentiemodel

6.1.5 NEN2767-4

6.1.5.1 NEN2767 als referentiemodel

6.1.6 BGT/IMGeo

6.1.6.1 IMGeo als referentiemodel

6.1.7 SOR

6.1.8 IMKL