IMGEO informatie wordt uit de transformatie gelaten about imbor

[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