IMGEO informatie wordt uit de transformatie gelaten

[RiX012]

IMGEO records zetten we niet over naar de ontologie (deze filteren we bij de transformatie er uit op basis van informatie uit de Access database. Dit is de relatie tussen de tabel [X_Informatiemodellen] en [X_ObjecttypesAttributen]. Deze gaat Jochem nog toevoegen (20191029)
Bijproduct is een Excel sheet met in kolom A de URI's van de IMBOR objecttypen en de naam in IMGEO

IMGEO is apart informatiemodel die we niet in de OTLBOR moeten willen onderhouden

[RiX012]

Afhankelijkheid van Jochem van InArea

[RiX012]

Ivm beslissing om IMGeo als mapping model op te nemen is deze heropend

[RiX012]

Vanwege de afhankelijkheid tussen BGT en IMBOR is 4e kwartaal 2020 besloten om de IMGeo-IMBOR mapping tabel uit de Access database om te zetten naar een LD-mapping model. De LD-versie van de BGT was een afhankelijkheid. Deze is begin november beschikbaar gekomen.

Bij analyse van de mapping tabel in Access bleek gebruik te zijn gemaakt van een praktijkrichtlijn van Geonovum (een uitbreiding op IMGeo). Deze is ontwikkeld om het horizontale berichtenverkeer mogelijk te maken (Geo gecombineerd met BOR). Dit betreft een product waarmee IMBOR types uitgedrukt kunnen worden in IMGeo (dus geen attributen e.d.). Dit product is echter niet uitgedrukt in LD (i.t.t. IMBOR en IMGeo). Om de mapping wel mogelijk te maken is deze file gecreëerd in deze pull request #123.

De mapping in SHACL bleek echter gecompliceerd door de manier waarop BGT-LD is neergezet. Zie ook deze uitleg van @NielsHoffmann. Er staat een vraag open bij Kadaster om hier verder in te duiken.

Van te voren hadden we reeds een verkenning gedaan of we een semantisch zwakke of sterke mapping wilden maken. De keuze was op SHACL gevallen omdat we daarmee alle mogelijkheden hadden, plus een sterkte mapping. SHACL (en ook OWL) lukt voorlopig niet, dus zijn we teruggevallen op een simpele maar sterkte mapping middels rdfs:subClassOf. Deze mapping is hier te vinden.

Wij verwachten dat dit mapping model voor de meeste usecases van nu afdoende is. Daarnaast is het mogelijk om de expressiever te maken met SHACL wanneer nodig en mogelijk.

@NielsHoffmann @nreyngou graag jullie beeld hierbij.

[RiX012]

Niet meer van toepassing vanwege IMBOR2022 (was issue voor IMBOR-LD 2020-08