diff --git a/.github/workflows/verslagen-generate-index.yaml b/.github/workflows/verslagen-generate-index.yaml
new file mode 100644
index 0000000..a75c30b
--- /dev/null
+++ b/.github/workflows/verslagen-generate-index.yaml
@@ -0,0 +1,46 @@
+name: Generate Verslagen Index
+
+on:
+ workflow_dispatch:
+ push:
+ paths:
+ - 'docs/verslagen/**'
+
+jobs:
+ generate_index:
+ runs-on: ubuntu-latest
+
+ steps:
+ - uses: actions/checkout@v3
+
+ - name: Generate Index
+ run: |
+ cd docs/verslagen
+ echo "# Verslagen" > index.md
+ echo "" >> index.md
+
+ for dir in */; do
+ dir=${dir%/}
+ if [ -d "$dir" ]; then
+ echo "## $dir" >> index.md
+ find "$dir" -type f | while read -r file; do
+ file_link=$(echo "$file" | sed 's/ /%20/g')
+ file_name=$(basename "$file")
+ echo "- [$file_name]($file_link)" >> index.md
+ done
+ echo "" >> index.md
+ fi
+ done
+
+ # for dir in /; do
+ # dir=${dir%/}
+ # if [ -d "$dir" ]; then
+ # echo "## $dir" >> index.md
+ # find "$dir" -type f -printf "- [%f](%p)\n" | sort >> index.md
+ # echo "" >> index.md
+ # fi
+ # done
+ - name: Commit changes
+ uses: stefanzweifel/git-auto-commit-action@v4
+ with:
+ commit_message: Update verslagen-index na upload
diff --git a/docs/techdoc/docs/imbor-distributie.md b/docs/techdoc/docs/imbor-distributie.md
index 989ed92..1cd7af2 100644
--- a/docs/techdoc/docs/imbor-distributie.md
+++ b/docs/techdoc/docs/imbor-distributie.md
@@ -1,20 +1,22 @@
## IMBOR distributie
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](https://begrippen.crow.nl/)
-* In de loop van 2022 wordt een ontologie viewer ter beschikking gestelt
+* Via een online viewer: [imbor-viewer.apps.crow.nl](https://imbor-viewer.apps.crow.nl)
+* Via formulieren in een MS Access database
+* Via voor gedefinieerde query’s op de [CROW SPARQL webapplicatie](https://sparql.crow.nl/ldp)
+* Via het [begrippen platform](https://begrippen.crow.nl/imbor/nl/) van CROW is het begrippenkader (vocabulaire) van IMBOR te raadplegen
-Al deze vormen van publicatie zijn zonder kosten te raadplegen. Voor de CROW SPARQL webapplicatie is wel een [MijnCROW account][mijncrow] nodig.
+Al deze vormen van publicatie zijn _zonder kosten_ te raadplegen. Voor de [CROW SPARQL webapplicatie](https://sparql.crow.nl/ldp) is wel een [MijnCROW account][mijncrow]nodig.
-Wanneer IMBOR geïmplementeerd moet worden in software is uiteraard de gehele content beschikbaar. Hiervoor zijn ook twee distributiekanalen:
-* IMBOR tabellen in Access
+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
-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.
+Alle informatie hierover en versies hiervan is/zijn via [GitHub releases](https://github.com/Stichting-CROW/imbor/releases) te raadplegen. Wat betreft het gebruik van IMBOR, raadplegen de sectie over [licenties](#licenties)
-Wat betreft het gebruik van IMBOR, raadplegen de sectie over [licenties](#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.
+
@@ -23,13 +25,6 @@ Wat betreft het gebruik van IMBOR, raadplegen de sectie over [licenties](#licent
Overzicht IMBOR Beheer, Distributie en Publicatie
-
-
-De IMBOR Ontologie viewer is nog in ontwikkeling en zal in de loop van 2022 klaar zijn.
-
-
-
-
### IMBOR in MS Access
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.
@@ -75,7 +70,7 @@ In het diagram van het fysieke datamodel wordt dit ook aangegeven door de groene
Alle tabellen die invulling geven aan de vocabulaire.
##### imborVoc_Termen
-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.
+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-2:2022][nen2660: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`).
##### imborVoc_Collecties
@@ -87,7 +82,7 @@ De enige andere tabel in het begrippenkader naast `imborVoc_Termen`. Dit betreft
Alle tabellen die invulling geven aan het IMBOR kernmodel.
##### imborKern_Klassen
-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`.
+Klasse is een nieuw begrip vanaf IMBOR2022. Het kan gelijkgesteld worden aan het [NEN2660-2:2022][nen2660:2022] "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.
@@ -95,7 +90,7 @@ Er zijn `Klasse` die 1-op-1 overeenkomen met een `Objecttype`. Dit is intentione
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 `Objecttype`n. Hiermee kan de klasse `InformatieObject` ook gerelateerd worden aan de NEN2660-2.
+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 `Objecttype`n. Hiermee kan de klasse `InformatieObject` ook gerelateerd worden aan de [NEN2660-2:2022][nen2660:2022].
@@ -137,7 +132,7 @@ Met deze tabel wordt aangegeven binnen welke `Vakdiscipline` een `Objecttype` ka
##### imborKern_K_ObjecttypenSemantischeRelaties
-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.
+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:2022][nen2660: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.
@@ -166,10 +161,10 @@ Ook de LinkedData versie van IMBOR (IMBOR-LD) is volgt de modulaire indeling. In
- `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:*`.
+Omdat IMBOR een extensie is van de [NEN2660-2:2022][nen2660:2022] is de IMBOR kern direct 'gesubclassed' aan de [NEN2660-2:2022][nen2660:2022] concepten. Vandaar dat de concepten die we gebruiken uit de [NEN2660-2:2022][nen2660:2022] afgebeeld zijn met de prefix `nen2660:*`.
-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.
+In de [NEN2660-2:2022][nen2660: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][nen2660:2022] voor de IMBOR context.
#### Begrippenkader
@@ -183,7 +178,7 @@ Op deze class worden alle attributen vastgelegd die het concept (conceptueel) de
Deze class bevat alle collecties waarin de termen kunnen worden ingedeeld.
#### NEN2660
-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.
+Dit zijn alle classes uit de [NEN2660-2:2022][nen2660:2022]2 waaraan wij ons committeren. De basis betreft het `nen2660:DiscreteObject` (buiten de [NEN2660-2:2022][nen2660: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:DiscreteObject
Gedefinieerd als: "A real object consisting of a contiguous amount of form-retaining matter, held together primarily by internal forces (gravity, electromagnetic force)"
@@ -211,7 +206,7 @@ Het IMBOR kernmodel bevat niet veel meer dan 'Objecten', 'Attributen' en 'Domein
##### imbor:Klasse
-Deze class betreft alle Klassen, `InformatieObject`en en `Objecttype`en 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 betreft alle Klassen, `InformatieObject`en en `Objecttype`en 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][nen2660: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.
##### 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.
@@ -236,3 +231,5 @@ Omdat de referentiemodellen een informatief onderdeel van IMBOR zijn, worden dez
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.
[mijncrow]: https://crowsso.b2clogin.com/crowsso.onmicrosoft.com/B2C_1A_signup_signin/oauth2/v2.0/authorize?client_id=e0b429f6-ef7f-4d0e-be5f-2711b5d4393f&redirect_uri=https://crow.nl/Truelime/AzureADAuthenticationHandler.ashx&response_type=code&scope=openid&response_mode=query&state=eyJSZXR1cm5VcmwiOiIvTWlqbkNST1cvSG9tZSIsIlNob3BwaW5nQ2FydCI6IjAwMDAwMDAwLTAwMDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCIsIklkIjoiODQwYzBlYmMtZjBmOC00YmE5LTg3YzAtZGEwYThiZGUxYmMwIiwiU2lnbk91dCI6ZmFsc2V9
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/imbor-modellen.md b/docs/techdoc/docs/imbor-modellen.md
index 37b8c0d..7e3c4af 100644
--- a/docs/techdoc/docs/imbor-modellen.md
+++ b/docs/techdoc/docs/imbor-modellen.md
@@ -1,16 +1,17 @@
## IMBOR in modellen
-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][MIM]) definieert. Hier worden vier 'lagen' van modellen gedefinieerd:
+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][MIM]) definieert. Hier worden vier 'lagen' van modellen gedefinieerd:
1. [Niveau 1][n1]: Model van begrippen
1. [Niveau 2][n2]: Conceptueel informatiemodel
1. [Niveau 3][n3]: Logisch informatiemodel
1. [Niveau 4][n4]: 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.
-### Model van begrippen
+IMBOR acteert met name 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.
+
+### 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][MIM] als de [NEN2660-2:2022][nen2660:2022] bevelen dit aan.
-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][MIM] als de NEN2660-2 bevelen dit aan.
-Onderstaande figuur is niet het model zelf, maar het ([conceptuele][n2]) metamodel hiervan.
De IMBOR Vocabulaire is te verkennen op:
@@ -19,36 +20,40 @@ De IMBOR Vocabulaire is te verkennen op:
-
+
-IMBOR Vocabulair 'Metamodel' -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
+IMBOR vocabulaire structuur -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
-### Logisch informatiemodel
+### Informatiemodel
-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][MIM] en de NEN3610, echter de NEN2660-2 blijft het voornaamste uitgangspunt.
+Binnen IMBOR gaan we uit van bestaande standaarden, te weten de [NEN2660-2:2022][nen2660:2022], de [NEN3610:2022][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][nen2660:2022]. Hiermee sluiten we aan bij de ordeningsregels en uiteindelijk ook de taalbinding die in de [NEN2660-2:2022][nen2660:2022]beschreven 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][MIM] en de [NEN3610:2022][nen3610:2022], echter de [NEN2660-2:2022][nen2660:2022] 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][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.
+Onderstaande figuur toont de structuur hoe IMBOR is opgebouwd. In de LinkedData versie wordt er middels een ETL-pipeline gezorgd dat het er correct volgens de [NEN2660-2:2022][nen2660:2022] en [MIM][MIM] taalbinding uit komt. Deze IMBOR structuur 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][nen2660:2022] structuur van belang.
-
+
-IMBOR Kern 'Metamodel' -- rechtermuisknop "Openen in nieuw tabblad" voor leesbare versie
+IMBOR structuur' -- 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 [MIM][MIM] wordt op meerdere plekken aangehaald binnen IMBOR. Omdat IMBOR in eerste instantie de [NEN2660-2:2022][nen2660: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`. 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`.
+ 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 IMBOR niet meer aanwezig.
- 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`.
+ 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 vanaf 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:
@@ -64,11 +69,7 @@ Omdat IMBOR nu nog gedistribueerd wordt in een MS Access database en LinkedData
Het fysieke datamodel in LinkedData kan gelijk worden gesteld aan de 'serialisatie'. In het geval van IMBOR is dit [[turtle]].
-
@@ -76,4 +77,6 @@ De IMBOR Ontologie is te verkennen in de 'CROW | Ontologie verkenner' op:
[n1]: https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#niveau-1-model-van-begrippen
[n2]: https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#niveau-2-conceptueel-informatiemodel
[n3]: https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#niveau-3-logisch-informatie-of-gegevensmodel
-[n4]: https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#niveau-4-fysiek-of-technisch-gegevens-of-datamodel
\ No newline at end of file
+[n4]: https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#niveau-4-fysiek-of-technisch-gegevens-of-datamodel
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/imbor-referentiemodellen.md b/docs/techdoc/docs/imbor-referentiemodellen.md
index 5eb05a6..045e861 100644
--- a/docs/techdoc/docs/imbor-referentiemodellen.md
+++ b/docs/techdoc/docs/imbor-referentiemodellen.md
@@ -11,10 +11,10 @@ Vanwege de positie van IMBOR worden er veel relaties naar andere standaarden gel
#### NEN2660-2
-De NEN2660-2 vormt de belangrijkste leidraad voor IMBOR2022 door twee belangrijke dingen te specificeren:
+De [NEN2660-2:2022][nen2660:2022] vormt de belangrijkste leidraad voor IMBOR2022 door twee belangrijke dingen te specificeren:
1. Een praktisch toplevelmodel waarin genoeg semantiek aangegeven wordt om IMBOR in uit te drukken
1. 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.
+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][nen2660:2022] zich op focust. IMBOR neemt plaats in de "M1: Informatie model" laag.
@@ -26,13 +26,13 @@ IMBOR maakt gebruik van deze twee keuzes en probeert daarom zo goed mogelijk aan
In de sectie [IMBOR samenhang en hiërarchie](#imbor-samenhang-en-hierarchie) wordt de keuze en de interpretatie van het praktisch toplevelmodel toegelicht in detail. In de sectie [IMBOR in LinkedData](#imbor-in-linkeddata) wordt de toepassing van de LinkedData principes in detail toegelicht.
-In 2022 is de nieuwe versie van de NEN2660-2 vrijgegeven waaraan IMBOR zich committeert.
+In 2022 is de nieuwe versie van de [NEN2660-2:2022][nen2660:2022] vrijgegeven waaraan IMBOR zich committeert.
#### NEN3610
-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](#imbor-top-hierarchie). 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.
+De [NEN3610:2022][nen3610:2022] 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:2022][nen2660:2022] is reeds een relatie tussen de [NEN2660-2:2022][nen2660:2022] en de NEN[NEN3610:2022][nen3610:2022]3610 aangegeven. Het gaat hier alleen om een afstemming tussen de begrippenkaders. IMBOR heeft deze afstemming overgenomen in de [tophiërarchie](#imbor-top-hierarchie). Binnen IMBOR wordt daarmee zo veel mogelijk aangesloten op de semantiek van de [NEN3610:2022][nen3610:2022] (en daarmee de [NEN2660-2:2022][nen2660:2022]), maar wordt (nog) geen volledige sterke relatie met de rest van de norm [NEN3610:2022][nen3610:2022] beschreven. Er wordt zodoende ook niet beweerd dat er volledige compatibiliteit met de [NEN3610:2022][nen3610:2022] is (wel met de [NEN2660-2:2022][nen2660:2022]), 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:2022][nen3610:2022] 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:2022][nen3610:2022]) volledige toegepast in IMBOR als identificerende attributen.
#### MIM
@@ -52,11 +52,11 @@ In 2022/2023 zijn er gesprekken gaande tussen CROW, Geonovum en NEN om het in sa
#### 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. 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.
+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:2022][nen2660:2022] 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.
##### GWSW als referentiemodel
-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.
+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:2022][nen2660:2022] 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](#gwsw-relatie-toevoeging)
@@ -66,7 +66,7 @@ De NEN2767 en IMBOR hebben ook een lange historie. Veel gebruikers van IMBOR geb
##### NEN2767 als referentiemodel
-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.
+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:2022][nen2660:2022] 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.
#### BGT/IMGeo
@@ -74,7 +74,7 @@ De relatie tussen BGT/[IMGeo][9] en IMBOR is altijd noodzakelijk geweest. IMBOR
##### IMGeo als referentiemodel
-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.
+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:2022][nen2660:2022]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.
#### SOR
@@ -86,15 +86,15 @@ Er is nog geen definitieve versie van de SOR verschenen. Er is begin 2021 een
+#### TOOI
+[TOOI][15] 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'](https://standaarden.overheid.nl/tooi/waardelijsten/work?work_uri=https%3A%2F%2Fidentifier.overheid.nl%2Ftooi%2Fset%2Frwc_gemeenten_compleet) 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.
+
#### 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. 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.
+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:2022][nen2660:2022] bedoelt wordt.
##### QUDT als referentiemodel
@@ -122,7 +125,7 @@ Binnen IMBOR wordt geregistreerd hoe de IMBOR `Eenheid` uitgedrukt worden in QUD
#### GWSL
-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.
+GWSL moet het GWSW voor openbare verlichting worden, gebaseerd op het IMBOR framework (en dus de [NEN2660-2:2022][nen2660: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 `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:2022][nen2660:2022] gebaseerd en wanneer GWSL in een eerste versie gereed is zal het beheer ook door CROW gedaan worden.
Er is nog geen definitieve versie van GWSL verschenen. Er is in 2021 hard gewerkt aan een eerste versie.
@@ -146,7 +149,7 @@ De Basisregistratie Ondergrond (BRO) is een centrale registratie met publieke ge
#### CB-NL
-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.
+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:2022][nen2660:2022] 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.
#### IMGeluid
@@ -164,7 +167,7 @@ De Nederlandse CAD standaard (NLCS) is de CAD-standaard van de Nederlandse GWW-s
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
-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.
+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:2022][nen2660:2022] en de gedistribueerde vastlegging van informatiemodellen een feit is. Zodoende kan dan een sterke semantische relatie (mapping) tussen PIM en IMBOR gerealiseerd worden.
#### Wegbeheersystematiek
@@ -250,3 +253,6 @@ Dit betreffen de 'Domeinwaarden' die in de referentiemodellen onderscheiden word
[12]: https://www.aquo.nl/index.php/Hoofdpagina
[13]: https://www.crow.nl/getattachment/Thema-s/Wegbeheer-en-wegonderhoud/Wegbeheersystematiek/Keurmerk-beheersoftware-voor-wegbeheer/Afstemming-IMBOR-en-Wegbeheersystematiek-2019.pdf.aspx?lang=nl-NL
[14]: https://docs.geostandaarden.nl/cvgg/img/#detail_class_IMGeluidAlgemeen_Wegdektype
+[15]: https://standaarden.overheid.nl/tooi
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/imbor-top.md b/docs/techdoc/docs/imbor-top.md
index 75a24d0..8fedd97 100644
--- a/docs/techdoc/docs/imbor-top.md
+++ b/docs/techdoc/docs/imbor-top.md
@@ -1,10 +1,12 @@
## 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 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.
+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][nen2660:2022] en de [NEN3610:2022][nen3610:2022].
### 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 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.
+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][nen2660:2022] en de [NEN3610:2022][nen3610:2022] komen uit de [NEN2660-2:2022][nen2660:2022] documentatie zelf. Deze indeling zorgt ervoor dat voor alle IMBOR `Objecttype`n (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 `Objecttype`n` 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](viewer).
@@ -14,140 +16,23 @@ In onderstaand diagram is de top van de hiërarchie te vinden, met in kleur aang
-#### Definities in hiërarchie
-
-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
-
-
#### Totstandkoming
De uitgangspunten voor de totstandkoming van deze hiërarchie waren:
1. Hergebruiken wat er reeds is;
1. Aansluiten bij de meest recente versie van de standaarden;
-1. NEN2660-2 gebruiken als uitgangspunt, inclusief de daarin vermelde relatie met de NEN3610;
-1. Aansluiting eerst op de SOR (dan pas IMGeo), inclusief de daar in vermelde relatie met de NEN3610;
+1. [NEN2660-2:2022][nen2660:2022]gebruiken als uitgangspunt, inclusief de daarin vermelde relatie met de [NEN3610:2022][nen3610:2022];
1. Alleen de concepten vermelden waar gebruik van gemaakt wordt;
1. Meervoudige overerving is toegestaan;
-1. Alle ObjectTypen moeten een plek krijgen;
+1. Alle `Objecttype`n moeten een plek krijgen;
1. Termen en definities uit te standaarden hergebruiken (boven eigen gemaakte);
-1. Type relaties alleen degene uit toegestaan uit NEN2660-2;
-1. Vooralsnog alleen `Object`, `FysiekObject`, `Activiteit`, `GeometrischeRepresentatie` en `InformatieObject` gebruiken uit de NEN2660-2 (en in IMBOR2022 daar verder op in gaan);
-1. Verdeling van attributen over `Objecttype`n moet zo veel mogelijk gelijk blijven t.o.v. IMBOR2020-08 (afgezien van waar de koppeling al niet goed was);
+1. De gebruikte relaties alleen komen alleen uit de [NEN2660-2:2022][nen2660:2022], tenzij die niet in de behoefte voorzien;
+1. Dan geniet het gebruiken van bestaande relaties de voorkeur boven eigen relaties;
+1. Verdeling van attributen over `Objecttype`n moet zo veel mogelijk gelijk blijven t.o.v. vorige versies van IMBOR (afgezien van waar de koppeling al niet goed was);
#### Semantische relaties
-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:
+Ten opzichte van IMBOR2020-08 is de introductie van semantische relaties een grote verandering. Middels relaties geadopteerd uit de [NEN2660-2:2022][nen2660:2022] wordt het mogelijk gemaakt om tussen concepten binnen IMBOR betekenisvolle relaties te leggen. De relaties betreffen:
1. `isSubtypeVan` (NEN2660-2: Is een verbijzondering van)
1. `heeftDeel` ([NEN2660-2:hasPart](https://w3id.org/nen2660/def#hasPart))
1. `isVerbondenMet` ([NEN2660-2:isConnectedTo](https://w3id.org/nen2660/def#isConnectedTo))
@@ -157,12 +42,47 @@ Ten opzichte van IMBOR2020-08 is de introductie van semantische relaties een gro
1. `voertUit` ([NEN2660-2:executes](https://w3id.org/nen2660/def#executes))
1. `bestaatUit` ([NEN2660-2:consistsOf](https://w3id.org/nen2660/def#consistsOf))
+In IMBOR2025 zijn daar de volgende relaties bijgekomen:
+1. `heeftBetrekkingOp` (uit de NEN2660-1)
+1. `speelt` (uit de NEN2660-1)
+1. `isGeregistreerdMet` ([registratiegegevens](https://modellen.geostandaarden.nl/def/nen3610-2022/index.html#registratiegegevens) uit de [NEN3610:2022][nen3610:2022])
+1. `startNode` ([net:startNode](https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/7dde22fde631409957a445f97af5868299f2330e/net/net.ttl#L286) uit INSPIRE via [NEN3610:2022][nen3610:2022])
+1. `endNode` ([net:endNode](https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/7dde22fde631409957a445f97af5868299f2330e/net/net.ttl#L66) uit INSPIRE via [NEN3610:2022][nen3610:2022])
+
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+
+
+
-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.
+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`n niveau te leggen.
-### IMBOR Bouwstenen
+##### Inverse van 'heeftDeel' relatie
+In de [NEN2660-2:2022][nen2660: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 meta-model. Deze is de inverse van `nen2660:hasPart` en mag ook gebruikt worden op dezelfde manier, maar dan in de andere richting.
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+
+
+### IMBOR Bouwstenen
+
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.
@@ -183,33 +103,48 @@ Binnen de IMBOR cursus wordt uitgelegd wat de bouwstenen van IMBOR zijn. Deze Re
Binnen IMBOR zijn er een aantal modelleerkeuzes gemaakt die extra uitleg verdienen. Deze kunnen geschaard worden onder de 'informele' modelleerregels
#### Objecttypen
-`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 `Vakdiscipline`s.
+`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 kunnen worden en de 'concrete' `Objecttype` juist wel. `Objecttype` zijn als enige ook ingedeeld in `Vakdiscipline`s.
-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.
+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.
#### InformatieObjecten
-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.
+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.
-#### Gebiedsindeling
+#### Gebiedsindeling & andere afleidbare attributen
-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](#automatische-waarden).
+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.
-Op termijn zal gekeken moeten worden of de expliciete modelleering via de semantische relaties hier ook afdoende voor is.
+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][nen2660:2022]. Vele IMBOR-attributen behelzen namelijk (ruimtelijke) relaties tussen verschillende objecten (bijvoorbeeld tussen Ruimtelijke gebieden en Reële objecten).
-#### Automatische waarden
-
-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.
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
#### Classificerende attributen
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][1]. 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 `Objecttype`n 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.
+
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
#### Vakdisciplines
@@ -223,25 +158,132 @@ Ter verduidelijking: daadwerkelijke geregistreerde objecten (de instanties van `
#### Gekwalificeerde waardeshapes
-In de LinkedData versie van IMBOR wordt `sh:class` gebruikt om bij de [semantische relaties](#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][626] 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 de LinkedData versie van IMBOR wordt `sh:class` gebruikt om bij de [semantische relaties](#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_.
-[626]: https://github.com/Stichting-CROW/imbor/issues/626
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+
+#### Topologie & netwerkmodel
+
+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 ten behoeve van de vakdisciplines Riolering, Water en Wegen. 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][INSPIRE] die de [NEN3610:2022][nen3610:2022] voorschrijft. De [NEN3610:2022][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. De uitwerking van `imbor:RioleringNode` en `imbor:RioleringLink` in domeinspecifieke voorbeelden van netwerkelementen wordt ontleend aan IMBOR Stedelijk Water. In vorige versies van IMBOR waren dit de `imbor:TopologischeElement`en.
+
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
-#### Topologische elementen
-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](#gwsw-als-referentiemodel). Er wordt niet uitgesloten dat IMBOR in de toekomst zelf ook specificaties van topologie gaat maken.
+[INSPIRE]: https://www.geonovum.nl/geo-standaarden/inspire
+
+#### Temporele aspecten
+IMBOR implementeert vanaf versie 2025, in samenhang met de implementatie van [NEN2660-2:2022][nen2660:2022], de mogelijkheid uit [NEN3610:2022][nen3610:2022] om tijdlijnen voor de registratie van historische wijzigingen van objecten.
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+
+##### Modellering
+[NEN3610:2022][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][nen3610:2022] eigenschappen van de klasse `nen3610:Registratie`. De IMBOR-implementatie van deze temporele aspecten schippert tussen de [NEN2660-2:2022][nen2660:2022] en de [NEN3610:2022][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][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][nen2660:2022] als de [NEN3610:2022][nen3610:2022] als subproperty van `nen2660:isDescribedBy` wordt beschouwd.
+
+##### 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][nen3610:2022] en IMBOR adopteert dit volledig. Hoe de implementatie dan precies werkt wordt toegelicht in de [NEN3610:2022][nen3610:2022], maar specifiek voor graphs en IMBOR is een uitwerking te vinden in: [IMBOR best practice temporele aspecten](https://docs.crow.nl/imbor/best-practices/#nen3610-temporele-aspecten).
+
#### Materie
-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.
+Vóór IMBOR2022 werden materialen als attributen van Objecttypen vastgelegd. Binnen de [NEN2660-2:2022][nen2660:2022] is hiervoor een modelleerconstructie gegeven die IMBOR nu 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:2022][nen2660: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.
-Ter verduidelijkingL IMBOR limiteert niet welke relaties er tussen een `FysiekObject` en een `Materie` gelegd kunnen worden. We geven alleen 'voorstellen'.
+Ter verduidelijking IMBOR limiteert niet welke relaties er tussen een `FysiekObject` en een `Materie` gelegd kunnen worden. We geven alleen 'voorstellen'.
+#### 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](nen2660-1:2022). Omdat de [NEN2660-2:2022][nen2660:2022] hier geen standaard oplossing voor biedt, is er een in IMBOR een modelleerconstructie die conform de [NEN2660-1:2022](nen2660-1:2022) gemaakt is. Het gaat hier om de introductie van `imbor:Actor` (als subklasse van `nen2660:PhysicalObject`) en `imbor:Rol`. `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](#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:ProRail | imbor:speelt | ex:Beheerder123 | imbor:heeftBetrekkingOp | ex:Railsegment456 |
+| { .data } | | | | |
+
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+
+
+#### Hiërarchie van attributen
+
+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.
+
+
+
+
+ Zie ook gerelateerde issue(s) op GitHub:
+ 👇
+
+
+
+
+[viewer]: https://imbor-viewer.apps.crow.nl/
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
+[nen2660-1:2022]: (https://www.nen.nl/nen-2660-1-2022-nl-291666)
diff --git a/docs/techdoc/docs/inleiding.md b/docs/techdoc/docs/inleiding.md
index 4fb0b69..e472137 100644
--- a/docs/techdoc/docs/inleiding.md
+++ b/docs/techdoc/docs/inleiding.md
@@ -1,20 +1,20 @@
## Inleiding
-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][1].
+Het IMBOR uniformeert begrippen en concepten voor het vakgebied ‘beheer openbare ruimte’. Zie ook [over IMBOR][1].
-In 2021 is besloten om IMBOR te herzien n.a.v. een aantal ontwikkelingen:
+In 2021 is besloten om IMBOR grondig 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][2]
-* Het beschikbaar komen van de herziende [NEN3610][10]
+* Het beschikbaar komen van de [NEN2660-2:2022][nen2660:2022]
+* Het beschikbaar komen van de herziende [NEN3610:2022][nen3610:2022]
* De vraag om LinkedData versies van sectorstandaarden
* De bredere adoptie van het [MIM][8]
-* De adaptatie van het werken met ontologieën (vaak onder de noemer 'OTL's)
-* De vraag om afstemming tussen standaarden ([SOR][3], [IMBOR-NEN2767-4][4], [GWSW][7], [GWSL][5] en [CB-NL2.0][6])
+* De adaptatie van het werken met ontologieën (vaak onder de noemer 'OTL-en' of 'Informatie modellen')
+* De vraag om afstemming tussen standaarden (zoals [NLCS][6], [IMGEO][3], [GWSW][7], [GWSL][5] en [IMBOR-NEN2767-4][4])
* 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.
+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. 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.
+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.
### Normatief & informatief
@@ -31,27 +31,27 @@ Deze ReSpec is ingedeeld in secties. Alle secties zijn 'normatief' tenzij dit an
IMBOR Normatief & Informatieve onderdelen
-
- 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.
-
+>NOTE
+>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.
### 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 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/
+* 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.
+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).
#### 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][9] 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'.
+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][nen2660: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][nen2660: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][nen2660: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'.
-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](#referentiemodellen-1) 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.
+>NOTE "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][nen2660:2022]. Zodat zij hun software kunnen gaan 'vullen' met ontologiën zoals IMBOR en andere modellen die op de [NEN2660-2:2022][nen2660: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
#### Regie op standaarden
-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,
+Met de modellering van IMBOR op basis van de [NEN2660-2:2022][nen2660: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:
+* hun ontologie te baseren op de [NEN2660-2:2022][nen2660:2022] en de [NEN3610:2022][nen3610:2022],
* 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
@@ -64,14 +64,16 @@ Dit document is bedoeld als 'technische documentatie' rondom IMBOR. Het is dan o
>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][11].
-[1]: https://www.crow.nl/thema-s/management-openbare-ruimte/imbor/over-imbor
+[1]: https://www.crow.nl/Onderwerpen/Assetmanagement-en-beheer-openbare-ruimte/Data-en-informatie/imbor/
[2]: https://www.nen.nl/nieuws/normontwerp-informatiemodellering-van-gebouwde-omgeving-ter-commentaar/
-[3]: https://docs.geostandaarden.nl/disgeo/hiso/
+[3]: https://www.geonovum.nl/geo-standaarden/bgt-imgeo
[4]: https://www.nen.nl/nieuws/conditiemeting/eerste-stap-eenduidige-aansluiting-tussen-imbor-en-nen-2767-gezet/
[5]: https://www.linkedin.com/pulse/start-ontwikkeling-gegevenswoordenboek-stedelijk-licht-verhoeven?trk=read_related_article-card_title
-[6]: https://www.bimloket.nl/p/98/CB-NL
+[6]: https://www.digigo.nu/standaarden/nlcs/
[7]: https://www.crow.nl/thema-s/management-openbare-ruimte/imbor/de-relatie-tussen-imbor-en-gwsw
[8]: https://www.geonovum.nl/geo-standaarden/metamodel-informatiemodellering-mim
[9]: https://www.nen.nl/elasticsearch/?search=2660-2&sortmode=asc&viewmode=list
[10]: https://www.nen.nl/nen-3610-2022-nl-296137
-[11]: https://docs.crow.nl/imbor/modelleerregels
\ No newline at end of file
+[11]: https://docs.crow.nl/imbor/modelleerregels
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/licenties.md b/docs/techdoc/docs/licenties.md
index b6fd8f3..48e709d 100644
--- a/docs/techdoc/docs/licenties.md
+++ b/docs/techdoc/docs/licenties.md
@@ -30,4 +30,6 @@ De randsoftware (zoals de viewer en REST-API) wordt uitgegeven onder de [MIT][MI
[1]: https://docs.crow.nl/imbor/beheerplan/
[MIT]: https://opensource.org/licenses/MIT
[CC4]: https://creativecommons.org/licenses/by/4.0/deed.nl
-[ODC]: https://opendatacommons.org/licenses/by/summary/
\ No newline at end of file
+[ODC]: https://opendatacommons.org/licenses/by/summary/
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/mim-addendum.md b/docs/techdoc/docs/mim-addendum.md
index c44a11f..fa5f05a 100644
--- a/docs/techdoc/docs/mim-addendum.md
+++ b/docs/techdoc/docs/mim-addendum.md
@@ -2,7 +2,9 @@
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](https://docs.geostandaarden.nl/mim/def-st-mim-20201023/#metamodel-in-linked-data-ld). 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 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.
+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][nen2660: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.
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/docs/oagbd.md b/docs/techdoc/docs/oagbd.md
index afdb74e..6ea3417 100644
--- a/docs/techdoc/docs/oagbd.md
+++ b/docs/techdoc/docs/oagbd.md
@@ -14,8 +14,10 @@ Binnen het onderzoek is bij elke combinatie van klasse en attribuut in IMBOR2022
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][2] 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.
+De bovenstaande conceptualisering van objectlevensfases is ontwikkeld voor de onderverdeling van IMBOR-attributen. Binnen de [NEN2660-2:2022][nen2660: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][2].
+OAGBD kan dus gezien worden als een situatiespecifieke verbijzondering van de algemene wisselwerking tussen geplande en gerealiseerde entiteiten uit [NEN2660-2:2022][nen2660:2022].
[2]: https://www.nen.nl/nieuws/normontwerp-informatiemodellering-van-gebouwde-omgeving-ter-commentaar/
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
diff --git a/docs/techdoc/docs/samenvatting.md b/docs/techdoc/docs/samenvatting.md
index 7abaf28..9b180c7 100644
--- a/docs/techdoc/docs/samenvatting.md
+++ b/docs/techdoc/docs/samenvatting.md
@@ -1,10 +1,15 @@
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 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][nen2660: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][nen2660: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][nen2660: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 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.
\ No newline at end of file
+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.
+
+Zie ook de [CROW site over IMBOR](https://www.crow.nl/Onderwerpen/Assetmanagement-en-beheer-openbare-ruimte/Data-en-informatie/imbor/).
+
+[nen3610:2022]: https://www.nen.nl/nen-3610-2022-nl-296137
+[nen2660:2022]: https://www.nen.nl/nen-2660-2-2022-nl-291667
\ No newline at end of file
diff --git a/docs/techdoc/img/Bouwstenen_IMBOR_cursus_1.png b/docs/techdoc/img/Bouwstenen_IMBOR_cursus_1.png
index ad228cc..f254720 100644
Binary files a/docs/techdoc/img/Bouwstenen_IMBOR_cursus_1.png and b/docs/techdoc/img/Bouwstenen_IMBOR_cursus_1.png differ
diff --git a/docs/techdoc/img/Bouwstenen_IMBOR_cursus_2.png b/docs/techdoc/img/Bouwstenen_IMBOR_cursus_2.png
index 5a6fe34..0df0c95 100644
Binary files a/docs/techdoc/img/Bouwstenen_IMBOR_cursus_2.png and b/docs/techdoc/img/Bouwstenen_IMBOR_cursus_2.png differ
diff --git a/docs/techdoc/img/IMBOR-begrippen-structuur.drawio.png b/docs/techdoc/img/IMBOR-begrippen-structuur.drawio.png
new file mode 100644
index 0000000..c09a94b
Binary files /dev/null and b/docs/techdoc/img/IMBOR-begrippen-structuur.drawio.png differ
diff --git a/docs/techdoc/img/IMBOR-structuur.drawio.png b/docs/techdoc/img/IMBOR-structuur.drawio.png
new file mode 100644
index 0000000..2142709
Binary files /dev/null and b/docs/techdoc/img/IMBOR-structuur.drawio.png differ
diff --git a/docs/techdoc/img/IMBOR-top.drawio.svg b/docs/techdoc/img/IMBOR-top.drawio.svg
new file mode 100644
index 0000000..9b32a82
--- /dev/null
+++ b/docs/techdoc/img/IMBOR-top.drawio.svg
@@ -0,0 +1,2747 @@
+
\ No newline at end of file
diff --git a/docs/techdoc/img/IMBOR2022-top.drawio.svg b/docs/techdoc/img/IMBOR2022-top.drawio.svg
index dda4e63..1397634 100644
--- a/docs/techdoc/img/IMBOR2022-top.drawio.svg
+++ b/docs/techdoc/img/IMBOR2022-top.drawio.svg
@@ -1,55 +1,32 @@
-